Future implementation
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?
On 14 April 2010 14:35, Luis Busquets <luis.busquets(a)ilidium.com> wrote:
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.
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.
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?
I certainly haven't heard of any plans to include an emulator in Wine.
3. 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.
On Wed, Apr 14, 2010 at 12:35 PM, Luis Busquets <luis.busquets(a)ilidium.com> wrote:
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.
Wine also runs on BSD and OpenSolaris, so if OSS was removed it would kill sound support on these platforms. Tom
On Wed, Apr 14, 2010 at 1:46 AM, Tom Wickline <twickline(a)gmail.com> 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
On Wed, Apr 14, 2010 at 1:52 AM, John Klehm <xixsimplicityxix(a)gmail.com> wrote:
On Wed, Apr 14, 2010 at 1:46 AM, Tom Wickline <twickline(a)gmail.com> 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. -- -Austin
On Wed, Apr 14, 2010 at 6:35 AM, Luis Busquets <luis.busquets(a)ilidium.com> wrote:
Could someone please confirm the following points?:
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?
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
Damjan Jovanovic wrote:
On Wed, Apr 14, 2010 at 6:35 AM, Luis Busquets <luis.busquets(a)ilidium.com> wrote:
Could someone please confirm the following points?:
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?
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
Luis Busquets wrote:
Could someone please confirm the following points?:
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?
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
participants (8)
-
Austin English -
Ben Klein -
Damjan Jovanovic -
John Klehm -
Luis Busquets -
Michael Stefaniuc -
Morten Rønne -
Tom Wickline