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.
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.
1[autoexec] 2cls 3mount c . 4c: 5cd GameCD 6rem e: 7imgmount d Twinsen.cue -fs iso 8c: 9cd \ 10TWINSEN.EXE 11exit
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.
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.
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?
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:
1def parse(path): 2 if path startswith(/) or path.startswith([A-z]:) #it's absolute, therefore useless for portability 3 return new File(path) 4 if OS.Win 5 path= replace("/", OS.PathSeparator, path) 6 File f = new File(path) 7 if ( !f ) #because the file had forbidden characters 8 warning, fail the imgmount mount, cueparsing command, return null etc 9 else 10 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.
emendelson wrote:But these work exactly as expected under Windows: […] Show full quote
But these work exactly as expected under Windows:
1mount c: . 2mount c: .. 3mount c: ..\..\ 4mount c: ..\..\..\..\ [if that directory actually exists, of course] 5mount 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
emendelson wrote:But these work exactly as expected under Windows: […] Show full quote
But these work exactly as expected under Windows:
1mount c: . 2mount 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:
1rem This is Windows console 2cd c:\windows 3c:\path\to\dosbox\dosbox.exe
1rem This is DOSBox console 2mount 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.
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).