Message-Id: <199605041802.OAA04875@mail-e2b-service.gnn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 04 May 1996 14:07:14 From: Jethro Wright III To: djgpp AT delorie DOT com Subject: Re: MSDOS-compatibility (OBJ-files etc.) [snip] >In general, object code format are not compatible between >compilers. I haven't tried this for several releases of Borland and >Microsoft, but in the past I had to be careful when switching back >and forth to get rid of all object code and libraries. This meant >that there were 5 different versions of our image compression toolkit >on one release (Microsoft 5.1 and 6, Borland C++ 2.0, 3.0, and 3.1). Actually, most compiler vendors will *tell* you this in the documentation, *if* one bothers to read it. The principal problem centers around "helper" subroutines, little compiler-specific, do-hickeys that assist for things like inline type conversion/promotion/demotion. >Major releases are often not compatible with the previous release. >This seems to have improved somewhat, the actual code seems stable, >but debug info is still changing between releases. Again, most compiler vendors tell you this. Recently (in the past three years), Borland and MSOFT have really revamped their systems, first to implement their initial native C++ compilers, then to bring on stream new flat 32-bit capabilities. And as far as I know, 16-bit and 32-bit .OBJs aren't compatible at all, even in the same executable made w/ the same compiler. : I also have no idea how djgpp's protected mode would conflict with : real-mode programs then. To be honest, this DPMI-stuff still baffles me : (no modes? hmmm...). I also dislike having to use some sort of : DPMI-manager all the time... can't djgpp be used to use (16 bit) : real-mode programs as well? That would be handy in terms of : MSDOS-compatibility. Richard: This is not at all possible. MSDOS' legacy is that it was written before a prot mode x86 was widely available. Hence, MSOFT *and* IBM did many bad things from a prot mode compatibility perspective. The 1st problem was the use of the 1st 32 sware intr vectors, which are reserved exclusively for the CPU on the 286 and up. Therefore, in order to use DJGPP, you'll have to become DPMI aware and acquire a copy of the DPMI 0.9 spec from Intel's FTP site. It isn't too bad, really. You can easily use the DPMI simulate real mode sware intr sub-fn, to access most of MSDOS/BIOS, w/ very little trouble and there are a few, well-commented examples of how this is done ref'd in the FAQ (Martynas K's keyboard trap demo is one good starting place.) ================================================================ In Paris, they simply stared when I spoke to them in French; I never did succeed in making those idiots understand their own language. - Mark Twain, The Innocent Abroad,1869 ================================================================