Mail Archives: djgpp-workers/2006/05/12/06:48:56
Message included below..
What might be the reason for these bounce messages that I
tend to get only on the first attempt to post? (It has
happened a number of times.)
djgpp-workers AT delorie DOT com
SMTP error from remote mailer after initial connection:
host delorie.com [207.22.48.162]: 500 Your IP address 213.250.81.161 doesn't resolve to a name
Return-path: <djgpp-l AT aw DOT gs>
Received: from localhost ([127.0.0.1])
by dynamite.narpes.com with esmtp (Exim 4.43)
id 1FeV4x-000CU7-Iy
for djgpp-workers AT delorie DOT com; Fri, 12 May 2006 10:41:03 +0000
Date: Fri, 12 May 2006 10:41:02 +0000 (GMT)
From: "A. Wik" <djgpp-l AT aw DOT gs>
To: djgpp-workers AT delorie DOT com
Subject: Re: DJGPP ELF
In-Reply-To: <20060511182531 DOT 89322 DOT qmail AT web42207 DOT mail DOT yahoo DOT com>
Message-ID: <20060512083723 DOT V2491 AT dynamite DOT narpes DOT com>
References: <20060511182531 DOT 89322 DOT qmail AT web42207 DOT mail DOT yahoo DOT com>
On Thu, 11 May 2006, Daniel Borca wrote:
> Some points for switching to ELF were:
> 1. reduce the size of executables
> 2. get rid of that Fat DS stuff (that is, use True Flat)
> 3. circumvent the DXE3 limitation for variable access
> 4. ET_DYN (not necessarily ET_EXEC) compatibility with Linux
> 5. easy upgrade (although module versioning is NYI)
> 6. debugging of shared objects (NYI)
> 7. DXE3 unresolveds against libc must be added by hand
> (a nightmare for extensible applications like PythonD)
> 8. I forgot... :)
>
> Yes, number 7 was _that_ bad. Manually exporting certain
> symbols to satisfy DXE3 is tricky. Required symbols slightly
> change, in a way that's invisible to the user, depending on
> gcc version, DJGPP release etc.
>
> DXE3 was only a home-breed workaround for dynamic linking,
> and somehow I could still find software floating over the
> net using it (not for the sake of it, but because there was
> nothing better).
As nice as it may be to avoid the duplication of code
implemented in DLLs, and upgrade one library file rather
than a thousand executables, let's not forget the problems.
Such as attempting to take advantage of the ease of
upgrades, and breaking large numbers of binaries, some of
which may be critical, requiring a restart with a bootdisk.
While I can't imagine a DOS system becoming so dependent
on DLLs, it's easy to do with Linux. At other times, the
conflicts are subtle enough that the X11 server will run,
only to crash without warning in a few hours or days,
having generously given you the time to open a few dozen
windows with various amounts of unsaved work...
-aw
- Raw text -