Future implementation

[Luis Busquets]

Could someone please confirm the following points?:

1. Sound system. The configuration that wine will implement is:
winmm --> WASAPI --> OpenAL
and
DirectSound --> OpenAL
After that is done wineoss, winejack, winealsa, ... will be removed from 
the tree.

2. Integration of DosBOX or other emulator. How this will be done? Is 
the plan to use them when wine detects that the programme is compiled 
for real mode? Does that mean that the sake of wine is to provide 
compatibility only for applications built to be run on protected mode?

3. Direct3D10 and Direct3D11, Is there a target date for them?

[Ben Klein]

On 14 April 2010 14:35, Luis Busquets  wrote:
> Could someone please confirm the following points?:
> - Sound system. The configuration that wine will implement is:
>
> winmm --> WASAPI --> OpenAL
> and
> DirectSound --> OpenAL
> After that is done wineoss, winejack, winealsa, ... will be removed from the
> tree.

I can't speak for the Developers That Matter (TM), but I don't think
there is any plan to remove wineoss, winejack and winealsa from the
tree completely. I think it's more likely that wineopenal will be
available (probably as default in the long term) as an alternative.
> - Integration of DosBOX or other emulator. How this will be done? Is the
>
> plan to use them when wine detects that the programme is compiled for real
> mode? Does that mean that the sake of wine is to provide compatibility only
> for applications built to be run on protected mode?

I certainly haven't heard of any plans to include an emulator in Wine.
> - Direct3D10 and Direct3D11, Is there a target date for them?

Work has already begun, but Wine as a project generally does not set
target dates for any feature support.

[Tom Wickline]

On Wed, Apr 14, 2010 at 12:35 PM, Luis Busquets
 wrote:
> Could someone please confirm the following points?:
> - Sound system. The configuration that wine will implement is:
>
> winmm --> WASAPI --> OpenAL
> and
> DirectSound --> OpenAL
> After that is done wineoss, winejack, winealsa, ... will be removed from the
> tree.

Wine also runs on BSD and OpenSolaris, so if OSS was removed it would kill
sound support on these platforms.

Tom

[John Klehm]

On Wed, Apr 14, 2010 at 1:46 AM, Tom Wickline  wrote:
> Wine also runs on BSD and OpenSolaris, so if OSS was removed it would kill
> sound support on these platforms.

Doesn't openal support bsd and solaris too?
http://connect.creativelabs.com/openal/OpenAL%20Wiki/Platforms.aspx

--John Klehm

[Austin English]

On Wed, Apr 14, 2010 at 1:52 AM, John Klehm  wrote:
> On Wed, Apr 14, 2010 at 1:46 AM, Tom Wickline  wrote:
> > Wine also runs on BSD and OpenSolaris, so if OSS was removed it would kill
> > sound support on these platforms.
>
> Doesn't openal support bsd and solaris too?
> http://connect.creativelabs.com/openal/OpenAL%20Wiki/Platforms.aspx

Yes, but in their current ports (last I checked), the version is not
new enough for wine to support.

[Damjan Jovanovic]

On Wed, Apr 14, 2010 at 6:35 AM, Luis Busquets
 wrote:
> Could someone please confirm the following points?:
> - Integration of DosBOX or other emulator. How this will be done? Is the
>
> plan to use them when wine detects that the programme is compiled for real
> mode? Does that mean that the sake of wine is to provide compatibility only
> for applications built to be run on protected mode?

Just yesterday (http://www.winehq.org/pipermail/wine-devel/2010-April/082983.html)
I wrote that we don't need emulation even on 64-bit since we can still
get into virtual 8086 mode using the http://v86-64.sourceforge.net
project.

In any case, a real mode DOS application can still switch into
protected mode, and a 16-bit protected mode Windows 3.1 application
can still call into DOS, so there's no escape from DOS in Wine :-).

Damjan

[Michael Stefaniuc]

Damjan Jovanovic wrote:
> On Wed, Apr 14, 2010 at 6:35 AM, Luis Busquets
>  wrote:
> > Could someone please confirm the following points?:
> > - Integration of DosBOX or other emulator. How this will be done? Is the
> >
> > plan to use them when wine detects that the programme is compiled for real
> > mode? Does that mean that the sake of wine is to provide compatibility only
> > for applications built to be run on protected mode?
>
> Just yesterday (http://www.winehq.org/pipermail/wine-devel/2010-April/082983.html)
> I wrote that we don't need emulation even on 64-bit since we can still
> get into virtual 8086 mode using the http://v86-64.sourceforge.net
> project.

And yesterday ;) I wanted to reply that Wine cannot rely on that
feature. That stuff is a kernel patch in the early stage. Provided that
Linus is willing to accept that feature it is at least 2 kernel versions
out; I see it earliest in 2.6.36 aka 1 year from now. And it will take
another 6-12 month until that feature is generally available in Linux
distributions. Also the non-Linux OSes would need to provide a similar
functionality too.
> In any case, a real mode DOS application can still switch into
> protected mode, and a 16-bit protected mode Windows 3.1 application
> can still call into DOS, so there's no escape from DOS in Wine :-).

16bit Windows applications do run in Wine on a 64bit OS without any need
for VM86.

bye
    michael

[Morten Rønne]

Luis Busquets wrote:
> Could someone please confirm the following points?:
> - Integration of DosBOX or other emulator. How this will be done? Is
>
> the plan to use them when wine detects that the programme is compiled 
> for real mode? Does that mean that the sake of wine is to provide 
> compatibility only for applications built to be run on protected mode?

It was briefly discussed when I wrote about implementing VGA mode 18. 
This does require a lot of changes in the DOSVM (another mail incoming 
about that).
It was seen as a way of making more real mode programs run without 
having to redo what others have already done.
But doing so present it's own set of problems. For me the main thing 
would be how to tell the user that they are now "leaving" wine and what 
ever error that might come should be directed at someone else.

So for me the way forward is still to improve wine's dosvm to handle 
more cases. Something I hope I can devote some time to.

BR
Morten Rønne