truth5678 wrote:I'll definitely work on it. I'm almost finished with my current task, I believe it is certainly an obscure line of code in this […]
Show full quote
I'll definitely work on it. I'm almost finished with my current task, I believe it is certainly an obscure line of code in this current case!
I'll run a difference between 0.72 and SVN and isolate the issue that way. I'll verify the different cores and whether they have an effect in either or both versions. 😀
Edit: saw this in the compat list for second reality (must be 0.72? (2008)) --
"Runs perfectly, on my setup.
Demo crashing halfway (during the "particle spring" part) is a bug in the demo, which relates to the path being to long (also happens to real DOS machines). Run it from C: or a 1 level deep subdirectory to fix."
Huh. So the programmers used too short a char buffer for file paths?
I extracted the Second Reality files to a folder and made that drive C, then used symbolic links (in Linux, 'ln -s') that point back to the root directory. To the DOS VM, they become subdirectories that have the same content as the root directory to make doing this test easier.
I would like to note that in my tests it doesn't matter if you use GUS, SB, or silent audio output, the crash is the same. In these tests, I used GUS playback.
Test results:
Starting dosbox-x with dynamic core, running SECOND.EXE and no ULTRASND variable: Invalid opcode exceptions
Starting dosbox-x with normal core, running SECOND.EXE and no ULTRASND variable: It works
Starting dosbox-x with dynamic core, running SECOND.EXE and ULTRASND variable (GUS emulation enabled): It works
weird...
Run from C:\SECOND.EXE - No problems.
Run from C:\X\SECOND.EXE - Particles fall rapidly, hit the floor, crash with runtime divide by zero (same result as vanilla DOSBox). Music for that section kept playing with a blank screen until the next part.
Run from C:\XX\SECOND.EXE - Same as "X"
Run from C:\XXX\SECOND.EXE - No problems.
Run from C:\XXXX\SECOND.EXE - No problems.
Run from C:\XXXXX\SECOND.EXE - Lockup (DOSBox complains about invalid opcodes)
Run from C:\XXXXXX\SECOND.EXE - Lockup (DOSBox complains about invalid opcodes)
Run from C:\XXXXXXX\SECOND.EXE - No problems.
Run from C:\XXXXXXXX\SECOND.EXE - No problems.
Run from C:\XXXXXXXX\X\SECOND.EXE - Particles fall but many of them are not being drawn, then part hangs.
Run from C:\XXXXXXXX\XX\SECOND.EXE - Lockup (DOSBox complains about invalid opcodes)
Run from C:\XXXXXXXX\XXX\SECOND.EXE - Lockup (DOSBox complains about invalid opcodes)
Run from C:\XXXXXXXX\XXXX\SECOND.EXE - Particles fall but many of them are not being drawn, then part hangs.
Run from C:\XXXXXXXX\XXXXX\SECOND.EXE - Particles fall but many of them are not being drawn, then part hangs.
Run from C:\XXXXXXXX\XXXXXX\SECOND.EXE - No problems.
Run from C:\XXXXXXXX\XXXXXXX\SECOND.EXE - No problems.
Run from C:\XXXXXXXX\XXXXXXXX\SECOND.EXE - Lockup (DOSBox complains about invalid opcodes)
I'm sure I could run all the way out to several directories deep, but I think this conveys the apparent pattern well.
The thing is I remember running the demo possibly one, two, or three folders deep from Windows 98 "DOS mode" back in the day with no problems. Are you sure DOSBox isn't doing something to overrun a buffer somewhere? According to descriptions of the source code, part of their "Demo Interrupt Server" involves hooking INT 21h to allow running EXE files and their datafiles directly from within the SECOND.EXE which probably doesn't help diagnosing this problem.
One guess I have is that this might be another one of those memcpy() vs memmove() mistakes, possibly within DOSBox-X itself. The difference between copying one region of memory to another (that doesn't overlap) verses copying memory regions that overlap, in order to shift contents back or forth a few bytes, like when taking a C-string and using memmove() to shift the rest of the string back to overwrite some characters you don't want anymore. I can explain in more detail why memcpy() vs memmove() matters if you like.
DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.