Mail Archives: djgpp/1992/02/06/22:33:48
Yes, if someone has already created a 16-bit helper segment to act as
the interface to Windows, then you could use djgpp to develop Windows
programs. The 16-bit helper segment would contain everything that
calls Windows directly. The 32-bit code would call out to the 16-bit
code to access Windows. Then you would be left with the problem of
loading the a.out.
I wonder how this might be done. It's the same sort of thing one would
have to do to run go32 programs under DPMI 0.9. I'm not sure how to
make the data appear in the right place in the address space. I think
it says in one of DJ's documents that data usually appears at 0x400000,
but of course in the file it appears at some other arbitrary offset.
Likewise for the text. So, the text and data segments would have to be
mapped completely differently. That's not a problem if there's no data
in the text or no code in the data. One problem is that it seems
likely we would need a negative base for the data. We get a 32-bit
memory block from Windows/DPMI 0.9 at address X into which we load the
a.out. The data appears at offset Y in the file. We want
(DS base)+0x400000 == X+Y, or (DS base) == X+Y-0x400000, where it's
likely that X+Y < 0x400000. Can 32-bit segments wrap around the end of
memory? We'd also be taking advantage of Windows' lax memory
protection. The other problem is that Unix code assumes that data and
stack addresses can be used interchangeably, so the SS base must be the
same as the DS base which implies that the relationship between the two
is fixed once the program starts running. I.e. the physical size of
the heap has to be decided ahead of time.
I'd like to be told that my reasoning is wrong and that there's a
better way to do this, but if my assumptions are correct I think things
would look this way. Maybe it's not so bad.
- Raw text -