VOGONS

Common searches


First post, by RodneyJones

User metadata
Rank Newbie
Rank
Newbie

I have really enjoyed using DOSBox on a daily basis for the past few months (ever since getting my Windows 7 64 bit computer), and use it to run a wide variety of old DOS applications. However, there is one glitch I am currently experiencing with a pyrometallurgy simulator called Pyrosim. I think I have isolated the problem to the fact that DOSBox seems to support only a limited subset of the functions of the DOS COPY command. (Please correct me if I am wrong about this, but this is the impression I have from what I have read so far.) Embedded within Pyrosim is the use of the COPY command to concatenate nine text files into one. I think I can distill the problem into a simple command-line test.

If I type
COPY file1.txt + file2.txt + file3.txt
into an original DOS prompt, the result would be that the new file1.txt contains the contents of all three files together.

However, if I type
COPY file1.txt + file2.txt + file3.txt
into DOSBox, I get a message saying
FILE1.TXT
Illegal Path.

My question for the DOSBox developers is 'are you perhaps able (or willing) to add concatenation to the capabilities of the COPY command within DOSBox'? I would be deeply grateful if you were able to extend the functionality of your wonderful program in this way. Thanks very much.

Rodney Jones, Randburg, South Africa

Reply 1 of 19, by Zup

User metadata
Rank Oldbie
Rank
Oldbie

I guess that option is not used in games, so DOSBox developers won't put it in their to-do list.

Also, have you tried running 4DOS in DOSBox? As a command.com replacement, the copy command may work as you wish.

I have traveled across the universe and through the years to find Her.
Sometimes going all the way is just a start...

I'm selling some stuff!

Reply 3 of 19, by collector

User metadata
Rank l33t
Rank
l33t

It does work in DOSBox. There are a number of games that shipped on floppy that had resources split to span across several disks. The original installers concatenate these resources and I can confirm that this works in DOSBox.

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

Reply 4 of 19, by RodneyJones

User metadata
Rank Newbie
Rank
Newbie

I expect that it's possible that your installation concatenation was done using some other method than the COPY command. I certainly couldn't get the simple example shown in my first message to work for me.

Reply 5 of 19, by ykhwong

User metadata
Rank Oldbie
Rank
Oldbie

Try this one. It should work in DOSBox. I've just tried "copy file1.txt + file2.txt file3.txt" and it successfully created file3.txt.

Attachments

  • Filename
    COPY.7z
    File size
    12.45 KiB
    Downloads
    260 downloads
    File comment
    COPY command from FreeDOS
    File license
    Fair use/fair dealing exception

Reply 6 of 19, by Myloch

User metadata
Rank Member
Rank
Member

Dosbox is not meant to be a substitute of dos (a lot of commands and functions are missing). Dosbox mission is to successfully run games (primarily) and applications (secondarily).
This is why concatenation is now available.

Reply 7 of 19, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

thought we supported copy a+b c
Don't know about spaces between the parts though.

Water flows down the stream
How to ask questions the smart way!

Reply 9 of 19, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

In MSDOS, copying files like "copy file1+file2+file3" puts all parts in file1. I think this is because the destination filename is optional in DOS, and defaults to the source filename if not specified. For example "copy file1" results in the error "File cannot be copied onto itself". In DOSBox, "copy file1" causes file1 to be truncated to zero length. Anyway, it's probably best to always use a destination filename in DOSBox.

Reply 10 of 19, by collector

User metadata
Rank l33t
Rank
l33t

The syntax that the old Sierra installers used was

copy resource.000 + %2:resource.001  
copy resource.000 + %2:resource.002
copy resource.000 + %2:resource.003
copy resource.000 + %2:resource.004
copy resource.000 + %2:resource.005

etc., with file checks in between each copy command as each part was on a different disk. This does work in DOSBox.

Reply 11 of 19, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

