Date: Tue, 12 Dec 2000 11:28:14 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: George Snyder cc: djgpp AT delorie DOT com Subject: Re: Current Directory Switches to Short Format on NT In-Reply-To: <3A357114.D84E1021@averstar.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Mon, 11 Dec 2000, George Snyder wrote: > 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. DJGPP programs are _not_ Windows executables. They are DOS programs, albeit 32-bit protected-mode ones. > 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> Why is it important what does the shell prompt display? What's important is what do library functions such as `getcwd' report. Can you check what does `getcwd' return when you have ntlfn loaded? > 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. If this indeed happens, it might be a bug in ntlfn, so please provide a short test program which exhibits the problem. > Are 32-bit executable versions of the v2gnu programs available? The FAQ has a pointer to the Cygwin ports in section 3.6.