Message-Id:	<199605041802.OAA04875@mail-e2b-service.gnn.com>
Mime-Version:	1.0
Date:	Sat, 04 May 1996 14:07:14
From:	Jethro Wright III <Jetman AT gnn DOT com>
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
================================================================

- Raw text -