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

[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:

[ghaerr]

Hello @sduensin,

I downloaded a macOS version of DJGPP and have everything compiling over here. I plan on making changes to microwindows/src so that you don't have to run sed statements, and will commit them. I also plan on cleaning up Makefile.dos and the other Makefiles to allow for easier setting of various options, and will commit that also.

Using build.sh also works, I will look into how to help make that work with the existing older versions of FreeType, etc libraries that are part of @georgp24's project, and possibly allow for upgrading to newer versions later, after we get everything working.

I notice that your larger tarball you posted does not have the version of FLTK included that you will be using. Can you post your version so I can also be compiling that up? I should then be able to compile up the entire library set, including Microwindows, and we can eventually post a build.sh that will do that for others.

Thank you!

[sduensin]

Yeah, I did all the sed stuff to avoid changing the original repos. I just downloaded the latest of everything and got to work. The idea being that someone else could do the same and not need to apply a bunch of patches.

There's no FLTK in my tarball because I hadn't made it that far in my work yet. I'm planning on grabbing the latest and trying to make it work.

This is a busy weekend for me but I'm going to try and get at least a little more work done. :-)

[georgp24]

I made the PXlib by compiling nano-X and nxlib into one library. The reason was that many Linux applications just include Xlib and it is easier to replace this in the makefiles with PXlib rather than replacing it with two libraries.

As far as I recall, in the freetype driver font_freetype2.c I made a small change to get it to run with DOS. This change was removed by Greg when he started to work on Microwindows again.

Scott, I recommend to try to get an old FLTK version to work as I documented it in detail in the faq2.html file. Once you got that version working you can give it a try at a later version.

[ghaerr]

Hello @georgp24,

As far as I recall, in the freetype driver font_freetype2.c I made a small change to get it to run with DOS. This change was removed by Greg when he started to work on Microwindows again.

Thank you for the heads-up. I will check this to determine whether that change needs to be reconsidered (along with looking at other changes in the your repo that should be updated in master).

Scott, I recommend to try to get an old FLTK version to work as I documented it in detail in the faq2.html file.

I agree as well, using the original version that @georgp24 got working will likely be much easier. Georg, do you recall what that FLTK version number is?

Thank you!

[georgp24]

This is the section on FLTK in my faq2.html file:

How to compile FLTK for Microwindows?

For this you should compile Microwindows with the config.fltk file in the configs directory. Rename config
in the src directory to e.g. config.default and then copy the config.fltk file as config into the src directory.
When using the X11 platform, leave SHAREDLIBS=Y and LINK_APP_INTO_SERVER=N.

Download FLTK 1.3.x and cd into the fltk directory. Then enter:

./configure --x-includes=/home/test/src/nanoX/nxlib/X11 \
--x-libraries=/home/test/src/nanoX/microwin/src/lib \
--disable-gl \
--disable-xinerama \
--disable-xft \
--disable-xdbe \
--disable-xfixes

Then replace the "-lX11 and -lXext" files with "-lNX11 -lnano-X" or "-lPX11" in makeinclude
and fltk-config. You can use the replace-lX11.sh script in the microwindows/src directory for that.
You can run that once with makeinclude entered on the command line and once with fltk-config specified
on the command line.
However, behind the -lPX11 parameter in makeinclude you have to add "-lfreetype" to get
FLTK to compile.

If you are using Microwindows on the Linux X11 platform, you will need to make a patch to the FLTK source code
since FLTK will dynamically load XRANDR support when starting and that causes your program to crash immediately.
So open the file "src/Fl_x.cxx" and add the line "#undef USE_XRANDR" right after the line
"#define USE_XRANDR (HAVE_DLSYM && HAVE_DLFCN_H)" which currently is line 51. This will avoid that XRANDR support
will be loaded.

Then enter make in the fltk directory. If you enter make -k it will not stop when trying to compile the sudoku game.
It may stop at the UTF-8 program, but the examples and FLTK will work anyway.

If you want to compile a program from the command line you can enter:
"g++ test/hello.cxx -o hello -Llib -lPX11 -lfreetype -lfltk -ldl"

Then you can run the examples, however, you will find that the fonts do not work, you just get the small default font.
To enable truetype fonts you can either copy the fonts.alias file example from the "src/nxlib/fonts" directory into the truetype
directory into e.g. "/usr/share/fonts/truetype" using sudo. Or you change the selected fonts from FLTK by modifying
the font names in the file "fltk-1.3.2/src/fl_font_x.cxx" if you are comfortable with XLFD descriptions.

If you are not using the X11 platform and have set LINK_APP_INTO_SERVER=Y in the microwindows config file, you can start
the examples with "test/hello".
If have set this macro to N as required for X11 you have to use a script like that: "nano-X & nanowm & test/hello & sleep 10000".
On some platforms these commands do not work from the command line, just from a script. After terminating the
application you have to terminate this script with CTRL-C.
Also, sometimes the application window hides behind other windows.

Additional details are provided by Ian MacArthur here: Article #1352
This article now refers to an earlier version of Microwindows and thus is partially deprecated now. The NX11 library does not
need to be compiled separately any more and you do not need to remove VNC or patch the image_png.c and Text16.c files.
You can use -PX11 instead of -lNX11 and -lnano-X now.

[ghaerr]

This is the section on FLTK in my faq2.html file

Thanks - it looks like you were using FLTK v1.3.2. I'll pull that down and see how that compiles and links with the source that @sduensin is using.

I notice here you have two seperate repositories with Microwindows and/or FLTK:

https://sourceforge.net/projects/fltk-dos/ https://github.com/georgp24/microwindows-android-bin

Which of these do you recommend working with, for the issue here related to getting Nano-X and FLTK back into a maintained state using DJGPP?

[sduensin]

@georgp24 I've had your FAQ open in a tab all week. :-)

Just need time to follow it!

[georgp24]

Up to now I refered to https://github.com/georgp24/microwindows-android-bin . However, the latest version I had been working on is this one: https://github.com/ghaerr/microwindows/tree/7af44df4f383d2ff5998d6b702304cd1bf86aae1

The faq2 file in this version includes instructions for FLTK 1.4.x

[ghaerr]

What about the applications in your FLTK for DOS / XFDOS on sourceforge? Are those FLTK demo applications, or did you write/port other applications for that project? Your screenshots look great - it would be nice to try compiling up all that for showing FLTK and Nano-X, not just on DOS platforms, but perhaps others as well...

I don't quite understand exactly what the FLTK for DOS vs XFDOS projects are, are they the same?

[georgp24]

FLTK for DOS is the basis of XFDOS. XFDOS is a bootable CD which you can download from Sourceforge and contains an FLTK for DOS GUI based on Microwindows plus several applications I have ported to XFDOS and have written for XFDOS with FLTK. Also some demos of Nano-X, i.e. the games. All applications are using Nano-X, NXlib and FLTK and thus should run on Linux too.

Based on XFDOS I made the NanoLinux distro: https://sourceforge.net/projects/nanolinux/

[ghaerr]

Hello @sduensin,

I have made a commit that fixes the DJGPP compilation problems, as well as updated and simplified Makefile_nr so that it works with ARCH=CROSSDOS and includes current window draw/manager options and is easier to modify and maintain.

I also added a tools/crossdos.sh and tools/cleandos.sh for testing, and to show the slight changes you'll make to your build.sh in order to have Microwindows easily built with your other libraries and eventually FLTK. I have added another option, ARCH=MACOSX which allows me to completely build Microwindows using the Makefile_nr makefiles and run sample executables on my desktop, to more easily see the affects of option changes. I also added an ARCH=LINUX option should you wish to duplicate this capability in your environment.

The new changes also build the Microwindows (non-Nano-X) demos, which previously didn't work. (You won't be using those).

