As long as you keep the same mountings when you run the game as when you installed the game, you can use all kinds of long paths. Because those long paths and directory names you use in the mount comman will ALWAYS be translated into a single driver letter.

Ok, I kinda found out what the problem is...

I used the standard template for all the games, meaning the VirtualHD folder gets mounted to C:\. If you check drive C:\ in a running dosbox it has (as would be expected) several folders:

(commander keen games)

COMMAN~1
COMMAN~2
COMMAN~3
...

Now, for some reason, the order is not the same as D-Fend RL assumes. So, some of them try to start the exe from the right folder, and some don't. My CK4 tries to start from COMMAN~1 (I added them to D-Fend in their chronological order though) where it doesn't finde keen4e.exe, obviously.

Is there any workaround/fix for this other than mounting the game directory itself rather than VirtualHD?? While still using the long paths that is.

My God! That's twisted even for the n00bs in this board.

My God! That's twisted even for the n00bs in this board.

huh? maybe it's because I'm German but I have no clue what you just said

I meant that it would take a very unexperienced user to use long filename folders in such a way that it would be confusing for DOSBox.

That's just my opinion, anyway.

it happends 😀
things like
Master of orion
Master of orion 2
and unzipping the latter first. but usually these aren't experienced dos users.

it is not confusing for dosbox at all.
but for frontends that try to navigate to the folder in dosbox.

@Neville

I don't think you understand the problem. For various reasons using 8-letter folder names is not an option for many despite knowing it would mean less problems. While DOSBox itself has no problems with shortening the names, any front-end needs to create the exact same short name to directly launch a file correctly.

Now, for example, I've installed all 7 Commander Keen in their release order and named all folders like the full correct title of the games. Which means I have 7 folders in DOSBox COMMAN~1 to COMMAN~7. No problem when you start the games manually. For some bizarre reason though, Windows creates different short names for some of the folders. It has COMMAN~1 to COMMAN~4 but 3 completely different ones, CO6SOMETHING and CO7SOMETHING I think. DFRL seems to use these names, which of course creates the problem that the folders don't match the ones actually present in DOSBox and as such, the automatic game start doesn't work.

Do as I do: Create folders with long names, and inside each folder create a folder called C-drive. Then mount the C-drive folder in your frontend.

Thanks hydr0x for explaining.
In short and in general:
Up to 0.4.0 DFR used the Windows-API function for making short names. (This worked fine if you do not have folders with the first 6 chars identical.)
Since 0.5.0 I'm using some Qbix inspired algorithm for resorting the ~1 ~2. But sometimes Windows makes some really strange short names (see hydr0x's post) and this breaks the idea of simply reassigning the numbers. I've already found the make-short-name function in the DOSBox source code and will build some new own function for DFR from this.

So if 0.4.0 works fine for you, very good. If you have problems with long names probably 0.5.0 fixes then. And if you still have problems 0.6.0 will (hopefully) fix them finally.

(But why Windows sometimes uses "CO6803~1" as short name for "Commander Keen in Invasion of the Vorticons - Episode One - Marooned on Mars" will always stay a mystery to me.)

hydr0x wrote:

@Neville

I don't think you understand the problem.

True. English is my third language, and when I read the first explanation of the problem I understood the problem occurred when somebody had two or more folders which first six characters were the same character.

As in:

AAAAAA1

AAAAAA2

And that seemed to me very unlikely. Only later, when Qbix mentioned the examples I understood.

The funny thing is that I have folders named in such fasion, like "Prince of Persia I" and "Prince of Persia 2". I guess I didn't have any problems with them because I created them chronologically.

Use KEEN1 to KEEN9 or play counterstrike.

Hi Neville,
ok, perhaps my explanation was a bit unclear. Sorry for this. And yes, if chronical order=alphabetical order for your long files names, everything was right for you in all versions. Indeed the problem was reported the first time with "Prince of Persia 1" being PRINCE~2 and "Prince of Persia 2" being PRINCE~1. 0.5.0 can handle this and 0.6.0 will hopefully be able to get the last things right, too.

