What I tend to do in my DOSBOX setups is in the config file, I MOUNT the DOSBOX home directory as drive Y.
I always use full paths when I mount because I can then retirect the output of MOUNT within DOSBOX to get the
actual host paths for the mounted drives.

If you would like, I can easily write a little .COM utility which will set a DOSBOX environment variable to the host path used
to mount the specified drive...

I have also patched my copy of DOSBOX to use "DOSBOX.INI" as the config file name instead of DOSBOX.CONF this
avoids compatibility problems the DOSBOX generated "short" versions of long filenames on it's host (which can
change from one session to the next) this lets me reliably read (and update) the config file from within a program
running under DOSBOX (but you shouldn't have to do this for what you want to do).

Dave

Just added GMNT.COM to my DBUTIL archive.
Gets the host MouNT point for a DosBox drive into a DosBox environment variable.

Little bit tricker than I anticipated, DosBox apparently destroys environment variables created by a program when that
program terminates - GMNT.COM makes a temporary batch file you must run to actually SET the environment variable.
(It does at least delete itself).

Hopefully it will still be useful. Was at least a little bit enjoyable writing it!

Dave
Search "Dave's Old Computers" see "my personal" at bottom!

Re-reading your post, I think you migh be looking for something a bit
more complex tahn finding the DosBox home directory:

The dosbox command: config -l
on my system outputs: ';;' lines are comments that I have added

;;-------------------------------------
;; I tend to just copy DosBox into a directory (usually C:\DosBox) and
;; "just run" the .EXE, keeping my DOSBOX.INI in that directory and DosBox
;; finds and uses it. I don't use DosBox commands to update the config
;; because that contributes to the "droppings" left in places like AppData
;; So the following is completely incorrect for my instance (there is no
;; "AppData\DosBox" folder, but if you "installed" DosBox the following
;; line might be correct, and could be the best was to find the config path.
DOSBox SVN_MB6 configuration directory:
C:\Users\Dave\AppData\Local\DOSBox\

;; This was a test run with: DOSBOX -conf r:\DOSBOX.INI
;; It appears to actually contain the specified path, but this could
;; be tricky if you use a relative path like: -conf ..\..\asub\DOSBOX.INI
Primary config file:
r:\DOSBOX.INI
;; When I just launch DOSBOX and let it find my config file in the
;; DosBox home directory, this just reads
DOSBOX.INI
;; Worth noting that it does have the file name correct, as I have patched
;; my DOSBOX.EXE to use "DOSBOX.INI" which is more consistant within DosBox
;; than "DOSBOX.CONF" **

;; I have a shortcut which launches: C:\DosBox\dosbox.exe
;; So this indicates the full path which was used in the command
DOSBox was started with the following command line parameters:
C:\DosBox\dosbox.exe -conf r:\DOSBOX.INI
;; If I just go to C:\DOSBOX and run: dosbox
;; It just reads
dosbox
;;-------------------------------------

This output can be redirected to a file and might provide everything you
would need for a smarter version of my "GMNT" which would get the actual
location of the running config file. This could work if:
- DosBox is installed and "configuration directory" is reported correctly.
-or-
- DosBox was launched with -conf specifying a full path
-or-
- DosBox found a config file in it's home directory -and-
- DosBox was launched speecifying it's full path

Again, I could create a simple tool to do this, but I would need you
to send me the output of: config -l
for the cases where you want to be able to find the config, as well os
what you would like to see set in an environment variable.

Dave

** If you want to know what I'm talking about with long filenames
not being always consistant, try this (Windows host):

echo 1 >Longfile1.file
echo 2 >Longfile2.file
echo 3 >Longfile3.file
del Longfile2.file

As expected, this leaves two files, which are:

Long-Name Short-Name Content
-------------- ------------ -------
Longfile1.file LONGFI~1.FIL 1
Longfile3.file LONGFI~3.FIL 3

Now, if you run DosBox and look, you will find two files:

Name Content
------------ -------
LONGFI~1.FIL 1
LONGFI~2.FIL 3

Note the discrepancy between the Windows short name vs the DosBox
name of the file containing '3'.

Use of DOSBox SVN MB6 has been discouraged since it is abandoned many years. On the other hand, there is full long file name (LFN) support included in DOSBox-X which fixes the LFN <=> SFN conversion issue, apart from the main LFN feature. So the SFNs are indeed consistent, as long as they are available in the host system. The main LFN feature can be enabled with either ver=7.1 or lfn=true in the DOSBox-X configuration.

I have updated my DBUTIL archive, replacing GMNT.COM (Get MoNT path) with
GDBCM (Get DosBox Config/Mount information into env variable).

This addresses the points I made in a previous post, and lets you get
at various bits of information available in the output of the "config"
and "mount" commands.

>Use of DOSBox SVN MB6 has been discouraged since it is abandoned many
>years. On the other hand, there is full long file name (LFN) support
>included in DOSBox-X which fixes the LFN <=> SFN conversion issue, apart
>from the main LFN feature. So the SFNs are indeed consistent, as long as
>they are available in the host system. The main LFN feature can be enabled
>with either ver=7.1 or lfn=true in the DOSBox-X configuration.

I debated responding to this for a while, I see you've posted essentially
the same thing in my thread about the availability of my tools.

I don't think it's particularily relavent to this discussion. Perhaps
DosBox-X has new features to let you more easily access this information,
but I didn't see that mentioned in your posting.

I woldn't think the fact that I happened to test this on an older DosBox
version would matter to this. It is possible that the tool I provided
might not work if DosBox-X has changed the output displayed by "config"
and/or "mount" - but it seemed to look the same to me...

I also think you misunderstand - I DON'T *want* to use long filenames in
DosBox - DOS didn't get LFN's until it became a launchpad for WinBlows.
I still have a couple of DOS systems running, and they are both using DOS 5 ..
no long names.

I'm also someone who uses and is very familier with the command line. so...
I tend to avoid long filenames because I'm not a big fan of excessive
typing. I "grew up" on systems with small filenames (sometimes less than 8.3)
and as a reflection of that, my filenames tend to be short (unless long makes
sense).

The reason I mentioned in is my post is that although DosBox seems to be
somewhat oriented toward short names.. but.. it *forces* you to use a
long name if for any reason you want to access the configuration file.
For some unfathomable reason even though the progam was called DOSBOX.EXE,
uses short names for it's other resources, DLL etc., it was "decided" that
the perfect name for the config file would be "DOSBOX.CONF" - almost a
short name.. but the 4 character extension breaks he 8.3 rule.

And for the reasons I already stated this is not consistant within DOSBOX.
Thats behaviour is OK with me because I have LOTS of DOS tools which don't
know about LFN's - in fact I don't know that I would have done anything
differently (other than use a 8.3 name for the config file) because for hosts
which don't have native "8.3 short names" you would have to implenet and
maintain your own database within DosBox to make the short names consistent.

So my copy of DOSBOX has be patched to use a short name for the config file.
and that makes everytihing work to my liking. I don't want LFN support in
DOS ... I just don't want to be forced to use LFNs in related files.

And I have no doubt that had I not explained why, there would have been people
telling me how much it was "wrong".

I've looked at DosBox-X and there are some improvments in it that I like...
but I haven't climbed on that bandwagon yet because there are a couple of
things I'm not so sure about:

- A per above, it's much more into long filenames. Older DosBox was almosts
all short names except for .conf which was "close". DosBox-X appears to have
departed from this quite a bit - and sure, I could redesige all my DOS tools
to use the (Windows versions of DOS) LFN interface, but that would be a lot
of work considering that I don't need/want LFN's in DOS.

- It's pretty massive. MegaBuild 6 which I use most .EXE is less than 3megs,
I don't recall the details of -X which I don't have on this system but IIRC
it's .EXE was over 12meg. >4 times is more than a few fixes and additions.

Sure, I know - everyone has Gigs of RAM and Terabytes of drive space - so
why would it "matter". In my experience a big project (and DosBox was big to
start) rarely gets more reliable when "lots of stuff" is added to it.
I haven't looked at the -X source, but I wouldn't at all be surprised if a
lot of this were "libraries" which have been bludgeoned enough to mostly do
something like what was wanted - I don't want to argue the point, but I
generally don't quite trust projects which increase so dramatically.

Anyway, don't want to argue or belabour this subject, just letting you
know my thoughts.

Dave

in svn, you can use -pr as parameter to mount to let paths be relative to the configuration file location.

Qbix wrote on 2021-05-26, 17:49:

in svn, you can use -pr as parameter to mount to let paths be relative to the configuration file location.

Indeed, since the latest DOSBox SVN has such a hidden option in its MOUNT command, the OP may achieve his need using something like the following when using the current DOSBox SVN (or DOSBox forks incorporating latest SVN commits including DOSBox-X, ECE, or staging):

1mount -pr Y .
2imgmount D Y:\GAMECD.IMG -t cdrom

Meanwhile, for DaveDDS, I understand what you were saying and I appreciate your reply, but since this thread is not intended for such detailed comparisons between DOSBox forks (my original comment for these forks was only one paragraph), I just want to mention that LFN is an *optional* feature in DOSBox-X and in fact disabled by default, but can be enabled for anyone who desires it (the LFN <=> SFN conversion fix is always enabled though as long as SFN is available in the host system). And MS-DOS 7.x which supports long filenames (LFN) is certainly NOT just a launchpad for Windows - I used it as a FULLY standalone DOS (and as my primary OS) for many many years indeed (much longer than MS-DOS 6.x for example), although I only enabled the LFN feature (via DOSLFN) about 40% of the time but not always (I like MS-DOS 7.1 especially because of apparent advantages like large HDD and FAT32 support which simply do not exist in older DOS versions), and you don't need to type filenames because there is filename auto-completion feature (via Tab key) available (using Enhanced DOSKEY in the case of MS-DOS, and as a built-in feature in DOSBox-X). As for the binary size, I agree that the size of DOSBox-X is bigger than DOSBox MB, but so are other forks like DOSBox ECE. DOSBox-X has everything included in one single EXE file without requiring any additional DLLs to run, whereas forks like DOSBox ECE and MB6 may require several DLLs in order to run, and EXE + DLLs for say DOSBox ECE take at least 8MB too because of libraries such as FluidSynth support, and in the case of DOSBox-X also features like save states and NEC PC-98 support as well as accurate emulation which also increase its binary size.

Please note that the last paragraph is intended to let you know what I thought about your detailed reply; I will not put detailed comments on comparisons between these DOSBox forks in this thread. In case you want to have more discussions on this topic, we can certainly discuss it in more details elsewhere.

>this thread is not intended for such detailed comparisons between DOSBox forks

agreed, but I'm of mixed opinion... I have't seen much else going on in this
thread and since I'm responding to comments made due to my positing in it,
I'm not sure creating a whole new thread would improve... but would just add
"noise" for people who don't care about this stuff...

Sorry, I do tend to be a bit wordy in my responses, years of experience with
being misunderstood when detail not given...

>And MS-DOS 7.x which supports long filenames (LFN) is certainly NOT just a
>launchpad for Windows...

Agreed, but not sure MSOFT does. AFIK Dos 7 was only released on Windows
install CD's, boots up to install Windows and you have to work at it a bit
to get a non-windows tied version. Also:
From Booted DOS-5 system:
C:\> ver
MS-DOS Version 5.00
From Win98 restarted in "DOS mode":
C:\> ver
Windows 98 [Version 4.10.2222]

(and being into DosBox, we are more aware of DOS than many users. Windows
before 95 was presented as a GUI under DOS. If you asked people using Win3
what OS their computer was running, I think a fair number (but not all)
would have said "DOS".

If you asked the same question to "typical" Win95/98/ME users, I think most
of them would have said "Windows".

>you don't need to type filenames because there is filename auto-completion
>feature (via Tab key)

Well aware of auto-complete and Tab key .. but there's a lot more to using
files by name than just typing them on the command line. Particularity with
a system file like ".CONF" I may enter it's name into programs, .C, .BAT files
etc. and long names would have to be supported by the program and even if so
are much more prone to typo's.

BTW, auto-complete is one of the few "bugs" I actualy do mind in older DosBox
versions, because it can lose you data - "-X" seems to have fixed it but have
not tested in detail yet - but that a different story.

Again I think you misunderstood the intent of my posting (sorry for the lack
of detail). I do most of my DOS programming with my own Micro-C compiler, and
never added LFN support to the DOS library (never use it and can't rely on in
DOS). And many of my DOS tools could "break" if much longer than 8.3 names are
returned by findfirst/next() .. so the actual DosBox "feature" that I don't
like is NOT that LFN/SFNs aren't reliably accessible (see my last post), but
the fact that an LFN is "forced" on you for a critical DosBox system file that
you might want to access within DosBox! as stated before, only relates to
this discussion because the patched name I use would otherwise have seemed odd
in console output I posted as part of examples.

Dave

DaveDDS wrote on 2021-05-29, 10:14:

>this thread is not intended for such detailed comparisons between DOSBox forks […]
Show full quote

>this thread is not intended for such detailed comparisons between DOSBox forks

agreed, but I'm of mixed opinion... I have't seen much else going on in this
thread and since I'm responding to comments made due to my positing in it,
I'm not sure creating a whole new thread would improve... but would just add
"noise" for people who don't care about this stuff...

Sorry, I do tend to be a bit wordy in my responses, years of experience with
being misunderstood when detail not given...

>And MS-DOS 7.x which supports long filenames (LFN) is certainly NOT just a
>launchpad for Windows...

Agreed, but not sure MSOFT does. AFIK Dos 7 was only released on Windows
install CD's, boots up to install Windows and you have to work at it a bit
to get a non-windows tied version. Also:
From Booted DOS-5 system:
C:\> ver
MS-DOS Version 5.00
From Win98 restarted in "DOS mode":
C:\> ver
Windows 98 [Version 4.10.2222]

(and being into DosBox, we are more aware of DOS than many users. Windows
before 95 was presented as a GUI under DOS. If you asked people using Win3
what OS their computer was running, I think a fair number (but not all)
would have said "DOS".

If you asked the same question to "typical" Win95/98/ME users, I think most
of them would have said "Windows".

>you don't need to type filenames because there is filename auto-completion
>feature (via Tab key)

Well aware of auto-complete and Tab key .. but there's a lot more to using
files by name than just typing them on the command line. Particularity with
a system file like ".CONF" I may enter it's name into programs, .C, .BAT files
etc. and long names would have to be supported by the program and even if so
are much more prone to typo's.

BTW, auto-complete is one of the few "bugs" I actualy do mind in older DosBox
versions, because it can lose you data - "-X" seems to have fixed it but have
not tested in detail yet - but that a different story.

Again I think you misunderstood the intent of my posting (sorry for the lack
of detail). I do most of my DOS programming with my own Micro-C compiler, and
never added LFN support to the DOS library (never use it and can't rely on in
DOS). And many of my DOS tools could "break" if much longer than 8.3 names are
returned by findfirst/next() .. so the actual DosBox "feature" that I don't
like is NOT that LFN/SFNs aren't reliably accessible (see my last post), but
the fact that an LFN is "forced" on you for a critical DosBox system file that
you might want to access within DosBox! as stated before, only relates to
this discussion because the patched name I use would otherwise have seemed odd
in console output I posted as part of examples.

Dave

Regarding MS-DOS 7.x, actually Microsoft officially refers to it as MS-DOS 7.0/7.1 in several released files of Windows 98, and it was just that commands like VER gave you "Windows 98" instead of "DOS". For example, if you try to run Win98's WIN.COM from e.g. MS-DOS 6.x, you will get the following message:

This version of Windows does not run on MS-DOS 7.00 or earlier.

Also, if you rename Windows 98's VMM32.VXD to VMM32.EXE and run it from MS-DOS 6.x or 7.0, you will get the following:

Cannot run Windows with the installed version of MS-DOS.

Upgrade MS-DOS to version 7.1 or higher.

You can verify the above yourself of course. So as you see, Microsoft officially referred to it as MS-DOS 7.1 and even asked you to upgrade to it in order to run Windows 98. For some reason Microsoft did not officially release MS-DOS 7.1 as a separate product, but other people already did this job for Microsoft long time ago so that you can easily install standalone version of MS-DOS 7.1 on your computer (using either install floppies or install CD) without any need for Windows (or the need to get rid of Windows files). With standalone MS-DOS 7.1 setup program you can install MS-DOS 7.1 as easily as older MS-DOS versions, and typing VER will show "MS-DOS 7.1" too. You can take a look at the following page for example: REMOVED

DOSBox-X has enhanced the filename completion feature a lot of course, including support for LFN filename completions. Either SFN or LFN should work, just like in real MS-DOS 7.1 with Enhanced DOSKEY or a Windows Command Prompt. There has been no doubt that I have used this a lot and thus very familiar with LFN filename completion, although I am familiar with SFN filename completion too. There are many newer DOS software which support LFNs, while also working perfectly on systems without LFN support. Thus LFN support may actually be done relatively easily in many cases, and I think whether to support them is more a personal choice and experience.

>Regarding MS-DOS 7.x, actually Microsoft officially refers to it as
>MS-DOS 7.0/7.1 in several released files of Windows 98, and ...

I don't argue that MSDOS 7.x IS DOS --- but someone at MSOFT decided
that it should show "Windows" as it's version.. That tells me that at
some meetine it was decided that it's main role (for MSOFT) would be a
way to launch Windows. We have all worked in large projects, and we
know that developers will often use "old names" in various non-title
places out of habit ... but (IMHO) the decision to show the Version
information as "Windows" says a lot about the control "up the ladder".

And yes, you can easily format a bootable disk in DOS 7 and remove
the windows tripe .. so It's certainly possible to make a DOS 7 only
install ... but MSOFT made the decision not to do that for you.

The fact that you can get NON-MSOFT hacks of DOS 7.1 which don't say
Windows doesn't reflect the opinion of MSOFT ... but this is straying
too far from DosBox...

And just for further clairity, my use of the term "AGREED, but NOT SURE Msoft
does..." was an indication that I do think of DOS7 as DOS and not just a
"Windows launched" - I used that term for a bit of levity, and also becuse
I'm really "not sure" MSOFT had any use for it other than such. FWIW,
since "NT" there's been nothing resembling DOS...

Dave

DaveDDS wrote on 2021-06-01, 03:34:

>Regarding MS-DOS 7.x, actually Microsoft officially refers to it as >MS-DOS 7.0/7.1 in several released files of Windows 98, an […]
Show full quote

>Regarding MS-DOS 7.x, actually Microsoft officially refers to it as
>MS-DOS 7.0/7.1 in several released files of Windows 98, and ...

I don't argue that MSDOS 7.x IS DOS --- but someone at MSOFT decided
that it should show "Windows" as it's version.. That tells me that at
some meetine it was decided that it's main role (for MSOFT) would be a
way to launch Windows. We have all worked in large projects, and we
know that developers will often use "old names" in various non-title
places out of habit ... but (IMHO) the decision to show the Version
information as "Windows" says a lot about the control "up the ladder".

And yes, you can easily format a bootable disk in DOS 7 and remove
the windows tripe .. so It's certainly possible to make a DOS 7 only
install ... but MSOFT made the decision not to do that for you.

The fact that you can get NON-MSOFT hacks of DOS 7.1 which don't say
Windows doesn't reflect the opinion of MSOFT ... but this is straying
too far from DosBox...

And just for further clairity, my use of the term "AGREED, but NOT SURE Msoft
does..." was an indication that I do think of DOS7 as DOS and not just a
"Windows launched" - I used that term for a bit of levity, and also becuse
I'm really "not sure" MSOFT had any use for it other than such. FWIW,
since "NT" there's been nothing resembling DOS...

Dave

While I agree that there was probably indeed some internal meeting at Microsoft where it was decided that its VER command would show "Windows" for some reason, we never know the details of such a meeting, or the exact reason why this was made, so it appears to me that the sentence "it was decided that its main role (for MSOFT) would be a way to launch Windows" is still speculative rather than facts. There should be no doubt that Microsoft decided to release both DOS7 and Win4.x (9x GUI) as a single software package, under the name "Windows 95" or "Windows 98". Considering that the GUI is booted by default and VER command is used inside the Windows MS-DOS Prompt too (not just pure DOS7), it could be argued that the purpose for showing "Windows" is for something else, e.g. they expect most users entering this command to be indeed running Windows GUI, and the software package is named Windows 95/98 anyway, or that someone at Microsoft just wanted its users to believe Windows 9x was a fully standalone "operating system" as he tried to advertise rather than a GUI running in DOS. But this of course does not mean it is indeed the case for Windows 9x (c.f. Windows 2000/XP and later which are based on NT).

You said that developers often use "old names" in various non-title places out of habit, which is certainly true, but this only said part of the truth. The fact that "MS-DOS 7.0" and "MS-DOS 7.1" officially appeared in various release files of Windows 9x clearly reveal the fact that internally Microsoft developers indeed considered DOS7 to be DOS too (as you also agree), and also considered DOS7 as requirement to run Windows 9x GUI, similar to how Windows 3.x GUI worked in DOS. It also shows that they did expect other people (especially those familiar with computers) to know this too, otherwise these terms would definitely be modified or removed before official releases. But these terms appeared throughout Windows 95, 98, and ME release files, which did show that they acknowledged such facts very well (at least internally, but not only so because the software containing these terms were officially released to the public too), even though someone at Microsoft may have tried to advertise something different for reasons not publicly revealed. In summary, I think there was likely not a single Microsoft opinion about this (i.e. will depend on who will be asked, although I do expect its marketing department will assert the same thing), but such a naming confusion was probably resulted from a mix of marketing and technical aspects.