Long File Name (LFN) support (SDL1)

[Wengier]

Yes, please. Post it to the development forum, I'll move it to patches then.

OK, I have posted it here:

viewtopic.php?f=32&t=41179

[truth_deleted]

Thread title could be renamed to "Long File Name support".

[truth_deleted]

Edit: thank you for the long file name patch, it works great! It would be a nice addition to have the joliet extensions, I'll try to find reference manuals.

Edit 2:
https://github.com/grate-driver/linux/b ... s/joliet.c
http://johnson.tmfc.net/dos/file/shcdx33f.zip

The 2nd link has the source code in assembler. However, it may provide enough insight into how that mscdex replacement driver is reading the file names and possibly signals from the "hardware".

[emendelson]

Apologies for a complete newbie question. Could someone kindly spell out the syntax for applying Wengier's patch to current SVN? I've used Tortoise SVN to download the current code.

I won't waste bandwidth on my various attempts to use GNU patch.exe (it can't find the file, then, if I type in the name of the file, it tells me that it expects '---' on line 9, but '---' IS on line 9, and I've converted the file to DOS format) or Tortoise SVN (which simply displays a big red X button when I tell it which directory to use).

I think I knew the answer once, but I think that was with a different .diff format than Wengier's. Any help will be gratefully received. Apologies again for a newbie question, but I've spent a lot of time trying to find an answer that works.

[truth_deleted]

The "long file name" patch applies cleanly to the latest dosbox source code. It may be applied manually by editing the dosbox source code with lines from the patch. It was nice that Wengier spent time on developing it.

[emendelson]

Thank you for that! Instead of wasting time trying to use patch.exe, I should have used the time to apply the patch by hand - which I always prefer to do anyway. Thanks again. I'm off to work in UltraEdit-32 right now... It was *extremely* generous of Wengier to do this, and he's been generously helping DOS users in other ways for years and years.

[truth_deleted]

I think the patch may apply cleaner to dosbox SVN-r3869, instead of r3871.

[truth_deleted]

I believe that the "long file name" function will only work where xms=true in the dosbox.conf file. Verified this in the source code. I assume this occurs so that the dos version (and uselfn) are updated on the start of dosbox. It seems reasonable, if so.

[Wengier]

I was away from PC most of the day yesterday, so I am doing this now. I have attached the new build of DOSBox with LFN and mouse copy/paste support, which now incorporate the changes in the latest svn version r3871, and LFN functions will not only work when xms is set to true.

Attached is the Windows binary with all required DLLs, zipped, and also diff from the svn version r3871.

[Wengier]

Hi emendelson! Thanks for your support! I will try to make the zip of all source files that have been changed from the latest svn version too. This should be more convenient for your use.

EDIT: Now I have made the zip containing all source files changed from the latest svn version. Please see the attachment.

[emendelson]

Thank you, Wengier!

[truth_deleted]

Yes, thank you for the update in the case of xms=false! It works great.

[truth_deleted]

The following line changes don't seem necessary for compiling with your patch:

Code: Select all

diff -x '*.exe' -x '*.a' -x '*.o' -x '*.in' -x '*.m4' -x '*.status' -x visualc_net -x .deps -x 'Makefile*' -x 'configure*' -r dosboxsvnn/src/dos/cdrom_aspi_win32.cpp dosbox/src/dos/cdrom_aspi_win32.cpp
36,37c36,37
< #include "ddk/ntddcdrm.h"      // Ioctl stuff
< #include "ddk/ntddscsi.h"
---
> #include "ntddcdrm.h"      // Ioctl stuff
> #include "ntddscsi.h"
diff -x '*.exe' -x '*.a' -x '*.o' -x '*.in' -x '*.m4' -x '*.status' -x visualc_net -x .deps -x 'Makefile*' -x 'configure*' -r dosboxsvnn/src/dos/cdrom_ioctl_win32.cpp dosbox/src/dos/cdrom_ioctl_win32.cpp
33c33
< #include "ddk/ntddcdrm.h"      // Ioctl stuff
---
> #include "ntddcdrm.h"      // Ioctl stuff
diff -x '*.exe' -x '*.a' -x '*.o' -x '*.in' -x '*.m4' -x '*.status' -x visualc_net -x .deps -x 'Makefile*' -x 'configure*' -r dosboxsvnn/src/hardware/mixer.cpp dosbox/src/hardware/mixer.cpp
25a26
> #include <cstdlib>
diff -x '*.exe' -x '*.a' -x '*.o' -x '*.in' -x '*.m4' -x '*.status' -x visualc_net -x .deps -x 'Makefile*' -x 'configure*' -r dosboxsvnn/src/ints/int10_char.cpp dosbox/src/ints/int10_char.cpp
26a27
> #include "stdio.h"

This line I'm not as sure about its necessity for the original patch to function (however, it's not used in the pdcurses based patch):

