Open JoeC4281 opened 3 years ago
ADDENDUM: It would also seem that I cannot run the compiled .EXE, without DosBox-X hanging, in anything but Simple CPU Core.
That is, pre-link I do;
Z:config -set cpu core simple
...then;
EXOSPACE.EXE FILE TEST2
TEST2.EXE is generated successfully. Next;
Z:config -set cpu core auto
C>test2.exe
DOS/16M Protected Mode Run-Time Version 6.01
Copyright (C) Tenberry Software Inc. 1987 - 1994
...and DosBox-X hangs.
Joe
FURTHER: Here is the source code for TEST2.PRG;
#include "simpleio.ch"
Proc Main()
LOCAL a
a = val("3")
? a
? val("3")
Return
On DosBox-X, TEST2.EXE displays;
C>test2.exe
DOS/16M Protected Mode Run-Time Version 6.01
Copyright (C) Tenberry Software Inc. 1987 - 1994
2
2
On vDosPlus 2015.11.01 (build 2017.03.15), reported DOS version: 7.10, TEST2.EXE displays;
C>test2.exe
DOS/16M Protected Mode Run-Time Version 6.01
Copyright (C) Tenberry Software Inc. 1987 - 1994
3
3
Note that I used the same file, TEST2.EXE, on both DosBox-X and vDosPlus, and that DosBox-X does not display the correct results.
Joe
Can you send us the said program(s) so that we can check them out directly? Thanks.
Hey @Wengier, I have Clipper 5.3 on a CD, but it would probably be easier for you (and me) to download it from WinWorld;
https://winworldpc.com/download/c29d36c3-af2f-5a65-11c3-a5c28fc2a3ef
Clipper 5.3a update: https://winworldpc.com/download/c39c6bc3-a0c2-a35a-6511-c3a5c28fc2a3
Joe
TEST2.EXE is in the attached test.zip file
@JoeC4281. Thanks for the links. I can confirm that with the setting core=auto
or core=dynamic
(dynamic_rec or dynamic_x86) DOSBox-X will freeze when executing the command exospace file test2
. However, if I set core=normal
or core=simple
then DOSBox-X will run the command just fine, and I will eventually get the result 3 (not 2) when running test2.exe:
So it should run fine if core=normal
is set, in addition to core=simple
.
It appears that I got the result 2 instead of 3 only if I run the Visual Studio 64-bit builds (SDL1 or SDL2). Can you please try the Visual Studio 32-bit builds (SDL1 or SDL2) or MinGW builds instead for the result?
I guess I should have mentioned that I compile from source using Visual Studio 2019, and generate an x64 .EXE
I will compile from source using Visual Studio 2019, and generate an x32 .EXE, and see what happens with that.
Joe
Okay, with an x32 DOSBOX-X.EXE, I get;
C>Z:config -set cpu core normal
C>test2.exe
DOS/16M Protected Mode Run-Time Version 6.01
Copyright (C) Tenberry Software Inc. 1987 - 1994
3
3
C>Z:config -set cpu core simple
C>test2.exe
DOS/16M Protected Mode Run-Time Version 6.01
Copyright (C) Tenberry Software Inc. 1987 - 1994
3
3
Core set to auto or dynamic hangs TEST2.EXE
EXOSPACE.EXE also works as it should with simple and normal, but hangs with auto or dynamic.
Thus, as you said, DOSBOX-X.EXE, when compiled with VS2019 to an x64 .EXE, produces the incorrect results for TEST2.EXE, but compiling to an x32 .EXE produces correct results for TEST2.EXE
Also, core set to auto or dynamic causes DOSBOX-X.EXE to hang in both x32 and x64 .EXEs with TEST2.EXE, and EXOSPACE.EXE
If it matters, I'm using;
Microsoft Visual Studio Community 2019
Version 16.8.6
VisualStudio.16.Release/16.8.6+31019.35
Thankyou @Wengier, I'm looking forward to finding out why this happens.
Joe
Hi @Wengier I just installed 0.83.18 (October 1, 2021).
In regards to my Clipper app printing 2 instead of 3;
I'm still having the problem with the e:\dosbox-x\win64_builds\x64_release, and the e:\dosbox-x\win64_builds\x64_release_sdl2, that is, printing 2 instead of 3
The e:\dosbox-x\win64_builds\mingw version returns the correct results. The e:\dosbox-x\win32_builds\x86_release version returns correct results.
Looking forward to finding out why this happens.
Joe
It is know that the VisualStudio builds have issues with the FPU emulation as VS does not support the "long double" data type.
The below error occurs when running test2.exe (using Visual Studio 2019 SDL1 x64 build), regardless of the core used.
ERROR EXEC:stack underflow/wrap at EXEC SS:SP=0000:0000
As stated above, dynamic/auto core gets stuck (DOSBox-X itself is not frozen, you can still use the menus and exit, etc.) and so does full core. Simple and normal cores don't get stuck.
I believe that I have found a solution.
In the .conf file, if I set fpu=false
the .prg compiles, links, and executes with no problems,
and returns the correct results,
using the MSVC 64-bit DOSBOX-X.EXE, version 0.83.21 (SDL1, 64-bit), Dec 31, 2021
The LOGFILE.TXT contained;
Pentium CMPXCHG8B emulation is enabled
0 FPU:FPU core: double FPU (caution: possible precision errors)
which I hope will assist in finding out why fpu=true
causes the errors that I indicated in my op.
Joe
The FPU does not work properly on MSVC builds. This is a limitation of MSVC. Try a MinGW build instead.
I believe that I have found a solution.
In the .conf file, if I set
fpu=false
the .prg compiles, links, and executes with no problems, and returns the correct results,
For what?
DOSBox-X currently provides full 80-bit IEEE floating point precision support for the x86_32 and x86_64 architectures. The exception here is the version vsbuild-win64 which also does not provide full precision. This has been mentioned twice in this thread. Many times in others.
The app you provided TEST2.EXE
works fine in DOSBox-X with core=dynamic_x86
with DPMILD16.EXE.
I checked under Win98 SE and the result is also correct (of course with core=dynamic_x86
).
It seems that EXOSPACE will only work when I am using the Simple CPU Core.
Using CPU core -> Simple core;
I can link an .OBJ file with no errors;
Using CPU core as Normal, Dynamic, or Full results in EXOSPACE hanging DosBox-X;
...with DosBox-X having to be shut down and restarted.
Why does EXOSPACE only work with the Simple CPU Core?
Joe
NOTE: Please find attached the LOGFILE.TXT for each scenario.
logfile.hang.txt logfile.txt