X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f X-Recipient: djgpp AT delorie DOT com X-Authenticated: #27081556 X-Provags-ID: V01U2FsdGVkX1+AoUpgAUuA6SeeNBBWR5d7LpY+85+alxpo+6V3QX yRpXrJdw6zVHMf From: Juan Manuel Guerrero To: djgpp AT delorie DOT com Subject: Isues concerning the INT 21 Windows95 - LONG FILENAME FUNCTIONS (0x71XX) implementation. Date: Sat, 10 Sep 2011 13:40:47 +0200 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201109101340.47663.juan.guerrero@gmx.de> X-Y-GMX-Trusted: 0 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. I have already patched all functions so that the CF is always set before calling 0x71XX. Now, the question arises how to proceed when it is detected that the required 0x71XX function is not available. Especialy if renaming or deleting functions are used. E.g., shall remove really remove a SFN file if it does not find the LFN file because the LFN API function is not available? Is the relationship between SFN and LFN really always unique? Shall we really rename a file using SFN API if LFN API is not available? Other functions like filelen, _creat and findfirs/findnext are less critical. It would also be possible to improve _use_lfn() to check for _all_ 0x71XX functions. The questions is shall we use the corresponding SFN API function if the LFN API function is not available, risking to corrupt the file and/or the file system? Any suggestions will be welcome? Regards, Juan M. Guerrero libc/ansi/stdio/remove.c 0x713A, 0x7141 libc/ansi/stdio/_rename.c 0x7156 libc/dos/dir/findfirs.c 0x714e, 0x71a1 libc/dos/dir/findnext.c 0x714f, 0x71a1 libc/dos/dos/truename.c 0x7160 libc/dos/io/flushdc.c 0x710d libc/dos/io/_chmod.c 0x7143 libc/dos/io/_creat.c 0x716c libc/dos/io/_creat_n.c 0x716c libc/dos/io/_open.c 0x7143, 0x7160, 0x716c libc/dos/lfn/lfnshort.c 0x7100, 0x71a8 libc/dos/lfn/_use_lfn.c 0x7100, 0x71a0 libc/dos/process/dosexec.c 0x7160 libc/posix/dirent/opendir.c 0x71a1 libc/posix/sys/stat/fchmod.c 0x71a6 libc/posix/sys/stat/filelen.c 0x71A6 libc/posix/sys/stat/fixpath.c 0x7147, 0x7160, 0x713b libc/posix/sys/stat/fstat.c 0x71a6 libc/posix/sys/stat/lfilelen.c 0x71A6 libc/posix/sys/stat/mkdir.c 0x7139 libc/posix/unistd/chdir.c 0x713b libc/posix/unistd/getcwd.c 0x7147 libc/posix/unistd/getcwd.c 0x7160 libc/posix/unistd/rmdir.c 0x713a libc/posix/utime/utime.c 0x7143