VirtualBox

Ticket #3639 (new enhancement)

Opened 5 years ago

Last modified 4 years ago

[PATCH] list WineD3D as installable guest addition

Reported by: rmh Owned by:
Priority: major Component: 3D support
Version: VirtualBox 2.1.4 Keywords:
Cc: Guest type: Windows
Host type: other

Description

This patch adds WineD3D to the menu list as an installable guest addition (in addition to the official guest addition CD).

WineD3D provides Direct3D for Windows guests by wrapping calls to the OpenGL implementation in VBox (more about this in ticket 2940).

The URL used for WineD3D builds points to Savannah, which is now providing them in their mirror network:

 http://download.savannah.nongnu.org/releases/wined3d/latest/wined3d.iso

(redirects to a location geographically close)

More info at:

 http://www.nongnu.org/wined3d/

Attachments

wined3d.diff Download (6.1 KB) - added by rmh 5 years ago.

Change History

Changed 5 years ago by rmh

comment:1 Changed 5 years ago by rmh

Note: Savannah uses HTTP 301 redirect, so the patch in ticket 3641 is a pre-requisite for this one.

comment:2 follow-up: ↓ 3 Changed 5 years ago by sandervl73

I appreciate the work you've done, but I have a serious problem with replacing system files like this.

There are perhaps safer options to try out. Two come to mind:

  • dynamically intercept DirectX imports
  • create a forwarder dll with the same name as the original system dlls and forward calls to the right dll (by default system) based on a configurable setting.

The latter might be worth investigating first as it shouldn't be that much work.

Please mention here if you are going to pursue this. We intend to do so as well before the next major release of VirtualBox.

comment:3 in reply to: ↑ 2 Changed 5 years ago by rmh

Replying to sandervl73:

I appreciate the work you've done, but I have a serious problem with replacing system files like this.

Can you give more details on that? Is it because of the annoying requirement to reboot in safe mode, or something else?

There are perhaps safer options to try out. Two come to mind:

  • dynamically intercept DirectX imports
  • create a forwarder dll with the same name as the original system dlls and forward calls to the right dll (by default system) based on a configurable setting.

The latter might be worth investigating first as it shouldn't be that much work. Please mention here if you are going to pursue this.

I'm not sure I have the expertise for that. Is it possible to make all programs find our DLLs first in their search path, without overwriting the MS Direct3D ones?

We intend to do so as well before the next major release of VirtualBox.

Nice to hear. If you manage to sort it out, I'd suggest you get it merged in the wined3d project at Savannah. This way it will benefit other use cases and make your approach more tested (as well as providing support for older versions of VBox that distributors are shipping).

comment:4 Changed 5 years ago by Technologov

Very interesting development. I want to join to receive emails about this topic.

-Technologov

comment:5 follow-up: ↓ 6 Changed 5 years ago by Technologov

It is especially interesting in light of VBox OSE commit "Changeset [19678]".

-Technologov

comment:6 in reply to: ↑ 5 Changed 5 years ago by rmh

Replying to Technologov:

It is especially interesting in light of VBox OSE commit "Changeset [19678]".

Interesting... I got two suggestions:

  • I would recommend that you integrate the build system that comes with Wine into yours, instead of manually maintaining a list of C files, it will pay off in the long run.
  • I'm not sure what's the default compiler you use on win32, but specifically for Wine it's a good idea to use GCC, since this configuration is the one tested by most Wine users. I suppose you want to avoid having to debug compiler-related portability issues.

comment:7 Changed 5 years ago by sandervl73

Neither suggestion sounds very appealing to me. We use MSVC on Windows and it would be a shame to have to switch to GCC (for this component). GCC is just a pita on Windows as you can't debug properly (i.e. use windbg).

It should be easy to just compile everything using our build system. Using two build systems is not an option.

comment:8 Changed 5 years ago by Technologov

