microwindows
microwindows copied to clipboard
ghaerr
DJGPP and DOS
After installing DJGPP and reading the Microwindows FAQs and DJGPP PDF, running: make -f Makefile_nr ARCH=DOS results in:
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!
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?
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!
I need to move my setup to a Windows box so I have scrollback. I'll see what I can do. Thanks again!
lol I've tried that, and if you can even get it to compile, the mouse code is broken.
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.
Try copying everything in microwindows\src\include to DJGPP\INCLUDE. That worked for me.
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
Anyone have time to help with this? There's coffee or beer in it for you. :-)
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.
@georgp24 can you help me get this building for DOS using DJGPP under Linux? I'll be your friend. :grinning:
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?
@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).
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!
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.
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!
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!
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.
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.
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.
Whoo! This is working! It's very rough but it builds the demos and they run in DOSBox!
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.
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.
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!
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).
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.
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:
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!
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. :-)
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.
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!
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.
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?
@georgp24 I've had your FAQ open in a tab all week. :-)
Just need time to follow it!
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
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?
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/
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!
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
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
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!
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.
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!
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.
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. ?
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.
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.
Ok. So a better solution would be to use the newer TOOLSPREFIX= that is built into the .sh files now, and not do the source setenv. Can that be made to work, it would be much simpler. If you need to, you can add a separate PATH= in the .sh file to path your compiler, but it is too dangerous to do that for the microwindows build at the moment.
Otherwise, if you need the source setenv for the other builds, perhaps each function needs to be built in a sub shell, where each does source setenv except for microwindows.
That's why my original batch file had all the various weird environments for different functions. Ugly but it worked. Usually. :-)
That's why my original batch file had all the various weird environments for different functions. Ugly but it worked
I think it should be easily solved by running sh build_fltk etc at the bottom of crossdos.sh. Export other variables if necessary but I don't think you'll need to.
And put the source setenv in each function, not global. And put the source setenv in each function, not global. Also, please git pull from microwindows, I have been changing stuff in there to help, for all but tools/crossdos.sh and buildcrossdos.sh that I will leave to you.
Arrgh. I either end up with a broke DJGPP environment, or, when trying to override HOSTCC I get this:
x86_64-linux-gnu-gcc: fatal error: cannot execute ‘cc1’: execvp: No such file or directory
I either end up with a broke DJGPP environment, or, when trying to override HOSTCC I get this:
Lets take this one step at a time. I spent quite a while Saturday designing this so that we can move forward in an incremental fashion. The first step is getting Microwindows itself to build correctly, OUTSIDE of tools/buildcrossdos.sh.
To do that, use only tools/cleandos.sh, then tools/crossdos.sh (not buildcrossdos.sh). As can be seen, you must use the TOOLSPREFIX= which is set correctly in crossdos.sh, and you cannot remap HOSTCC=. That means that you cannot use source ${DJGPP}/setenv as buildcrossdos.sh does. Do you have tools/crossdos.sh working?
If tools/crossdos.sh is not working, we will need to fix that, but I had that working on macOS. It should work fine on Linux.
After that is working, you will need to move the source ${DJGPP}/setenv outside of the global script of buildcrossdos.sh, and into all the build_xxx functions, EXCEPT for build_microwindows. You will also need to run sh build_xxx so that the setenv function does not change the master buildcrossdos.sh shell environment. The build_microwindows function should NOT include the source ${DJGPP}/setenv. That should fix the problems you are having.
If you would like, I can make the changes you need and check those in. Please let me know.
Hello @sduensin,
I've (finally) got truetype fonts back working again with FLTK and Nano-X, we're going to need some additional capabilities of specifying where the full pathname of various fonts live, and some crash fixes, which I'll be adding.
Here's a screenshot of the FLTK 1.3.8 test/fonts demo running on Nano-X with both the X11 and Microwindows font directories provided to nx11:
Will you be running truetype fonts only, or also perhaps PCF? It seems both are in fairly wide use in X11 servers. I'll probably fix up Microwindows font directories to work automatically with Microwindows-supplied truetype and PCF fonts for common names and sizes. There are also problems I'm debugging with the fonts.dir and fonts.alias files, which are causing crashes.
I'll probably go ahead and push the changes I was suggesting for tools/buildcrossdos.sh, so that you don't have to do it. Sorry if this is making your porting effort harder in the short term.
Thank you!
Those fonts look fantastic! And, honestly, I have no idea what I'll use font-wise yet. My current GUI only has a console font that I yanked out of the DOSBox VGA BIOS.
As for cleandos.sh and 'crossdos.sh`, I'm a tool. I never even looked at them. They work much better than what I have at the moment. Chasing down a link error with them...
compiling /home/scott/code/microwindows-dos/microwindows/src/bin/mwdemoalpha.exe
/home/scott/code/microwindows-dos/microwindows/src/../../djgpp/bin/i586-pc-msdosdjgpp-gcc -DDOS_DJGPP=1 -DMSDOS=1 -s -I/home/scott/code/microwindows-dos/microwindows/src/include -I/home/scott/code/microwindows-dos/microwindows/src/../../installed/dos/include -I/home/scott/code/microwindows-dos/microwindows/src/../../installed/dos/include/freetype2 -I/home/scott/code/microwindows-dos/microwindows/src/nx11/X11-local -Wno-deprecated-declarations -O3 -DHAVE_FILEIO=1 -DMW_FEATURE_IMAGES=1 -DMW_FEATURE_TIMERS=1 -DHAVE_SIGNAL=0 -DHAVE_MMAP=0 -DNONETWORK=1 -DNANOWM=1 -DUPDATEREGIONS=0 -DERASEMOVE=0 -DXORMOVE=1 -DOUTLINE_MOVE=1 -DHAVE_BMP_SUPPORT=1 -DHAVE_GIF_SUPPORT=1 -DHAVE_PNM_SUPPORT=1 -DHAVE_XPM_SUPPORT=1 -DHAVE_FPRINTF=0 -DHAVE_JPEG_SUPPORT=1 -DHAVE_PNG_SUPPORT=1 -DHAVE_FNT_SUPPORT=1 -DFNT_FONT_DIR=\"fonts/fnt\" -DHAVE_PCF_SUPPORT=1 -DPCF_FONT_DIR=\"fonts/pcf\" -DHAVE_PCFGZ_SUPPORT=1 -DHAVE_FREETYPE_2_SUPPORT=1 -DFREETYPE_FONT_DIR=\"fonts/truetype\" -DSCREEN_HEIGHT=600 -DSCREEN_WIDTH=800 -DSCREEN_DEPTH=8 -DSCREEN_PIXTYPE=MWPF_TRUECOLORARGB -DMWPIXEL_FORMAT=MWPF_TRUECOLORARGB -L/home/scott/code/microwindows-dos/microwindows/src/lib -o /home/scott/code/microwindows-dos/microwindows/src/bin/mwdemoalpha.exe demos/mwin/mwdemoalpha.o -lmwin -limages -L/home/scott/code/microwindows-dos/microwindows/src/../../installed/dos/lib /lib/libjpeg.a /lib/libpng.a /lib/libz.a /lib/libz.a /lib/libfreetype.a /lib/libz.a
i586-pc-msdosdjgpp-gcc: error: /lib/libjpeg.a: No such file or directory
i586-pc-msdosdjgpp-gcc: error: /lib/libpng.a: No such file or directory
i586-pc-msdosdjgpp-gcc: error: /lib/libz.a: No such file or directory
i586-pc-msdosdjgpp-gcc: error: /lib/libz.a: No such file or directory
i586-pc-msdosdjgpp-gcc: error: /lib/libfreetype.a: No such file or directory
i586-pc-msdosdjgpp-gcc: error: /lib/libz.a: No such file or directory
make: *** [Makefile_nr:368: /home/scott/code/microwindows-dos/microwindows/src/bin/mwdemoalpha.exe] Error 1
It's adding /lib/ to the names of libraries it wants instead of just using the actual LD path.
I have no idea what I changed but the demos are now compiling. Except the timing code in Tetris. DJGPP is not liking that. :-)
My current GUI only has a console font that I yanked out of the DOSBox VGA BIOS.
Well, we'll definitely have to upgrade that. I'm getting excited about the font code. @georgp24 and others put a lot of work into it, and I noticed on Georg's nanoLinux project, which uses FLTK applications, extensive use of truetype fonts made the screenshots look fantastic. I'm getting some crashes from a few last bugs over here, but things should be working great shortly.
As for cleandos.sh and 'crossdos.sh`, I'm a tool. I never even looked at them. They work much better than what I have at the moment
Great, I'm glad I mentioned them. Definitely want to get your using crossdos.sh working perfectly first, then we'll debug buildcrossdos.sh to add the other libraries and FLTK to Nano-X.
It's adding /lib/ to the names of libraries it wants instead of just using the actual LD path. i586-pc-msdosdjgpp-gcc: error: /lib/libz.a: No such file or directory
Make sure you're running my latest version of Makefile_nr and the Microwindows repo, I've made lots of changes in the last couple days. It looks like the LIBRARY_FLAGS="-L{$INSTALLED}/lib" line in crossdos.sh is resulting in empty string for $INSTALLED. That could be because the INSTALLED= line at the top needs to be "export INSTALLED=".
I have no idea what I changed but the demos are now compiling.
I added all that, so that you can test both Win32 and Nano-X APIs for a lot of demos.
Except the timing code in Tetris.
What seems to be the problem, I will look at it.
Tetris just needs to know it's using DJGPP and to define HAVE_USLEEP in the header. Trying to figure out what definition identifies this particular compiler.
Yep. Easy fix.
#ifdef __DJGPP__
#define HAVE_USLEEP
#else
#undef HAVE_USLEEP
#endif
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
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. :-)
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... ?
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. :-)
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!
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.
OK, I'm confused. I did the following with FLTK:
- In
MakefileI removedfluidfrom theDIRSvariable - I renamed
fluid/Makefileto 'fluid/Makefile.hidden` - I added
ln -s "$(which fluid)" fluid/fluid.exetobuildcrossdos.shto use the system copy offluid
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.)
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.
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?
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. :-)
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:
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.
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?
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.
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.
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!]
@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?)
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?
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.
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...
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.
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.
TUXCHESS still hangs at start. And every FLTK demo I tried hangs on exit. But nothing has outright blown up!
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
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... ?
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!
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.
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.