Date:	Sat, 14 Apr 2001 20:23:22 +0300
From:	"Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender:	halo1 AT zahav DOT net DOT il
To:	Martin Str|mberg <ams AT ludd DOT luth DOT se>
Message-Id:	<6480-Sat14Apr2001202321+0300-eliz@is.elta.co.il>
X-Mailer:	Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.9
CC:	djgpp-workers AT delorie DOT com, sandmann AT clio DOT rice DOT edu
In-reply-to:	<200104141408.QAA08162@mother.ludd.luth.se> (message from Martin
	Str|mberg on Sat, 14 Apr 2001 16:08:14 +0200 (MEST))
Subject:	Re: Stub trying to find COMSPEC=A:\COMMAND.COM\CWSDPMI.EXE!
References:	<200104141408 DOT QAA08162 AT mother DOT ludd DOT luth DOT se>
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

> 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.

I'm also not sure what do you want comments about. The TRUENAME
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
of long file names to 8+3 limits.  More generally, every file-oriented
DOS function runs its argument through TRUENAME first, before actually
doing its thing, to normalize the name (upcase it, resolve all the
defaults, like current drive and default directory, etc.).

I will try to guess why each TRUENAME is called, but the real answer
is in FreeDOS sources and in djlsr203.zip.

> 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.

> 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?

> 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?

> Comments?

Anything else you wanted to know? ;-)

- Raw text -