X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f From: Juan Manuel Guerrero Newsgroups: comp.os.msdos.djgpp Subject: Re: Isues concerning the INT 21 Windows95 - LONG FILENAME FUNCTIONS (0x71XX) implementation. Date: Thu, 15 Sep 2011 09:08:15 -0700 (PDT) Organization: http://groups.google.com Lines: 132 Message-ID: <9a4f248a-9734-4f4e-b06c-db4b9960a7d4@hb5g2000vbb.googlegroups.com> References: <201109101340 DOT 47663 DOT juan DOT guerrero AT gmx DOT de> <83vct04a4x DOT fsf AT gnu DOT org> NNTP-Posting-Host: 109.193.148.146 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: posting.google.com 1316102896 19532 127.0.0.1 (15 Sep 2011 16:08:16 GMT) X-Complaints-To: groups-abuse AT google DOT com NNTP-Posting-Date: Thu, 15 Sep 2011 16:08:16 +0000 (UTC) Complaints-To: groups-abuse AT google DOT com Injection-Info: hb5g2000vbb.googlegroups.com; posting-host=109.193.148.146; posting-account=OsAajgoAAADdKJnkJkmhzqP0jo6I_P_0 User-Agent: G2/1.0 X-Google-Web-Client: true X-Google-Header-Order: HUALESNKRC X-HTTP-UserAgent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20100101 Firefox/6.0.2,gzip(gfe) Bytes: 7133 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id p8FGF1RF000463 Reply-To: djgpp AT delorie DOT com On 15 Sep., 11:48, Ozkan Sezer wrote: > On Sat, Sep 10, 2011 at 7:47 PM, Eli Zaretskii wrote: > >> From: Juan Manuel Guerrero > >> Date: Sat, 10 Sep 2011 13:40:47 +0200 > > >> I have checked the repository and found that the following functions use the > >> INT 21 Windows95 - LONG FILENAME FUNCTIONS (0x71XX).  Accoring to RBIL61, the > >> recommended way to proceed here is always to set CF before calling a 0x71XX > >> function, and after the function call has been performed to check that the > >> AX register does not contain 0x7100.  If AX == 0x7100 the functionality is not > >> provided by the LFN API and the corresponding SFN API function shall be called. > > >> Not a single of the functions set CF before calling 0x71 functions.  This can > >> produce serious malfunctions as has been seen with MSDOS 6.22 and DOSLFN 0.40e > >> in threat > >> Except for _use_lfn and lfnshort not a single function checks for AX != 0x7100. > >> This is certainly wrong and makes a lot of programs fail (e.g., gcc, gdb, grep). > >> Some of these functions call _use_lfn to decide if LFN support is available or > >> not, but _use_lfn only checks for 0x71a0 and this is certainly not enough to > >> decide if the required 0x71XX functions are really available or not. > > > The assumption was that LFN functions are either all supported or not > > at all.  If that assumption is not true, by and large, then many > > things will fall apart. > > >> shall remove really remove a SFN file if > >> it does not find the LFN file because the LFN API function is not available? > > > No!  It should simply fail.  If some environment supports 0x71a0, but > > does not support 0x7156, then it basically means LFN is not supported, > > and the user will have to disable LFN through the environment > > variable. > > > The same goes for `_rename' and other basic functions that accept file > > names as their arguments, and make destructive changes to the > > filesystem. > > > Functions that accept file descriptors, by contrast, could fall back > > on SFN functions where that makes sense, i.e., where some useful data > > can be still returned to the caller. > > >> It would also be possible to improve _use_lfn() to check for _all_ 0x71XX > >> functions. > > > That would make it painfully slow, which is not a good idea, because > > as I recall it is called internally by many library functions.  Don't > > forget that calling any Int 21H function requires an expensive mode > > switch.  It is better to add recovery to the few functions we found > > now to be not supported well by DOSLFN. > > > Below are my suggestions for the functions you mentioned: > > >  libc/ansi/stdio/remove.c       0x713A, 0x7141         -- fail > >  libc/ansi/stdio/_rename.c      0x7156                 -- fail > >  libc/dos/dir/findfirs.c        0x714e, 0x71a1         -- fail for 0x714e > >  libc/dos/dir/findnext.c        0x714f, 0x71a1         -- fail for 0x714f > >  libc/dos/dos/truename.c        0x7160                 -- fall back on 0x6000 > >  libc/dos/io/flushdc.c          0x710d                 -- fall back on BIOS DISK RESET > >  libc/dos/io/_chmod.c           0x7143                 -- fail > >  libc/dos/io/_creat.c           0x716c                 -- fall back on SFN > >  libc/dos/io/_creat_n.c         0x716c                 -- fall back on SFN > >  libc/dos/io/_open.c            0x7143, 0x7160, 0x716c -- fall back on SFN > >  libc/dos/lfn/lfnshort.c        0x7100, 0x71a8         -- fall back on SFN > >  libc/dos/lfn/_use_lfn.c        0x7100, 0x71a0         -- return 0 > >  libc/dos/process/dosexec.c     0x7160                 -- ignore > >  libc/posix/dirent/opendir.c    0x71a1                 -- ignore > >  libc/posix/sys/stat/fchmod.c   0x71a6                 -- already handles this > >  libc/posix/sys/stat/filelen.c  0x71A6                 -- fall back on 0x42XX > >  libc/posix/sys/stat/fixpath.c  0x7147, 0x7160, 0x713b -- fall back on 0x4700 > >  libc/posix/sys/stat/fstat.c    0x71a6                 -- already handles > >  libc/posix/sys/stat/lfilelen.c 0x71A6                 -- already handles > >  libc/posix/sys/stat/mkdir.c    0x7139                 -- fall back on 0x3900 > >  libc/posix/unistd/chdir.c      0x713b                 -- fall back on 0x3b00 > >  libc/posix/unistd/getcwd.c     0x7147                 -- fall back on 0x4700 > >  libc/posix/unistd/getcwd.c     0x7160                 -- already handles > >  libc/posix/unistd/rmdir.c      0x713a                 -- fail > >  libc/posix/utime/utime.c       0x7143                 -- only uses 0x7143 on NT/2K/XP > > What is the status of this issue? I am working on this. Be patient. I think I will post a patch on week end. > On a related note which of v2.03r2 and v2.04-20110904 is > more suitable for use (with or without the above LFN issues > addressed) ? A question of preference, I assume. I use only 2.04 Regards, Juan M. Guerrero