Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!uunet!math.fu-berlin.de!opal!unido!gmdzi!strobl From: strobl@gmdzi.gmd.de (Wolfgang Strobl) Newsgroups: comp.windows.ms.programmer Subject: Re: Borland C++ target hosts Message-ID: <4425@gmdzi.gmd.de> Date: 30 Mar 91 16:46:06 GMT References: Distribution: comp Organization: GMD, St. Augustin, F.R. Germany Lines: 32 tonyb@titania.juliet.ll.mit.edu ( Tony Berke) writes: >I've noticed what appear to be follow-ups on this issue, but not the >answer to the basic question: Can I only write Windows programs that >will run on 386's ?? If that's true, I assume it has to do with >Windows' bogus memory management scheme, and Borland's desire to make >it a non-issue. [...] Don't assume that everything you don't understand is bogus. Windows memory management is built in a way which allowes moving around memory blocks behind the back of the program. This is a usefull and necessary feature. Its implentation is based upon the segmented architecture of the processor. Unfortunately, it requires some cooperation from the programmer (proper locking and unlocking of memory segments), because the 8086/88 processors implementation of segmentation is too simplistic: segments are adresses, not names (indizes) of addresses, which makes it impossible to move around something a far pointer (a segment/offset pair) points to, without changing the actual segment register content. On the 80286 (and above) in protected mode, this is different, now segment registers point to descriptors, which in turn point to memory. This makes it possible to reorganzize memory without the programs cooperation. The nice think is that no code changes are necessary for a Windows application to run in protected mode. Only the necessity for proper memory locking/ unlocking has gone, if you don't care whether your program still runs in real mode. Obviously, the whole memory management has been designed for the protected mode of the 80286 up processors, which required quite a lot of foresight, in my opinion. Wolfgang Strobl #include