From:	Martin Str|mberg <ams AT ludd DOT luth DOT se>
Message-Id:	<200104141735.TAA14753@mother.ludd.luth.se>
Subject:	Re: Stub trying to find COMSPEC=A:\COMMAND.COM\CWSDPMI.EXE!
To:	eliz AT is DOT elta DOT co DOT il
Date:	Sat, 14 Apr 2001 19:35:27 +0200 (MEST)
Cc:	djgpp-workers AT delorie DOT com (DJGPP-WORKERS)
In-Reply-To:	<6480-Sat14Apr2001202321+0300-eliz@is.elta.co.il> from "Eli Zaretskii" at Apr 14, 2001 08:23:22 PM
X-Mailer:	ELM [version 2.5 PL2]
MIME-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

According to Eli Zaretskii:
> 
> > From: Martin Str|mberg <ams AT ludd DOT luth DOT se>
> > Date: Sat, 14 Apr 2001 16:08:14 +0200 (MEST)
> > 
> > FreeDOS is fun and educational. I put in print-outs for which paths
> > truename is called with.
> 
> I'm not sure I follow: the print-outs are inside the FreeDOS kernel or
> in the DJGPP library?  I assume it's the former, because otherwise
> what you see doesn't make sense.

In the kernel.

> I'm also not sure what do you want comments about. The TRUENAME

The strange call with COMSPEC!

> function (function 60h of Int 21h) is one of the main workhorses of
> the DOS filesystem code, so you shouldn't be surprised you see it so
> much.  For example, this function is what's behind silent truncation

No of course not. I'm not surprised. I was giving a complete record
(to avoid confusion; and thereby caused some - sigh!). Plus you might
be interested in what calls were made in general.

> > Current directory is "D:\DJGPP\BIN" and PATH is "c:\fdos\bin;a:\".
> > I enter "a:df" and this is what I see:
> > 
> > truename("A:\DF.EXE")
> 
> COMMAND.COM calls FindFirst to look for the program you invoked.
> 
> > truename("A:\DF.EXE")
> > truename("A:\DF.EXE")
> 
> DOS Exec function opens df.exe to read it into memory.  Each call to
> the DOS OpenFile function usually involves a call to FindFirst, which
> calls TRUENAME internally.  I guess there are two calls because
> OpenFile calls TRUENAME again, or something.
> 
> > truename("A:\CWSDPMI.EXE")
> 
> Stub tries to exec CWSDPMI from the same place where df.exe was found.
> 
> > truename("c:\fdos\bin\CWSDPMI.EXE")
> 
> Stub tries to exec CWSDPMI from the first directory on PATH.
> 
> > truename("a:\CWSDPMI.EXE")
> 
> Stub tries to exec CWSDPMI from the second directory on PATH.
> 
> > truename("COMSPEC=A:\COMMAND.COM\CWSDPMI.EXE")
> 
> Don't know where does this come from.

Yes, this is the main question.

> > truename("CWSDPMI.EXE")
> 
> Stub tries to exec CWSDPMI from the current directory (and succeeds).
> 
> > truename("CWSDPMI.EXE")
> > truename("CWSDPMI.EXE")
> 
> Probably called during CWSDPMI's load by DOS.
> 
> > truename("EMMXXXX0")
> 
> CWSDPMI opens the EMMXXXX0 device, to see if VCPI is present.  (Every
> memory manager that supports EMS installs a driver for this device,
> since there are IOCTL calls you can use to control a memory manager.)
> 
> > truename("A:DF.EXE")
> 
> The stub opens the executable to read it into memory.
> 
> > truename("c:\cwsdpmi.swp")
> 
> CWSDPMI creates the paging file.
> 
> > truename("a:/emu387.dxe")
> 
> npxsetup (called from the startup code) calls _dxe_load which opens
> and loads "a:/emu387.dxe".
> 
> > Note that call with "COMSPEC=A:\COMMAND.COM\CWSDPMI.EXE" above! Is
> > that really intentional?
> 
> Can you tell if this call is coming from the stub, and if so, from
> where, exactly?

From what I understand it must come from the stub given the calls
above. I'll see if I can find out where in the stub.

> > Further note that the emulation library is only searched for at the
> > location where the program resides. Is that intentional?
> 
> Yes, that's what npxsetup does when EMU387 is not set in the
> environment.  I guess the DJGPP variable was not set and/or djgpp.env
> was not present?

Ok.


Right,

						MartinS

- Raw text -