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
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.