MiniMax wrote:

Does the problem also happen when you run it is DOSBox on XP?

Yes -- there is the same behavior using DOSBOX on XP machine as on the EeePC using Xandros Linux.

In answer to your other question, the anti-virus engines are different. Not sure what the EeePC one is called -- McAfee on the XP.

I can report one other quirk / distinction between the action of DOSBOX and regular DOS on the XP machine.

I use the program PKZIP, as you saw in the dumps of runs before. Version 2.50. When I run that program in a DOS box (using 4NT) I see a screen output of:

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þ Pentium  class CPU detected.
6þ XMS version 2.00 detected.
7þ DPMI version 0.90 detected.
8þ Using 32-Bit Protected Mode Normal Compression.

But when I run same program in DOSBOX I get:

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þ EMS version 4.00 detected.
7þ XMS version 3.00 detected.
8þ Using 16-Bit Real Mode Normal Compression.

In addition, I notice that on the XP DOS box if I do a zip compression using the parameter -k (= do not update zip file time/date) then that parameter is obeyed and the zipfile keeps the original date/time stamp.

But, on the DOSBOX run, that parameter is not obeyed and the date/time stamp of the zip file is updated to current time and date.

This effect has minor impact on my intended use -- but the differences as listed above may give you guys some clues as to the source of the other problem that is of concern to me.

Again -- thanks for continued interest and suggestions.

DOS box versus DOSBox - so easy to mix up. Better use the term NTVDM (NT Virtual DOS Machine) when refering to the "DOS" emulation in Windows NT/2K/XP.

Detecting DOSBox as a 80486 CPU is a little weird. It should only see a 386 I believe. Not that it makes any difference I hope.

Timestamps.... Sounds like a small DOSBox bug (or missing feature). When run in NTVDM pkzip operates with the real file system. When inside DOSBox, the file system calls for last-modification date appears not to reach the real file system.

486 is fine, depends on the test routines of the app though.

I think we are down to 2 options now:

1) You have to convince a DOSBox code guru that this is an interesting problem to solve. Could be difficult since i don't think this Bluewave application falls within the stated goal of DOSBox: To be the best environment for playing DOS games.

2) You need to get hold of a debug-enabled version of DOSBox and learn how to trace the flow through DOSBox, and determine exactly what is going wrong. And then you need to come up with a fix - and maybe get the fix accepted into the main DOSBox code.

Ad 1) A donation to DOSBox via PayPal might help here, but that is something I leave up to you to arrange with whoever might show an interest in the the problem.

A typical method for executing DOS commands (including batch files) from within a program is to execute COMMAND.COM with INT 21, AX=4B00 and set for it a command line of "/C <command>". I can say for sure that when using this method in DOSBox, as in real DOS, the calling application will wait for the spawned command interpreter to exit after running the command set for it.

ripsaw8080 wrote:

A typical method for executing DOS commands (including batch files) from within a program is to execute COMMAND.COM with INT 21, AX=4B00 and set for it a command line of "/C <command>". I can say for sure that when using this method in DOSBox, as in real DOS, the calling application will wait for the spawned command interpreter to exit after running the command set for it.

That sounds interesting and I'd like to try it -- but I don't understand how to set those parameters / variables. What happens now is there is a configuration line that defines how my Bwave program calls the compression routine. It reads

1d:\util\myzip.bat @F @I

I could easily change that to

1command /cd\util\myzip.bat @F @I

but how would I get the INT and AX values set?

I did attempt entering the command.com as on the above line, and got even more wierd behavior. Instead of executing the myzip.bat, it simply dropped me out to a command window with a prompt. Typing exit then returned to the Bwave program. In addition, the file that was supposed to be the target compression file disappeared. I tried a variety of ways of entering the command using " marks, but all had the same strange effect.

MiniMax wrote:

I think we are down to 2 options now:

In any case, thanks to you and the others for trying.

