VOGONS

Common searches


Long File Name (LFN) support

Topic actions

Reply 61 of 104, by Wengier

User metadata
Rank Member
Rank
Member

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.

Reply 62 of 104, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
Wengier 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.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 63 of 104, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

I have some free time tonight. I'm going to go ahead and try integrating again. I might be able to determine what breaks path lookup on my Linux system.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 64 of 104, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

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.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 65 of 104, by Wengier

User metadata
Rank Member
Rank
Member
TheGreatCodeholio wrote:
Hm, I think I figured out what's wrong with the patch on my Linux system. […]
Show full quote

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;

Last edited by Wengier on 2015-08-30, 19:24. Edited 2 times in total.

Reply 66 of 104, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

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?

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 67 of 104, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

Will do. Trying it now.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 68 of 104, by Wengier

User metadata
Rank Member
Rank
Member
TheGreatCodeholio 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.

Reply 69 of 104, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

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.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 70 of 104, by Wengier

User metadata
Rank Member
Rank
Member
TheGreatCodeholio 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.

Reply 71 of 104, by Azarien

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 72 of 104, by Wengier

User metadata
Rank Member
Rank
Member
Azarien 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.

Reply 73 of 104, by Wengier

User metadata
Rank Member
Rank
Member

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

Attachments

  • Filename
    dosboxlfn3954.diff
    File size
    56.94 KiB
    Downloads
    102 downloads
    File license
    Fair use/fair dealing exception

Reply 74 of 104, by Azarien

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 75 of 104, by Wengier

User metadata
Rank Member
Rank
Member
Azarien wrote:
Thanks, it works. There are several problems however: […]
Show full quote

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.

Last edited by Wengier on 2016-03-21, 19:45. Edited 18 times in total.

Reply 76 of 104, by Wengier

User metadata
Rank Member
Rank
Member

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.

Attachments

  • Filename
    dosboxlfn.diff
    File size
    96.7 KiB
    Downloads
    95 downloads
    File license
    Fair use/fair dealing exception
  • Filename
    srcchanges.zip
    File size
    217.58 KiB
    Downloads
    84 downloads
    File license
    Fair use/fair dealing exception
Last edited by Wengier on 2016-03-27, 19:57. Edited 5 times in total.

Reply 77 of 104, by emendelson

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 78 of 104, by Wengier

User metadata
Rank Member
Rank
Member

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.

Reply 79 of 104, by avx

User metadata
Rank Newbie
Rank
Newbie

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)