DJGPP and DOS

[sduensin]

After installing DJGPP and reading the Microwindows FAQs and DJGPP PDF, running: make -f Makefile_nr ARCH=DOS results in:

[ghaerr]

Hello @sduensin,

The DJGPP port is contributed, and Makefile_nr not well maintained, I am sorry. However, the gcc output clearly shows that the file device.h, which exists in the microwindows/src/include directory, is not accessible. A quick look at Makefile_nr shows that perhaps MW_DIR_SRC := $(CURDIR) isn't working. I am thinking you should change that and the MW_DIR_BIN on the next line to use the full path to microwindows/src.

Thank you!

[sduensin]

Thanks. I tried that. Tried setting MW_DIR_SRC on the command line, in the environment, changing the makefile, etc. It's not happy.

If it doesn't actually run on DOS and nobody supports it, maybe not list it as a target platform?

[ghaerr]

If it doesn't actually run on DOS and nobody supports it

It does work, I guess I was just saying that I can't easily test it, as my development environments are macOS and Linux.

Tried setting MW_DIR_SRC on the command line, in the environment, changing the makefile, etc.

I can't see the full gcc command line in your screenshot, since it's scrolled off the screen. I can see the method of getting the includes is complicated, with INC=-I$(MW_DIR_SRC)/include being set, then CFLAGS += $(INC), then contrib/makefile_nr/Makefile-drivers being used in a separate make -f. Can you show me the portion of the screen that shows the gcc command line and the -I options?

Thank you!

[sduensin]

I need to move my setup to a Windows box so I have scrollback. I'll see what I can do. Thanks again!

[lighth7015]

lol I've tried that, and if you can even get it to compile, the mouse code is broken.

[georgp24]

The DOS port has not been maintained for several years, it has to be checked now with the latest DJGPP version plus the changes done for Microwindows during the last years. In 2014 it did work, see my XFDOS distribution which I did with Microwindows and FLTK based on it. https://sourceforge.net/projects/fltk-dos/ I am currently working on a different project and do not have the time to test Microwindows for DOS. Georg From: Scott Duensing Sent: Tuesday, November 24, 2020 2:12 AM To: ghaerr/microwindows Cc: Subscribed Subject: Re: [ghaerr/microwindows] DJGPP and DOS (#56) I need to move my setup to a Windows box so I have scrollback. I'll see what I can do. Thanks again! — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[sduensin]

Yeah, I tried to build XFDOS, too. :-(

[GNUfan42]

Try copying everything in microwindows\src\include to DJGPP\INCLUDE. That worked for me.

[lighth7015]

Eventually, I need to get around to seeing why the mouse code is broken, because I'd love to see kind of a nice, in-process UI for (e.g. setup) applications that don't want to provide their own home-grown UI code, and could just fallback on nano-X. :D

[sduensin]

Anyone have time to help with this? There's coffee or beer in it for you. :-)

[lighth7015]

Beer works for me, or a few weeks worth of snacks! xD

[georgp24]

I made a fork of Microwindows several years ago. https://github.com/georgp24/microwindows-android-bin This is a version which compiles with DJGPP (in the version of DJGPP at that time). It also worked with FLTK and is almost the version I used for XFDOS.

[sduensin]

@georgp24 can you help me get this building for DOS using DJGPP under Linux? I'll be your friend. 😀

[georgp24]

I compiled it in a DOSBox of Windows XP, I never used DJGPP under Linux

[ghaerr]

Hello @sduensin, what are you looking to get working? I haven't (yet) used DJGPP but would like to help. Are you trying to cross-compile Microwindows using DJGPP on Linux for a DOS target, or run DJGPP on DOS itself?

Can DJGPP be run on a Linux or macOS system, to cross-compile for DOS?

I don't have easy access to DOS, but it looks from your first screenshot that the include file directories are not setup properly on the DOS box. Perhaps DJGPP is not setup properly. Can it be used to compile other C programs on your DOS system?

[sduensin]

@ghaerr short version: I need a killer GUI for a DOS program I'm building.

At this point, you can ignore the screenshot I posted. I had originally tried to build in DOS using the instructions in the repo. DJGPP and DOSBox don't exactly love each other and I can never seem to get a very reliable install of DJGPP fod DOS working.

The way I'm going about it now is to code and test on Linux and then cross-compile for DOS using DJGPP. I used the following to get my copy of DJGPP:

https://github.com/andrewwutw/build-djgpp

I've had some initial luck with @georgp24 's fork. A few minor tweaks and I got some of the demos to run. In an ideal world, I'd be using the "official" branch with the GRX backend. (GRX: http://grx.gnu.de/) I can live without GRX as long as I can get backends to work for both DOS and Linux.

The end goal is to run some kind of very lightweight window manager and FLKT (or similar) on top of it to allow creating a windowed GUI from C that runs in DOS. The project I'm working on is large enough without me needing to roll my own GUI (which is what I'm currently doing - very slowly).

