Wine on Windows (via opengl32.dll)

Open forum for end-user questions about Wine. Before asking questions, check out the Wiki as a first step.
Forum Rules
Locked
Casm
Newbie
Newbie
Posts: 4
Joined: Thu Jun 24, 2010 5:56 am

Wine on Windows (via opengl32.dll)

Post by Casm »

Hello!

I'm trying to replace "default" Direct3D7 implementation with gorgeous Wine software (ddraw.dll/wined3d.dll).
However initialization brings surprises.

wined3d.dll tries to load opengl32.dll (it's correct I suppose).
opengl32.dll calls GetSystemMetrics from user32.dll (it's probably correct)
user32.dll tries to use ddraw.dll to calculate some parameters. Maybe it's correct but totally unexpected.
Thus recursion of calls to WineDirect3DCreate is detected.

The complete call stack is here:

WINED3D.dll!InitAdapters(IWineD3DImpl * This=0x000b98a0) Line 4977 C
WINED3D.dll!wined3d_init(IWineD3DImpl * wined3d=0x000b98a0, unsigned int version=7, IUnknown * parent=0x000b73a0) Line 5301 + 0x9 bytes C
WINED3D.dll!WineDirect3DCreate(unsigned int version=7, IUnknown * parent=0x000b73a0) Line 91 + 0x11 bytes C
ddraw.dll!657d9814()
[Frames below may be incorrect and/or missing, no symbols loaded for ddraw.dll]
ddraw.dll!657d9cab()
user32.dll!_GetSystemMetrics@4() + 0x4b bytes
opengl32.dll!_GLInitializeProcess@0() + 0x1b5 bytes
opengl32.dll!_DllInitialize@12() + 0x44 bytes
ntdll.dll!_LdrpCallInitRoutine@16() + 0x14 bytes
ntdll.dll!_LdrpRunInitializeRoutines@4() + 0x205 bytes
ntdll.dll!_LdrpLoadDll@24() - 0x1b8 bytes
ntdll.dll!_LdrLoadDll@16() + 0x110 bytes
kernel32.dll!_LoadLibraryExW@12() + 0xc8 bytes
kernel32.dll!_LoadLibraryExA@12() + 0x1f bytes
kernel32.dll!_LoadLibraryA@4() + 0x2d bytes
WINED3D.dll!InitAdapters(IWineD3DImpl * This=0x000b8fe8) Line 4980 + 0xd bytes C
WINED3D.dll!wined3d_init(IWineD3DImpl * wined3d=0x000b8fe8, unsigned int version=7, IUnknown * parent=0x000b7288) Line 5301 + 0x9 bytes C
WINED3D.dll!WineDirect3DCreate(unsigned int version=7, IUnknown * parent=0x000b7288) Line 91 + 0x11 bytes C
ddraw.dll!657d9814()
ddraw.dll!657d9e01()
shimeng.dll!_StubGetProcAddress@8() + 0x8f bytes


Can anything be done with this behaviour?

Thank you
Thunderbird
Level 5
Level 5
Posts: 336
Joined: Mon Nov 24, 2008 8:10 am

Post by Thunderbird »

The recursion problem is a known issue. It is not really Wine's fault but actually Windows its fault. The problem is that native opengl32.dll uses ddraw.dll.

A possible solution (which I never experimented with) is to load the ICD driver directly and skip opengl32.dll altogether. It would require some custom WGL calls to the ICD. I'm not sure if this will work though since I'm not sure if the ICD drivers export GL 1.1 calls (those are loaded from opengl32.dll and 1.1+ is loaded from the ICD driver). It migh tbe cleanest to write an opengl32 wrapper around the ICD.
Casm
Newbie
Newbie
Posts: 4
Joined: Thu Jun 24, 2010 5:56 am

Post by Casm »

Thunderbird wrote:The problem is that native opengl32.dll uses ddraw.dll.
Which purpose does it use ddraw.dll for? What does returning of NULL in the second recursive call lead to?
Thunderbird wrote:A possible solution (which I never experimented with) is to load the ICD driver directly and skip opengl32.dll altogether. It would require some custom WGL calls to the ICD.
Does it have anything with Wine?
Thunderbird wrote:I'm not sure if this will work though since I'm not sure if the ICD drivers export GL 1.1 calls (those are loaded from opengl32.dll and 1.1+ is loaded from the ICD driver). It migh tbe cleanest to write an opengl32 wrapper around the ICD.
Is there any "template" for the wrapper? Does MESA have something simular? Or any other project?
Thunderbird
Level 5
Level 5
Posts: 336
Joined: Mon Nov 24, 2008 8:10 am

Post by Thunderbird »

On Windows opengl32.dll contains a software opengl renderer (Microsoft GDI Renderer, OpenGL 1.1). Hardware acceleration is provided using a ICD (installable client driver) which acts as a sort of plugin. You can try to load a ICD driver directly. The main thing wined3d needs is: (wgl)GetPixelFormat, (wgl)SetPixelFormat, (wgl)ChoosePixelFormat and wglCreateContext, wglMakecurrent and wglShareLists. I explicitly put some calls between () because there are two versions of some. The difference might matter this time.
Casm
Newbie
Newbie
Posts: 4
Joined: Thu Jun 24, 2010 5:56 am

Post by Casm »

Well, that's great.
But I prefer to receive answers on questions I asked rather than those I didn't.
jorl17
Level 5
Level 5
Posts: 365
Joined: Mon Jul 28, 2008 6:44 pm

Post by jorl17 »

I believe Thunderbird provided answers to two of your three questions.
Thunderbird
Level 5
Level 5
Posts: 336
Joined: Mon Nov 24, 2008 8:10 am

Post by Thunderbird »

Among things I did the wined3d -> windows porting and of course experimented with ddraw on Windows. I never went to deep to see what opengl32.dll is actually doing since I don't want to be exposed to Microsoft dll internals (in this case opengl32) which would prevent me from doing other Wine hacking.

WineD3D uses a very different design compared to Windows. There are various DirectDraw specific / DirectDraw-Win32 interaction APIs in parts of Windows which we don't have because we use a different design.

The only way I think the issues might be fixable is to skip opengl32.dll but load an OpenGL ICD. Parallels did this as well in the time they used WineD3D and it worked fine.
DaVince
Level 8
Level 8
Posts: 1099
Joined: Wed Oct 29, 2008 4:53 pm

Post by DaVince »

Casm wrote:Well, that's great.
But I prefer to receive answers on questions I asked rather than those I didn't.
Any answers that seem unrelated are probably answers to earlier questions - these forums are connected to the wine mailing list.
Casm
Newbie
Newbie
Posts: 4
Joined: Thu Jun 24, 2010 5:56 am

Post by Casm »

Thank you for the information you gave me. I doubt I can use it anyway, but it is only my problem from the very beginning.
magicwolf
Newbie
Newbie
Posts: 3
Joined: Fri Feb 15, 2013 5:28 am

Re: Wine on Windows (via opengl32.dll)

Post by magicwolf »

As I understood now in case of initialization of wined3d_init wined3d_adapter_init_nogl is used,
i.e. it seems as ddraw shall be launched normally?!
http://source.winehq.org/source/dlls/wi ... tx.c#L5211
Can eat somewhere new build WineD3D for win?
User avatar
André H.
Moderator
Moderator
Posts: 207
Joined: Sun Dec 07, 2008 8:33 am

Re: Wine on Windows (via opengl32.dll)

Post by André H. »

magicwolf
Newbie
Newbie
Posts: 3
Joined: Fri Feb 15, 2013 5:28 am

Re: Wine on Windows (via opengl32.dll)

Post by magicwolf »

Yes I read it. The last WineD3DOnWindows version (http://ftp.twaren.net/Unix/NonGNU//wined3d/) from 06-Feb-2010 12:49. The last wined3d version (http://source.winehq.org/source/dlls/wined3d/) from 2013-02-15 20:44:27. If I correctly understood, WineD3DOnWindows (http://wiki.winehq.org/WineD3DOnWindows) is compiled from the source code wined3d. Then the WineD3DOnWindows version is already obsolete. And I would like to know if the new WineD3DOnWindows version based on the source codes wined3d?
magicwolf
Newbie
Newbie
Posts: 3
Joined: Fri Feb 15, 2013 5:28 am

Re: Wine on Windows (via opengl32.dll)

Post by magicwolf »

I tried to compile WineD3D on Windows. In a script for compilation there is a line "$HOME/wine-git/configure - without-x", to it it is necessary to add a key "--without-freetype". And a script came to the end with a mistake:

checking for i586-mingw32msvc-dlltool... no
checking for dlltool... no
checking for i586-mingw32msvc-dllwrap... no
checking for dllwrap... no
configure: error: could not find a way to build shared libraries.
It is currently not possible to build Wine without shared library
(.so) support to allow transparent switch between .so and .dll files.
If you are using Linux, you will need a newer binutils.

What to do?
Loooooker
Level 1
Level 1
Posts: 5
Joined: Mon Jul 22, 2013 5:29 am

Re: Wine on Windows (via opengl32.dll)

Post by Loooooker »

I builded wine parts for use on Windows many times with wine versions thru 1.2 to 1.5.7.
I used these recommendations: http://wiki.winehq.org/WineD3DOnWindows
Build platform was Linux x86 and all works great.

Now I try to build last versions of wine dlls on x86_64 and encountered some problems.
I have followed these recomendations: http://wiki.winehq.org/WineOn64bit and work under chroot
If I just make Wine, all works great, but when I use cross-compile with "--host=i586-mingw32msvc" (which links to -i686-w64-mingw32),
libwine.dll builds ok, but any of /dlls/* won't with this error (full listing):

Code: Select all

(raring_i386)root@Sonne://home/romawk/wine-win32# make -C dlls/wined3d
make: Entering directory `/home/romawk/wine-win32/dlls/wined3d'
/home/romawk/wine-tools//tools/winegcc/winegcc -b i686-w64-mingw32  -B/home/romawk/wine-tools//tools/winebuild --sysroot=../.. -fasynchronous-unwind-tables -shared /home/romawk/wine/dlls/wined3d/wined3d.spec arb_program_shader.o ati_fragment_shader.o buffer.o context.o device.o directx.o drawprim.o gl_compat.o glsl_shader.o nvidia_texture_shader.o palette.o query.o resource.o sampler.o shader.o shader_sm1.o shader_sm4.o state.o stateblock.o surface.o swapchain.o texture.o utils.o vertexdeclaration.o view.o volume.o wined3d_main.o       version.res    -o wined3d.dll  -luuid -lopengl32 -luser32 -lgdi32 -ladvapi32  ../../libs/port/libwine_port.a   

/usr/bin/i686-w64-mingw32-windres: unexpected version string length 68 != 32 + 8
winebuild: /usr/bin/i686-w64-mingw32-windres failed with status 1
winegcc: /home/romawk/wine-tools//tools/winebuild/winebuild failed
make: *** [wined3d.dll] Error 2
I have no experience build cross x86 apps under x86_64 and have no idea what's wrong.
Any suggestions?
Loooooker
Level 1
Level 1
Posts: 5
Joined: Mon Jul 22, 2013 5:29 am

Re: Wine on Windows (via opengl32.dll)

Post by Loooooker »

[Resolved]
Looks like the problem is in mingw-binutils version lower than 2.23.1-2
(change in this version: "- Backported patch unexpected version string length error in windres (RHBZ #902960)")
So, most of currents distribs has bugged mingw-binutils.
I try to take it from debian-sid (2.23.52) and all works fine.
Locked