@wd:
I really do not understand your problem. I think DOSBox is one of the best pieces of software I have ever seen. The only thing missing is a GUI that allows unexperienced users (and users being to lazy to work with the conf files all the time) to use it. (And no, I do not think somebody not able to understand the DOSBox readme is not worthy using DOSBox.) So I'm trying to make a good frontend for it. DOSBox can handle long file names (by making short versions and offering this versions to the programs inside DOSBox). And by the way I think the plattform independent way of DOSBox of making short names is very reasonable. So why shouldn't I try to make DFR able to handle this ?

I really do not understand why you say use short names or go away (=play cs) although DOSBox can handle the long file names (so everything should be fine from your point of view) and the only thing missing is support for some rare things in DFR (and this is my problem). I could understand if you would say DFR is bad because it doesn't use the same short names as DOSBox does under all circumstances but not this.

If all user request in history would have been answered this way we would not have left medieval yet. (Do not misunderstand me: It's absolutely ok to say "Yes, sound reasonable, but I've no time or don't feel like implementing this.") But answering a request (not even addressed at you) by saying go away is not very nice (at least I think so).

I don't know what wd's problem is either. I also don't know what hydr0x problem is, and why he needs to use long file names in DOSBox. All I have heard so far is "various reasons". Frankly there is no need to use those convoluted names, neither when organizing or playing the games.

So why shouldn't I try to make DFR able to handle this ?

Did i say it shouldn't? I was just replying to that "i've got 7 keen directories and am confused" guy.

Hi MiniMax,
of course there is no need to use long names for directories used with DOSBox, but Windows is supporting long path names, DOSBox is supporting long path names (by making them short for DOS progams) and DFR is supporting the DOSBox way of making short names (with the bug described above).

So I think the right thing if a user wants to use long names (for what reason ever) is to fix the bug in DFR and not telling the user not to use long path names or even asking him if he really needs long names.

Greetings and good night
Alexander

Did i say it shouldn't? I was just replying to that "i've got 7 keen directories and am confused" guy

Where did I say I was confused? All I did say was that it doesn't work. Of course I know DOS itself does not support such path names but DOSBox does, and so does the frontend. If, despite the support for this, it doesn't work as it should, it's a bug. All I did was report this bug and Alexander, apparently being a much more user oriented dev than you are, perfectly understood the situation and tries to fix the bug so people can use the full functionality DOSBox offers with his frontend. Where's the problem?

For my reasons to use long filenames, there's two basic things to say. 1) Why the heck do you care? I'm a free person and If I want to use this feature offered by your programs I'm allowed to do so. 2) If you think it's such a stupid feature to have, why did you include it in DOSBox to start with. Go ahead and remove it, you'll make a lot of friends among your users.

But if you really need to know, the main reason I'm using the full game names is that, well, they are the full game names. How often have I heard you devs complain about bug reports using some weird abbreviation for a persons favorite game. I do not want to use shortened names that I can't remember anymore in a year or two (It was bad enough back in the day, even with the limited disk space). I also don't want to have to make up a different short name if the logical one is already taken by another game. Additionally, it's just a principal thing. I'm the maintainer of a video game database and accuracy is the nuts and bolts of such a project. I want the DOS game names from the database reflected 1:1 in my installation of those games.
Now, I could of course achieve all this in the frontend and still use short directory names the frontend points to. But (no offense Alexander), it's stupid to assume that any given tool will be here forever and if I ever have to leave DFRL behind and switch to something that doesn't offer an import for its database/profiles I'd be ****ed. My game directory though, with all the correctly named subdirectories will always be with me (yes, I have secondary off-location backups, the chance that I will lose the folder is very very low), allowing me to not be depend on a single tool.

But enough of this, I do not have to defend myself for using a given feature of your application.

And I use long folder names myself, but I do it the correct way.

Here is a view of my OldGames tree. Each game is kept in a separate folder with a the long, descriptive name. Inside each game-folder, I have a C-drive folder that gets mounted. That way, I never ever have to deal with long names inside DOSBox, and neither do the games themselves.

1C:\DOCUMENTS AND SETTINGS\MINIMAX\MY DOCUMENTS\DOSBOX\OLDGAMES
2|
3+---Aleshar - World of Ice
4|   +---C-drive
5|   |   \---GAMES
6|   |       \---ALESHAR
7|   +---capture
8|   \---Unpacked
9|       \---aleshar
10|
11+---Beneath a Steel Sky
12|   +---C-drive
13|   |   \---SKY
14|   +---capture
15|   \---Unpacked
16|
17+---Colonization
18|   +---C-drive
19|   |   \---MPS
20|   |       \---COLONIZE
21|   +---capture
22|   \---Unpacked
23|       \---COLDOS
24|           \---PATCHES
25|
26+---Command & Conquer - Red Alert
27|   +---C-drive
28|   |   \---WESTWOOD
29|   |       \---REDALERT
30|   +---capture
31|   \---Unpacked
32|       \---RedAlert1_AlliedDisc
33|           +---RedAlert1_AlliedDisc
34|           |   \---XP_Patch
35|
36+---Death Rally (Shareware episode)
37|   +---3D Realms Site  Death Rally-filer
38|   +---C-drive
39|   |   \---RALLY
40|   +---capture
41|   \---Unpacked
42|
43+---Descent
44|   +---C-drive
45|   |   \---GAMES
46|   |       \---DESCENT
47|   \---capture
48|
49+---Dragons History 2006
50|   +---capture
51|   \---Czech manual
52|
53+---Headline Harry
54|   +---C-drive
55|   |   \---HH
56|   +---capture
57|   \---Unpacked
58|
59+---IndyCar Racing II (Demo)
60|   +---C-drive

61|   |   \---ICR2
62|   |       +---CARS
63|   |       |   \---CARS95
64|   |       +---EFFECTS
65|   |       +---OBJS
66|   |       +---ROL
67|   |       +---SOUND
68|   |       \---TRACKS
69|   |           +---LAGUNA
70|   |           \---MICHIGAN
71|   \---capture
72|
73+---Magic Carpet Plus
74|   +---C-drive
75|   |   \---CARPET.CD
76|   |       +---DATA
77|   |       +---LEVELS
78|   |       \---SAVE
79|   \---capture
80|
81+---Quake (Shareware v. 1.08)
82|   +---C-drive
83|   +---capture
84|   \---Unpacked
85|       +---BIN
86|       +---MANIFEST
87|       \---Quake RM
88|
89+---Sam & Max Hit the Road (Demo)
90|   +---C-drive
91|   |   \---SNMDEMO
92|   +---capture
93|   \---Unpacked
94|
95\---Wolfenstein 3D - Shareware episode
96    +---3D Realms Site  Wolfenstein 3D-filer
97    +---C-drive
98    |   \---WOLF3D
99    +---capture
100    \---Unpacked

Each long-name folder contains a dosbox.conf file for that game, and it always starts out with key information about the game. Like this for Red Alert:

1# Title:        Command & Conquer - Red Alert
2# Developer:    Westwood Studios
3# Publisher:    Virgin Interactive
4# Year:         1996
5# Genre:
6# Status:       Freeware (as of August 31, 2008)
7#
8# Link:         http://www.ea.com/redalert/news-detail.jsp?id=62
9# Link:         ftp://ftp.westwood.com/pub/redalert/updates/RA108USP.EXE
10#
11# MD5-sum:      6f6fe85caf92774fff6ec731872c1f62 *CD1_ALLIED_DISC.ISO
12# MD5-sum:      94dd7b393bcde22e6153c5771653bfc4 *CD2_SOVIET_DISC.ISO
13#
14# Archives:     RedAlert1_AlliedDisc.rar
15# Install:      D:\Setup.Exe
16# Run:          C:\Westwood\RedAlert\RA.Exe
17# Setup:        C:\Westwood\RedAlert\Setup.Exe
18# Save-games:   C:\Westwood\RedAlert\SaveGame.00?
19# Game-configs: C:\Westwood\RedAlert\RedAlert.Ini

That's a very nice setup I will consider. It does currently conflict with the frontend though, which I want to use for it's functionality of showing the screenshots and meta data. Well, it could be done that way in the frontend, but I think I'd have to manually set up the capture folders for every game, which is now done automatically.

Btw, the C&C genre is Strategy->RTS 😉

Where's the problem?

Did i say that was a problem? I even told you the solution.