i was mainly interested in the answer to the first part of the question 😉
but i guess "unrelated to LFN" means "No"? 😉
Some info about Town With No Name (and also Psycho Killer by the same developer):
The games were either co-developed for CDTV or developed there and ported to DOS (link, link), which is the origin of the long filenames on the CD. Although the discs were mastered with a filesystem supporting long filenames, DOS does not see more than the first 8 characters of the filename and the first 3 characters of the extension.
The issue with DOSBox was that the filenames weren't clipped to 8.3 like in real DOS (*weren't* because the issue is resolved in SVN when using IMGMOUNT with a disc image, but the issue still exists with MOUNT because supporting the 8.3 clipping in the disk cache is complicated).
At any rate, these games are NOT examples of why LFN support is needed for DOS games. If anything, they demonstrate that rigorous enforcement of 8.3 is necessary. IMO, the only reason for LFN support is games that were developed to run under a Windows-tinged DOS like with Win9x, and that's not what DOSBox targets.
Sorry... what then, exactly, does DosBox target?
I thought it targeted running apps under DOS. Joe Consumer would, therefore, expect that a program that says "DOS" will run under DosBox.
Hey... I agree that it may be more work than it's worth to fix this specific problem, but I am surprised that you blame it on not being in the scope of what DosBox intends to do.
I mean, if you just don't want to fix the MOUNT command, then OK. Or, are you saying you'd reject a patch which fixed the 8.3 issue in the disk cache?
what then, exactly, does DosBox target?
dos games
I mean, if you just don't want to fix the MOUNT command, then OK.
Feel free to post a patch.
wrote:I am surprised that you blame it on not being in the scope of what DosBox intends to do.
DOSBox targets DOS 5/6, which don't need LFN support; this is only a statement of fact, there is no "blame" for anything. Maybe DOSBox will be expanded at some point to support DOS 7+, but there's more to that than just LFN services.
wrote:if you just don't want to fix the MOUNT command, then OK. Or, are you saying you'd reject a patch which fixed the 8.3 issue in the disk cache?
It seems like you've combined the 8.3 filename clipping issue with MOUNT and LFN support, although they are separate things, but who said anything about not wanting to fix the filename clipping issue? I said the issue still exists with MOUNT because fixing it is complicated. I look forward to seeing your patch for the disk cache that can handle identical rather than unique short names.
wrote:DOSBox targets DOS 5/6, which don't need LFN support; this is only a statement of fact, there is no "blame" for anything. Maybe DOSBox will be expanded at some point to support DOS 7+, but there's more to that than just LFN services.
Hey... I can't read everything around here, but taking a quick look at your "Information" page and the main page of the DosBox wiki, there is absolutely nothing limiting the upper version of DOS to 5/6.
If DOS 5/6 is all you want to worry about.. that's fine. But, if it's not posted, don't expect people to avoid posting about DOS 7 or WinDOS issues.
wrote:It seems like you've combined the 8.3 filename clipping issue with MOUNT and LFN support, although they are separate things, but who said anything about not wanting to fix the filename clipping issue? I said the issue still exists with MOUNT because fixing it is complicated. I look forward to seeing your patch for the disk cache that can handle identical rather than unique short names.
I'll take that as a challenge. (Which, in all honesty, I'll probably fail.) However, I don't have to get it to handle identical short names. All I have to do is get it to do whatever DOS did. If it can do it, then I can do it.
I mean.. if a program crashes under DOS, then I feel compelled to make DosBox crash as well under the same circumstances. 😉
wrote:If DOS 5/6 is all you want to worry about.. that's fine. But, if it's not posted, don't expect people to avoid posting about DOS 7 or WinDOS issues.
I don't think anyone expects people to avoid reporting such issues; rather, I think the devs like to hear them, as it could help in deciding whether enhancements are really needed... just my opinion. I don't think you'll find many reports for DOS7+ issues, though.
wrote:However, I don't have to get it to handle identical short names. All I have to do is get it to do whatever DOS did. If it can do it, then I can do it.
DOS (through MSCDEX) can handle identical filenames in the same directory, and with the clipping you most definitely can get identical short names from different long names, so fixing the issue means you DO have to change the disk cache to "get it to do what DOS did". Don't say no one told you it would be challenging, but I sincerely would like to see the issue resolved, so thanks for taking a crack at it, and good luck.
wrote:I don't think anyone expects people to avoid reporting such issues; rather, I think the devs like to hear them, as it could help in deciding whether enhancements are really needed... just my opinion. I don't think you'll find many reports for DOS7+ issues, though.
That's the attitude I would prefer to see, but, frankly, reading this thread came across more like, "That's not real DOS, so go away." If your attitude would have been taken, it would have been more, "Yeah.. we know.. it's a rarely used feature. Feel free to make your own fix and submit it, but, honestly, I doubt we'll have time to get to it."
wrote:DOS (through MSCDEX) can handle identical filenames in the same directory, and with the clipping you most definitely can get identical short names from different long names, so fixing the issue means you DO have to change the disk cache to "get it to do what DOS did". Don't say no one told you it wouldn't be challenging, but I sincerely would like to see the issue resolved, so thanks for taking a crack at it, and good luck.
If I recall, it took the first 5 or 6 characters, appended a '~' and a unique number. At least that what Win9x did.
What I don't know is how a program would expect to open on of the LFN files. I guess I need one of these program that does it.
Anyone have an image of this "Town with No Name" that I can borrow? Or another DOS program that uses LFN?
At least that what Win9x did.
And that's exactly NOT what dos does.
this thread came across more like, "That's not real DOS, so go away."
No the attitude is "LFN is not supported in back-then-msdos" so no old game cares.
wrote:And that's exactly NOT what dos does. […]
At least that what Win9x did.
And that's exactly NOT what dos does.
this thread came across more like, "That's not real DOS, so go away."
No the attitude is "LFN is not supported in back-then-msdos" so no old game cares.
Ok.. save me some time and tell me what DOS does do, then. When I load up a CD with LFN and MSCDEX, what does a directory show me? I won't be able to get to it until next week, anyhow.
You're saying that "Town with No Name" doesn't care? It's a 1993 game. It runs under DOS. It doesn't run under DosBox because it has LFN and you can't use the normal MOUNT -t cdrom command. At least, that's what I get from reading this thread.
Are you saying that "Town with No Name" would not run off of DOS 6.22?
ripsaw already wrote in detail how the CD file names are cropped and why the current mangling in dosbox
for the non-images does not work with that game. Adding any sort of LFN handling would actually
screw up this game under msdos since it won't find the cropped files.
Real DOS would not allow identical filenames in the same directory under "normal" conditions. One could edit a directory entry at the low level to create duplicates, but that is not a normal condition.
AFAIK, the only situation where you can get duplicate/identical filenames in the same directory under normal conditions is through MSCDEX and a disc with long names such as TWNN and Psycho Killer. In this situation, the long filenames are clipped to 8.3 by real DOS, but DOSBox is converting them to short/mangled form with a tilde like Windows when using MOUNT (IMGMOUNT is already fixed, it does not use the disk cache).
The practical reality is that people will sometimes mount folders in DOSBox that contain long filenames, and the decision was made to use Windows-style name mangling for unique short names rather than clipping that can cause duplicate/identical short names, and I'm sure that decision was carefully considered. FYI, a patch was recently put in SVN to support WINE-style name mangling.
As I see it, to fix the issue the disk cache should be able to handle duplicate filenames when the drive is of cdrom type, but continue to use mangled unique names for other drive types, and therein lies the complication.
wrote:Real DOS would not allow identical filenames in the same directory under "normal" conditions. One could edit a directory entry a […]
Real DOS would not allow identical filenames in the same directory under "normal" conditions. One could edit a directory entry at the low level to create duplicates, but that is not a normal condition.
AFAIK, the only situation where you can get duplicate/identical filenames in the same directory under normal conditions is through MSCDEX and a disc with long names such as TWNN and Psycho Killer. In this situation, the long filenames are clipped to 8.3 by real DOS, but DOSBox is converting them to short/mangled form with a tilde like Windows when using MOUNT (IMGMOUNT is already fixed, it does not use the disk cache).
The practical reality is that people will sometimes mount folders in DOSBox that contain long filenames, and the decision was made to use Windows-style name mangling for unique short names rather than clipping that can cause duplicate/identical short names, and I'm sure that decision was carefully considered. FYI, a patch was recently put in SVN to support WINE-style name mangling.
As I see it, to fix the issue the disk cache should be able to handle duplicate filenames when the drive is of cdrom type, but continue to use mangled unique names for other drive types, and therein lies the complication.
wd -- If you're referring to the explanation above, I must have missed it if it was explained elsewhere. Apologies.
The compromise that was made makes perfect sense to me. As does ripsaw's suggestion on how to mangle cdrom files differently. EDIT: I originally asked where the complexity was, but then noticed I had missed ripsaw's final sentence which stated it was there, so I'll trust that I just haven't looked into it.
(One other compromise would be to mangle the first non-unique 8.3 LFN by truncating and the rest ala Win95.)
I don't know enough of the required runtime environment needed by TWNN to discuss it any further with any intelligence. If it runs under DOS 6.22 with no special drivers, then I'll be happy to look into why it doesn't run under DosBox. If it doesn't run under DOS 6.22, I'm happy with the call that DOS 6.22 is the maximum DOS that DosBox attempts to emulate.
It does run under plain dos since it only needs one of the duplicate (though non-identical) files.
And it's just by luck or careful testing that the right duplicate file was opened?
I wonder if the program attempts to open the filename with a long filename or if it's coded to use the truncated one.
Well.. it's a challenge. If I come up with an implementation of ripsaw's suggestion that truncation is used for cdrom mounts, that'll be acceptable for the next DosBox version?
I'll still need a copy of the game, if anyone can provide one.
The complication is that the disk cache currently relies on a 1:1 relationship between short and long names; duplicate short names mess up that relationship. Also, when you try to open a filename that has duplicates, DOS/MSCDEX will choose the "first" one, presumably in internal directory order, but how does "first" translate in MOUNTed folders? (with IMGMOUNT there is no uncertainty about order).
wrote:The complication is that the disk cache currently relies on a 1:1 relationship between short and long names; duplicate short names mess up that relationship. Also, when you try to open a filename that has duplicates, DOS/MSCDEX will choose the "first" one, presumably in internal directory order, but how does "first" translate in MOUNTed folders? (with IMGMOUNT there is no uncertainty about order).
Excellent points!
The short answer to your question is that you can't. Once you require a specific ordering of files that you can't reproduce, you're stuck.
If, however, you could solve the ordering issue, the problem becomes simple. You just replace the first of the would-be duplicates with the truncated name and then use Win95 standard for the rest.
For instance:
Filename1.xxx -> Filename.xxx
Filename2.xxx -> Filena~2.xxx
Now it works both ways. But it all hinges on the ordering issue.
For the particular game in question, couldn't they just rename the appropriate files to the appropriate truncated name, delete the rest of the would-be duplicates, and run normally?
Here's what the games do from my previous analysis:
There is a directory on the discs containing MS-DOS specific files, and among these files is a text file with a table that translates long names to short names, but there is only an entry in the table if the clipping of the long name produces a duplicate that is not the "first" duplicate. There is a copy of the listed files with a unique short name in this folder that the game opens instead of the non-first duplicates that DOS can't open. However, if the long name is not listed because there are no duplicate short names, then the game uses the full long name to open the file and expects DOS/MSCDEX to open it, whether that means internally clipping to 8.3 or whatever.
Now, given the game's methods, you may be thinking: why not just "drop" every duplicate short filename after the first? I thought about that initially, but remember that "first" might not be straightforward because the host OS can have its own ideas about that for MOUNTed folders. (Windows file sorting does some strange stuff with filenames containing numbers, for example). Also, the fact is that the duplicate filenames do show up in a directory listing of the disc under real DOS, so just dropping the dupes is not accurate.
Yes.. I get that. Once you've lost the original order, you can't really get it back.
So, you're sunk unless you provide additional information to DosBox. It's not complicated, but it would have to be done on a game-by-game basis to provide the file mapping. If it turns out that the method you described was pretty common, then all you really need is the directory and text file name to handle those cases. If you really wanted to spend the time, you could search for it... locate the directory, location the file, compare short and long file names to figure out the 'first' one, etc.
I'm just talking... it may not be that common, and, as you've all noted, there just aren't that many games to deal with. Maybe for those, it would be best to provide instructions on renaming/moving files so that it would work. I don't mean for DosBox to provide that information, but for the community.
For the few games it seems enough to make an image of the CD and imgmount it, so no further instructions needed IMO
