Long File Name (LFN) support (SDL1)

Here you can discuss the development of patches.

Re: Long File Name support

Postby collector » 2015-8-27 @ 02:33

I haven't been following it closely enough to say.
User avatar
collector
l33t
 
Posts: 4059
Joined: 2003-1-15 @ 10:39

Re: Long File Name support

Postby Wengier » 2015-8-29 @ 19:02

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.
Wengier
Member
 
Posts: 110
Joined: 2014-9-03 @ 19:56

Re: Long File Name support

Postby TheGreatCodeholio » 2015-8-30 @ 01:38

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.
User avatar
TheGreatCodeholio
Member
 
Posts: 471
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: Long File Name support

Postby TheGreatCodeholio » 2015-8-30 @ 06:48

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.
User avatar
TheGreatCodeholio
Member
 
Posts: 471
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: Long File Name support

Postby TheGreatCodeholio » 2015-8-30 @ 16:49

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.
User avatar
TheGreatCodeholio
Member
 
Posts: 471
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: Long File Name support

Postby Wengier » 2015-8-30 @ 18:55

TheGreatCodeholio wrote: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-8-30 @ 19:24, edited 2 times in total.
Wengier
Member
 
Posts: 110
Joined: 2014-9-03 @ 19:56

Re: Long File Name support

Postby TheGreatCodeholio » 2015-8-30 @ 19:07

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.
User avatar
TheGreatCodeholio
Member
 
Posts: 471
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: Long File Name support

Postby TheGreatCodeholio » 2015-8-30 @ 19:17

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.
User avatar
TheGreatCodeholio
Member
 
Posts: 471
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: Long File Name support

Postby Wengier » 2015-8-30 @ 19:17

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.
Wengier
Member
 
Posts: 110
Joined: 2014-9-03 @ 19:56

Re: Long File Name support

Postby TheGreatCodeholio » 2015-8-30 @ 19:28

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.
User avatar
TheGreatCodeholio
Member
 
Posts: 471
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: Long File Name support

Postby Wengier » 2015-8-30 @ 19:57

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.
Wengier
Member
 
Posts: 110
Joined: 2014-9-03 @ 19:56

Re: Long File Name support

Postby Azarien » 2015-11-24 @ 16:04

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.
Azarien
Member
 
Posts: 426
Joined: 2015-5-14 @ 07:14

Re: Long File Name support

Postby Wengier » 2015-11-26 @ 15:02

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.
Wengier
Member
 
Posts: 110
Joined: 2014-9-03 @ 19:56

Re: Long File Name support

Postby Wengier » 2015-12-03 @ 04:11

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
You do not have the required permissions to view the files attached to this post.
Wengier
Member
 
Posts: 110
Joined: 2014-9-03 @ 19:56

Re: Long File Name support

Postby Azarien » 2015-12-09 @ 20:17

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.
Azarien
Member
 
Posts: 426
Joined: 2015-5-14 @ 07:14

Re: Long File Name support

Postby Wengier » 2015-12-10 @ 02:01

Azarien wrote: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-3-21 @ 19:45, edited 18 times in total.
Wengier
Member
 
Posts: 110
Joined: 2014-9-03 @ 19:56

Re: Long File Name support

Postby Wengier » 2016-1-14 @ 00:01

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.
You do not have the required permissions to view the files attached to this post.
Last edited by Wengier on 2016-3-27 @ 19:57, edited 5 times in total.
Wengier
Member
 
Posts: 110
Joined: 2014-9-03 @ 19:56

Re: Long File Name support

Postby emendelson » 2016-2-12 @ 19:33

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
Oldbie
 
Posts: 730
Joined: 2010-2-14 @ 02:00

Re: Long File Name support

Postby Wengier » 2016-2-12 @ 19:53

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.
Wengier
Member
 
Posts: 110
Joined: 2014-9-03 @ 19:56

Re: Long File Name (LFN) support

Postby avx » 2016-4-07 @ 00:18

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)
avx
Newbie
 
Posts: 43
Joined: 2015-6-01 @ 00:14

PreviousNext

Return to DOSBox Patches

Who is online

Users browsing this forum: aardvark82 and 0 guests