[ghaerr]

I've had some initial luck with @georgp24 's fork. A few minor tweaks and I got some of the demos to run. In an ideal world, I'd be using the "official" branch

After you've played around a bit more with @georgp24's fork and have a feel for what works and doesn't, we can try to get things working from this repo, so feel free to share your experiences of what is working/not. I can do a diff -urN to determine what is different (Makefile_nr's, engine, nano-X etc) and should then be able to get this version running (again) with DJGPP.

In order for me to best help, I need to see specific error messages, which allow us to determine whether the problem is in tools setup, DJGPP itself, makefile(s), or a problem in the source code. Feel free to post that information.

In an ideal world, I'd be using the "official" branch with the GRX backend.

How does the GRX backend fit within Microwindows? Are you using GRX only for the EGA/VGA screen drivers, and somehow hooking that into the engine code? Or are you trying to port Nano-X code on top of GRX?

Thank you!

[sduensin]

I hope to get some more time to bang on it later today. At the moment, I have Nano-X building with JPEG and PNG support, and zlib for some font types. Freetype is next up and then FLTK.

Only thing in the code I had to change was a backslash to a slash in an include statement. I think it was the DJGPP VESA header. I really butchered the makefile in the main src directory though. :-) Make is not my strong point.

GRX isn't really needed. I just know it has really good VESA support and tends to be pretty fast.

[sduensin]

Okay! I have an update. I've managed to get Nano-X and NX11 to build. PX11, not so much. And none of the demos. Here's what I've learned...

My original problem from waaaaaaaaay back where it can't find device.h was due to the subst function in the makefile not working for some reason. I suck at make, so I just worked around it.

I'm using DJGPP on Linux Mint x86_64. I've made a tarball of my working directory hoping someone (hint, hint, @ghaerr ) feels like taking a look to see if they can make more progress and not make it an ugly mess like I fear I've done. I've made no changes to any of the files in the various source directories. Everything I've changed is contained in Makefile.dos and the build.sh script that compiles everything.

Running build.sh sets up a few environment variables, then does ugly bash-fu to adjust the environment of a subshell for compiling the various different libraries. There are a few sed statements that fix minor issues encountered along the way. It then copies my makefile into the microwindows directory and kicks off a build.

Everything is here: https://nextcloud.kangaroopunch.com/s/EPy4j6aEf9ZWFkd

If you want to chat about this in mostly real time, I'm found on my support Discord at: https://kanga.world/chat/discord

Long live DOS!

[ghaerr]

Hello @sduensin,

I've diff'd your Makefile.dos and the current (but old, originally named) Makefile_nr in this repo, and they are quite similar.
From the look of it, I would venture a guess that you could copy Makefile.dos and build.sh over to microwindows/src, and start the build on the current repo. You could then post the errors you're getting, and I could provide fixes quickly, if required in the source tree. After we get things working better, we could commit Makefile.dos and build.sh to replace the earlier non-maintained Makefile_nr.

