I have a new EeePc with default Xandros linux installed. I have installed dosbox in order to run one of my favored DOS applications. It runs quite well except for one strange problem.
The application is called BlueWave, which reads QWK mail packets for messaging offline on BBSes. The application is fairly old, abandonware, but I have a paid registration -- and it works perfectly well running in a DOS window on my XP machine (actually I use 4NT, not DOS -- but think that is irrelevant to the problem).
The specific problem is that at one step, Bluewave spawns a call to a compression program (i.e. pkzip). The specific call is listed in a configureation file as
d:\util\pkzip.exe -ex @F @I
Running on XP, this works fine.
But on the linux system something goes wrong. As a result of substituting a batch file for the direct call to pkzip, I have determined the problem -- but not a solution.
What goes wrong seems to be that the Bluewave program on the linux system carries on doing its thing after spawning off the call to the batch file that runs the pkzip -- and its next step is to delete the files that were going to be packed up by pkzip. On the XP machine, this does not happen and the files are there to be zipped. On the linux machine they are gone before the batch file can process them.
Yes, I have mounted the D and H drives needed. pkzip is in the proper place in d:\util, and does get called ok. I substituted a bat file to manage the call and look at contents of directories, and that is how I proved to myself that the file needed had disappeared before pkzip got a chance to pack it up.
Since my original post, I have done two more relevant experiments. I installed DOSBOX onto my XP machine and also got it configured with the appropriate mount commands. Both version 0.65 (which is what was installed on Xandros system) and version 0.72 have the same behavior as on the XP machine as on the Xandros machine -- namely that the file has disappeared before pkzip gets a chance to pack it up. That does not happen when I run the program Bluewave directly in an XP dos window.
There seems to be something different about how DOSBOX handles the spawning of a program and how XP does it.
Stockholm, Sweden, Europe, Earth Interests: Old games & young women
Hmmm. Okay, a wild guess. Maybe PKZIP is assuming some C:\TMP or C:\TEMP or %TEMP% directory somewhere during the unpacking procedure? And if that directory does not exists, it silently fails?
I am quite certain that the problem is not in pkzip itself, but in the fact that the file is being deleted by bluewave before pkzip can pack it up --- and that should not happen until after the pkzip call.
I have the ability to push to DOS from within bluewave. If I do that, and then do a "dir" on the relevant directory, the file exists at that time. I then return to bluewave, and do the operation that causes the call to the batch file. The first thing that batch file does is "dir" on the relevant directory, and the relevant file is gone. Then the call to pkzip is made, and it echos "nothing to do" or something like that.
I don't seem to have the ability to do a cut and paste from the DOSBOX dos window like I do in a normal DOS Window on XP, or I'd show you the results of the dir commands.
Thanks for the continued interest.
First, here is the current version of the batch file which directs the outputs to a file called file.txt. Batch file is called myzip.bat and is located on the path in a directory d:\util
-- myzip.bat --
-- end of myzip.bat --
And now comes the output that was sent to file.txt. I have annotated it with some comments. Everything I added has beginning of the line set to *COMMENT -- <some text>
Sorry for the length of it.
-- file.txt --
*COMMENT -- push to DOS and DIR of the relevant directory
*COMMENT -- notice that file OWL.XTI exists.
*COMMENT -- below is the output caused by the batch file
*COMMENT -- that does the compression and does the
*COMMENT -- error dumps of directories
*COMMENT -- first that batch file echos the two parameters
*COMMENT -- which are the zip file (named OWL.821)
*COMMENT -- and the file to be compressed into it (OWL.XTI).
*COMMENT -- and here we have directed the PKZIP output
*COMMENT -- to this file
1PKZIP (R) FAST! Create/Update Utility Version 2.50 03-01-1999 2Copr. 1989-1999 PKWARE Inc. All Rights Reserved. Shareware Version 3PKZIP Reg. U.S. Pat. and Tm. Off. Patent No. 5,051,745 4 5þ 80486 CPU detected. 6þ Using 16-Bit Real Mode Maximum Compression. 7 8Updating ZIP: H:/QMODEM/DOWNLOAD/MAIL/OWL.821 9 10PKZIP: (E12) nothing to do!
*COMMENT -- and since the file has disappeared, pkzip says
*COMMENT -- nothing to do.
*COMMENT -- below are calls made when the program BWAVE
*COMMENT -- is exiting. By then it has cleared out
*COMMENT -- the WORK directory.
1H:\QMODEM\DOWNLOAD\MAIL\OWL.REP 2H:\BWAVE\REPLY\OWL.BW~\*.* 3Directory of H:\BWAVE\WORK\. 4. <DIR> 06-04-2008 1:02 5.. <DIR> 06-04-2008 1:03 6 0 File(s) 0 Bytes. 7 2 Dir(s) 110,540,800 Bytes free. 8Directory of H:\BWAVE\REPLY\. 9. <DIR> 06-04-2008 1:02 10.. <DIR> 06-04-2008 1:03 11OWL BW~ <DIR> 06-04-2008 1:03 12 0 File(s) 0 Bytes. 13 3 Dir(s) 110,540,800 Bytes free. 14 15PKZIP (R) FAST! Create/Update Utility Version 2.50 03-01-1999 16Copr. 1989-1999 PKWARE Inc. All Rights Reserved. Shareware Version 17PKZIP Reg. U.S. Pat. and Tm. Off. Patent No. 5,051,745 18 19þ 80486 CPU detected. 20þ Using 16-Bit Real Mode Maximum Compression. 21 22Creating ZIP: H:/QMODEM/DOWNLOAD/MAIL/OWL.REP 23 Adding: OWL.MSG Deflating % 00 (54%), done.
*COMMENT -- again a call packing up the reply packet,
*COMMENT -- seems to work ok, not relevant to the problem
*COMMENT -- of the missing OWL.XTI .
-- file.txt --
Hope that one of you can see what I mean. When I do the same thing on my windows XP machine in a normal CMD window, the OWL.XTI file is still sitting in the WORK directory when the batch is called. It does not get ridded until after that call to the compression batch file is finished.
It looks like DOSBOX is allowing a multi-thread to happen, i.e. spawning off the compression batch and immediately returning to the main program which then carries on. If so, that is the reason for the error.
I don't think the problem has anything to do with "Multitasking". When you're running DOSBox, you're running a "single-tasking-OS" (that's not 100% correct in technical terms, but a good enough description) inside a multi-tasking environment, so the programs running inside DOSBox will run "one after another", just like in DOS.
I've had some strange effects with piping/redirection (>, >>) inside DOSBox in the past, but i can't remember what the effects were in detail. You could try to run 4DOS (now open source, and free) before running your app, or starting it with the batches your app is using. The whole redirection stuff would then be handled by 4DOS' functions.
P.S.: another thought - i'm no linux user, but i know that a lot of problems can be caused by incorrect file/directory permissions. Are you sure the permissions of the user running DOSBox are set correctly? To test if the problem is permission-related, run DOSBox as root.
I don't think the problem has anything to do with "Multitasking". When you're running DOSBox, you're running a "single-tasking-OS" (that's not 100% correct in technical terms, but a good enough description) inside a multi-tasking environment, so the programs running inside DOSBox will run "one after another", just like in DOS.
That is what I would have thought. But there may be something strange in the way that this program (bwave) handles the calls to external programs or batch files.
I've had some strange effects with piping/redirection (>, >>) inside DOSBox in the past, but i can't remember what the effects were in detail. You could try to run 4DOS (now open source, and free) before running your app, or starting it with the batches your app is using. The whole redirection stuff would then be handled by 4DOS' functions.
I have 4DOS and 4NT, but don't see how that might help here. It is not a problem with piping or redirection.
P.S.: another thought - i'm no linux user, but i know that a lot of problems can be caused by incorrect file/directory permissions. Are you sure the permissions of the user running DOSBox are set correctly? To test if the problem is permission-related, run DOSBox as root.
I sort of did that test when I ran DOSBOX on my XP system. I'm getting the same effect there.
