Date:	Sat, 3 Dec 1994 17:20:48 +0900
From:	Stephen Turnbull <turnbull AT shako DOT sk DOT tsukuba DOT ac DOT jp>
To:	dj AT stealth DOT ctron DOT com
Cc:	djgpp AT sun DOT soe DOT clarkson DOT edu, dylan AT takoyaki DOT demon DOT co DOT uk, justin AT qdeck DOT com
Subject:	object file format change?

   Date: Fri, 2 Dec 94 16:42:18 -0500
   From: dj AT stealth DOT ctron DOT com (DJ Delorie)

   What do people think about changing the object file format from COFF
   to ELF for V2.0?  We would be able to make all the configurations 100%
   compatible with Linux to make things a lot easier, and get better
   debugging and linking support too.

Despite my comments below, I think I would go for ELF.  But does it delay
the delivery date for V2.0?

   The drawback is that all existing libraries will have to be
   recompiled, but is that such a bad thing?

Well, Quarterdeck finally got around to providing X11R5 and Motif
1.2.4 libraries only a couple of months back.  (In fact, after the
release of X11R6.)  Besides the fact that the Motif library is pretty
expensive (more than DESQview/X itself I seem to recall; further,
although the X11R5 lib is free, it does not provide source), recently
they also seem to be fairly unresponsive to 'small' and freeware
developers; who knows whether they'll be able to recompile their
libraries for us at all in anything like a timely fashion?  (Sorry,
Justin; but you know how long Dylan and I've been waiting for what we
need....)  While I expect that V2.0 will shake out most of the bugs in
a short period after initial release, I don't expect that it will come
out bug-free; this will cause further delays in something as complex
as what amounts to a complete interface to a new operating
environment.  So I would guess at least a couple of quarters after the
release of V2.0 before there would be a release of QDLIB and/or Motif
for V2.0 DJGPP.
    On the other hand, despite your sanguine attitude (in another
message) toward support of (non-X) programs in DV/X windows in V2.0,
it's not clear to me whether this is going to be easily done.  QDPMI
and DV/X apparently communicate through proprietary extensions to the
DPMI 0.9 standard (well that's what I was told, I don't know the
standard myself).  The alpha versions of the free DPMI "sort of" work
in a DV/X window, but if the reason they don't really work is due to
the proprietary extensions and not to a CWSDPMI bug?  If we have to go
with QDPMI, there won't be that much benefit (initially) to using
V2.0:  besides being idiosyncratic, QDPMI makes almost as large demands
on low RAM as GO32 does.  DV/X users may have to live with V1.x for a
while in any case.
    I guess basically what it comes down to is "how many users of
proprietary libraries are there out here?"  QDLIB is the only one I
use, and I personally can live with using V1.x for DV/X development
for the forseeable future (I can afford the space to keep several
separate development environments around), but I suppose there are
other such libraries, and certainly lots of people with much more
limited space.
    Stand up and be counted, folks!
    --Steve

- Raw text -