I would be interested to know what stops working in your build, using this route. We could certainly make changes to eliminate the sed kluges etc in build.sh.

I'm running on macOS, not Linux, so I won't be able to easily cross-compile using DJGPP, but I think I could probably get the regular macOS (or another gcc) compiler working on macOS using the single Makefile.dos (to be renamed later) with a different TOOLSPREFIX= or TOOLS= prefix. At this point, you're compiling the tree(s) from a Linux DJGPP compiler toolchain, correct?

There may be other changes in @georgp24's tree that were never submitted, that could be required for using FLTK. After getting the basic Microwindows/Nano-X build working, we can diff -urN the microwindows/src tree differences and I should be able to quickly surmise what else needs to be done. The end result would be that we get DJGPP support back into a maintainable status, using the current repo so that future changes are easily tracked.

What do you think?

Thank you!

[sduensin]

Yeah, I started with Makefile_nr and just applied some changes to get it working. Where I'm at now is getting libPX11.a to build. It just doesn't happen. No errors at this point.

After libNX11.a is built, it does this:

make[1]: Leaving directory '/home/scott/code/FLTK_Nano-X_DOS/microwindows/src/nx11'                       
/home/scott/code/FLTK_Nano-X_DOS/djgpp/bin/i586-pc-msdosdjgpp-gcc  -I/home/scott/code/FLTK_Nano-X_DOS/micr
owindows/src/include -I/home/scott/code/FLTK_Nano-X_DOS/installed/dos/include -I/home/scott/code/FLTK_Nano
-X_DOS/installed/dos/include/freetype2 -I/home/scott/code/FLTK_Nano-X_DOS/microwindows/src/nx11/X11-local 
-Wno-deprecated-declarations -O3 -s -DDOS_DJGPP=1 -DMSDOS=1 -DHAVE_FILEIO=1 -DMW_FEATURE_IMAGES=1 -DMW_FEA
TURE_TIMERS=1 -DHAVE_SIGNAL=0 -DHAVE_FPRINTF=0 -DNONETWORK=1 -DUPDATEREGIONS=1 -DERASEMOVE=1 -DHAVE_MMAP=0
 -DNANOWM=1 -DHAVE_BMP_SUPPORT=1 -DHAVE_GIF_SUPPORT=1 -DHAVE_PNM_SUPPORT=1 -DHAVE_XPM_SUPPORT=1 -DHAVE_JPE
G_SUPPORT=1 -DHAVE_PNG_SUPPORT=1 -DHAVE_FNT_SUPPORT=1 -DHAVE_PCF_SUPPORT=1 -DHAVE_PCFGZ_SUPPORT=1 -DHAVE_F
REETYPE_2_SUPPORT=1 -DSCREEN_HEIGHT=600 -DSCREEN_WIDTH=800 -DSCREEN_DEPTH=8 -DSCREEN_PIXTYPE=MWPF_TRUECOLO
RARGB -DMWPIXEL_FORMAT=MWPF_TRUECOLORARGB -L/home/scott/code/FLTK_Nano-X_DOS/microwindows/src/lib   -c -o 
demos/nanox/landmine.o demos/nanox/landmine.c
echo "compiling /home/scott/code/FLTK_Nano-X_DOS/microwindows/src/bin/landmine.exe"
compiling /home/scott/code/FLTK_Nano-X_DOS/microwindows/src/bin/landmine.exe
/home/scott/code/FLTK_Nano-X_DOS/djgpp/bin/i586-pc-msdosdjgpp-gcc  -I/home/scott/code/FLTK_Nano-X_DOS/micr
owindows/src/include -I/home/scott/code/FLTK_Nano-X_DOS/installed/dos/include -I/home/scott/code/FLTK_Nano
-X_DOS/installed/dos/include/freetype2 -I/home/scott/code/FLTK_Nano-X_DOS/microwindows/src/nx11/X11-local 
-Wno-deprecated-declarations -O3 -s -DDOS_DJGPP=1 -DMSDOS=1 -DHAVE_FILEIO=1 -DMW_FEATURE_IMAGES=1 -DMW_FEA
TURE_TIMERS=1 -DHAVE_SIGNAL=0 -DHAVE_FPRINTF=0 -DNONETWORK=1 -DUPDATEREGIONS=1 -DERASEMOVE=1 -DHAVE_MMAP=0
 -DNANOWM=1 -DHAVE_BMP_SUPPORT=1 -DHAVE_GIF_SUPPORT=1 -DHAVE_PNM_SUPPORT=1 -DHAVE_XPM_SUPPORT=1 -DHAVE_JPE
