VOGONS


First post, by digistorm

User metadata
Rank Member
Rank
Member

If not, then I have discovered a bug 😉
I am running DOSBox 0.74 and with certain demo scene demo's, it crashes on load of the executable. With 0.73 it hangs (meaning the DOSBox window doesn't respond to input).
Is there any interest in demo code making DOSBox crash, or does it fall outside the games-only focus? Demo code is known for the use of obscure instructions and constructions that may never be used in commercial software.
I am running Mac OS X Lion 10.7.1 and I don't recall having tried to run the same code under Snow Leopard. It had nothing to do with the SDL bug, other software runs just fine within the bounds of the current SDL build (that has its flaws).

Reply 1 of 12, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

your topic title has nothing to do with your question.

To answer your question.
We sometimes fix them, but they are low priority. If you search the forum you will some threads were actively demos have been analized and fixed

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

Reply 3 of 12, by digistorm

User metadata
Rank Member
Rank
Member

Well, my question was really if a crashing DOSBox is expected behavior. And with crashing I thus mean ungracefully closing of the program or stopping to respond. And apparently that is the case. I have never seen any other emulator do this by design, so my question seems reasonable to me.
I don't mean that code run inside an emulator shouldn't crash of course, it can be expected that certain programs (especially demoes) crash, and I know that some demoes have been recompiled to remove MMX code that is not emulated in DOSBox. So, I really meant: crashing is normal? I can imagine that working with the dynamic cpu core is tricky - emulators for other platform not usually do this.

Reply 4 of 12, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Have you tried the different cores and emulated systems?

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 5 of 12, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

I've seen VPC, Vmware, Virtualbox crash plenty when code is run in them so yes it does happen but as you can imagine people have better things to do than prevent DOSBox from crashing when someone runs a program in the emulator that isn't a goal of the emulator to run.

How To Ask Questions The Smart Way
Make your games work offline

Reply 6 of 12, by collector

User metadata
Rank l33t
Rank
l33t

When code can crash a real DOS machine, why should it be any surprise that the same code can crash a DOS emulator? Like DosFreak, I have had nearly all emulators/virtualizers running DOS crash at some point, too.

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

Reply 7 of 12, by digistorm

User metadata
Rank Member
Rank
Member

because an emulator simulates another machine, and the software that you run runs in a closed environment. The simulated environment can die, but the shell around it (the emulator) should not. Just as we don't expect our browser to crash from a bad plugin or our operating system crash from bad software. Yes they do, but it is not designed behavior, and considered a bug. And that was my whole question: is this expected behavior or did I find a bug? And no, I don't expect that DOSBox is made to run all exotic software that can be found, but I would like to repeat that emulators of OTHER PLATFORMS (I am not talking about VMware or the likes, but emulators of C64's, SNESes and other oldskool platforms) do not crash unless it's a bug.
On the other hand, I can UNDERSTAND that x86 emulators are more likely to crash because the environment is much more complicated and the emulation is not cycle exact and uses tricks to achieve reasonable speed.

Reply 9 of 12, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

it's not even a game, it's a demo...
@digistor, you could try my svn build, see the stick SVN builds thread in this forum right at the end

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 11 of 12, by digistorm

User metadata
Rank Member
Rank
Member

Ok, relax everybody... I think I've elaborated quite a bit that I did not expect anybody to change the way DOSBox works or to put a lot of work in something that is not worth the effort. I just wanted to know if I stumbled upon something that was worth checking out for the developers. From the way that people react on this, I _guess_ that what I experience is the way DOSBox works and is meant to work. That is okay with me. But if anyone was interested to find out how I got it to crash, I could at least give the executables. But I too realize that it may be a lot of work for just a single case where things crash. And that the source of the problem is an executable that may not be stable in the first case. So I wondered if that would be even worth the effort, and what the official view is concerning crashing applications. Well, I think I get it now.
@Dominus: I have tried almost every combination of core and cpu type, and also via only, svga s3 and vesa, but the result is the same. I expect the executable to use some non standard cpu instruction or memory driver, demoes were notorious for using awkward and home built protected mode systems.
I've tested your SVN snapshot, and it does not crash and quit, but it seems to hang and stop to respond to user input. For example: when a DOS program hangs, I can still quit the DOSBox with the red close button. That will not work in this case.
@h-a-l-9000: For now, the demo that does weird things is Misguided by Haujobb, to be found at http://www.scene.org/file.php?file=/demos/gro … sg.zip&fileinfo