Re: Apple Drops Backward Compatibility for Next MacOS

[andrey@alumnae.caltech.edu (Andre T. Yew)]

nathan@visi.com (Nathan Mates) writes:

>   That 640K problem is a limitation of MS-DOG. With the 286 series of
>chips that could easily address 1MB of ram, Mickeysoft had a perfect
>opportunity to shatter the 640K barrier, letting programs use RAM as
>much RAM as they could on the machine. However, in putting the
>"backward" in backward compatability, they decided to cripple DOS on
>the 286, the 386, the 486, the Pentium, and the Pentium Pro. STUPID
>move. You can break a few things once that assume 640K only, or you
>can cause enough headaches for the next 15+ years to get a subsidy from
>Tylenol.

	Hi Nathan,

	As a daytime Win32 developer, let me expand on what you just said.
The 640 kB limit is only the tip of the terrible dungheap known as MS
backwards compatibility.  For example, in Win16 (everything before Win95
and after Win 2.0), a single selector (what the real mode segment mutated
into) can only address 0xff0000 bytes or 16 MB - 64 kB of memory.  Why is
this?  It turns out that a selector can really only hold 64 kB of memory
for backwards compatibility reasons (real mode segments could address only
a 64 kB window), so Windows would chain together a whole bunch of 64 kB
selectors to make up almost 16 MB.  However, they made the first selector
a special selector that is used to access the rest of the chain, and allocated
only a byte as a selector count, hence the 0xff0000 limit:  255*64 kB.
It gets worse from here:  it turns out that the chain of selectors must be
contiguous slectors in the selector table to accomodate pointer arithmetic
in C.  This is so you can increment a pointer, for example, without having
wacky relocations in every part of a program.  This way, they'd do what x86
real mode programmers have been doing to increment a pointer through a region
larger than 64 kB:

1.  Increment 16-bit offset.
2.  Check if offset == 0
3.  If so, then increment selector
4.  If not, go on.

	This becomes a problem when you realize that there only 13 bits worth
of selectors, and some two thousand are taken by the time you start Windows.
If you don't have enough contiguous selectors to tile the memory space you
want to allocate, the allocation will fail even if you have more than enough
memory to fulfill the allocation.  Therefore selector fragmentation becomes 
a very real problem and is generally intractable.

	Having said all that, the Win32 environment is much nicer to develop
in and is quite protected --- I've crashed large Win32 apps and my Windows 95
machine recovers quite nicely.  It has a flat memory space, using the full
memory addressing capabilities of 32-bit selectors.  The only time I lock the
machine up is when I try to do somewhat fancier things involving semaphores
and shared memory DLLs, and devices like serial ports.  UNIX is still better
but not great at keeping processes like that under control.

--Andre

P.S  toddpw says hi.

--
PGP public key available