On 26 Dec 2001 12:46:33 -0800 Alexandre Julliard julliard@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