It's not the palette as 0 is COLORREF RGB(0) so it uses the direct color. For palette colors it needs to use PALETTLERGB() or PALETTEINDEX() (for SetTextColor, the DIB palette is different). The StretchDiBlt calls have MERGEPAINT and SRCAND rops so it's mixing the source and destination bitmaps.
It's not the palette as 0 is COLORREF RGB(0) so it uses the direct color. For palette colors it needs to use PALETTLERGB() or PALETTEINDEX(). The StretchBlt calls have MERGEPAINT and SRCAND rops so it's mixing the source and destination bitmaps.
It's looking for the movie in the H: drive which is what I'd expect but mmioOpen is returning null which means the file isn't found. 59a4:Call MMSYSTEM.1210: MMIOOPEN(16df005e "H:\\qtw\\making\\makingof.mov",0000:0000,00000020) ret=1757:03df ds=1787 59a4:Ret MMSYSTEM.1210: MMIOOPEN() retval=00000000 ret=1757:03df ds=1787 winmm32.mmioOpenA: filename="H:\qtw\making\makingof.mov" ioinfo=0 open=0x20 dxwTranslatePathA: fake CD(1) new FileName="C:\Games\MYST\cd\\qtw\making\makingof.mov" winmm32.mmioOpenA:...
What is it doing? It's looking for the movie in the H: drive which is what I'd expect but mmioOpen is returning null which means the file isn't found. 59a4:Call MMSYSTEM.1210: MMIOOPEN(16df005e "H:\\qtw\\making\\makingof.mov",0000:0000,00000020) ret=1757:03df ds=1787 59a4:Ret MMSYSTEM.1210: MMIOOPEN() retval=00000000 ret=1757:03df ds=1787 winmm32.mmioOpenA: filename="H:\qtw\making\makingof.mov" ioinfo=0 open=0x20 dxwTranslatePathA: fake CD(1) new FileName="C:\Games\MYST\cd\\qtw\making\makingof.mov"...
Works fine for me.
curiously, the TAICHI.HLP is a valid help file but the viewer can't be run from inside the game. The log shows a missing winhlp32.exe16 file, is that correct? This uses the currently unimplemented HELP_FORCEFILE command. I'll have to fix that.
LPDRAWDIBTIME is in vfw.h. The header hasn't changed since 1995 so it shouldn't matter the msvc version. Anyway, here it is in the wine headers. https://gitlab.winehq.org/wine/wine/-/blob/master/include/vfw.h#L1569 suppose that the reason is because the msvfw32.dll is not hooked at all. Is that possible? Probably. MCIAVI32 needs to be added to additional modules for it to work with IAT patching.
A possibility is to use DefineDosDeviceW https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-definedosdevicew which is how subst works.