www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1996/10/19/16:03:26

From: "John M. Aldrich" <fighteer AT cs DOT com>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: loader bug?
Date: Sat, 19 Oct 1996 01:19:16 -0700
Organization: Three pounds of chaos and a pinch of salt
Lines: 52
Message-ID: <32688F04.1FE8@cs.com>
References: <32682D18 DOT 1213 AT Tek DOT com>
Reply-To: fighteer AT cs DOT com
NNTP-Posting-Host: ppp104.cs.com
Mime-Version: 1.0
To: Phil Galbiati <Philip DOT S DOT Galbiati AT Tek DOT com>
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

Phil Galbiati wrote:
> 
> When I tried to run a djgcc-compiled program on a DOS6.22/Win3.1
> machine which had no DPMI server (I had forgotten to copy
> CWSDPMI.EXE to it), it printed the following message:
> 
>    Load error: no DPMI
> 
> The bug is that it printed it to stdout, and since I had redirected
> stdout to a file, I didn't see the error message.  Shouldn't it have
> been printed to stderr?

The code which prints those error messages at runtime is contained in a
2K real-mode stub that is written in assembly.  The stub has to do
_everything_ itself, because it can't call on any library functions or
other code for support, and it still has to fit into 2K, so I would
guess that putting in a 'stderr'-like functionality would overly bloat
it.  You can certainly look at the stub code (found in src/stub/) to see
if you can implement something that would work.

> Also, I don't like having two different versions of GO32.EXE with
> the same name, but in different directories (I can get VERY picky
> on fridays).  Would it be possible in some future version of djgpp
> to have the path & filename of the old GO32.EXE specified in an
> environment variable, rather than using the search path?  That way,
> I could rename the v1.12 GO32.EXE to GO32V112.EXE and keep it in my
> DJGPP\BIN directory, rather than creating an OLDBIN directory for
> it (I ran out of space in my PATH variable a long long time ago, so
> having an OLDBIN directory with only one file in it is very
> undesireable).

This is a hack to allow running of old v1.x programs with a v2
installation.  There's really no elegant way to solve the problem,
AFAIK; the FAQ itself even suggests that you convert all your v1.x
programs/libraries to v2 ASAP.  You can propose as many solutions as you
want, but since v1.x is no longer actively supported, most likely the
only way they'd get implemented is if you do it yourself.

> If I wanted to modify the existing v2.0 source to look for an
> environment variable to find the v1.xx GO32, where in the source
> tree should I be poking around?

You should probably lurk around the code for go32-v2.exe, and/or the
stub loader code.  I'm not sure exactly where this bit of code is
located because I haven't looked for it.  :)

-- 
---------------------------------------------------------------------
| John M. Aldrich, aka Fighteer I  |        fighteer AT cs DOT com         |
| Plan:  To find ANYONE willing to |   http://www.cs.com/fighteer   |
| play Descent 2 on DWANGO!        | Tagline: <this space for rent> |
---------------------------------------------------------------------

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019