"copy file1 + file2" or "copy file1 +file2" results in "Illegal Path." error and file1 truncated to zero length.
"copy file1+ file2" or "copy file1+file2" works OK.
So, DOSBox doesn't like a space before the plus sign.
The OP's and collector's example have spaces on both sides of the plus sign, and that does not work in my tests.

Reply 12 of 19, by collector

User metadata
Rank l33t
Rank
l33t

The above example comes from the install script file for QfG3. The resource files do get concatenated by the Sierra installer. The "%2:" is a variable for the source disk, of course and the resource.000 is already in the install folder. It doesn't seem likely that having the two files in different locations should make a difference.

here is the entirety of the script. It is used by the Sierra installer and is not a stand alone batch file.

clear
space %1: 7500 NoSpace
godir %1:%4 CantCreate

echo Copying Drivers ...
copy %2:version
copy %2:sierra.exe
copy %2:*.drv
copy %2:interp.*
copy %2:install.*
copy %2:*.map
copy %2:read*.*

copy %2:resource.msg
echo %3 > resource.cfg

clear
echo Processing Audio Files ...
%2:audio.exe >nul
if exist %2:*.fon copy %2:*.fon
if exist %2:*.hep copy %2:*.hep
if exist %2:*.msg copy %2:*.msg
if exist %2:*.pal copy %2:*.pal
if exist %2:*.scr copy %2:*.scr
if exist %2:*.tex copy %2:*.tex
if exist %2:*.txt copy %2:*.txt
if exist %2:*.voc copy %2:*.voc
if exist %2:*.p56 copy %2:*.p56
if exist %2:*.v56 copy %2:*.v56

if exist resource.000 del resource.000
clear
copy resource.000 + %2:resource.001

clear
exists %2:resource.002 Please insert the disk labeled "Disk 2" in drive %2:.
copy resource.000 + %2:resource.002

clear
exists %2:resource.003 Please insert the disk labeled "Disk 3" in drive %2:.
copy resource.000 + %2:resource.003

clear
exists %2:resource.004 Please insert the disk labeled "Disk 4" in drive %2:.
copy resource.000 + %2:resource.004

clear
exists %2:resource.005 Please insert the disk labeled "Disk 5" in drive %2:.
copy resource.000 + %2:resource.005

clear
echo
echo To play Quest for Glory III now:
echo Type SIERRA [ENTER]
echo
echo To play later:
echo From the directory of %1:%4,
echo and type SIERRA [ENTER]
echo

Show last 19 lines
pause
goto Exit2


:NoSpace
clear
echo
echo You do not have enough disk space on %1
echo to install Quest for Glory III!
echo 7.5 megabytes of hard disk space are required.
echo
pause

:Exit2
end

:CantCreate
alert Cannot create directory %1:%4.
end

This does work in DOSBox and the resources are successfully joined.

Reply 13 of 19, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Going by debug log messages, the QFG3 installer does not use its script to execute DOS commands. Rather, it appears to interpret the script and perform the necessary file operations itself.

 226858069: FILES:file open command 0 file A:resource.001
226858251: FILES:file create attributes 0 file resource.000
226858697: DOSMISC:DOS:57:Set File Date Time Faked
226896610: FILES:file open command 0 file A:resource.002
226896816: FILES:file open command 1 file resource.000
226904533: DOSMISC:DOS:57:Set File Date Time Faked
226942464: FILES:file open command 0 file A:resource.003
226942670: FILES:file open command 1 file resource.000
226950387: DOSMISC:DOS:57:Set File Date Time Faked
226988300: FILES:file open command 0 file A:resource.004
226988506: FILES:file open command 1 file resource.000
226996223: DOSMISC:DOS:57:Set File Date Time Faked
227034140: FILES:file open command 0 file A:resource.005
227034346: FILES:file open command 1 file resource.000
227042063: DOSMISC:DOS:57:Set File Date Time Faked

