Is DOSBox replacing native DOS support in Wine?

flerchjj · Post by **flerchjj** » Sat Sep 10, 2011 3:20 am

I haven't followed Wine in quite a while, other than to do an occasional update (but hopefully this will change). I noticed DOSBox support was added in January 2011.

My understanding is that when Wine can't even attempt to run DOS programs itself (MAC OSX, 64bit OSes, etc) that it will attempt to run using DOSBox. Is this correct? Is the plan to replace native Wine DOS support across the board with DOSBox, use DOSBox only on certain OSes/chipsets, allow use of DOSBox on a program by program basis using config files, or use DOSBox only as a failure mode?

The move to 64bit OSes and lack of 16bit support worries me about Wine's internal method for interpreting DOS & Win 3.2 executables.

SpawnHappyJake · Post by **SpawnHappyJake** » Mon Sep 12, 2011 11:49 pm

I was wondering about that too.

FrÃ©dÃ©ric Delanoy · Tue Sep 13, 2011 4:10 am

On Sat, Sep 10, 2011 at 10:20, flerchjj <[email protected]> wrote:

I haven't followed Wine in quite a while, other than to do an occasional update (but hopefully this will change). I noticed DOSBox support was added in January 2011.

My understanding is that when Wine can't even attempt to run DOS programs itself (MAC OSX, 64bit OSes, etc) that it will attempt to run using DOSBox. Is this correct? Is the plan to replace native Wine DOS support across the board with DOSBox, use DOSBox only on certain OSes/chipsets, allow use of DOSBox on a program by program basis using config files, or use DOSBox only as a failure mode?

The move to 64bit OSes and lack of 16bit support worries me about Wine's internal method for interpreting DOS & Win 3.2 executables.

You can run 16bit binaries on 64 bits OSes as long as you don't
compile/run a 64bit wine, but a 32bit one.
So basically, your 16bit binaries will run as long as your 64bits OS
supports 32bits apps.

SpawnHappyJake · Post by **SpawnHappyJake** » Tue Sep 13, 2011 4:54 am

So 32-bit WINE runs 16-bit applications without processor emulation while 64-bit WINE always uses DOSBox for 16-bit applications. Is that right?

I understand that a 64-bit OS can be running a 32-bit program and a 64-bit program at the same time. Does the trouble arise when one program wants to switch modes? It would seem like WINE would go into whatever mode the program is that it is running, but apparently not.

Cheers,
Jake

flerchjj · Post by **flerchjj** » Tue Sep 13, 2011 6:46 am

I thought there were no vm86 libs for 64bit OSes (including Mac OSX). This library is called by Wine to run 16bit code.

Below is an excerpt from wikipedia (http://en.wikipedia.org/wiki/Virtual_8086_mode) that adds to this:

Support for Virtual 8086 mode (VM86) is not available in x86-64 Long Mode, although it is still present on 64-bit capable processors running in 32-bit protected mode. The removal of this sub-mode means that 16-bit compatibility must be rewritten or removed from 64-bit operating systems. For example, DOS and 16-bit Windows application support is not present in x64 editions of Windows, necessitating the use of 3rd party emulation software such as DOSBox.

flerchjj · Post by **flerchjj** » Tue Sep 13, 2011 6:48 am

FrÃ©dÃ©ric Delanoy wrote:You can run 16bit binaries on 64 bits OSes as long as you don't
compile/run a 64bit wine, but a 32bit one.
So basically, your 16bit binaries will run as long as your 64bits OS
supports 32bits apps.

I not convinced that's true. See my last post.

vitamin · Post by **vitamin** » Tue Sep 13, 2011 8:46 am

flerchjj wrote:My understanding is that when Wine can't even attempt to run DOS programs itself (MAC OSX, 64bit OSes, etc) that it will attempt to run using DOSBox. Is this correct?

Correct.

flerchjj wrote:Is the plan to replace native Wine DOS support across the board with DOSBox, use DOSBox only on certain OSes/chipsets, allow use of DOSBox on a program by program basis using config files, or use DOSBox only as a failure mode?

No, AFAIK there are no plans to completely remove DOS support from Wine. But there are also no active work to make it work better. The reason to keep DOS mode in Wine is to support multi-platform applications, that have pieces that run in DOS, win16, and win32.

flerchjj wrote:The move to 64bit OSes and lack of 16bit support worries me about Wine's internal method for interpreting DOS & Win 3.2 executables.

Don't confuse 16-bit protected mode and good old vm86 (aka real mode). Even 64-bit systems still do support 16-bit protected mode, used in win3.1 and supported by older Windows.

Almost the same applies to real mode. You can't remove it, that's how the system starts. CPU enters 16-bit real mode after power on and used by BIOS. The problem is, you can not switch to vm86 from protected 64-bit mode...

flerchjj · Post by **flerchjj** » Tue Sep 13, 2011 4:06 pm

Can Wine run 16bit protected mode DOS programs, the winecmd, and batch files on OS X and 64bit linux? Is real mode aka virtual 8086 mode the only instance it falls back to DOSBox? Can anyone confirm?

vitamin · Post by **vitamin** » Tue Sep 13, 2011 8:03 pm

flerchjj wrote:Can Wine run 16bit protected mode DOS programs on OS X and 64bit linux?

No, this is only possible with DOSBox.

tutmirleid · Post by **tutmirleid** » Wed Sep 14, 2011 3:06 am

vitamin wrote:
flerchjj wrote:Can Wine run 16bit protected mode DOS programs on OS X and 64bit linux?
No, this is only possible with DOSBox.

Unfortunately

oiaohm · Post by **oiaohm** » Wed Sep 14, 2011 6:05 am

flerchjj vm86 and 64 bit intel chips. The wikipedia is wrong.
http://v86-64.sourceforge.net/

You cannot go straight into vm86 mode from x86-64 Long Mode but you can switch to 32 bit protected then switch to vm86. Longer chain to get there.

Correct is that the method of getting vm86 has to be rewritten. The 64 bit design by AMD did include a path to use vm86 while the core OS was in x86-64 Long Mode. Microsoft decided against it so this means it will not be well tested as a functional path.

So safer for it to disappear. Also DOSBox most likely will be lighter on context switching.

As you can see v86-64 patch basically does it. Not that i would recommend using it there is a performance interference due to the steps.

Basically vm86 with kernel in x86-64 Long mode is possible just not advisable because of side effects to performance.