Enrico Horn wrote:
I tried my dos4gw games with dos32a and they "work"(except some warning dos32a prints) but you have to run these games like this to get an result: wine -- dos32a game.exe thats is because the stub which loads the dos extender doesnt work and i have no idea why.
Neither dos4gw stub loader nor dos4gw itself work. Making these work would be nice, but since there are free, compatible DOS extenders available that work rather well with Wine, I'm not particularly interested to figure out what is wrong with them. I have toyed with an idea of trying to contact dos4gw authors (if I can find them) and ask them if they could help, but I'm just too lazy for this kind of stuff.
the games i use all make use of vesa they want 640x480x256 ddraw traces show a primary surface that is 8bit paletted. is there any problem drawing this thing? where is this done? is there a routine that regularly updates the screen with content of this surface? i have looked in x11drv(can it be that x11drv is in need of a rewrite?) and havent found anything but i am not expert at this and just poke around randomly where i see an interest.
That mode should work with DOS VESA emulation. It could be that those programs use VESA features that are not supported or that VESA emulation is faulty. It is also possible that those programs are waiting for timer interrupt which is not delivered in protected mode (I have a good idea how to do this, but we shall see when I have time to implement it).
See dlls/winedos/int10.c and dlls/winedos/vga.c. It is unlikely that DOS display problems are due to x11drv bugs.
-
Jukka Heinonen