G_SUPPORT=1 -DHAVE_PNG_SUPPORT=1 -DHAVE_FNT_SUPPORT=1 -DHAVE_PCF_SUPPORT=1 -DHAVE_PCFGZ_SUPPORT=1 -DHAVE_F
REETYPE_2_SUPPORT=1 -DSCREEN_HEIGHT=600 -DSCREEN_WIDTH=800 -DSCREEN_DEPTH=8 -DSCREEN_PIXTYPE=MWPF_TRUECOLO
RARGB -DMWPIXEL_FORMAT=MWPF_TRUECOLORARGB -L/home/scott/code/FLTK_Nano-X_DOS/microwindows/src/lib -o /home
/scott/code/FLTK_Nano-X_DOS/microwindows/src/bin/landmine.exe demos/nanox/landmine.o  -L/home/scott/code/F
LTK_Nano-X_DOS/installed/dos/lib -ljpeg -lpng -lz -lz -lfreetype -lz -lnano-X
demos/nanox/landmine.o:landmine.c:(.text.startup+0x60): undefined reference to `GdError'
demos/nanox/landmine.o:landmine.c:(.text.startup+0x264): undefined reference to `GdError'
demos/nanox/landmine.o:landmine.c:(.text.startup+0x814): undefined reference to `GdError'
demos/nanox/landmine.o:landmine.c:(.text.startup+0xa15): undefined reference to `GdError'
demos/nanox/landmine.o:landmine.c:(.text.startup+0xac0): undefined reference to `GdError'
demos/nanox/landmine.o:landmine.c:(.text.startup+0xd45): more undefined references to `GdError' follow
/home/scott/code/FLTK_Nano-X_DOS/microwindows/src/lib/libnano-X.a(srvmain.o):srvmain.c:(.text+0x11a): unde
fined reference to `GdDelay'
/home/scott/code/FLTK_Nano-X_DOS/microwindows/src/lib/libnano-X.a(srvmain.o):srvmain.c:(.text+0x452): unde
fined reference to `GdError'

You can see from the link that it's trying to link against libnano-X.a which I don't think contains all those missing functions. I don't know if it's trying to do the demos before PX11 or what. Like I said, I'm good enough with GNU Make to be dangerous.

[ghaerr]

Where I'm at now is getting libPX11.a to build. It just doesn't happen. No errors at this point.

Don't bother with libPX11, it isn't required and libNX11 can be used instead. libPX11 is not supported in the current repo. I can't remember exactly why @georgp24 originally created it, but libNX11 is now built to link directly with -lX11.

The GdError problem can probably be resolved by adding code that works with DJGPP to drivers/osdep.c::GdError(). Check that the osdep.o file is being linked - this was a later addition to move system dependent stuff out of the graphics engine source.

GdDelay is also in drivers/osdep.c, it will be resolved the same way.

[sduensin]

It seems osdep.o isn't listed as a needed object file in makefile_nr/Makefile-drivers. Adding it gets me farther. Now I have linker issues with additional libraries like FreeType. I think it may be the order they're being specified during the link.

[sduensin]

Whoo! This is working! It's very rough but it builds the demos and they run in DOSBox!

build.sh.txt
Makefile.dos.txt

[ghaerr]

