tonyb@titania.juliet.ll.mit.edu ( Tony Berke) (03/22/91)
OK, there are probably lots of old postings on this subject, bit I'm not sure how to get at them. Here's the question: A little note in the README file of my newly acquired C++ says something to the effect of 'C++ only supports windows protected-mode target files'. 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. That's all very nice, but it would seem to preclude writing mass-market applications using the product. Please let me be wrong on this... I *really* don't want to have to keep using the SDK and C. Any trick workarounds (that don't look as ugly as the real thing) ? Thanks, Tony Berke (email -- tonyb@juliet.ll.mit.edu)
oneel@heawk1.rosserv.gsfc.nasa.gov ( Bruce Oneel ) (03/22/91)
Windows runs in 3 modes. 1. Real Mode. Minimum of an 8088/8086 and 640k of memory. Very similiar to windows 2.x. 640 k of memory, limited use of EMS. 2. Standard Mode. Minimum of 80286 and 1 meg of memory. 16 meg of memory maximum. Multitasking windows apps if they are written correctly, dos sessions in full screens, but you can switch from one to another. 3. Enhanced mode. Minumum of 80386 and 2 meg of memory. Virtual memory, dos programs in windows, multitasking. Technically, bc++ only produces standard and enhanced mode apps. The limitation seems to be tlink. If you put REALMODE in the .DEF file you can force the application to be runable in real mode. Borland doesn't currently guarantee this to work properly and wants you to pay close close attention to any tlink warnings. This is from Sidney@borland.com or sidney on CI$. Until recently I had a 8086 with 640k and I was able to build all of the demo programs and run about half of them. I did put REALMODE in the .DEF files and sometimes got complaints and sometimes not. The existance of warnings didn't coorelate with the application running properly. Now my opinion. It isn't too big a deal. Windows in real mode is so so slow that I can't imagine it being used too often. Borland claims (and this is kind of supported in that the only mention of this limitation is in the read.me file) that this was a list minute bug which wasn't fixed to their satisifaction before shipment. They imply that it will be fixed. I think you might be able to use the linker from the SDK or the Supplimental compilers disk from Microsoft in place of TLINK and get away with real mode applications though. Just my thoughts. bruce -- representing no one. -- | Bruce O'Neel | internet : oneel@heasfs.gsfc.nasa.gov| | Code 664/STX | span : lheavx::oneel | | NASA/GSFC |compuserve: 72737,1315 | | Greenbelt MD 20771 | AT&Tnet : (301)-286-1119 |
johnm@spudge.UUCP (John Munsch) (03/23/91)
In article <TONYB.91Mar21152525@titania.juliet.ll.mit.edu> tonyb@titania.juliet.ll.mit.edu ( Tony Berke) writes: >Here's the question: A little note in the README file of my newly >acquired C++ says something to the effect of 'C++ only supports >windows protected-mode target files'. > >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 ?? "Protected mode" refers to Windows programs that run in Standard or Enhanced mode. That means that you will be limited to 286 and 386 platforms rather than just 386 machines. Considering how few apps really run in real mode Windows this probably isn't a problem for you, I know it isn't for me. >Please let me be wrong on this... I *really* don't want to have to >keep using the SDK and C. Any trick workarounds (that don't look as >ugly as the real thing) ? You're wrong, feel better now ;-) John Munsch
ebergman@isis.cs.du.edu (Eric Bergman-Terrell) (03/25/91)
With BC++ 2.0 you can just can't write applications that run in real mode. Standard and 386 Enhanced modes are fully supported. So your programs will only require a '286 or above. Terrell
ebergman@isis.cs.du.edu (Eric Bergman-Terrell) (03/25/91)
I've ordered the Compilers Utilities Disk from MicroSoft to see if the linker on the disk can be used with BC++ 2.0 to produce real mode applications. I'll post the results. BTW the compiler utilities disk is a freebie from MicroSoft... Terrell
strobl@gmdzi.gmd.de (Wolfgang Strobl) (03/31/91)
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 <std.disclaimer.hpp>