can you access the folder backups when in the dosbox shell ?

Qbix wrote:

can you access the folder backups when in the dosbox shell ?

Yes.
A "dir" at the C:\ level shows it, a "cd" changes to it, an "echo" can then create a file in it, and finally a "type" displays the content of the file just created.

Qbix wrote:

can you access the folder backups when in the dosbox shell ?

And here is an interesting [to me anyway] development: it turns out that the prompts for pathnames exhibit two different behaviors:
A. prompts for "internal" paths DO accept \BACKUPS [as well as \ACBLSCOR \ACBLSCOR\GAMEFILE GAMEFILE\ - any path that actually exists AFAICT]
B. prompts for "external" paths [which wouldn't accept \BACKUPS] also won't accept \ACBLSCOR \ACBLSCOR\GAMEFILE GAMEFILE\ - or, it appears, any path.

Could there be an ASCI <-> UNICODE conversion problem [or something similar]? I have already converted every folder name to CAPS in order to eliminate possible case-sensitivity issues, and I have tried both with and without the trailing "" [although possibly not exhaustively].

Been through many of the menu options, but don't have any real data, so most of the complaints are about that. What is an "internal" vs. "external" path as far as this program is concerned? Also, what menu options take you to a prompt that is not accepting paths that appear to be valid?

fxm wrote:

A. prompts for "internal" paths DO accept \BACKUPS [as well as \ACBLSCOR \ACBLSCOR\GAMEFILE GAMEFILE\ - any path that actually exists AFAICT]
B. prompts for "external" paths [which wouldn't accept \BACKUPS] also won't accept \ACBLSCOR \ACBLSCOR\GAMEFILE GAMEFILE\ - or, it appears, any path.

Online docs for this program (thanks, Google... *ahem*) suggest that when prompted to import, for instance, you need to "Enter the letter of your diskette drive (A: or B:)".

if it's expecting a floppy disk, then, try mounting that backups folder as drive A (use -t floppy). or if that doesn't work, maybe a blank diskette image will...

ripsaw8080 wrote:

Been through many of the menu options, but don't have any real data, so most of the complaints are about that. What is an "internal" vs. "external" path as far as this program is concerned? Also, what menu options take you to a prompt that is not accepting paths that appear to be valid?

Thank-you! 😀

The dialog at
Setup | Set path
sets "internal" [my terminology] paths. Generally, these contain template and configuration files needed for the program to do anything at all.

As you leave either input field, any valid path is silently accepted [and applied], and any invalid path triggers
"Location CBLSCOR\GAMEFILE\ not found." <for example>
followed by a wait [PRESS ENTER TO CONTINUE]

All 10 functions at
Utilities | Backup/Restore
eventually ask for a pathname. Every filename/pathname dialog in this area that I have tested so far rejects every entry, no matter how obviously valid it is.

The paths entered here contain "external" files [again, my terminology]. They are needed only for import/export and it is not an error for them to be empty - but it is an error for them to be not found.

There are other dialogs in the "reject" category but given that you don't have the required data, you can't reach them now.

VileRancour wrote:

Online docs for this program (thanks, Google... *ahem*) suggest that when prompted to import, for instance, you need to "Enter the letter of your diskette drive (A: or B: )".

if it's expecting a floppy disk, then, try mounting that backups folder as drive A (use -t floppy). or if that doesn't work, maybe a blank diskette image will...

Thanks for the observation.
I'm impressed and astonished at the interest in my problem, the speedy replies, and the effort put into checking out a program that most of you may not have known existed until today 😀

However, diskette drives are not mandatory [or even expected]. In fact, some files the program imports or exports are far too large to fit on a floppy. For example, the master database from the ACBL is about 17meg, LZH compressed. The local active database [which is routinely backed up] runs well over 2meg LZH compressed [on the order of 6 meg flat].

In a normal installation the dialogs in question are perfectly happy with HD paths [\BACKUPS being one that I use routinely].

Using official DOSBox 0.74, I tried "Backup Game files" after creating a Game (so there was something to process), and it asks for a Backup Location. If I enter a directory that doesn't already exist then it says the location is invalid, but if I enter a directory that does exist then it is accepted; so, apparently it can't/won't create a directory. After giving it an existing directory, it then asks which files to backup using a date mask -- I take the default of ?????? for all dates, and then it creates a XXXXXX.LZH archive file that contains my Game data in the directory specified. There is this message in a red box after the archive is created, but it doesn't seem related to the problem you describe:

The backup file C:\BACKUPS\XXXXXX.LZH is NOT part of any ACBL report and should NOT be set to Memphis. […]
Show full quote

The backup file C:\BACKUPS\XXXXXX.LZH
is NOT part of any ACBL report and should
NOT be set to Memphis.

PRESS ENTER TO CONTINUE

Do you see anything in what I did that differs from what you are doing? If not, I suspect a problem in how the software was installed.

Although it is a DOS program, there is a Win32 installer that takes you into a command console program to install. I installed to C:\ACBLSCOR, then copied the entire folder structure to C:\MOUNTC\ACBLSCOR so the pathing is the same in DOSBox when C:\MOUNTC is mounted as the C drive. Did you also do this, or something else?

BTW, if you plan to use the program's printing features then you will probably need to use hal's megabuild, because printing is not supported in the official release of DOSBox. However, the printing stuff appears to have some Windows elements, so it might not work even with the megabuild.

ripsaw8080 wrote:

Using official DOSBox 0.74, I tried "Backup Game files" after creating a Game (so there was something to process), and it asks for a Backup Location. If I enter a directory that doesn't already exist then it says the location is invalid, but if I enter a directory that does exist then it is accepted

Your experience differs significantly from mine. I can't get any existing pathname to work in this context [even \ACBLSCOR, which comes with the package].

As for \BACKUPS, I originally created
C:\mountc
and
C:\mountc\backups
in Win7. When I ran into these problems I renamed them [again, in Win7] to
C:\MOUNTC
and
C:\MOUNTC\BACKUPS
[leaving me unsure whether the cases of the DOS ["short"] name and the LFN match or not]. How did you create that folder?

I won't be able to address the rest of your points until later this morning.

Thanks again for your - and everyone's - help.
What a pleasure it is to have found this forum!

ripsaw8080 wrote:

Do you see anything in what I did that differs from what you are doing? If not, I suspect a problem in how the software was installed.

Although it is a DOS program, there is a Win32 installer that takes you into a command console program to install. I installed to C:\ACBLSCOR, then copied the entire folder structure to C:\MOUNTC\ACBLSCOR so the pathing is the same in DOSBox when C:\MOUNTC is mounted as the C drive. Did you also do this, or something else?

I dragged the Win32 installer to C:\ [providing credentials as I did so].
I ran the installer there [responding "continue" to a permissions question] and saw [what appeared to be] normal "copying..." messages.
When that finished, a popup from Win7 appeared: "may not have installed properly".
I scanned the entire filesystem for files which should have been installed
They weren't there, so I chose the "repeat with recommended settings" option.
After that I still couldn't find the files, so I dragged a complete copy
[C:\ACBLSCOR and all of its contents] from a working XP installation to a flash drive and from there to the C:\MOUNTC folder on Win7/64.

I see now that the the DOS INSTALL.EXE [which should start with
This procedure will install ACBLscore on your hard drive.
To install ACBLscore Version 7.71 press ENTER.
To stop the installation press ESC.
in a splash box] never ran. Good catch by you. 🙁
Can you suggest why that step failed here? Or how to cure that, as you obviously did?

BTW: I did read DOSBox IS NOT SUITED TO RUN YOUR NON-GAMING DOS APPLICATION but there is significant value to me in getting this version of the program to work and I rate the risk of a DOSBox glitch/failure in production as very low.

ripsaw8080 wrote:

BTW, if you plan to use the program's printing features

Luckily, I don't. All output is sent to files which are published to a web site and/or edited/printed in Windows.

Thanks for the reference, though.

And thanks again for your attention 😀

Try this to see if it fixes the problem with finding directories: In DOSBox, copy COMMAND.COM from the Z: drive to the root of the C: drive.

This appears to be some quirk of the program, not a DOSBox issue. It's strange, because the program doesn't execute COMMAND.COM, it just seems to want it there for some reason.

ripsaw8080 wrote:

Try this to see if it fixes the problem with finding directories: In DOSBox, copy COMMAND.COM from the Z: drive to the root of the C: drive.

The C: drive emulated in DOSBox, not the host OS C: drive.

Your comment is in the form of a reply to me, but I hope you're clarifying for the thread starter, because I know exactly what I meant.

ripsaw8080 wrote:

In DOSBox, copy COMMAND.COM from the Z: drive to the root of the C: drive.

ripsaw8080 wrote:

In DOSBox, copy COMMAND.COM from the Z: drive to the root of the C: drive.

Brilliant!
Problem [apparently] solved - although I haven't yet tested every input dialog and program function exhaustively.
This has saved me hours of work with the debugger - which I was only just downloading.
Thank you!!

This appears to be some quirk of the program, not a DOSBox issue. It's strange, because the program doesn't execute COMMAND.COM, it just seems to want it there for some reason.

Perhaps the program thinks that it has to modify certain behaviors [calls, formats, parameters] based on the platform.

ripsaw8080 wrote:

I know exactly what I meant.

As did I.

ripsaw8080 wrote:

Your comment is in the form of a reply to me, but I hope you're clarifying for the thread starter, because I know exactly what I meant.

You're right, I was supporting your answer with a cleaner statement,
hoping the threadstarter (or other readers as well) reads it right. 😀