It seems osdep.o isn't listed as a needed object file i

Yes - I mentioned that it was added later than the georg's tree.

in makefile_nr/Makefile-drivers

Are you starting with your Makefile.dos renamed, or using this repo's Makefile_nr? I suggest you use Makefile.dos from the other working tree first, then we'll replace this Makefile_nr with it.

Now I have linker issues with additional libraries like FreeType. I think it may be the order they're being specified during the link.

Feel free to post linker output, and we'll get through it quickly. All of libz, FT, jpeg etc should come after the libnano-X.a (and libNX11). Are you using the version of FT specified in engine/font_freetype2.c (v2.3.12), or a later version? I recommend staying with the older 2.3.12 at first, we can then port a later version.

[ghaerr]

Whoo! This is working! It's very rough but it builds the demos and they run in DOSBox!

Nice!!

Is the mouse working? @lighth7015 mentioned that it wasn't working.

Which version/where did you get the DJGPP compiler you are using? I am thinking about how I can test your Makefile.dos so I can help clean it up for commit.

[sduensin]

The mouse works fine in DOSBox Staging. I had issues in DOSBox-X but it has a zillion configuration options and I probably just haven't hit on the right one yet. I hope to try it on real hardware soon.

The DJGPP I use came from here: https://github.com/andrewwutw/build-djgpp

Still need to get FLTK to build but that shouldn't be too terribly difficult. Then I need to learn how to customize the entire thing so it looks decent and doesn't run like a rock. Dragging full windows around on a 486DX/100 is painful. Setting the defines in the makefile didn't change anything.

But this is awesome! I'm excited!

[ghaerr]

But this is awesome! I'm excited!

Me too. This issue has been open for a year and a half so its nice to get working finally!!

Dragging full windows around on a 486DX/100 is painful. Setting the defines in the makefile didn't change anything.

All the options XORMOVE, ERASEMOVE and UPDATEREGIONS in Makefile.dos only affect Win32 API programs. For nano-X, try editing include/nanowm.h and changing OUTLINE_MOVE to 1. There are a number of other configurable options in include/mwconfig.h you may want to look at. After you find options that work well, we can move them into -D options in a Makefile rather than having to run sed or edit a file, if needed.

so it looks decent and doesn't run like a rock

It's a bit more complicated, but if NUKLEARUI is set to 1, a much newer window frame is drawn. We can also work on optimizing the blit code based on the actual hardware you want to draw on, and it's color setting. What is the graphics hardware and pixel setting you want to use on the target? (e.g. 32 bit ARGB, 16 bit 565, etc).

[ghaerr]

The DJGPP I use came from here: https://github.com/andrewwutw/build-djgpp

Wow - that version is available for macOS, so I should be able to run the entire cross-compiler over here as well. That will help a lot.

[ghaerr]

Here's the window manager running the newer look with NUKLEAR=1, using ./runapp demo-ttfont. The colors can be tweaked to best match what FLTK might have to offer:

[sduensin]

Yep. Easy fix.

#ifdef __DJGPP__
#define HAVE_USLEEP
#else
#undef HAVE_USLEEP
#endif

[sduensin]

Alright! With just your repo and these three files, it's all building until we run into needing fluid for the host compiler, not the target. Not sure how to properly handle this yet. Ideally, we'd get a build for both.

buildcrossdos.sh.txt
Fl_Native_File_Chooser_GTK.cxx.txt
fl_open_uri.cxx.txt

[sduensin]

Not all the demos actually work under DOS (tuxchess for example), but I'm not terribly concerned. And some, like Tetris, don't do anything unless you're constantly wiggling the mouse around. :-)

[ghaerr]

Yep. Easy fix.
#ifdef DJGPP
#define HAVE_USLEEP

I'll fix that, thanks.

Not all the demos actually work under DOS (tuxchess for example).

Let me know which ones do not. tuxchess needs to have the chess piece images available (which are by default) in images/demos/tuxchess/. What isn't working?

