On Sun, 13 Jan 2002 ccrayne@crayne.org wrote:
Change Log: files/dos_fs.c ccrayne@crayne.org Fixed bug in DOSFS_ToFCBFormat which caused "*" to parse as "*." instead of as "*.*"
This sounds like intended behaviour. Under real DOS, "*" really means "*.". The user must type "*.*" to get all files. (This is the stuff that used to confuse DOS users converting to Linux - "*.*" no longer meant all files...)
Also, your mailer seems to mangle your patches. You may want to attach them instead of pasting them to avoid that.
On Mon, 14 Jan 2002, Ove Kaaven wrote:
On Sun, 13 Jan 2002 ccrayne@crayne.org wrote:
Change Log: files/dos_fs.c ccrayne@crayne.org Fixed bug in DOSFS_ToFCBFormat which caused "*" to parse as "*." instead of as "*.*"
This sounds like intended behaviour. Under real DOS, "*" really means "*.". The user must type "*.*" to get all files. (This is the stuff that used to confuse DOS users converting to Linux - "*.*" no longer meant all files...)
Strange because if I open a 'dos box' in Win95 or NT4, and I type 'dir *' I get a list of all the files, including those that have an extension like "autoexec.bat".
In fact I would rather say that "*.*" in Dos/Windows is equivalent to "*" in Unix. The reason is that Dos/Windows considers filenames to be split into two independent parts: - the name which was originally restricted to 8 characters - the extension which was originally restricted to 3 characters
And note that one always says 8+3, not 8+1+3. So in Dos/Windows "*.*" really means "any name and any extension" which really means 'any complete filename' (i.e. "*" on Unix), rather than Unix's "*.*" which means 'any filename containing a dot'.
So the change in DOSFS_ToFCBFormat looks like it is reasonable.
-- Francois Gouget fgouget@free.fr http://fgouget.free.fr/ Advice is what we ask for when we already know the answer but wish we didn't -- Eric Jong
On Mon, 14 Jan 2002, Francois Gouget wrote:
Strange because if I open a 'dos box' in Win95 or NT4, and I type 'dir *' I get a list of all the files, including those that have an extension like "autoexec.bat".
Quite possible, as I think those DOS boxes may not use the old DOS FCB routines - they probably use the LFN routines, which might quite possibly handle wildcards differently than the original DOS routines did. (Also, I think command.com might parse dir arguments itself before passing them on to int21, and of course NT's cmd.exe does not use int21 at all)
Then again, perhaps DOS 7+ really do parse FCBs differently than e.g. DOS 3.x did. The best way to know is probably to test (int21 ah=0x29 should do the trick).
In Pine.LNX.4.21.0201142000500.4461-100000@mizar.ping.uio.no, on 01/14/02 at 08:28 PM, Ove Kaaven ovehk@ping.uio.no said:
:Then again, perhaps DOS 7+ really do parse FCBs differently than e.g. DOS :3.x did.
As it turns out, DOS 7 does parse FCBs the same way as DOS always has, and wine's implementation is indeed broken, but not in the way which I previously thought. However, before I get into that, thank you Ove, for forcing me into digging deeper into this issue.
What actually happens is that most calls to "parse filename" are made with the parse options (al) set to 1, which means to scan off any leading separators, but otherwise to parse the file name as wine currently does.
However, the DIR function of command.com wants "*" to be parsed as "*.*", so it formats the FCB name field to all question marks, and calls "parse filename" with the parse options set to 0eh, which means that the parse routine must not fill in defaults for the drive ID, the filename, or the filename extension.
Unfortunately, DOSFS_ToDosFCBFormat is not even aware that the parse flags are part of the calling convention. Therefore, the correct fix is to modify DOSFS_ToDosFCBFormat to honor the flags. I am already aware that DOSFS_ToDosFCBFormat is also called by DOSFS_ReadDir, DOSFS_FindUnixName, and INT21_FindFirst, but I would like your thoughts on what other issues I need to consider.
-- Chuck Crayne ----------------------------------------------------------- ccrayne@crayne.org -----------------------------------------------------------
On 2002.01.14 13:21 Francois Gouget wrote:
On Mon, 14 Jan 2002, Ove Kaaven wrote:
On Sun, 13 Jan 2002 ccrayne@crayne.org wrote:
Change Log: files/dos_fs.c ccrayne@crayne.org Fixed bug in DOSFS_ToFCBFormat which caused "*" to parse as "*."
instead
of as "*.*"
This sounds like intended behaviour. Under real DOS, "*" really means "*.". The user must type "*.*" to get all files. (This is the stuff
that
used to confuse DOS users converting to Linux - "*.*" no longer meant
all
files...)
Strange because if I open a 'dos box' in Win95 or NT4, and I type 'dir *' I get a list of all the files, including those that have an extension like "autoexec.bat".
Yup! With long filenames windows treats the extension like UNIX does. That is a "dir *" will in fact show all files in the directory when command.com is running under windows.
When it's not running under windows a "dir *" is equivilent to a "dir *."
As for dir *.* showing filenames not containing a dot... well, I think this is because short names are still around and therefore when you look up the file as an 8.3 name *.* does match it because a file named "FOOBAR" will have the shortname equivilant to "FOOBAR."
Anybody know what happens under NT if you turn off short name generation, then make a file named foobar and then do a dir *.* in that directory? I am guessing MS has this figured out and when the windows APIs see "*.*" they convert it to a simple "*". Of course I could be wrong and it may in fact simply not show the file since *.* would not match it by standard wildcard rules as it has no shortname with an implicit dot and the longname doesn't contain a dot.
Should be simple enough to test. Load up NT or 2k, mod the reg to disable short filenames, reboot, make the file then do a dir /x (I think it is /x) to show both long and short filenames and verify it does not have a SFN. Then dir *.* and see if it finds it.
-Dave
-
ccrayne＠crayne.org -
David Elliott -
Francois Gouget -
Ove Kaaven