[Shrinker] Another landmine

Robert Baruch autophile at starband.net
Wed Dec 26 18:52:50 CST 2001


On 26 Dec 2001 12:46:33 -0800
Alexandre Julliard <julliard at winehq.com> wrote:

> But unlike EXC_CallHandler there is no good reason to do that, except
> to work around Shrinker stupidity. And for all we know there might be
> 20 more similar tests (and if not, they may be added in the next
> Shrinker version), which will lead to major code obfuscation. We will
> also most likely have a lot of trouble supporting the various -winver
> versions.

That was my initial worry. Altering Wine in specific ways just to trick
Shrinker will just make Wine that much less understandable. I can imagine
that other vendors could write their tools in a similar way, so that their
tools check for Genuine(R) Microsoft(TM) Parts(SM). Eventually Wine code
would be Microsoft code!

In addition, as you pointed out before, if there are other Shrinker
versions, there could be more checks to make, and thus more changes to
Wine.

> At this point I think it would be a better strategy to write an
> un-Shrinker tool that disables the most idiotic tests directly in the
> shrinkered binary. Thanks to the DMCA, this should probably be done by
> someone living outside the US...

Well, there's still that SHRINKER.VXD thing under 95/98. If that VXD does
not check for specific Microsoft code, then there could be success in
emulating it and adding to Wine's "VXD toolbox". Of course, if that VXD
contains the "copyright unprotection" code, then emulating it would also
be a violation of the DMCA. But I'm up for a little civil disobediance :)
OTOH, although IANAL, the interoperability clause of the DMCA (section
103f) could be an out.

--Rob




More information about the wine-devel mailing list