Dosbox-x: Really Bizarre Filesystem Issue

[sduensin]

Describe the bug
Using OpenWatcom to compile a program, the results are written in totally the wrong place:

• Everything is a subdirectory under C:\fltkpico
• Source code is in src
• Compiled object code should be written to obj

But...

• A zero-byte file is written to obj
• The actual obj output is written into the source file!

To Reproduce
Unpack the attached tarball. (Rename, please, GitHub didn't like my bz2 file.) My configuration and everything are included. The B.BAT in the root begins the build.

Expected behavior
fltk.lib generated in the lib folder. Confirmed this works under actual DOS (Windows 98).

Screenshots
No screenshot. DOSBox-X eventually blows up.

Environment (please complete the following information):
DOSBox-X 0.83.8 on Linux Mint 19

Additional context
Never seen anything like this before. :-)

Not really a zip:
dosbox-x.tar.bz2.zip

[Wengier]

@sduensin Thanks for posting the issue you encountered. I have tried your package and made minor modifications to the B.BAT batch file to let it run on my system. What I got is the following screen:

Clearly wpp386 complains about the source file srcfl.cxx. And by looking at the file fl.cxx in your tarball, it is apparently not a C source file (similar for FL_Bitmap.cxx). Perhaps you did not include the original source file in the tarball?

Also, can you post the DOSBox-X configuration file you are using? Thanks!

[sduensin]

Ah crap! Yep, that's the object file that overwrote the source. Apparently I tarred the wrong thing. New src attached. And this time, it IS a zip. :-)

src.zip

[grapeli]

@sduensin
Looks like a serious bug (with long filenames or 4dos.com). Certainly source files should never be overwritten with relocatable files.
From FreeDOS (doslfn) running under DOSBox-X, the compilation is done correctly and successfully, and the whole thing is really fast.

For comparison (on a really slow processor) how fast is the compilation process from the included dosbox-x.tar.bz2.zip file:
54s - dosemu1 (32-bit), (host filesystem) - video, kernel+initrd
72s - dosemu2 (host filesystem)
161s - qemu-2.8 (kvm), freedos (doslfn)
192s - qemu-5.2.0-rc2 (kvm), freedos (doslfn)
414s - dosbox-x (core=dynamic_x86), freedos (doslfn)
2538s - qemu-5.2.0-rc2 (tcg), freedos (doslfn)

edit: I created a minimal image with bootable freedos and only the necessary files needed to run a test build.
freedos.img.zip
B.BAT starts the compilation process.
From this smaller image, compilation is faster under qemu.

[Wengier]

Thanks @sduensin for reporting the issue and @grapeli for the testing and the minimal image! I could reproduce the issue, and I noticed something very strange with the input (DS:SI) to one of the LFN functions (and always the input to this function; the data for other LFN functions seem to be okay) when running Watcom C++ 2.0. I will study it further.

[Wengier]

@sduensin and @grapeli I think I have already solved this issue in the latest code. Hopefully the source files will no longer be overwritten for running Watcom C++ 2.0 in LFN mode any more.

[grapeli]

I confirm. Now compilation runs correctly and successfully directly from DOS DOSBox-X. No files are overwritten anymore. You got it really fast.

C:\fltkpico>ver
DOSBox-X version 0.83.9 (SDL2). Reported DOS version 7.10.

[sduensin]

Fixed before I reported! That's fast! Thanks!