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)
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?
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.
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.
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)
ripsaw8080 wrote: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:You could use setting the reported major DOS version to 7 (VER SET 7) as a toggle for LFN support... just a thought.
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.
truth5678 wrote:Is the source code patch available? Interested in testing under dosbox/95: http://support.microsoft.com/kb/152200.
Users browsing this forum: No registered users and 1 guest