I plan on working further on this, and am thinking of adding the capability into the GitHub repo to automatically pull the proper Freetype, Jpeg, PNG and Zlib libraries and build them as part of a master build, allowing for Microwindows to be deployed more easily with its own frequently used dependencies, on any supported platform. [EDIT: this is now done by tools/buildcrossdos.sh and tools/buildmacos.sh for cross-djgpp DOS and macOS respectively.]

When you have time next week, take a look, and please try modifying your build.sh to use Makefile_nr and eliminate the sed scripts. It should work well, with the exception that the JPEG/PNG/LIBZ/FT CFLAGS=/LIBS= entries in Makefile_nr may have to be uncommented for you. I am still working on a better solution for all this that does not require Makefile_nr changes for each individual's compilation (such as including one of the standard Config/config.* configuration files).

Thank you!

[ghaerr]

I have completed building scripts for macOS and CROSSDOS DJGPP to automatically build all of the following:

LIBZ 1.2.12
PNG 1.6.37
JPEG 6b
FREETYPE 2.10.4
MICROWINDOWS (Github current)
FLTK 1.3.8

These scripts are in microwindows/src/tools/buildmacos.sh and buildcross.sh respectively. Although I have the got DJGPP cross-compiling on macOS, I wasn't able to get the DJGPP cross-build completely going on macOS. The buildmacos.sh script builds all of the libraries on native macOS using X11, then replaces the X11 with NX11 such that everything actually runs on Microwindows, including many of the FLTK demos. The scripts need to be copied to just above the microwindows/ directory, and then have all the other libraries unpacked. There are undoubtably changes need to be made in crossdos.sh.