I see two other options:
3. Live with it. Or work around it. I think I could figure out how to achieve the desired effect with a manually invoked batch file.
4. Try another emulator.
a. I have tried Wine, and that is a total no-go. Wine does not run DOS programs at all.
b. I have tried DOSEMU, and that has more severe problems. It does not pass CTRL- and ALT- keys to the program, and my Bwave depends on a variety of such key combinations.
c. ?? Not sure what else is out there. DOSBOX certainly had the best look and feel.

As a side question: If there are things that would normally go into CONFIG.SYS, how do they get entered? I don't see any way of doing that, other than that some of those things are sections in DOSBOX.CONF.

The command you were using would be substituted for <command> in my example by the program, so no need to change it. The INT 21 stuff is how the program would execute from within its code.

However, it's an interesting thing to try. If you set the command to run as just "COMMAND.COM", with no parameters, the command shell should just sit there until you type "exit". While it's sitting there, use that spawned command shell to see if the file in question has been deleted.

Re: c) You could try booting DOSBox with real MS-DOS or FreeDOS and see if that makes any changes. I guess it will be much like using DOSEMU, but you should get the keypresses passed to your application.

Edit: DOSBox don't use a CONFIG.SYS. If an application for some inexplicable reason wants a file called CONFIG.SYS with certain lines in it (lines that will be ignored by DOSBOX!) then go ahead an create a CONFIG.SYS on the mounted C-drive.

ripsaw8080 wrote:

However, it's an interesting thing to try. If you set the command to run as just "COMMAND.COM", with no parameters, the command shell should just sit there until you type "exit". While it's sitting there, use that spawned command shell to see if the file in question has been deleted.

That was an interesting thought -- but unfortunately, the file in question had been deleted when COMMAND was called.

Perplexing why this is so in DOSBOX and not in NTVDM.

I ran version 2.3 as an eval, and the file to be compressed is deleted by the program before it even shells out to the archiver. 😵

It would take some work with the debugger to find out why it decides to delete it. I thought maybe sensitivity to correct date/time stamps on files might be a factor; but ykhwong's CVS build has support for them, and the file gets deleted in that build too. The wiki article on the program's Y2K problems was what made me wonder about the stamps: http://en.wikipedia.org/wiki/Blue_Wave

No solution for you, but at least we can say shelling out to DOS is not the issue. Even if the specific cause is pinned down, there might never be an official fix for it if a game isn't involved.

ripsaw8080 wrote:

I ran version 2.3 as an eval, and the file to be compressed is deleted by the program before it even shells out to the archiver. 😵

But yet, if I push to DOS using ALT-D just before that call, it is still there. And it is still there during the compression call in NTVDM. Just not in DOSBOX.

It would take some work with the debugger to find out why it decides to delete it. I thought maybe sensitivity to correct date/time stamps on files might be a factor; but ykhwong's CVS build has support for them, and the file gets deleted in that build too.

That checks off another thing that was suggested:-}} Thanks.

The wiki article on the program's Y2K problems was what made me wonder about the stamps: http://en.wikipedia.org/wiki/Blue_Wave

I am well aware of the Y2K problem. I have attempted to run BWAVE both with the later fix mentioned there, and the earlier one that I wrote back in 1999.

No solution for you, but at least we can say shelling out to DOS is not the issue. Even if the specific cause is pinned down, there might never be an official fix for it if a game isn't involved.

I do appreciate the efforts that folks here have made. I'm not quite done trying things, but may be forced to use alternative means to accomplish my goals.

This EeePC is going to be a travel machine, XP desktop remains my primary when at home.

Another emulator to try would be Bochs. Didn't see you list it, thought you might want to try that one, too.

