"copy" behaves weird in Daum SVN, error in interplay Star Trek games installation

Topic actions

  • This topic is locked. You cannot reply or edit posts.

First post, by Pelger

User metadata
Rank Newbie

Hello, I just joined to share this information. I hope I get it right. This is not a question, more like "I discovered something strange, here's the information".

I'm using Daum SVN february 05 2013.
Some specs just in case: this computer is a core 2 duo 2.26ghz 4gb ram, nvidia gt9600m 512mb graphics, windows 7 ultimate 64 bits.
I have a folder mounted as the C hard disk:
mount c d:\emu\dosbox\disk
and I mount d as the cdrom, I use either a real drive (mount d e:\ -t cdrom) or daemon tools with the simulated drive being f: in windows and mounted to d in dosbox (mount d f:\ -t cdrom) or loading an iso image using the program's gui. (equivalent to the imgmount command).
I don't think the problem I'll describe has anything to do with paths, drives, images, I double checked everything and it's all properly mounted, I know where the files and folders are, I've been using DOSBOX a lot for some years and I've been using real DOS my whole life, so I guess it's not like I misplaced a folder or something like that.
So, here it goes:
I tried to install "star trek 25th anniversary" and "judgement rites" (the interplay adventure games) cd versions and I got some errors. 25th anniversary installed but gave an error message, "invalid command" intead of quitting to DOS with the usual message of "type startrek to run the game, setup to configure" or something like that. the program terminated abnormally.
I thought "how weird", then when I tried "judgement rites" the installation kept failing, it didn't copy all the files to the hard disk, it copied just a few files and ignored the rest, it didn't even copy the exe and bat files, just 3 or 4 files (it's supposed to be more than that). during the copy process the installation screen displayed weird black bars, I thought it was just a glitch, but it's not. (keep this in mind). the program exits normally, doesn't crash. ok, I tried changing the installation path to a shorter directory like "c:\trek2" instead of "c:\intrplay\trek2", I tried different ways of simulating the cd drive, with an iso, with daemon tools, with a folder, and every time I got the same results, it just refuses to copy most of the files. if I explored the cd with dir or even xtree gold, the whole thing is there, and the files are not damaged, if I copy them directly on windows to a folder they copy. the problem is internal.
I thought "maybe it's a weird incompatibility", so i tried disabling stuff like glide and joystick, I tried surface, directdraw and direct3d, setting the cpu to 486, setting the core to normal instead of auto or dynamic, lowering the ram, 1mb of video memory instead of 2, and during the vgaonly test I got something interesting: the black bars during the installation are the text error messages!. in svga in color you can't see it but it's readable in the greyscale mode the installer uses in vgaonly!.
The error messages are a lot, one for each file the installation program tries to copy, and they go like this:

C:\INTRPLAY\TREK2>copy D:\fed.dir C:\INTRPLAY\trek2\.
Unable to open C:\INTRPLAY\TREK2\.DIR.
0 file(s) copied.
Unsuccessful termination.
C:\INTRPLAY\TREK2>copy D:\fed.run C:\intrplay\trek2\.
Unable to open C:\INTRPLAY\TREK2\.RUN.
0 file(s) copied.
Unsuccessful termination.

repeat that a lot, one per each file.
I checked and the files exist in the source, the destination folder is not read only, there's nothing unusual.
I tried copying the files myself manually using the same syntax and the same thing happened.

I tested it on the latest Daum SVN (2015 012 5) and the same thing happened, BUT... when I tried on normal 0.74, vanilla svn 3990, and an older svn based on 0.73, (under the same conditions, same folder as C, same drive as the CD, same destination path, same configuration for cpu, core and everything) THE INSTALLATION WORKED PERFECTLY. (on both games, 25th anniversay worked too). The program copied all the files normally, the game worked.
So, my conclusion is Daum SVN's version of the copy command behaves differently, it must manage wildcards differently than "normal" dosbox or real dos. it's obvious it's not the same implementation when I run just "copy" and it displays information about the usage that's different from what the "normal" dosbox copy displays if you just run it with no parameters. the help is not the same.
I guess Daum SVN uses a different copy tool??, maybe a third party replacement copy code??.
For this game the solution is easy, install on 0.74. I'm considering switching to 0.74 full time but I like the gui in Daum SVN, it makes it easier to mount floppy or cd images... but... I'm worried the different behaviour in the copy utility might break something else.
That's why I decided to make this long post. Sorry for the bad english, sorry for the convoluted story, but since I came across this weird incident I figured it might help somebody else that's going insane trying to install Star Trek 25th Anniversary CD or Judgement Rites CD using Daum SVN.
I bet the problem might be a combination of how the installation program uses the copy syntax and how the Daum SVN uses wildcards. Maybe the installation program does sometihng "unorthodox" not covered by the Daum implementation of the copy command?.
Anyway, I hope the unexpected behaviour doesn't break anything else, I haven't had any other problems with it, and worst case scenario, I'll switch to a vanlla version.
I'll attach a capture of the error messages displayed by the game installer just in case. (using vgaonly forces it into greyscale mode, in normal conditions like s3 or nolfb vesa it uses 640x480x256 and you can't read the error messages, they are just black bars).
Thanks for your time.


  • copy_000.png
    File size
    17.32 KiB
    File license
    Fair use/fair dealing exception
Last edited by Pelger on 2016-08-08, 07:42. Edited 1 time in total.

Reply 1 of 6, by Qbix

User metadata
Rank DOSBox Author
DOSBox Author

Please use a clean and current SVN build and not DAUM.
If it happens there, then we are interested, as it might be one of the many bugs introduced by the daum build or it was a bug that has been fixed since.

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

Reply 2 of 6, by Pelger

User metadata
Rank Newbie
Qbix wrote:

Please use a clean and current SVN build and not DAUM.
If it happens there, then we are interested, as it might be one of the many bugs introduced by the daum build or it was a bug that has been fixed since.

Ok, it works perfectly with both an older and the latest clean svn. I guess the problem doesn't matter then if Daum is not recommended.

Reply 6 of 6, by Stiletto

User metadata
Rank l33t++
ixfd64 wrote:

I'll always prefer vanilla DOSBox to third-party builds. The official version may not be updated very often, but at least it's the most stable.

The official DOSBox SVN is updated several times a month typically. That's not very often? All you gotta do is compile your own, or rely on various others, to try the latest bug fixes and features.

They don't officially release new binaries often is what I think you mean. 😉

"I see a little silhouette-o of a man, Scaramouche, Scaramouche, will you
do the Fandango!" - Queen