There were a few bug fixes to get things working and things are not perfect yet, but this should help @sduensin and others wanting to use DJGPP well on their way. @sduensin, please try to use these updated scripts, and then post PRs for changes required, so that others will be able to follow, and we'll have it all checked in. I'll help with other bug reports as they are found.

Here's a video of FLTK's test/pixmap configured for X11 running on Microwindows on macOS on SDL2, with all libraries built automatically using buildmacos.sh:

https://user-images.githubusercontent.com/11985637/167320454-a1f85f29-efb1-4253-a411-0593299741be.mov

[sduensin]

@ghaerr that looks fantastic! Can't wait to try it!

[sduensin]

Ok, here's some updates from my Linux box. I had to edit four files to get it to mostly compile. Not all the FLTK demos work - anything that requires fluid to generate code from a layout file fails because FLTK does not cross-compile fluid. It generates a DOS binary which isn't exactly helpful during compilation.

Here's what I changed:

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

[ghaerr]

Thanks Scott, that was fast!

I'm going to check in your changes to buildcross.sh now, but I think our paths crossed with Makefile_nr, as I just committed an additional change to that. Perhaps you can see whether my latest Makefile_nr works, otherwise let me know.

I'll look at the FLTK changes tomorrow. When you're further along your project, we might want to add it as another patch for the FLTK build.

Thank you!

[sduensin]

FYI, make here does not like this at all:

Each line needs to be commented.

I've also added a make clean to the top of the block that builds FLTK in buildcrossdos.sh.

[ghaerr]

FYI, make here does not like this at all:

I'll fix it, I'm continuing to add demos to Makefile_nr now (that should not affect you when using crossdos.sh).

I've also added a make clean to the top of the block that builds FLTK in buildcrossdos.sh.

Thanks. I'll add that too, and we can resync after you're further along. Thanks!

[sduensin]

Not sure how you want to handle things like convbmp.exe in the src/images/tools folder. Is this intended to be a build-time tool or a runtime tool? Right now, it's trying to compile a mwin demo is blows up at:

../../tools/convbmp car8.bmp > car8.c

Because convbmp is a DOS binary.

[ghaerr]

I've just enhanced that file, as well as Makefile_nr. But I'm not getting that problem, even before: tools/convbmp is supposed to be built using $(HOSTCC) (see contrib/makefiles_nr/Makefile-bmp):

# compile for host not target
tools/convbmp: tools/convbmp.c
    $(HOSTCC) $(HOSTCFLAGS) tools/convbmp.c $(LIBS) -o tools/convbmp

There should not be a convbmp.exe in that folder. You're running cross compiler, right? Sounds like HOSTCC may be not working correctly if your system is creating a .exe file. ?

[sduensin]

You're right. HOSTCC is usually set to gcc - which is fine until you source ${DJGPP}/setenv - it alters the path so gcc calls i586-pc-msdosdjgpp-gcc.