VOGONS


First post, by Serious Callers Only

User metadata
Rank Member
Rank
Member

You know, paths that use "dir/anotherdir"

Because I know '\' doesn't work in linux but "/" does and "/" is also a path separator in windows, so it'd be 'best' if it worked on both for portable games and dosbox.conf. For .cue files tracks too, if they happen to be on a subdirectory.

Reply 1 of 10, by collector

User metadata
Rank l33t
Rank
l33t

Mount your "C:" drive with "mount c ." to mount the current directory. After mounting "C:" try to cd into the desired subdirectory and use "." to mount that directory as the drive you want. For imgmount cd into the subdirectory containing the image or cue file and mount it from there. This [autoexec] works on Windows. I do not currently have a box setup to test it on Linux, but I would imagine it would.

[autoexec]
cls
mount c .
c:
cd GameCD
rem e:
imgmount d Twinsen.cue -fs iso
c:
cd \
TWINSEN.EXE
exit

No path separators required if DOSBox is started from that conf if it is in the to be mounted "C:" folder. If you want something more elaborate you could just mount your C drive and run a batch file with a menu for multiple games in subdirectories under the mounted "C:" folder. Since it would be running in DOSBox all path separators in that bat menu could be "\" regardless of the host machine's platform.

The Sierra Help Pages -- New Sierra Game Installers -- Sierra Game Patches -- New Non-Sierra Game Installers

Reply 2 of 10, by Serious Callers Only

User metadata
Rank Member
Rank
Member

Yeah yeah i'm not a idiot, i know about workarounds for mount.

But those workarounds are generally terrible (cd into and out of each dir or put all games into a frankenstein 'c' and cd into each one and lose games being self-contained) and don't work if the path comes *from* a txt file like a cue or a gdi. Just tell me: *in windows does a relative path using '/' work for mounting, imgmount and cue files*?

Because a relative path using '/' as dir separator is totally legal in windows and linux and if this doesn't work it's simply a bug.

edit: there is another case where the 'cd' solution doesn't work. Imagine you have to imgmount multiple discs with seperate audio tracks. You can't compress the audio to gog/mp3/flac because imgmount won't let you put in relative paths and because the files would overwrite unless you changed all of cds tracks names to avoid name duplicates in order to combine all the tracks int a single dir.

Reply 3 of 10, by zirkoni

User metadata
Rank Member
Rank
Member
Serious Callers Only wrote:

Just tell me: *in windows does a relative path using '/' work for mounting, imgmount and cue files*?

Why don't you just test it and see what happens? Or do you not have a Windows machine available?

https://youtube.com/@zirkoni42

Reply 4 of 10, by Serious Callers Only

User metadata
Rank Member
Rank
Member

Yeah, i don't.

Reply 5 of 10, by konc

User metadata
Rank l33t
Rank
l33t

A relative path of what? And what does "/" and "\" have to do with relative paths? Those are 2 different things.
Yes, a "mount c c:/" works on a windows system.
No, a "mount c ../" doesn't (obviously) work. Do a .. of what? dosbox' executable?

Reply 6 of 10, by emendelson

User metadata
Rank Oldbie
Rank
Oldbie

But these work exactly as expected under Windows:

mount c: .
mount c: ..
mount c: ..\..\
mount c: ..\..\..\..\ [if that directory actually exists, of course]
mount c: ..\..\DIRNAME [again, if that directory actually exists]

And yes, "." is the directory containing DOSBox.exe and ".." is the parent directory.

Reply 7 of 10, by Serious Callers Only

User metadata
Rank Member
Rank
Member

It's not 'obvious' at all because windows is supposed to support '/' in several places as a path separator. And even if it didn't, it's not exactly *user friendly* to make users that might want to put their games on a pen drive and use them on different operating systems and force them to edit the conf (or even worse, cue) files every time.

The 'hacks' have the limitations i mentioned already.

I think would be simple to satisfy most people:

Make the unix syntax work for the cue parse of relative paths and all relative paths on the commands that accept paths (it has the least number of forbidden characters in filenames). In pseudocode:

def parse(path):
if path startswith(/) or path.startswith([A-z]:) #it's absolute, therefore useless for portability
return new File(path)
if OS.Win
path= replace("/", OS.PathSeparator, path)
File f = new File(path)
if ( !f ) #because the file had forbidden characters
warning, fail the imgmount mount, cueparsing command, return null etc
else
return f

Forbidden characters aren't a big problem here because FAT drivers in linux forbid the same characters. At most, the user couldn't copy if he tried to copy files with forbidden characters in filenames over from Ext4... it's really just the '\' in conf files imgmount arguments, mount arguments and cues.

Generally *if* windows allowed a mount of, say a squashfs VFS then... there would be problems if they kept the same forbidden characters (though i don't know why they'd do that).

So you just need to first replace any '/' by '\' (on windows), try to create the file to see if it can be represented and fail if not (reason of failure can remain unknown if you don't want to bother to check if the file has forbidden characters in the platform).

Linux destination side actually don't needs replacements because in this idea the windows style relative paths wouldn't get used on linux, but a subset of the linux style relative paths would be accepted on windows.

Last edited by Serious Callers Only on 2018-03-25, 00:34. Edited 20 times in total.

Reply 8 of 10, by konc

User metadata
Rank l33t
Rank
l33t
emendelson wrote:
But these work exactly as expected under Windows: […]
Show full quote

But these work exactly as expected under Windows:

mount c: .
mount c: ..
mount c: ..\..\
mount c: ..\..\..\..\ [if that directory actually exists, of course]
mount c: ..\..\DIRNAME [again, if that directory actually exists]

And yes, "." is the directory containing DOSBox.exe and ".." is the parent directory.

Yep, you're very correct about this. Wow, first time i see something similar. Definitely not expected, as it's NOT standard syntax behavior.
mount c ../ not OK,
mount c ../. is

Reply 9 of 10, by Azarien

User metadata
Rank Oldbie
Rank
Oldbie
emendelson wrote:
But these work exactly as expected under Windows: […]
Show full quote

But these work exactly as expected under Windows:

mount c: .
mount c: ..

And yes, "." is the directory containing DOSBox.exe and ".." is the parent directory.

I just tested this. As I guessed "." is *not* the directory containing dosbox.exe, rather it is the current directory from dosbox.exe's point of view. This may not be the directory that contains dosbox.exe, e.g. when DOSBox is run from a console window:

rem This is Windows console
cd c:\windows
c:\path\to\dosbox\dosbox.exe
rem This is DOSBox console
mount c: .

Bam! c:\windows mounted in DOSBox.

I would say this is standard and expected behavior. Every Win32 process has a notion of "current directory" as opposed to exe directory.

Reply 10 of 10, by Serious Callers Only

User metadata
Rank Member
Rank
Member

Ok that current directory digression is fine and all, but can i get a dev commenting on why not parse unix style relative paths on all platforms? It's not like you even have to worry about filtering forbidden characters (they wouldn't work anyway) because the games were originally for dos.

The current situation is simply terrible for portability and the 'workaround' of using 'cd' on every dir is both terrible and doesn't work for imgmount of multple cds or tracks in cues. It's not like all commands need to be altered, just whatever reads cue tracks, cd, mount and imgmount to convert those paths to windows style on windows.

It's not even a big jump because windows is supposed to support forward slash relative paths (they do the exact same thing, convert forward slashes to backwards behind the scenes).