If you use SVN "properly" you can just make a diff against it (svn diff > lfn.diff) and post that. Or find some other way to make a diff/patch (I'm not using Windows anymore so I can't really say).

Moving it to the patches forum as well (thread starting is prohibited to keep that forum kind of clean)

Dominus wrote:

If you use SVN "properly" you can just make a diff against it (svn diff > lfn.diff) and post that. Or find some other way to make a diff/patch (I'm not using Windows anymore so I can't really say).

Moving it to the patches forum as well (thread starting is prohibited to keep that forum kind of clean)

OK, Thanks. I have managed to make a patch.diff file of the source code using the diff command. Please see the attachment.

EDIT1: See later post for latest source patches, or get the updated zip file containing all source files changed from the latest SVN version from the URL: http://bit.ly/1umlc4J

EDIT2: For most recent source diff, please download from Page 5 of this thread.

I am not sure what happened to my earlier post, but are there any DOS games that require long file names, let alone can even read them?

collector wrote:

I am not sure what happened to my earlier post, but are there any DOS games that require long file names, let alone can even read them?

Good question! Personally I never played a commercial DOS game that would *require* LFN support myself, but since I am not a real gamer this does not mean there are no such games exist. However, LFN support in DOSBox is at least useful in two different respects. First of all, support for LFN in DOSBox shell commands (DIR, CD, COPY etc) would allow users to work with the more familiar names that are used in their host operating systems, such as Windows or Linux, instead of the truncated "ugly" 8.3 names. But of course they can ALSO work with the 8.3 names, so now users have more choices and they can select from one of them depending on their own preferences instead of forcing them to work with the 8.3 names, which many of them may not actually be very familiar with. Second, even though most (or all) games (or other DOS applications) do not necessarily require LFN, many of such games or applications will SUPPORT and also BENEFIT FROM them. These will be a big plus than the 8.3 only option.

LFN support will in most cases not give any benefit to DOS games or applications, and in fact can cause problems because there is an expectation of (or even reliance on) the 8.3 limit. The exception is games or apps developed to work in DOS 7 or the NTVDM where long filenames are used; however, official DOSBox targets DOS 5/6 where the 8.3 limit is inherent.

ripsaw8080 wrote:

LFN support will in most cases not give any benefit to DOS games or applications, and in fact can cause problems because there is an expectation of (or even reliance on) the 8.3 limit. The exception is games or apps developed to work in DOS 7 or the NTVDM where long filenames are used; however, official DOSBox targets DOS 5/6 where the 8.3 limit is inherent.

I think you are really talking about the implementation of LFN support. A good implementation of LFN will almost never cause any problems to actual DOS games or applications because the games or applications in the first category as you say (i.e. those expect or rely on 8.3 names) will never call the AX=71xx functions, but will instead rely on the usual 8.3 name calls so the returned results will certainly be 8.3 names, and long names will be completely invisible to such games/apps. Only those games or applications in the second category (i.e. LFN-aware games/apps) will support and and then will benefits from LFN features. When LFN support is properly implemented, it will be no harm to any existing programs, either LFN-aware or LFN-unaware programs, in theory at least. On the other hand, it will give extra benefits to LFN-aware programs, which are also the intended effects of such programs.

I believe the official mscdex driver does not support long file names. So, your code would not provide long file names to 95 (or DOS) while accessing CDROM files via the real mode driver.

truth5678 wrote:

I believe the official mscdex driver does not support long file names. So, your code would not provide long file names to 95 (or DOS) while accessing CDROM files via the real mode driver.

Thanks for making me aware of this. I will take a look at it. The combination of SHSUCDX and DOSLFN will give LFN support to CDROM files under a real DOS system, so it should be doable for DOSBox as well.

Wengier wrote:

I think you are really talking about the implementation of LFN support. A good implementation of LFN will almost never cause any problems because the games or applications in the first category (i.e. those expect or rely on 8.3 names) will never call the AX=71xx functions, but will instead rely on the usual 8.3 name calls so the returned results will certainly be 8.3 names, and long names will be completely invisible to such games/apps. Only those games or applications in the second category (i.e. LFN-aware games/apps) will support and and then will benefits from LFN features. When LFN support is properly implemented, it will be no harm to any existing programs, in theory at least. On the other hand, it will give extra benefits to LFN-aware programs, which are also the intended effects of such programs.

Wengier wrote:

LFN support in DOSBox come with two parts, one is LFN support for shell commands such as DIR/CD/COPY (as well as the auto-completion feature of the Tab key)

It would seem that your implementation is not good because you've changed the built-in shell. DOS games or apps that use shell commands to get files lists and the like can mess up with long filenames. A good implementation will require loading an alternate shell that is "LFN-aware" (i.e. uses the LFN functions of DOS 7). I suppose another option is some kind of toggle for the built-in shell.

In case you aren't aware, there is a TSR program named DOSLFN that adds LFN support to plain DOS, but I believe it relies on internal DOS structures that are not implemented in DOSBox's internal DOS emulation, and so will probably only work when booting real DOS. There is also a program named Instant File Access that adds LFN support to Windows 3.x, but I think it merely acts as a translation layer between the short names used by DOS and the long names in some kind of table.

