VOGONS

Common searches


Long File Name (LFN) support (SDL1)

Topic actions

Reply 22 of 87, by truth_deleted

User metadata

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/blob/ma … /isofs/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".

Reply 23 of 87, by emendelson

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 25 of 87, by emendelson

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 28 of 87, by Wengier

User metadata
Rank Member
Rank
Member

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.

Attachments

  • Filename
    patch.diff
    File size
    55.3 KiB
    Downloads
    16 downloads
    File license
    Fair use/fair dealing exception
  • Filename
    dosbox.zip
    File size
    1.7 MiB
    Downloads
    14 downloads
    File license
    Fair use/fair dealing exception

Reply 29 of 87, by Wengier

User metadata
Rank Member
Rank
Member

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.

Attachments

  • Filename
    srcchanges.zip
    File size
    202.68 KiB
    Downloads
    7 downloads
    File license
    Fair use/fair dealing exception
Last edited by Wengier on 2014-10-25, 13:42. Edited 2 times in total.

Reply 32 of 87, by truth_deleted

User metadata

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

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):

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];

Reply 33 of 87, by Wengier

User metadata
Rank Member
Rank
Member

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).

Last edited by Wengier on 2014-10-26, 00:52. Edited 1 time in total.

Reply 35 of 87, by Wengier

User metadata
Rank Member
Rank
Member

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.

Attachments

  • Filename
    dosbox.zip
    File size
    1.76 MiB
    Downloads
    10 downloads
    File license
    Fair use/fair dealing exception
  • Filename
    srcchanges.zip
    File size
    193 KiB
    Downloads
    24 downloads
    File license
    Fair use/fair dealing exception

Reply 36 of 87, by wackee

User metadata
Rank Newbie
Rank
Newbie

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 😀

Reply 37 of 87, by truth_deleted

User metadata

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?

Reply 38 of 87, by wackee

User metadata
Rank Newbie
Rank
Newbie
truth5678 wrote:

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.

Reply 39 of 87, by truth_deleted

User metadata

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).]