Hello Zeb,
I'd love to see Win16 tests in upstream Wine, so thanks for working on this! This would make picking changes from winevdm (the fork) into Wine a lot easier I think.
OpenWatcom is sometimes mentioned, but that only has win32 builds (as far as I'm aware), which makes it hard if not impossible to integrate into Wine.
You can compile OpenWatcom on Linux, or did I misunderstand that? I always thought the problem with OpenWatcom was that it's not as easily available as gcc and to avoid the dependency.
The compiler is called Rosé, and it lives here:
https://gitlab.winehq.org/zfigura/rose
It is not fully featured; it's still missing a few notable pieces (in particular: unions, multiple code segments) but it is reasonably complete, and I was able to use it to compile a modified version of winetest.exe, and produce working executables for Windows 98.
Could you provide a minimal example of a working program that uses MessageBoxA or printf?
- The compiler is small and could potentially be easily just imported into
Wine. I don't have any feelings about continuing to maintain it outside of Wine—i.e. it could easily just be imported and any further development done in Wine (much like e.g. widl). "Small" here means about 15k LoC across a few files, including the builtin CRT and headers.
Not that my opinion mattered a lot, but I would like having it under the Wine umbrella, makes my setup easier.
- NE executables, unlike both their predecessor (MZ) and successor (PE),
cannot output to a controlling console, and in general have no concept of a stdin/stdout/stderr. This does not fit well with wine tests, which are built to run with a console. There is also not much in the way of IPC available to a win16 process. They can, on the other hand, open a file and output to it.
Maybe a stupid question, but won't dos console interrupts works for console?
- In order to properly test Win16 we need a contemporaneous test VM, I think
ideally 98. A modern 32-bit Windows machine (of which I think we still have some) will *run* 16-bit code, and may be usable to test *some* functionality, but I do not think the results can be trusted.
Hm, I always thought XP would be a good win16 test-target. But then again, there is no XP VM either.
[2] The idea of introducing compiler support into GCC has obvious advantages: not just the reuse of frontend and optimization code, but the dialect is something that will already be perfectly familiar to a Wine developer. However, it also has disadvantages: it would take a lot of time to become familiar with gcc, and I expect that segmented address spaces will be very hard to fit into the GCC code and probably not accepted upstream.
Since gcc is capable of generating "fake" 16bit code using -m16, is this something that could be reused? Although I don't think one could get segmentation to work without way too much effort.
Regards, Fabian Maurer