From: Charles Sandmann Subject: Re: Virtual memory file mapping? To: MRMILLER AT delphi DOT com (Martin R. Miller) Date: Wed, 7 Dec 1994 21:14:48 -0600 (CST) Cc: djgpp AT sun DOT soe DOT clarkson DOT edu (DJGPP Mailing List) > Sorry I keep getting DPMI and non-DPMI modes confused -- as I prefer > and usually use the latter, and tend to forget about all the > limitations imposed by the first. Currently non-DPMI is superior for almost all tasks. DPMI support was added into GO32 in V1.10 to allow running under Win 3.1 and OS/2. It was not a particularly good match - the original Japanese concept used a completely different DPMI-only GO32 since there was very little code overlap. I have learned alot since then, DJ and other contributors have offered some excellent ideas. The current running V2 is faster than non-DPMI V1.x, if that is a concern, for virtually everything. It also has a well defined structure which will allow adding features like signals which have been lacking. It will be much more maintainable and easy to extend (anyone looked through all the code in GO32 lately?) There will only be a single run mode (DPMI) which will eliminate a lot of the bugs in one mode but not the other. > As a simple experiment, I compiled the following C++ file "huge.cc" > Running the program takes < 1 sec at my normal DOS (non-DPMI enabled) > command-line, but around 26 secs at a DOS prompt shelled-out from > within Windows (ie, under DPMI mode). The additional time, I assume, > is because the whole executable is being read in (and maybe back-out > again into a swap file). This is a bogus test. Yes, in DPMI mode you read the entire exe file in at the start of the program. Under V1.12 non-DPMI you only read in the pages you touch. Modify your program to read every element in the array and then compare the times. BTW, V1.x DPMI loads the image 4096 bytes at a time, V2.x loads it 60Kb at a time, which once again cuts the time. Since each pagefault in V1.x non-DPMI mode only reads 4K (or 8K) at a time, V2 images actually can do real work faster than V1.x images. > There has also been other discussions in the list regarding the lack of > graphics support, etc, in DPMI mode. I'd really hate to see the linear > graphics memory access go away, :-(, which to me is almost as good > having the 32-bit addressing and many other cool features of djgpp. We are discussing having some sort of support for page fault emulated linear graphics in the free dpmi provider or under DPMI 1.0 providers. Since graphics are not finalized, it may go either way. But if you rely on this feature, you will never be able to run under any future operating system like Windows 95, all of which require DPMI to access protected mode. It makes your programming more convenient now, but it is somewhat slower and will be much less "portable" in the future. > Why all the slavish devotion to DPMI (which sounds like it's only going > to intensify in V2)? Besides a lot of limitations, what exactly does it > buy? At least now one more-or-less has the option. A single documented API which is supported by many vendors (IBM OS/2, Windows 3.0, 3.1, NT 3.1, NT 3.5, 95, QEMM/QDPMI, 386MAX, and others). A single "emulation" layer; all of the libc code lives in GCC/GAS code and nothing to be maintained in TCC/16 bit code. Speed and maintainability. New features and extensibility. The only disadvantage is that you are somewhat at the mercy of your DPMI provider. This is why I have chosen to write a DPMI provider and make it available with source. All the GO32 hackers out there will feel right at home if they want to add custom features. Having the equivalent of "GO32" being 49K instead of 180K, being reentrant (one shared copy) I think is more attractive than the current setup anyway. Or better yet, under an advanced OS, you don't need this code at all, it is provided by the OS. With source availability, I am convinced the free version will become superior to anything commercially available!