Date:	Sat, 1 Apr 1995 11:51:38 -0800 (PST)
From:	".ASM SoftWare Systems" <rdc AT freenet DOT vancouver DOT bc DOT ca>
Subject:	Re: [?] GCC produce Portable .binaries - Was: 286, 88, 6502 Xcompile
To:	DJ Delorie <dj>
Cc:	UCKO AT vax1 DOT rockhurst DOT edu, ah230 AT leo DOT nmc DOT edu, djgpp AT sun DOT soe DOT clarkson DOT edu

On Sat, 1 Apr 1995, DJ Delorie wrote:
> >rdc AT freenet DOT vancouver DOT bc DOT ca wrote:
> 
> >  Portable .binaries ???
> > 
> >  What would the procedure be to compile a program using gcc (djgpp's)
> > under MSDOS (without adding go32 to it) and permit it to operate correctly
> > on Solarus, BSD, etc ... - Any system that used an X86 (x > 2) .
[tiny snip] 
> > I (obviously ?) would be prepared to link in a .library for each OS I
> > intended to support and to test for the OS name a the start of the program.
> 
> The problem is that the headers are different too, like different
> structure layouts and constants and such.  You do have to recompile.
> Things like "struct stat" are OS dependent, and scattered throughout
> the application's code.

I can appreciate that if I wished to know the last modifed time _AND_
the creation time of a file (and they differed) that MS-DOS would return the 
same value (false info) for both ...

We (_I_) do this now with djgpp to support some huge "stat" structures ...
I have guessed (succesfully) what some of the obscure things were for and
emulated (or ignored) the thing for MSDOS...


I can appreciate that if I access my HD by inodes I will have to create
a 'map' of either how it would be for MS-DOS _or_ use the inodes as an
index into a random file (ugly?) ...



_IF_ supporting multi-platforms (with minimal programmer effort) is something
desirable (we _MAY_ not agree on OS but we know where to get the most 
Mips/$ - the x86 line (and it's clones - Cyrix/AMD/etc) ) should we make
it possible ....


Above, I requote, "things ... are OS dependent, and scattered throughout" ...
Should OS dependent "things" be scattered throughout ?


Thanks for answering my question though.


Hmmmm....

C++ functions can accept parameters of different types and call the 
appropriate function for the type and return the appropriate type too.
Built-in ...

Unfortunate that we can't un-ifdef the source a bit (more of a gcc problem
than a djgpp problem - I understand you are Dosifying a Unixy program) ...
 and
concentrate the OS specific parts into an OS specific lib and other
parts that are NOT OS specific can go in thier appropriate libs ...



We can similarly (and {obviously} grossly different) use a '386 with _OR_
without a MathCo and djgpp programs run the same ...

It makes no difference whether you support MathCoprocessor specific calls
(by having a math chip) or not it you have a X86 (x>2) your OK ...

This is the case where a CHIP is missing ...
Not "just a (er... ) few (swallows) system calls" ...



Synopsis:

It's too bad I can't do it with 100 lines of code and linking in
5 different libs ...

The "scattering" is not great news either ...


I can accept that the _END_ of the branch would have many leaves ..
Why can't the tree have _ONE_ trunk ?

A last minute idea you'll enjoy adding to V2 ;>


 
> > Would 'emulator' support be an idea ?
> 
> If you emulate MS-DOS and DPMI, yes.  You can already do this under
> Linux, OS/2, and NT.
> 
This _IS_ _Great_ news ...
Though one (some) _might_ _expect_ these things ...


So if V2 has it's own DPMI and the O/S is prepared to emulate MS-DOS
('386(+) and all) then you would not need DPMT ???

Or would DJGPPs DPMI conflict with another DPMI (Qemm warns that other
implementations may not co-exist co-operativly, sometimes, EG: Wimpows'
{or was that 'Snow-US-too''s} less than DPMI ) ...

- Raw text -