Code: Select all

diff -x '*.exe' -x '*.a' -x '*.o' -x '*.in' -x '*.m4' -x '*.status' -x visualc_net -x .deps -x 'Makefile*' -x 'configure*' -r dosboxsvnn/src/gui/sdlmain.cpp dosbox/src/gui/sdlmain.cpp
279a281,282
> Uint32 u[640][400];

[Wengier]

truth5678:

For the first part, the changes (some of them at least) are required on my development platform (VS 2013), but indeed it may not be necessary on other platforms.

For the second part. Actually I have already removed that line in my latest build (see the latest patch in the other thread).

[truth_deleted]

One possibility is to direct the preprocessor to recognize VS2013 specific lines in code:

Code: Select all

#if (_MSC_VER >= 1800)
   // ... Do VS2013 specific stuff
#endif

[Wengier]

Thanks. I looked at them one by one and also made some changes to the configurations. But now I think it is indeed better to make the source changes in this forum more specific to the features themselves, so I have removed these changes from the overall patches. For the convenience of other users, I have attached the Windows binary of the latest DOSBox build with LFN and mouse copy/paste support (along with all required DLLs, zipped), and the zip containing all source files that have been changed from the latest SVN version (r3873). For only LFN patches, the changes in the files sdlmain.cpp, mouse.cpp, mouse.h and curses.h will not be required.

EDIT: Updated the attachments in 2014-11-25.

[wackee]

Hello there

First of all, thank you for this patch in general, which is something that I have been looking for for a long time
The tool that I use it for is Star Commander (available here http://sta.c64.org/sc.html), a great tool for managing Commodore 64 disk/tape image files, also used for transferring them from the C64 hardware to PC domain. It uses the 'Norton Commander'-like panel interface.

Everything works fine except for the fact that in directories where there are more files or folders, only few are listed. For example, in a dir of 300+ files, only the first 20+ are listed. And usually, the last file in the list is listed as a FOLDER which cannot be entered into.
Also, all files have incorrect size in the list - usually some huge number, and the size is the same for all files... even if in reality it is not.

I tried running the SC in Virtual PC XP Mode thingy from Microsoft. And in there, it works fine - meaning, all files are listed in the directories. Which led me to a conclusion this might be some bug that could be fixed in the LFN DosBox itself.
Is there a possibility to look into this issue? Me and other members of retro C64 community that use the Star Commander would be more than grateful

[truth_deleted]

Does Star Commander work with LFN disabled? Does the LFN function work for you outside Star Commander? While the LFN is active, can you enumerate the problem directories outside Star Commander? What led you to the conclusion that there is a bug, were you able to find a bug in the code or is it a guess?

[wackee]

Does Star Commander work with LFN disabled?

Yes, it does work. However, there is the same issue. Not all files are listed in the dir with 100+ files.

Does the LFN function work for you outside Star Commander?

Yes. If I fe. go outside of the SC in the DosBox window and do a DIR command, all files are listed with proper long filenames and all files are included in the DIR list.

While the LFN is active, can you enumerate the problem directories outside Star Commander?

As stated above, when I do a DIR command it works properly and displays everything correctly.

What led you to the conclusion that there is a bug, were you able to find a bug in the code or is it a guess?

It is definately a guess I am not a programmer, just a user, that's why I asked here for assistance and not propose any solution myself.
My conclusion might be wrong, but what is interesting the same Star Commander binaries work without this problem in the Windows Virtual PC XP Mode. So that is what made me think it could make sense to ask here.
I hope my suggestion was not perceived as offensive or anything.

[truth_deleted]

This enumeration issue in StarCommander does not appear to be linked to a large number of files. It occurs where a single long file name exists in a directory (regardless of lfn= value). I haven't fully tested, but I believe that the addition of the 1st long file name removes a short file name file (or whichever is at the end of the list) and it becomes a subdirectory (subsequent additions of LFNs results in removal of additional files from the file list). This is not yet a complete description of the issue, however. In addition, all file sizes and dates in dosbox-LFN are reported as a single value, whereas vanilla dosbox reports the true values; this last issue goes away with lfn=false.

Is it possible that the file list count is calculated differently by these file managers? Are the LFN files ignored by some function which counts the total number of files?

StarCommander is written in Pascal and assembler. An examination of EXTFILES.PAS shows some information on listing the long file names and it seems consistent with the Win95 mechanism (Int21h calls?). Another LFN aware DOS file manager is DosZip. It reports correct short file name file sizes but does not report any long file name files.

[Also, it may be possible for the poster to run real DOS inside an image and load a LFN driver, or run DOS 7. That may provide LFN support, too, but there are obvious downsides to booting off an image. I haven't tested booting from a DOS image in dosbox, so if that tries and fails, then another option is Win3.1 in protected mode (although this may require dosbox-x).]