And some, like Tetris, don't do anything unless you're constantly wiggling the mouse around. :-)

Actually, that helps a lot. That means that the GrGetNextEventTimeout() isn't working, which could affect some FLTK programs. I'm going to have to find a way to test the DOS DJGPP version of these executables. Are you using a DOS emulator to run these, and is there anything else required to be installed, other than, say MSDOS 6.22?

With just your repo and these three files, it's all building

Wow! Thanks for fixing up buildcrossdos.sh, I'll add your changes. And probably produce a patch file for the other two FLTK .cxx files.

until we run into needing fluid for the host compiler,

I'm thinking perhaps do the normal non-cross regular Linux build of FLTK, then copy fluid out somewhere into your path. Then, rebuild using buildcrossdos.sh, and hack the Makefile(s) somewhere to substitute the host version of fluid... ?

[sduensin]

GrGetNextEventTimeout() being broken may cause the demo issues I'm seeing. They tend to either show the desktop and mouse pointer and then freeze - but still respond to ESC, or they show the desktop, pointer, and totally freeze the DOS "machine" forcing me to close it.

For my testing, I'm using DOSBox Staging. It has it's own "DOS" built-in. You don't need anything else. The only thing I've done is adjust the config file to make it display at 3x on my screen and limit the "cycles" to approximate a 486DX4/100.

buildcrossdos.sh is almost exactly what I need as an end result. I typically have a "buildPrerequsites.sh" I can run in my projects to produce any libraries I can't just toss into my source tree.

I like the FLTK idea. I need Linux builds of everything anyway, so that's not any extra work. I'll need to look at the makefiles some more and see if I can grok what they're doing.

I can't express how much I appreciate all the help with this. There can't be that many crazy DOS programmers out there anymore. :-)

[ghaerr]

I'm using DOSBox Staging.
The only thing I've done is adjust the config file to make it display at 3x on my screen and limit the "cycles" to approximate a 486DX4/100.

Can you post your config file please, I'll download it and use your same settings.

Let me know how the fluid build hack goes, we can probably write a script for that too once you find how to do it. I'll commit buildcrossdos.sh and I think you needed the export INSTALLED= to crossdos.sh as well.

I can't express how much I appreciate all the help with this.

I'm happy to help. It's about time this open outstanding issue got resolved, and I'm glad the Makefile_nr stuff is back into being maintained and used :)

Definitely let me know about any other demos that don't work, or changes you make. We need to keep them in the repo so that it all works when we need it!

[sduensin]

Here's the shell script and config I use to run DOSBox. On Linux, I'm using a Flatpak so you'll have to adjust for Mac.

test.conf.txt
test.sh.txt

[sduensin]

OK, I'm confused. I did the following with FLTK:

• In Makefile I removed fluid from the DIRS variable
• I renamed fluid/Makefile to 'fluid/Makefile.hidden`
• I added ln -s "$(which fluid)" fluid/fluid.exe to buildcrossdos.sh to use the system copy of fluid

The build removes my symlink (which I added after make clean) and tries to compile fluid.exe itself. I have no idea where it's getting the idea to compile it's own fluid binary. The related output is:

Compiling editor.cxx...                                                                                   
Linking editor.exe...                                                                                     
Compiling ../fluid/fluid.cxx...                                                                           
Linking ../fluid/fluid.exe...                                                                             
../fluid/fluid.o:fluid.cxx:(.text+0x16b): undefined reference to `template_panel'              
../fluid/fluid.o:fluid.cxx:(.text+0x173): undefined reference to `make_template_panel()'        
../fluid/fluid.o:fluid.cxx:(.text+0x178): undefined reference to `template_clear()'                  
../fluid/fluid.o:fluid.cxx:(.text+0x186): undefined reference to `template_browser'

(Undefined reference errors continue for pages.)

[ghaerr]

I have no idea where it's getting the idea to compile it's own fluid binary.