The above is is only a portion of the log messages regarding resource files, but the rest of the log also shows that only file operations are taking place. There are no COPY commands being executed by the shell.

Reply 14 of 19, by RodneyJones

User metadata
Rank Newbie
Rank
Newbie

Thanks very much to ripsaw8080 for tracking down the exact cause of the problem I am experiencing with the Pyrosim pyrometallurgical simulator. I understand now that the DOSBox COPY command is indeed able to concatenate files, but is very fussy about the spaces in a command such as
COPY file1.txt + file2.txt + file3.txt
and results in the "Illegal Path." error and file1.txt being truncated to zero length, if there is a space before the plus sign. (It is worth remembering to avoid this for future use, but does not help with existing old software.)

Could I then please ask Qbix for a very specific request? Are you able to persuade DOSBox to ignore (like MS-DOS does) the space before the plus sign in the COPY command? I really hope you are able to make this change (that seems so small but probably isn't!), as that would make DOSBox even more useful to a whole lot of people.

Thanks again for writing such a useful piece of code, and thanks also to people (like ripsaw8080) who are willing to spend their time solving problems for others.

Reply 15 of 19, by collector

User metadata
Rank l33t
Rank
l33t
ripsaw8080 wrote:

Going by debug log messages, the QFG3 installer does not use its script to execute DOS commands. Rather, it appears to interpret the script and perform the necessary file operations itself.

The above is is only a portion of the log messages regarding resource files, but the rest of the log also shows that only file operations are taking place. There are no COPY commands being executed by the shell.

I had assumed that the installer script (.SCR) was used by the Sierra installer (INSTALL.EXE) rather than just a substitute for a batch file. In any case, there still may be some games out there that use the MS-DOS commands via actual batch files for their installers. Might be a good reason to have DOSBox's COPY behave like that of real DOS.

Reply 16 of 19, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

The attached patch is my attempt at handling any number of spaces on either side of the plus sign when concatenating source files in the COPY command. The changes are fairly minimal, and I've tried it with every permutation I can think of.

Edit: ltrim was not needed in any condition, so uploaded slightly simplified version of patch.

Attachments

  • Filename
    concat_spaces.diff
    File size
    708 Bytes
    Downloads
    223 downloads
    File license
    Fair use/fair dealing exception

Reply 17 of 19, by cfoesch

User metadata
Rank Newbie
Rank
Newbie

Looking at ripsaw's patch... yeah, that looks like it does what is intended.

I suppose if I were writing things from scratch though, I might do things differently, but bleh, that's way more work, and would introduce a hojillion bugs...

I suppose, we might want to report an error if someone puts in "copy + file1.txt + file2.txt file3.txt" ... As is, it just ignores the first "+" (which is perfectly legitimate).

Reply 18 of 19, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

report an error if someone puts in "copy + file1.txt + file2.txt file3.txt" ... As is, it just ignores the first "+"

I'm guessing this example was not actually tested, because the leading plus without a preceding source file causes a "Required parameter missing." error, with or without the patch.

A trailing plus (e.g. "copy file1+file2+") results in no error, and the concatenation into file1 works, but "0 files copied" is reported; however, it does that without the patch as well. In short, there's nothing in the patch to deal with malformed arguments, so the behavior in those cases should remain the same for the most part.

Reply 19 of 19, by cfoesch

User metadata
Rank Newbie
Rank
Newbie

I'm guessing this example was not actually tested, because the leading plus without a preceding source file causes a "Required parameter missing." error, with or without the patch.

Ah yes... I see now, the error is caught later in the function... I was looking at catching the error as early as possible, but rather it just checks after collecting all of the sources to see if the first one is an empty filename... hm...

One can however fall through that check and get copy to try and open the filename "" by using: "copy file1.txt+ + file2.txt file3.txt" (This is however caught as an "Illegal Path" error.)

So, yeah, none of this really matters unless one is concerned about throwing the "correct" errors, which really isn't the goal of DOSBox anyways...