VOGONS


First post, by rcblanke

User metadata
Rank Oldbie
Rank
Oldbie

Hi everyone,

First, let me tell you how much I like your work; DOSBox is truely a work of art as it is now! The amount of games and programs it can run at the moment is very impressive.

However, I seem to have stumbled on a problem. I tried to run an old C++ game that i've written a couple of years ago using DJ Delorie's DJGPP compiler in DOSBox, that crashed right after starting. Obvisously, the game works in a true DOS environment or on the windows command prompt.
In fact, even the smallest C++ program that I can think of:

#include <iostream>

int main() {
return 0;
}

crashes DOSBox (version 0.63, as well as the CVS as of 03-07-2005), or better, crashes CWSDPMI inside DOSBox. See my attachment for that.
I've used the latest GPP release, version 3.4.3 to compile the thingy.

Removing the starting #include line from the code makes it work correctly.

My question: Is this a known problem with DOSBox (maybe that someting isn't exactly finished inside DOSBox's sourcecode, or similar), and is there a solution to this problem other than just use plain C instead of C++ ? Or am I missing something here?

Again, thanks for your good work already, now lets see if we can make it even better!

I have attached the executable as well. It was compiled using -g so debugging info is available.

Regards,

Ronald

Attachments

  • dosbox_000.png
    Filename
    dosbox_000.png
    File size
    6.13 KiB
    Views
    2760 views
    File comment
    Screenshot of the DPMI crash
    File license
    Fair use/fair dealing exception
  • Filename
    a.exe
    File size
    596.97 KiB
    Downloads
    360 downloads
    File comment
    The compiled C++ code
    File license
    Fair use/fair dealing exception
Last edited by rcblanke on 2005-04-01, 11:20. Edited 1 time in total.

Reply 1 of 9, by ASM

User metadata
Rank Newbie
Rank
Newbie

Did you try an older version of GPP?
I'm not sure but I believe gcc/gpp 2.x is comes with the original DJGPP installation. Maybe this fixes your problem.

I compiled the DOS version of Quake v1.09 some time ago with DJGPP 2 and it works in DOSBox.

Reply 2 of 9, by `Moe`

User metadata
Rank Oldbie
Rank
Oldbie

I did some debugging, and found out the following:

The alleged illegal opcode is this:
00A7:3599 F00FC102 lock xadd [edx],eax

Dosbox doesn't (yet) recognize the LOCK prefix. It doesn't need to, anyways, as it is only needed for SMP machines (dual CPU or more). It appeared in the Pentium first, which DosBox doesn't try to fully emulate.

Running your program with my copy of CWSDPMI works just fine. So it seems to be the stub program that tries to execute that instruction. You can either fetch a copy of CWSDPMI.EXE over the internet or find out if djgpp has an option to produce 486-compatible executables (for the stub program, not your code!).

Reply 3 of 9, by rcblanke

User metadata
Rank Oldbie
Rank
Oldbie

Thanks for your replies guys,

Moe, thanks for your time! I think I understand why it doesn't work in DOSBox now. Is your version of CWSDPMI a special kind of build? I tried both r4 and r5 to no avail. Can you share your copy please, so I can try to run my c++ code?

I'll see if I can make the compiler spit out a 486-compliant stub...

Thanks again,

Ronald

Reply 4 of 9, by `Moe`

User metadata
Rank Oldbie
Rank
Oldbie

I've just downloaded cwsdpmi.exe fromt the internet and called your program like "cwsdpmi a.exe".

I've also just finished a patch that adds support for LOCK in full and dynamic core (normal core already has it), and for XADD in full and normal core (doing that in dynamic is still beyond me). If that patch gets accepted, this stub will work in the next release. Or you can compile your own patched dosbox 😉

Reply 7 of 9, by rcblanke

User metadata
Rank Oldbie
Rank
Oldbie

Great work guys!

Moe, FYI, calling a.exe (or any executable for that matter) using "CWSDPMI a.exe" does not actually run a.exe, only the DPMI extender itself. Simply placing CWSDPMI.EXE inside the directory where a.exe resides is enough to be able to launch it. you can, however make CWSDMPI become memory resident using the -p flag: CWSDPMI -p<enter>a<enter> but that doesn't change the fact that it crashes in DOSBox anyway.

I'll certainly try to build DOSBox myself to check your patch!

Regards,

Ronald

Reply 8 of 9, by wd

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Moe, any reason why you used Bit8u oldrmrd in xadd
(normal core)? I had Bit8/16/32u at this place, which
should be correct wrt for example dword -1, or have
you differing information?

wd

Reply 9 of 9, by `Moe`

User metadata
Rank Oldbie
Rank
Oldbie

Probably a cut&paste bug. You're right, the old* variable should be of the matching size. I've never been in there before, so thanks for spotting the mistake 😉

(To be honest, I wonder which app really _needs_ XADD... CWSDPMI may execute it, but it obviously doesn't depend too closely on it's results. It's a multitasking thing, which is probably way off our scope. That's no excuse for a bug, of course.)