I am guessing it is using the time/date stamp associated with the symbolic link to figure it needs to recompile fluid every time, with bad results.

Perhaps forget the ln -s idea, and remove fluid target Makefile dependencies that try to build fluid's .o files, then replace the actual fluid target build line with a cp $(which fluid) fluid/fluid. That should give make the idea that it is built.

Hopefully the Makefile isn't too nasty. I am not a fan of autogen.sh or ./configure, as its very hard to decipher the resulting makefiles.

[ghaerr]

Do you really need all the FLTK demos built? Even if you're using the fluid designer tool for your own applications, you should be able to write a script that uses the host fluid and DJGPP to compile and link the final binaries, right?

[sduensin]

I did remove the Fluid Makefile. No idea how it's figuring out how to build it.

And, no, I don't need the demos. You just seem to like getting demos to build, so I figured I'd do the same. :-)

[sduensin]

Ah ha! The cp instead of ln fixed the rebuild issue due to the time stamps. Good thinking!

Sudoku caused some issues as well due to a non-existent resource compiler on DOS (it assumed "EXE" was Windows).

This fixes both:

buildcrossdos.sh.txt

[sduensin]

I was going to make a list of demos that had issues but that's going to be "pretty much all of them". Add segfaults and redraw issues (RESIZE.EXE) to the list of problems.

[ghaerr]

Add segfaults and redraw issues (RESIZE.EXE) to the list of problems.

I just finished tracking down the nasty segfault bug where various applications would crash right on startup, but not always. It was an uninitialized pointer. I will be pushing that fix with the font setup fixes later tonight, along with fixes for the rest of your (smaller) reported problems.

What exactly is the redraw issue with RESIZE.EXE?

[sduensin]

[ghaerr]

Thanks for the report on FLTK test/resize, @sduensin. I have pushed the fixes for the application crashes, and all the font fixes, and lots of other stuff.

I am having big problems getting all the libraries cross-compiled for DOS using macOS, I can't even get past zlib, which is failing because macOS ar is being used, and it won't produce .o archives with DJGPP .o files. I'm working on that, but in the meantime I can reproduce all the library, Microwindows and FLTK code running on macOS at least, where there is still potential fixing to be done.

At this point, almost all the FLTK demos run, and work properly. Let me know what you find with the new code. If they don't run on DOS, that means we have porting issues, rather than actual Microwindows bugs. (yes, I'm sure we still have Microwindows bugs though :)

I am also aware of some Microwindows demos not working properly on DOS, like ntetris. I hope to debug that, but ran into huge issues trying to get a home-brew installed version of DosBox Staging installed, which nearly wrecked my development system, causing QEMU to fail, and ultimately would not install. It seems I need Catalina in order to run DosBox Staging, which I can run on my laptop. So DOS testing is delayed at the moment, which means the Nano-X timer issues remain unfixed.

[sduensin]

You can also try DOSBox-X or just boring old vanilla DOSBox. We're not really using any of the newer features of X or Staging other than possibly some improved S3 video code.

I'll get the latest built and test some of the demos and see what happens.

[ghaerr]

You can also try DOSBox-X or just boring old vanilla DOSBox.

How do you get the DOS programs loaded into DosBox-X? I notice DosBox Staging has a mount command that seems to auomatically add a host directory into a simulated FAT filesystem... is that available or DosBox-X, I do have that installed.
[EDIT: never mind, I found the mount command it it works!]

[ghaerr]

@sduensin, I have the Microwindows demos cross-compiling for DOS and running on DosBox-X!

However, the colors are wrong, and the mouse isn't working. How are you setting up the mouse to work within DosBox Staging? (and I assume the pixel layout too?)

[sduensin]

I also have mouse issues in DOSBox-X. There's some setting called "Internal Mouse" or some such that I haven't played with yet. I'll see what I can learn.

I don't have color issues in either version of DOSBox. Maybe compare the Video/S3 settings in the config I posted for Staging to the defaults in X?

