2 ms·

I think you can skip VC++97 and develop with msys and mingw. I haven't used those to target 9x in a long time, just older NT, so I'm not sure how up to the task

I think you can skip VC++97 and develop with msys and mingw. I haven't used those to target 9x in a long time, just older NT, so I'm not sure how up to the task it is these days. But I think it can get you more recent versions of C and C++ that route.

versteegen 3y ago
I use a recent mingw-w64 with a recent GCC (I'd assume the latest versions could work too) to target Windows 95 (through 11, obviously). I prefer the mxe toolchain to crosscompile from Linux for convenience but do also compile with mingw-w64 on Windows in a VM. mingw.org will probably work too perhaps with a little work. However recently I had to patch mingw-w64 to restore support for Win 95 through 2000, which they'd broken only for the sake of implementing SetThreadName [1]. My experience in general is it's pretty easy to support Windows 95+ as long as you make use of newer APIs optional by dynamically loading symbols, and deal with small issues as they appear. So it helps to have users actually testing occasionally... because I don't. [1] https://github.com/rversteegen/mxe/commit/aa87b55a77a62d4cffa1a893497444ecc615653d https://github.com/rversteegen/mxe/commit/aa87b55a77a62d4cff...
- asveikau 3y ago
  Thank you for this. That's a good reply. As for your diff, I'd be inclined to call AddVectoredExceptionHandler etc. through GetProcAddress where available. (Off topic, but I like to use that API for logging access violations.)
  - versteegen 3y ago
    Yes, I guess I could do that, then maybe I can get it upstreamed. However I was misremembering a bit and misspoke before both about how easy it's been to support Windows 95 (it was easy up until a few mingw-w64 releases ago... except for spawning processes) and how recent my mingw-w64 is (I'm using 7.0.0, 3.5 years old, and simply haven't tried anything newer; the GCC version is independent within limits). Also I have no idea the minimum Windows targetted by mingw-w64 actually is, they don't say. I think they don't actually care about Windows 9x support, they just never did anything to break it before 6.0.0. I have doubts they'd accept such a patch. The most important trick was you have to use a build of mingw-w64 with 'win32' rather than 'posix' threading ([1], and the rest of that thread is relevant too): > the 'win32' threading support in mingw-w64 is the original one and supports all 32-bit Windows, while 'posix' threading (winpthreads) is a recent addition which is necessary to support C++11 mutexes and threads, but has higher system requirements. ... That's why mxe switched to posix threads by default in 2019. [1] https://github.com/ohrrpgce/ohrrpgce/issues/1241#issuecomment-1232960187 https://github.com/ohrrpgce/ohrrpgce/issues/1241#issuecommen...

versteegen 3y ago

I use a recent mingw-w64 with a recent GCC (I'd assume the latest versions could work too) to target Windows 95 (through 11, obviously). I prefer the mxe toolchain to crosscompile from Linux for convenience but do also compile with mingw-w64 on Windows in a VM. mingw.org will probably work too perhaps with a little work. However recently I had to patch mingw-w64 to restore support for Win 95 through 2000, which they'd broken only for the sake of implementing SetThreadName [1]. My experience in general is it's pretty easy to support Windows 95+ as long as you make use of newer APIs optional by dynamically loading symbols, and deal with small issues as they appear. So it helps to have users actually testing occasionally... because I don't. [1] https://github.com/rversteegen/mxe/commit/aa87b55a77a62d4cffa1a893497444ecc615653d https://github.com/rversteegen/mxe/commit/aa87b55a77a62d4cff...

asveikau 3y ago
Thank you for this. That's a good reply. As for your diff, I'd be inclined to call AddVectoredExceptionHandler etc. through GetProcAddress where available. (Off topic, but I like to use that API for logging access violations.)
- versteegen 3y ago
  Yes, I guess I could do that, then maybe I can get it upstreamed. However I was misremembering a bit and misspoke before both about how easy it's been to support Windows 95 (it was easy up until a few mingw-w64 releases ago... except for spawning processes) and how recent my mingw-w64 is (I'm using 7.0.0, 3.5 years old, and simply haven't tried anything newer; the GCC version is independent within limits). Also I have no idea the minimum Windows targetted by mingw-w64 actually is, they don't say. I think they don't actually care about Windows 9x support, they just never did anything to break it before 6.0.0. I have doubts they'd accept such a patch. The most important trick was you have to use a build of mingw-w64 with 'win32' rather than 'posix' threading ([1], and the rest of that thread is relevant too): > the 'win32' threading support in mingw-w64 is the original one and supports all 32-bit Windows, while 'posix' threading (winpthreads) is a recent addition which is necessary to support C++11 mutexes and threads, but has higher system requirements. ... That's why mxe switched to posix threads by default in 2019. [1] https://github.com/ohrrpgce/ohrrpgce/issues/1241#issuecomment-1232960187 https://github.com/ohrrpgce/ohrrpgce/issues/1241#issuecommen...