BTW: I decided to provide some feedback about current WineD3D status:

 http://forums.virtualbox.org/viewtopic.php?f=1&t=17785&p=76432#p76432

-Technologov

comment:9 Changed 5 years ago by Technologov

OK, this is now FIXED in v3.0. Please close bug.

-Technologov

comment:10 Changed 5 years ago by rmh

Hi,

I think it'd still be a good idea to provide a link to download latest WineD3D.

The version of WineD3D that comes with VirtualBox is more tried and tested, and probably better integrated, but it's also older. WineHQ makes new releases very often, and the builds at  http://www.nongnu.org/wined3d are updated automatically with a cronjob. They could provide added value for a significant number of users.

I think both options complement each other, and providing more choice is a good thing IMO.

comment:11 Changed 5 years ago by Technologov

Those nightly builds are only of value to developers (either VirtualBox or Wine developers).

IMHO It can be documented somewhere on forums or wiki, but should not be exposed to end-users.

-Technologov

comment:12 Changed 5 years ago by rmh

Hi,

They're not nightly builds. Only Wine releases are provided. My cronjob detects when a new version is released by scanning an HTML page from WineHQ website.

They're intended for the general public (Wine developers use GIT instead), and are perfectly suitable for end users.

comment:13 follow-up: ↓ 14 Changed 5 years ago by leonid

Note, that one can't safely replace system dlls with wine's copy. For example, replacing d3d9.dll will make Vista guests freeze when trying to login the user. For that purpose, in particular, vbox provides a switching proxy dlls.

comment:14 in reply to: ↑ 13 Changed 5 years ago by rmh

Replying to leonid:

Note, that one can't safely replace system dlls with wine's copy. For example, replacing d3d9.dll will make Vista guests freeze when trying to login the user.

Any idea why?

Btw, did you figure out a way to circumvent Windows File Protection?

comment:15 Changed 5 years ago by leonid

wdm.exe tries to use it and fails. It's aero related etc. And no, there're way to trick WFP but we're not using it yet. If you're interested just google for "disabling windows file protection" there'd be several ways to "hack" it.

comment:16 Changed 5 years ago by rmh

I thought aero uses d3d10. In any case, I think wined3d should eventually support it.

As for WFP, I searched for it before, but none of the methods I found were suitable (e.g. binary patching of system files, etc).

comment:17 Changed 5 years ago by leonid

Yes, they're mostly "hacks" and not something suitable.

comment:18 Changed 4 years ago by Technologov

Since guest additions.ISO in VBox 3.0.x (and 3.1) already offers to install Direct3D, I recommend closing this wish.

-Technologov

comment:19 Changed 4 years ago by diablod3

This bug probably should be closed, but I don't think 3.1.0 has the 1.1.33 version of WineD3D so maybe this should be left open as a constant reminder to import new versions?

comment:20 Changed 4 years ago by rmh

Hi,

I think it'd still be a good idea to provide a link to download latest WineD3D.

The version of WineD3D that comes with VirtualBox is more tried and tested, and probably better integrated, but it's also older. WineHQ makes new releases very often, and the builds at  http://www.nongnu.org/wined3d are updated automatically with a cronjob. They could provide added value for a significant number of users.

I think both options complement each other, and providing more choice is a good thing IMO.

(Yes, this reply is a repetition of a previous comment. It'd help if people read the whole log before making the same points all over again....)

comment:21 follow-up: ↓ 23 Changed 4 years ago by Technologov

Giving untested code to users is very bad idea. If users want they can ask on forums about Direct3D, so we will point them to untested code if they _really_ want it.

-Technologov

comment:22 Changed 4 years ago by diablod3

Can the version in VBox be safely overwritten with the stock version of WineD3D?

comment:23 in reply to: ↑ 21 Changed 4 years ago by rmh

Replying to Technologov:

Giving untested code to users is very bad idea.

I assure you that Wine developers test their code before releasing it.

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use