EXOSPACE only works with Simple Core

[JoeC4281]

DosBox-X version 0.83.12 (SDL1, 64-bit)

Build Date/Time: Mar 14, 2021 8:28:39am

I am using 4DOS.COM as my command processor.

Windows 10 [Version 10.0.19042.867]
BuildNumber  Caption                   CSDVersion  OSArchitecture  Version
19042        Microsoft Windows 10 Pro              64-bit          10.0.19042

I am using Clipper 5.3 and Exospace for Clipper 5.3

C>exospace

ExoSpace for CA-Clipper 5.3
Copyright (c) 1993 - 1995 Computer Associates International, Inc.

DOS/16M Copyright (c) Tenberry Software, Inc. 1987 - 1995
Usage: EXOSPACE [@<scriptname>] [<script commands>]

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;

C>exospace file test2

ExoSpace for CA-Clipper 5.3
Copyright (c) 1993 - 1995 Computer Associates International, Inc.

DOS/16M Copyright (c) Tenberry Software, Inc. 1987 - 1995

EXO1 - General Linking Utility (for CA-Clipper ExoSpace).  V2.11(w/VMM 6.01)
Copyright (c) Tenberry Software, Inc. 1987 - 1994

Reading object files and library headers.
Processing library directories.
Extracting library objects.
Assigning selectors.
Preparing GDT image.
Writing code image to .EXP file.
Sorting 1734 relocations.
Building relocation tables.
Writing GDT image to .EXP file.


1032256 bytes used out of 31586240 bytes available.


Generating .\TEST2.EXE...

EXOSPACE : .\TEST2.EXE successfully linked

Using CPU core as Normal, Dynamic, or Full results in EXOSPACE hanging DosBox-X;

C>exospace file test2

ExoSpace for CA-Clipper 5.3
Copyright (c) 1993 - 1995 Computer Associates International, Inc.

DOS/16M Copyright (c) Tenberry Software, Inc. 1987 - 1995

...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

[JoeC4281]

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

[JoeC4281]

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

[Wengier]

Can you send us the said program(s) so that we can check them out directly? Thanks.

[JoeC4281]

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

test.zip

[Wengier]

@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.

[Wengier]

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?

[JoeC4281]

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

[JoeC4281]

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

[JoeC4281]

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

[rderooy]

It is know that the VisualStudio builds have issues with the FPU emulation as VS does not support the "long double" data type.

[Allofich]

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.

[JoeC4281]

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

[rderooy]

The FPU does not work properly on MSVC builds. This is a limitation of MSVC. Try a MinGW build instead.

[grapeli]

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).

dosbox-x.core.dynamic_x86.test2.exe.webm

dosbox-x.core.dynamic_x86.win98se.test2.exe.webm