This weekend I tried to compile #Allegro for #Win9x with #mingw.
I was able to get the examples running on #Win10, but when I copied them over to my #Win98 box they crashed with an illegal instruction.
That happened because mingw on #Ubuntu is targeting i686 and I have an AMD K6-II in my test rig.
Then I tried compiling mingw myself with i386 as a target, that failed because the 386 is missing an instruction that is needed by the runtime library.
I got it working with i486, though.
1/
When the i486 mingw was successfully compiled I tried running the Allegro examples again.
Win10 was good (as before), Win98 failed again, this time it was missing some Windows runtime libraries: API-MS-WIN-CRT-*.DLL is not available on Win98.
The interwebs tells me these are part of the MS Visual C++ redistributable. It also tells me vcredist for VSC 2005 should be fine.
Well, it isn't. It installs (after some hassle), but the missing DLLs are not included.
2/
@dec_hl I remembered a blogpost from a while ago, where someone had to patch a few things to remove dependencies of some runtime libs: https://fanael.github.io/stockfish-on-windows-98.html
I guess you'll have to do something similar for whatever exact bits your code needs...
@dec_hl You should be able to through targeting the base MSVCRT (v6), which should still be supported in MinGW-w64 for 32-bit x86.
@Conan_Kudo Yeah, thanks. That was exactly the problem. I solved it by building my own MinGW (see below).
@dec_hl oh i think i know this one, there's some compiler flag you need to specify to tell it to build with the runtime included, but i normally see that issue with msvc and not mingw
@dec_hl on msvc the compiler flag to get it to include the runtime in the output executable is /MT (as opposed to/MD), i'm not sure how you would get those dependencies being required on mingw, or what flag you'd need
unless it's linking in some library that needs them?
@krishean I'm totally unaware how mingw interacts with the win32 API. so far all my search was in vain if it is even possible to target win9x...
@dec_hl i know by default mingw sets the target os version flags in the pe header for 95/98
it's usually just a matter of making sure the api imports are supported on 9x (which i'm not entirely certain how to fix besides messing with compiler flags through trial and error), you already ran into and solved the other issue i know of which is instruction set compatibility
@dec_hl wait, you said you recompiled mingw to target i486, did you use msvc or mingw to do that?
@krishean I'm cross compiling. I'm on Linux and I compiled mingw with the native GCC...
@dec_hl alright, so it wanting to require the msvc runtime dlls makes even less sense in that case
@krishean well, the resulting EXEs need some kind of interface with the windows API. So I guess the default behavior of mingw compiled EXEs is through that runtime DLLs...
@dec_hl most of the time i see it just link to kernel32, user32, etc. i'm still at a loss as to why it would want msvc dlls and not the mingw runtime (libgcc_s_sjlj-1.dll or something)
@krishean this is the dependency tree. The libgcc_s_sjlj.dll depends on the MS-API-CRT DLLs
@dec_hl possibly try -static-libgcc
(via: https://bbs.archlinux.org/viewtopic.php?id=208166 )
there's also some other compiler flags you could try such as the -Wl,-Bstatic -lgcc -Wl,-Bdynamic magic invocation
@dec_hl are you using allegro v4.4.3.1? ( https://github.com/liballeg/allegro5/tree/4.4.3.1 )
if so i could try patching CMakeLists.txt to compile without linking to the runtime libraries, and send you the .patch file for it
@krishean it's actually allegro-4.3.3.1, but that would be great...
@dec_hl alright, i'll see what i can come up with, it might be a few minutes though
@krishean no worries, I'll not get back into it until next weekend 
@dec_hl it doesn't look like there's a tag in git for v4.3.3.1, but i was able to cross compile v4.4.3.1 with the regular mingw cross compiler and it didn't show the runtime linking issue you encountered
see if this works? https://gist.github.com/krishean/f57b453a737fd3240981f8cf729d237a
@krishean Ok, I managed to try this out.
Building Allegro using the mingw64 included with ubuntu I got the same result as you: it did depend on MSVCRT.DLL and not API-MS-WIN-CRT-*.DLL
The resulting EXE did not run on Win98 because it targets i686 (I guess).
When I replaced the mingw with the one I compiled I got the dependencies on API-MS-WIN-CRT-*.DLL again (even with the static binaries).
I then dug around mingw some more and I found this:
https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-doc/howto-build/ucrt-vs-msvcrt.txt
@krishean I'll now try to build my own i486 mingw64 version with using "--with-default-msvcrt=msvcrt" on everything mingw-configure-related...
Thanks again and I'll let you know.
@dec_hl i586 version of MinGW32 on Fedora created binaries working on Win98 on a Duron 750 for me. You might need this libwinpthread, though: https://objfw.nil.im/downloads/libwinpthread-1.dll
@dec_hl It’s libwinpthread with this patch, which I have upstreamed in the meanwhile, but might not be in the releases: https://objfw.nil.im/downloads/winpthreads_win98.patch
clang works if you add -march=i586.
@js so, did you compile mingw32 or does fedora still come with it?
@dec_hl Used the MinGW from Fedora. The patch has been upstreamed a while ago already: https://github.com/mingw-w64/mingw-w64/commit/cb7f42e05b94cbb1d94edcebdbfb47b652a45484
I think the Fedora package should have it by now.