ripsaw8080 wrote:

It would seem that your implementation is not good because you've changed the built-in shell. DOS games or apps that use shell c […]
Show full quote

Wengier wrote:

I think you are really talking about the implementation of LFN support. A good implementation of LFN will almost never cause any problems because the games or applications in the first category (i.e. those expect or rely on 8.3 names) will never call the AX=71xx functions, but will instead rely on the usual 8.3 name calls so the returned results will certainly be 8.3 names, and long names will be completely invisible to such games/apps. Only those games or applications in the second category (i.e. LFN-aware games/apps) will support and and then will benefits from LFN features. When LFN support is properly implemented, it will be no harm to any existing programs, in theory at least. On the other hand, it will give extra benefits to LFN-aware programs, which are also the intended effects of such programs.

Wengier wrote:

LFN support in DOSBox come with two parts, one is LFN support for shell commands such as DIR/CD/COPY (as well as the auto-completion feature of the Tab key)

It would seem that your implementation is not good because you've changed the built-in shell. DOS games or apps that use shell commands to get files lists and the like can mess up with long filenames. A good implementation will require loading an alternate shell that is "LFN-aware" (i.e. uses the LFN functions of DOS 7). I suppose another option is some kind of toggle for the built-in shell.

In case you aren't aware, there is a TSR program named DOSLFN that adds LFN support to plain DOS, but I believe it relies on internal DOS structures that are not implemented in DOSBox's internal DOS emulation, and so will probably only work when booting real DOS. There is also a program named Instant File Access that adds LFN support to Windows 3.x, but I think it merely acts as a translation layer between the short names used by DOS and the long names in some kind of table.

Thanks for your advice. The current build of LFN-enabled DOSBox will be seen as a "proof of concept" stuff, but it may actually evolve into a full-featured build that will take care all of this. Yes I am indeed aware of DOSLFN, and even had many communications to its author during its development. However, it is written in assembly (instead of C) and will also access disks directly, which is not allowed in recent versions of Windows (besides the fact that DOSLFN will not support NTFS drives obviously). The program named Instant File Access is also as you say not a real Win9x style LFN driver, but merely a translator.

You could use setting the reported major DOS version to 7 (VER SET 7) as a toggle for LFN support... just a thought. 😉

ripsaw8080 wrote:

You could use setting the reported major DOS version to 7 (VER SET 7) as a toggle for LFN support... just a thought. 😉

Thanks for the suggestion. It probably will actually work as this was also what I had done when I added LFN support to Paul Houle's Enhanced DOSKEY (http://paulhoule.com/doskey/) last month. Setting major DOS version to 7 or greater will cause DOSKEY to support quotation marks for Tab completion even if LFN API is not available, since (unlike MS-DOS 6.x or earlier) MS-DOS 7+ will understand quotes even in 8.3 only mode.

I guess another option is to use (external) shell command executables which support LFN and then have a switch to disable the built-in dosbox shell commands where applicable.

truth5678 wrote:

I guess another option is to use (external) shell command executables which support LFN and then have a switch to disable the built-in dosbox shell commands where applicable.

I think the implementation of DOS version emulation logic will be simpler to understand and easier to use, but in particular more extensible. This feature will essentially set the major DOS version that the user wants DOSBox to emulate, and the user can change this setting in dosbox.conf. For example, setting the emulated DOS version to 6 or earlier will disable LFN support, whereas setting it to 7 or greater will enable LFN support. This may be extended to certain other DOS version-specific features as well.

I was working on some other projects recently, but now I decided to update DOSBox LFN build once again after discussions with some other DOSBox users who are interested in this feature on other forums. By now I have already added the ability to turn LFN support on or off to the DOSBox LFN version. There is now a directive or command called "lfn" in dosbox.conf (see its [dos] section), which can be set to either true, false, or auto. When setting to "auto", LFN support will be enabled if and only if the major DOS version to report is set to at least 7 in dosbox.conf (e.g. by setting ver=7 in the file, which is now the default by the way), as suggested by ripsaw8080 earlier in this thread. But if you set lfn=true or lfn=false in dosbox.conf, then LFN support will be enabled or disabled regardless of what the major DOS version is set to be. Besides this feature, it will now also use the actual Windows SFNs instead of generating random SFNs by itself on Windows platforms (the latter approach is used by probably all original versions of DOSBox).

Regarding ISO image support also mentioned earlier, it should now support LFNs on RockRidge CDs, but not yet LFNs on Joliet CDs, since I have not been able to find some detailed information for this particular format.

I have attached the binary of this build (along with all required DLLs, zipped).

Is the source code patch available? Interested in testing under dosbox/95: http://support.microsoft.com/kb/152200.

truth5678 wrote:

Is the source code patch available? Interested in testing under dosbox/95: http://support.microsoft.com/kb/152200.

Sure, the source code patch is available. See attachment. Yes, I want to implement support for other CD formats too, but I was not yet able to find detailed information about the Volume Descriptor for Joliet CDs for example. It would be great if someone provides such information.

Furthermore, I have implemented mouse copy/paste support to DOSBox yesterday (not included in the above binary). Should I start a new thread for this feature?

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