oh no. I seemed to have written an i286 cpu emulator and also an HTML window system capable of rendering bitmap fonts and am intercepting 16-bit windows kernel calls. how did this happen.
if microsoft won't give away windows 3.1 then I'll rewrite it in a clean room from scratch in JavaScript. i already live in this hell, i don't give a shit.
We've got most of that wacky memory allocator in place and now we're in that good ol' message loop mess. Progress.
Pointing my code at an executable and seeing a HTML/CSS window pop up that is exactly right feels really good!
Getting the window event messaging callbacks working. Fun!! Calling into the VM when the API implementation is... yanno... not real code... is hard.
I still cannot figure out what Bayer matrix they are using. It is strange. But I'm starting to paint things.
One fun thing about writing an emulator is you go through a phase where unimplemented functions expose rarely-seen error messages, like this one from SkiFree:
I think the internet is lying to me about implementation details again. Or dosbox is messing things up.
Ah. So Windows 3.1 converts 16-color bitmaps to its own 16-color palette even though there are 256 colors available... So mine was showing what SkiFree should *REALLY* look like, but technically isn't as accurate. Oh well! (Palette is still wrong, tho)
Getting all of these weird blit functions in place. It has a weird rule for how it resolves blitting 8bpp to 1bpp; sets pixels that match the current background color and clears pixels otherwise, used to quickly create bitmap masks in SkiFree:
You can't tell, but I got eaten by the dreaded ski monster. Probably should fix the PatBlt call that erases backgrounds behind animation cels.
this is definitely a #glitchforandi for which I am always proud to contribute
This is fun. The call to CreateCompatibleDC returns a pointer to a graphics context in AX. It then writes 1 to AL (lower half of AX) and passes AX to the next function. Which means AX is, like my life, HOT TRASH. But it works since that function magically masks away high bits.
THAT'S UNDOCUMENTED AND RUDE.
@wilkie Is that how skiers talk?
@thomasfuchs I don't know. I've never been skiing since I'm terrified of the yeti.
@wilkie is this a color space issue? I.e., are you on macOS?
@antifuchs first, these screenshots come from the same display device, so not a color correction issue. here, the palette colors that are loaded on the (emulated) device are dramatically different than what the internet had told me, for which I am using in my emulated device.
@wilkie hm, what I mean is: the program that’s running can choose what color space to use when rendering the palette. If your emulator is running on macOS, it has a choice which space to use (ran into this with color themes on emacs a while back).
I’m probably misunderstanding what is happening though /:
@antifuchs that's definitely an overall emulator concern, yes. CRT vs LCD color space issues are a thing in general. very troublesome! here, though, the palettes are just so very different. that can only be explained as 'one of us is very wrong' :)
@wilkie hah! Computers sure love to go, “one _or more of us_ are very wrong” in response (and walk backwards off a cliff)
Server run by the main developers of the project 
It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!
Don't listen to that error message... it lies... here I am displaying every bitmap the program has loaded into memory as it loads them.