>>>windows/development 4237 geoffc(1212)7jun92 15:32 c4202*

>		       but to stop the competition from getting their
>hands on the programs & disassembling the code.

Are you saying that you have a copy protection scheme that prevents a PC
from actually reading the distribution disks?

There is a persistent belief that disassembly means running the code under
a debugger to see what it does.  The relevance of this to a Windows
conference is the discovery that my copy of WIN.COM (and presumably every
one else's) contains some 2KB of code and space designed to trap attempts
to run Windows under a non-DOS.  The code is real gobbledy-gook with lots
of redundant instructions to make it seem confusing and a crucial part is
encrypted.  Most significantly, it installs handlers for the debugger
interrupts (and NMI just in case you're using a sophisticated debugger)
that are guaranteed to cause the unexpected should anyone attempt to step
through the code.

As far as I know, this is Microsoft's first stoop to the practice.  Does it
indicate defensiveness on their part or mere curiosity?

My WIN.CNF (that SETUP copies to the SYSTEM subdirectory) is 16,112 bytes
long - stamped 10/03/92 at 3:10.  Would anyone with a different file please
let me know.

-- Geoff --
>>>windows/development 4241 djewell(223)8jun92 11:36 c4237*
Geoff :- this sounds very interesting ! When you say   

> designed to trap attempts to run Windows under a non-DOS  

do you mean:  

> designed to trap attempts to run Windows under a non-MS DOS  

Dave (intruiged.....) 
>>>windows/development 4243 geoffc(3013)8jun92 17:04 c4241*

I don't know what I mean, but I reckon that every now and then I turn up
something of reasonable interest.  The story goes like this:

The copy of WIN.COM that I have inspected is very interesting on a number
of counts.  Towards the end of the WIN.CNF component is some disguised
code that checks to see that a standard MS-DOS is running

 1. In the internal variable table (address obtained by int 21h
    function 52h), far pointers to the Handle-based SFTs, the standard
    input device, the standard clock device, the BUFFERS descriptor,
    the CDSs and the first device driver after NUL must all be non-zero.

    This would be the case for MS-DOS, but it is my vague understanding
    that it has not always been true for the OS/2 compatibility box.

 2a. If a redirector is running (int 2Fh with AX = 1100h returns al = FFh),
     then the upper case mapping routine (sought, curiously enough, only
     for country = US) must lie in the DOS kernel data segment (value
     returned in ds by int 2Fh with AX = 1203h)
 
     OR
  
 2b. Without a redirector, the offset address of the FCB-based SFTs must
     be zero.

     Again, both these are normally true for MS-DOS.

The checks in 2a and 2b are encrypted (just a bitwise XOR) - the relevant
section is bounded by "AARD" on both sides (and we all know which MS
employee this suggests).

For the whole test, interrupt vectors 01h, 02h, 03h are directed to a
stub containing either int 21h or int 2Fh (depending on when) followed by
an IRET, so single-stepping through this code or setting a break point or
whatever will have curious effects (calling DOS functions when registers
can't be known).

The code is littered with red herrings - long and convoluted operations
whose results are discarded - the whole style seems deliberately perverse.

In the WIN.COM copy I've inspected, the code is executed but not acted
upon (the message "non-fatal error #2761, contact Windows 3.1 beta support"
or similar, with a press ENTER to exit, "c" to continue) unless a
particular variable is non-zero.  Static allocation has this variable as
zero and it is not referenced anywhere else in the file.

Two things.  First, this copy of Windows is on a machine to which I have
access but I do not know its provenance.  It is hard to see where they
could have got a beta version from, though.  If the thing were for beta
release only, it would have been stripped from the file rather than let
it depend on a variable at run-time, surely?  My guess (perhaps a little
suspicious) is that Windows Setup patches the file in some circumstances.

Second, I don't believe the whole thing to be a red herring, because I
have seen a beta copy of HIMEM.SYS in which the code was active (and to
prove it, I have a device driver that sets a temporary FCB-SFT with
non-zero offset address to trigger the effect).

The whole thing is very odd!

May I refer you to the digest topic for a word or two on what must be the
worst example of MS programming I have ever seen?

-- Geoff --
>>>windows/development 4247 thines(218)9jun92 15:09 c4243*
What you describe is in the current release copy of Win 3.1 that I've
got here, including the "Please contact Windows 3.1 beta support"
message!  (The error number in my copy is #2726)

Verrry interesting :-)

| Tim |
>>>windows/development 4248 geoffc(305)9jun92 15:36 c4247
Thank you for the confirmation.  I would really like to know how to
proceed with this morsel, for I too find it interesting and am sure
that one or two industry watchers would also.  Most of the DOS bugs I 
know are going into my book but it's a little difficult to stretch
this to Windows.

-- Geoff --