On Sat, Apr 3, 2010 at 5:34 PM, Alexandre Julliard <julli...@winehq.org> wrote: > Stefan Dösinger <stefandoesin...@gmx.at> writes: > >> Am 02.04.2010 um 02:08 schrieb chris ahrendt: >> >>> Just my 2 phennings worth on this... >>> Why reinvent the wheel... I would say instead of doing the emulator inside >>> wine... or a JIT... why not have >>> wine intersept the call to start the vm86 mode.. and forks off and starts >>> DOSEMU or whatever DOS box system is >>> configured.. That way wine doesnt have to worry about it... >> Because you can mix modes in one executable. Take for example the >> average modern dos game: They start as real mode apps, then switch to >> a 32 bit protected mode dos extender(e.g. dos4gw.exe). I wouldn't be >> surprised if the app can transform itself into a Win16 app that tries >> to pop up a window. Wouldn't work well in Linux dosemu. > > DOS apps can't do that. Pretty much the only thing you really have to > share is the filesystem, and it should be easy to configure DosBox to > mount ~/.wine/drive_c, and to invoke Wine when a DOS app starts a > Windows binary. > > There's no reason to replicate DosBox inside Wine. On the contrary, a > nice project would be to improve integration with an external DOS > emulator and then rip out the half-broken vm86 support from Wine. > > -- > Alexandre Julliard > julli...@winehq.org > > >
But Win16 applications can access DOS int 0x21 functions (below, tested successfully on Wine and Vista), and at least some hardware (http://www.faqs.org/faqs/windows/programming/vxd/ describes how a Win16 application can access the VGA framebuffer). Doesn't that mean we need the vm86 support in Wine? Damjan #include <windows.h> int PASCAL WinMain( HINSTANCE this_inst, HINSTANCE prev_inst, LPSTR cmdline, int cmdshow ) { int val; char buffer[512]; __asm mov ax,0x6200 __asm mov bx,0 __asm int 0x21 __asm mov val,bx sprintf(buffer, "Hi from Win16 with PSP = %d", val); MessageBox(NULL, buffer, "Hello world", MB_OK); __asm mov ax,0x4c00 __asm int 0x21 /*return 0;*/ }
