Message-Id: <1.5.4.32.19970930141051.00698bf4@dce03.ipt.br>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 30 Sep 1997 11:10:51 -0300
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
From: Cesar Scarpini Rabak <csrabak AT dce03 DOT ipt DOT br>
Subject: Re: libc functions handling of UNCs
Cc: djgpp AT delorie DOT com
Precedence: bulk

At 15:39 30/09/97 +0200, Eli Zaretskii wrote:
>
>On Tue, 30 Sep 1997, Cesar Scarpini Rabak wrote:
>
>>     fnsplit(argv[0], szDrive, szPath, szFile, NULL);
>
>So the real problem is that argv[0] gets a UNC from Windows 95.
>
>Actually, programs that need to use argv[0] to open files, need to be 
>aware of this problem and translate the UNC into a d:/path name.  It is a 
>pain in the lower back, but I know of no other solution.  One other 
>problem with using argv[0] on Windows 95 is that it always gets the 8+3 
>alias, even if the .exe has a valid long name *and* you invoked the 

Yes, we noticed this idiosyncrasy as well... but this one did not bite our
hand,  (one is able to open a file via its alias).

>program using that long name.  The funny thing is, this also happens for 
>native Win32 programs (so I am told).  Looks like somebody at Microsoft 
>got lazy and didn't want to differentiate between DOS and Win32 programs.
>

Humm, your observation if correct, may mean that there is hope: if native
Win32 programs also have this problem, but aplications like Explorer,
Notepad, etc., are able to show in their file menus the longfilenames, then
there should be a documented way of doing it!

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Cesar Scarpini Rabak                      E-mail: csrabak AT ipt DOT br
DME/ASC                                   Phone: 55-11-268-3522 Ext.350
IPT - Instituto de Pesquisas Tecnologicas Fax:   55-11-268-5996
Av. Prof. Almeida Prado, 532.  Sao Paulo - SP 05508-901 BRAZIL
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~