wine users - Sep 2011 - Is DOSBox replacing native DOS support in Wine?

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.

I was wondering about that too.

On Sat, Sep 10, 2011 at 10:20, flerchjj <wineforum-user at winehq.org>
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.

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

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 wrote:
> Can Wine run 16bit protected mode DOS programs on OS X and 64bit linux?
No, this is only possible with DOSBox.

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 :(

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.