From: George Snyder <gjs AT averstar DOT com>
Newsgroups: comp.os.msdos.djgpp
Subject: Current Directory Switches to Short Format on NT
Date: Mon, 11 Dec 2000 19:28:05 -0500
Organization: AverStar, Inc.
Lines: 43
Message-ID: <3A357114.D84E1021@averstar.com>
NNTP-Posting-Host: hummel.burl.averstar.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Trace: inmet2.burl.averstar.com 976580884 5559 141.199.8.145 (12 Dec 2000 00:28:04 GMT)
X-Complaints-To: usenet AT inmet2 DOT burl DOT averstar DOT com
NNTP-Posting-Date: 12 Dec 2000 00:28:04 GMT
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

The Windows executables available from ftp.simtel.net
/pub/simtelnet/gnu/djgpp/v2gnu look like 16-bit programs on Windows NT.
If I load one into DEPENDS.EXE, I get an error message:

     No PE signature found.  This file appears to be a 16-bit DOS
     module.

One result of running a 16-bit program (even COMMAND.COM) on NT is that
the command process' current directory gets converted to short filename
format.  Note the directory name in the prompts in the following
example:

     E:\Program Files> \gnu\bin\ls

     AverStar                 Microsoft Visual Studio    seti
     Java                     RadView
     Jikes                    Visigenic

     E:\PROGRA~1>

(Another effect is that the command window briefly changes from an CMD
style window to a COMMAND style window, with no scrollbars and with at
most 50 lines, while the 16-bit program is running.  This is
disconcerting but apparently not harmful).

After this, programs which read the current directory name can go
wrong.  For example, a licensed CM program which gets the current
directory name and looks that up in a database fails, because the
database lists the long filename format.

I am using lfnsrv.dll and lfnload.com to enable LFN support (note the
long filenames listed in the example above).  The directory problem
occurs regardless of whether LFN is enabled.

I could not find any mention of this effect in the DJGPP FAQ.  Is it a
known problem?  Is there any way around it?  Are 32-bit executable
versions of the v2gnu programs available?

Thanks for any assistance.

-- George Snyder