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...
chris
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.
What may work better however is using a Win32 dosemu binary to load the app. Then we just have to make sure that windows dosemu can deal with such mixed apps.
Stefan Dösinger stefandoesinger@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.
On Sat, Apr 3, 2010 at 5:34 PM, Alexandre Julliard julliard@winehq.org wrote:
Stefan Dösinger stefandoesinger@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 julliard@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;*/ }
On Sun, Apr 04, 2010 at 10:53:46AM +0200, Damjan Jovanovic wrote:
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?
Yes, but those INT21 calls are in Win16 protected mode, not DOS real mode.
And VXD ... I doubt anything uses it.
Ciao, Marcus
On Sunday 04 April 2010 3:41:00 am Marcus Meissner wrote:
Yes, but those INT21 calls are in Win16 protected mode, not DOS real mode.
And VXD ... I doubt anything uses it.
Back in the Win95 era, I remember libnet having a DOS network driver that hooked into winsock.vxd. It allowed a DOS app (compiled with DJGPP) to use Windows' winsock driver when run under Windows. I remember that because I thought it was the best thing ever, since I only had DJGPP and wasn't interested in Win32 programming (and even if I could, I don't think MinGW was around, yet).
But beyond that, couldn't a pure DOS app launch a Win32 exe, and have that program run like a normal Windows app? How would that work if the app is run under DOSBox or similar?
how seamless could the integration be made? I've seen a number of programs (mainly installers) and also guilty of writing a few win apps that shell out a dos call and return to continue. Also while wine seems to encourage a spread of apps to work, the core DosBox guys have made it clear they are only interested retro games. So dosemu or a qemu/bochs co-operation may be more fruitful.
On Sun, Apr 4, 2010 at 3:32 PM, k4king k.king177@ntlworld.com wrote:
how seamless could the integration be made? I've seen a number of programs (mainly installers) and also guilty of writing a few win apps that shell out a dos call and return to continue.
The command prompt in windows works similar to DOS but it is not DOS. Things which invoke our command prompt should still work (well, win9x / nt4.0 stuff might depend on real DOS stuff though).
Also while wine seems to encourage a spread of apps to work, the core DosBox guys have made it clear they are only interested retro games. So dosemu or a qemu/bochs co-operation may be more fruitful.
Dosbox is available for all platforms and is relatively light. While they focus mostly on games, they aren't against general fixes. Dosemu is Linux specific but qemu/bochs would also be possible. Personally I'm in favor of Dosbox.
Roderick
<< While they focus mostly on games, they aren't against general fixes.
not the experience I had on a number of non game related postings, I was told the couple of bytes it would take to add support for a vesa std text video mode would add to much bloat and hit a number of other "it will not help games" responses on other things.
From memory they don't support lpt ports (for similar reasons) wheras you
can multi play games with serial ports so they do support those.
* On Mon, 5 Apr 2010, k4king wrote:
<< While they focus mostly on games, they aren't against general fixes.
From memory they don't support lpt ports (for similar reasons) wheras you can multi play games with serial ports so they do support those.
There exists some branch of DOSBox called MegaBuild. [3]
It implements LPT port emulation and enhances serial port emulation (at least for DirectSerial mode -- now MegaBuild5 switches DSR-DTR/DCD signal pair (and CTS-RTS one also) correctly with appropriate hardware loopback used.
LPT hardware loopback works also with DOS application.
Official DOSBox doesn't do that, so I believe you could use MegaBuild for games also.
S.
* On Tue, 6 Apr 2010, Saulius Krasuckas wrote:
There exists some branch of DOSBox called MegaBuild. [3]
It implements LPT port emulation and enhances serial port emulation (at least for DirectSerial mode -- now MegaBuild5 switches DSR-DTR/DCD signal pair (and CTS-RTS one also) correctly with appropriate hardware loopback used.
I meant sending and querying status line operations at UART I/O port level (not via BIOS or DOS ints).
S.
-
Alexandre Julliard -
chris ahrendt -
Chris Robinson -
Damjan Jovanovic -
k4king -
Marcus Meissner -
Roderick Colenbrander -
Saulius Krasuckas -
Stefan Dösinger