[ghaerr]

Maybe compare the Video/S3 settings in the config I posted for Staging to the defaults in X?

I can't find anything on Video/S3 in your config file, other than 'machine=svga_s3'. Do you mean that? I set it under [dosbox] and no change.

[ghaerr]

Also, tuxchess requires opening several .gif files for the board and chess pieces. I've just added them to be copied to demos/images/*.gif in Makefile_nr, and also enabled -DHAVE_GIF_SUPPORT=1, which was missing. However, it seems that the open code on those files may be failing. Does DOS require the open() to have the filenames in upper case? If so, that's our next problem.

We also need a way to map DPRINTF calls to somewhere preferably outside the emulator onto the terminal somehow to enable better debugging...

[sduensin]

DOS is not case sensitive. It shouldn't care. If the names are more than 8 characters long that could upset it.

I wish there was a way to write to the DOSBox console from a DOS program. Currently there is not. In my other apps I've just been logging to a file.

[sduensin]

I set up DOSBox-X and confirmed I'm using machine=svga_s3. The mouse issue turned out to be that DOSBox-X wants you to "capture" it before it will respond. Just hit CTRL-F10.

[sduensin]

TUXCHESS still hangs at start. And every FLTK demo I tried hangs on exit. But nothing has outright blown up!

[ghaerr]

Thanks, on the mouse, that works.

The color is still not correct - I'm using the unmodified pixel format in Makefile_nr: SCREEN_PIXTYPE = MWPF_TRUECOLORARGB. I changed that to BGRA and the programs won't even run, which is strange. Here's a screenshot:

Here is my "dosbox-x.conf":

[dosbox]
debug=true
machine=svga_s3

[sdl]
output=bitmap
doublescan=true

[ne2000]
ne2000=true
nicirq=12
backend=pcap

[ethernet, pcap]
realnic=lo0

[autoexec]
mount c /Users/greg/net/microwindows/src/bin
c:

I'm starting dosbox using:

./dosbox-x-sdl2 -set "dosbox quit warning=false" -fastlaunch

[ghaerr]

TUXCHESS still hangs at start. And every FLTK demo I tried hangs on exit. But nothing has outright blown up!

Yes, I can't get tuxchess to display anything. I don't think its a hang - just that it isn't displaying any graphics. I just recently updated Makefile_nr to support GIFs, but adding -DHAVE_GIF_SUPPORT=1 and copying the *.gif files to demos/tuxchess/images.

Did the FLTK demos work prior, and now they hang? That's also kind of strange, since I haven't really changed anything that should affect that. But at least most of them run now... ?

[ghaerr]

Hello @sduensin,

Ok, finally I have dosbox-x working. It required an upgrade to version 0.83.25 on macOS to fix the color issue, which luckily was just fixed 18 days ago. I can now test all Microwindows/Nano-X DJGPP binaries on DOS. Tuxchess is still not working because it can't load images, and then hangs when calling GrError, which tries to write to stderr. This must have something to do with trying to write text when the screen is in graphics mode in dosbox-x, or possible DOS as well.

I've figured out the timeout fix and ntetris is now working.

I can't test any of the FLTK directly on DJGPP/DOS, since still can't get external libraries cross-building on macOS, but that's ok.

Is there a way to turn on long filenames in dosbox-x, so I can actually read the longer .exe filenames from the Nano-X demos?

Thanks for your help!

[sduensin]

In the config file for DOSBox-X (look in ~/Library/Preferences/DOSBox-X <version number> Preferences) you can set ver=7.1 (the DOS version) or lfn=true to enable long filename support.

[ghaerr]

I've fixed tuxchess, turns out the load image open function didn't have O_BINARY set, required for DOS.

Tracking that done, found that GrError/GdError from Nano-X hung programs trying to write to stdout. Fixed by writing to log.txt and exiting.

Adding lfn=true worked, except that causes dosbox-x to abort segfault after doing file I/O, so I'm leaving that option out for now.