Ugh, Bochs is ssssllllloooowwwww... (; Didn't try the latest version, though - the changelog says there have been speed enhancements. My favourite is Qemu - small, portable and efficient. VMWare or VirtualBox are two other emulators/virtualizers to try.

dale5351, DOSBox has been developed to play games, not to run application programs. Many programs may work, but in general, i think it makes sense to use a "real" PC emulator/virtualizer for "serious" apps.

Btw, do you know "Crosspoint" (or XPoint)? That's what i was using back in the BBS days to read mails/newsgroups. I think it was superior to all other programs, though i'm not sure it was translated to english (it was a german program). Ah, the old days - polling 2MB of useless posts per day, with a USR DST (;

ADDiCT wrote:

My favourite is Qemu - small, portable and efficient.

Thanks, I'll take a look at that.

dale5351, DOSBox has been developed to play games, not to run application programs. Many programs may work, but in general, i think it makes sense to use a "real" PC emulator/virtualizer for "serious" apps.

So I have now gathered.

Btw, do you know "Crosspoint" (or XPoint)? That's what i was using back in the BBS days to read mails/newsgroups. I think it was superior to all other programs, though i'm not sure it was translated to english (it was a german program). Ah, the old days - polling 2MB of useless posts per day, with a USR DST (;

Have not come across that.

The problem was easier to find with the DOSBox debugger than I thought it would be. Blue Wave appears to have a flaw where it uses the DOS "FindFirst" function INT 21/4E with a malformed filespec. Using the example mail packet the program comes with, it tries to find "C:\BWAVE\WORK\WELCOME.XTI*.BAK". MSDOS 5/6 and the WinXP NTVDM are unforgiving and return error code 3 (invalid path), leading to a benign result. DOSBox is more lenient, and finds the "WELCOME.XTI" work packet, which the program proceeds to delete. Maybe the intent was to clean out .BAK files in the work folder; but that seems redundant because the program deletes *.* from there when it finishes recompressing the packet. It's probably just a mistake that wasn't noticed until DOSBox shed some light on it.

I adapted a little interrupt watchdog program to work around this situation in DOSBox. It monitors the FindFirst function, and if it sees a filespec with an extension of XTI* it will override with an error code 3 result. Run BWAVEFIX.COM from the BWAVE folder; it runs BWAVE.EXE as a child program. The child exit errorlevel is reflected through the parent, and the parent command line is given to the child, so the program is friendly to batch files. Assembler source code is included in the attached archive.

ripsaw8080 wrote:

Run BWAVEFIX.COM from the BWAVE folder; it runs BWAVE.EXE as a child program.

Thank you VERY much. I tried it, and it worked.

The only remaining problem is that in DOSBOX, the time/date stamp of the QWK file gets changed, whereas in NTVDM it is left at its original time and date. BlueWave uses that in an index file, but it is not really very important to me and I can live with the difference.

Since I have also asked in the Fidonet Bluewave echo about this problem, I'll post your solution there if that is ok. I'll give a short summary, and a pointer to this message base for getting the file.

ykhwong's CVS build of DOSBox has support for time and date stamps, but I don't know if that particular feature is in the Linux build or not: DOSBox SVN Builds

I noticed another thing that doesn't always work: in the list of packets to open, the statistics about the content of the packet in the list is often a bunch of dash characters. It is curious that it works sometimes; but it's probably not critical.

BTW, the problem is also in the 32-bit DOS version of Blue Wave, and the workaround applies there as well.

Maybe ask a moderator if you can link to the discussion here. However, feel free to repost the program anywhere you want.

has support for time and date stamps

No it doesn't, it has a date/time command that changes the reported date/time
but that's just useless.

No it doesn't, it has a date/time command that changes the reported date/time
but that's just useless.

I am not sure what exactly its support amounts to, but I think it may implement INT 21/57 to some extent; because when you unzip files with PKUNZIP using ykhwong's build, the extracted files retain their modification date/time stamps, where with the official build the stamps are set to the current date/time. So, I think the support goes further than you are suggesting. At any rate, that may be sufficient for the purpose of this mail reader program.