From: "John M. Aldrich" 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 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Phil Galbiati 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: | ---------------------------------------------------------------------