Reply 60 of 104, by collector
- Rank
- l33t
I haven't been following it closely enough to say.
I haven't been following it closely enough to say.
I have asked the question in that thread, but he seems to only talk about the Linux port of his DOSBox-X by now. Since my own LFN build seems to work fine on both Windows and Linux during my testings, any issue he mentioned so far is most likely specific to his DOSBox-X branch, probably only the Linux port of DOSBox-X. At the moment I need to get confirmation that the LFN patch does work fine on the Win32 port of DOSBox-X.
wrote:I have asked the question in that thread, but he seems to only talk about the Linux port of his DOSBox-X by now. Since my own LFN build seems to work fine on both Windows and Linux during my testings, any issue he mentioned so far is most likely specific to his DOSBox-X branch, probably only the Linux port of DOSBox-X. At the moment I need to get confirmation that the LFN patch does work fine on the Win32 port of DOSBox-X.
Would it be alright if we were to break integration of the LFN patch into stages? We could integrate each stage, then stop when we get to the part that breaks Linux path lookup.
Hm, I think I figured out what's wrong with the patch on my Linux system.
I don't think the patch addresses that Linux's ext4 filesystem matches files in a case sensitive manner, while Windows is case insensitive by default. "NSSI.EXE" is considered a different filename from "nssi.exe" in Linux. In my test the EXE came out of a ZIP file that named it NSSI.EXE and I type "nssi" to run it. Prior to the patch DOSBox seemed to handle the case difference just fine, while with this patch LFN emulation works but file open seems to not take the case sensitive matching into consideration while other file operations like renaming and deleting still work fine.
So with this patch I can't run NSSI.EXE by typing "nssi" but I can temporarily work around the problem by typing "NSSI" to run the program. All that needs to be done is to update the LFN code to do case insensitive LFN matching and it will work properly again.
Running strace on the compiled dosbox binary shows that when I type "nssi" it looks for "nssi.exe" which fails, and when I type "NSSI" it looks for "NSSI.EXE" and succeeds.
If it seemed like I was deliberately stalling I'm sorry but I understand now what is wrong with path lookup on my Linux system.
wrote:Hm, I think I figured out what's wrong with the patch on my Linux system. […]
Hm, I think I figured out what's wrong with the patch on my Linux system.
I don't think the patch addresses that Linux's ext4 filesystem matches files in a case sensitive manner, while Windows is case insensitive by default. "NSSI.EXE" is considered a different filename from "nssi.exe" in Linux. In my test the EXE came out of a ZIP file that named it NSSI.EXE and I type "nssi" to run it. Prior to the patch DOSBox seemed to handle the case difference just fine, while with this patch LFN emulation works but file open seems to not take the case sensitive matching into consideration while other file operations like renaming and deleting still work fine.
So with this patch I can't run NSSI.EXE by typing "nssi" but I can temporarily work around the problem by typing "NSSI" to run the program. All that needs to be done is to update the LFN code to do case insensitive LFN matching and it will work properly again.
Running strace on the compiled dosbox binary shows that when I type "nssi" it looks for "nssi.exe" which fails, and when I type "NSSI" it looks for "NSSI.EXE" and succeeds.
If it seemed like I was deliberately stalling I'm sorry but I understand now what is wrong with path lookup on my Linux system.
Thanks for figuring out the problem with the patch on your Linux system. This will be an easy fix I believe - simply adding the following two lines below the line "if (DOS_FileExists(name)) return name;" of the function "char * DOS_Shell::Which(char * name)" in the file src\shell\shell_misc.cpp will solve the Linux case problem you mentioned. You may try it again with this small change applied.
if (DOS_FileExists(name)) return name; <- this line already ready exists; add the two lines below
upcase(name);
if (DOS_FileExists(name)) return name;
Well... the problem is that some of the files are lowercase and some of the files are uppercase. The files I extract from ZIP archives are usually uppercase, while the DOS executables I compile from DOSLIB are lowercase. So the correct fix is not to just assume uppercase, but to use whatever worked before the patch to match filenames in a case insensitive manner despite Linux's case sensitive filesystem. Whatever allowed it to work previously needs to carry over in the LFN patch. Is that possible to do?
wrote:Well... the problem is that some of the files are lowercase and some of the files are uppercase. The files I extract from ZIP archives are usually uppercase, while the DOS executables I compile from DOSLIB are lowercase. So the correct fix is not to just assume uppercase, but to use whatever worked before the patch to match filenames in a case insensitive manner despite Linux's case sensitive filesystem. Whatever allowed it to work previously needs to carry over in the LFN patch. Is that possible to do?
edit conflict - I just made a small change to the above code, although it is not directly related to the issue you mentioned. The issue you raised does not exist in a way you described though, since DOSBox already generated the 8.3 name with automatic conversion to upper case. So it is not assuming uppercase - the 8.3 names are *already* in upper case. The LFN is not automatically converted to upper case, but the SFN is always converted to upper case by DOSBox.
That helps. But the problem also exists in file opening in general. I can run "nssi" now whether the EXE file name is uppercase or lowercase, but other DOS programs complain that they can't open any files they need. DOOM can't locate DOOM1.WAD unless I rename it to doom1.wad. Windows 3.1 complains it can't locate any of it's system files. It's not just the shell, it's deeper in the DOS kernel.
wrote:That helps. But the problem also exists in file opening in general. I can run "nssi" now whether the EXE file name is uppercase or lowercase, but other DOS programs complain that they can't open any files they need. DOOM can't locate DOOM1.WAD unless I rename it to doom1.wad. Windows 3.1 complains it can't locate any of it's system files. It's not just the shell, it's deeper in the DOS kernel.
In this case make a further change to the function "DOS_OpenFile" of the file src/dos/dos_files.cpp:
Change the following line from:
exists=Drives[drive]->FileOpen(&Files[handle],fullname,flags);
To:
exists=Drives[drive]->FileOpen(&Files[handle],fullname,flags)||Drives[drive]->FileOpen(&Files[handle],upcase(fullname),flags);
I don't currently have DOOM to test, but Windows 3.1 should not complain it can't locate any of its system files any more.
Wengier could you make a new diff for current SVN? I was trying to apply your patch to revision 3954, but there have been some serious changes, especially in dos_files.cpp that I don't know how to deal with.
wrote:Wengier could you make a new diff for current SVN? I was trying to apply your patch to revision 3954, but there have been some serious changes, especially in dos_files.cpp that I don't know how to deal with.
Sure, I will try to make a new diff for current SVN soon. Thanks for reminding me about this.
A new diff against the latest DOSBox SVN 3954 is now available. I have updated the Windows binary too, which is downloadable from: https://bitly.com/12jANWF
Thanks, it works. There are several problems however:
- the code as it is doesn't compile with C_CLIPBOARD set to 0 and without curses
- when compiled with VS2008 in debug mode, it crashes on CD or DIR with stack corruption. when i disable runtime checks it works, but i guess the bug is still there
- TYPE and tab-completion for TYPE doesn't work with files with space in name.
wrote:Thanks, it works. There are several problems however: […]
Thanks, it works. There are several problems however:
- the code as it is doesn't compile with C_CLIPBOARD set to 0 and without curses
- when compiled with VS2008 in debug mode, it crashes on CD or DIR with stack corruption. when i disable runtime checks it works, but i guess the bug is still there
- TYPE and tab-completion for TYPE doesn't work with files with space in name.
Thanks for the testing and the reporting. Both Point 1 and Point 3 are easy to fix. And for Point 2, I have fixed the crash in debug mode on my PC too. Now I have uploaded the updated diff along with the attachment srcchanges.zip containing all source files that have been changed from the latest SVN version. The updated Windows binary remains downloadable from: https://bitly.com/12jANWF
EDIT: Re-uploaded the updated source diff and changes in my next post.
I have updated the DOSBox with LFN and mouse copy/paste support to incorporate the changes in the latest DOSBox SVN 3972, and also changed the compiler of the Windows binary package to Visual Studio 2005 for better backward compatibility. It has been tested to work on Windows 98 and Windows 2000 too in addition to more recent versions of Windows such as Windows Vista and Windows 10. The download link for the Windows binary package remains the same: https://bitly.com/12jANWF
P.S. In case anyone wants the Windows binary compiled with MinGW instead of Visual Studio, here it is: http://bit.ly/1laDvGX
Attached are the updated diff named dosboxlfn.diff and the file srcchanges.zip containing all source files that have been changed from the latest official SVN version.
With help from Wengier Wu, I've put together a brief page with basic information and download links relating to Wengier's LFN-supporting versions of DOSBox and vDos. The page may be found here:
http://wpdos.org/dosbox-vdos-lfn.html
I hope this is useful to anyone who wants to use the LFN and copy/paste support in Wengier's version of DOSBox.
emendelson:
Thanks for posting the page. I have added the above link to the first post of the thread as well as the README.TXT file within the Windows binary packages of DOSBox SVN-lfn too.
This build has issues with atleast System Shock 1. With last years build it did not start, with the 20160327 build it now starts but cannot find the sound config. (I have it set to general midi + GUS)