Message-ID:	<32850222.2CAC@ananke.amu.edu.pl>
Date:	Sat, 09 Nov 1996 23:13:54 +0100
From:	Mark Habersack <grendel AT ananke DOT amu DOT edu DOT pl>
Reply-To:	grendel AT ananke DOT amu DOT edu DOT pl
Organization:	Home, sweet home
MIME-Version:	1.0
To:	Samuel Vincent <svincent AT zippy DOT sonoma DOT edu>
CC:	Leendert Combee <combee AT cambridge DOT scr DOT slb DOT com>, djgpp AT delorie DOT com
Subject:	Re: Adding Windows Support?
References:	<Pine DOT GSO DOT 3 DOT 94 DOT 961109025749 DOT 10484A-100000 AT zippy>

Samuel Vincent wrote:

> > Let's hope it won't take too long...
> 
> Well, I've got Visual C++ 4.0 with all the headers and everything.
> I'd love to give it a whack, but I'm not sure how I would go about doing
> so.  I'm afraid adding DLL support to DJGPP would be out of my league.  To
> be a true win32 compiler, one would have to be able to handle dll's in the
> linking stage along with being able to target to a DLL.  The switch
Handling DLLs in the linking stage is a part of the PE format. It
contains special section that holds all the information needed to do
dynamic linking at the load time. The problem with DJGPP (and, for that
matter, with gcc in general) is that it does not produce stack probes.
Another problem is the LD. It does not output relocations - this has
been patched by Cygnus, and since LD is GNU we might use it the patch
freely. Having these two things done, we don't have to worry about DLL
linking anymore. The only thing left would be to add import libraries -
M$ 32-bit compilers use the same AR format for their libraries, so it
should be easy to pick what they look like (I mean the records in them)
and implement it in DJGPP.

> between object code formats would make things difficult.  I would vote to
No, I don't think it would make things that difficult. Someone (Malcolm,
I think) suggested three solutions to this problem earlier in this
thread. I think that the best way (and as Malcolm said, the most
elegant) would be to modify LD to output PE executables.

> create a whole new project such as DJGPP-Win32, or something similar.  We
> could then work exclusively in microsoft's object format.  If you want DOS
I think that'd be too much struggle, not worth the effect. DJGPP already
is a 32-bit compiler, it outputs COFF objects (just as M$ tools do) and
lacks only three elements to be able to produce true-blue WinXX 32-bit
apps.

> + DPMI, use DJGPP (A Great Package!), if you want win32 functionality, use
> DJGPP-Win32.  (Now if we wanted more than the standard console library
Wouldn't it be great to be able to use the same executable for both
targets?

> functions and so didn't use DJ's libraries, and DJ didn't want to work
Speaking of libraries, I've just yesterday started to compile and
possibly convert the libc functions to Win32 API.

> Who would be interested in this attempt?  The difference between this and
> gnu-win32 would be libraries that aren't GPL'd.  We could distribute it as
> DJGPP is done, with our own library functions, making it free to use for
> commercial as well as other projects.
I'd love to join the developement. I think that a separate mailing list
would have to be necessary. Maybe it could be merged with that of DLM,
Ilya? But I'd vote not to create a completely new compiler port, but to
merely (sic!) adapt DJGPP to produce Win32 PE executables.

mark

-- 
**************************************************************************
You tell me I'm drunk then you sit back and smug a while convinced that
you're right, that you're still in command of your senses. I laugh at
your superior attitude, your insincere platitudes will make me throw up.
The sooner you realise I'm perfectly happy if I'm left to decide the
company I choose.
********************** http://ananke.amu.edu.pl/~grendel
*****************

- Raw text -