August 2007 - Wine-Devel - list.winehq.org

OS X and OpenGL

by Mike Kronenberg

Hello list, I'm a frequent user of wine and normally build my own copy, as no official distribution for Mac OS X exists. Lately I had to deal with a Program, that needs OpenGL. I found different hints on the list and around the net, that the current Apple X11 libGL is broken, so I tried different flavors of xdarwin and x11: X11R6.8.2 and X11R7.2. With X11R6.8 (compiled from fink) wine builds without error. (OpenGL Headers and libs where found) When I run the app, I get: err:wgl:X11DRV_wglGetProcAddress No libGL on this box - disabling OpenGL support ! err:wgl:X11DRV_wglGetProcAddress No libGL on this box - disabling OpenGL support ! err:wgl:X11DRV_wglGetProcAddress No libGL on this box - disabling OpenGL support ! err:wgl:X11DRV_wglGetProcAddress No libGL on this box - disabling OpenGL support ! err:wgl:X11DRV_wglGetProcAddress No libGL on this box - disabling OpenGL support ! err:wgl:X11DRV_wglGetProcAddress No libGL on this box - disabling OpenGL support ! err:wgl:X11DRV_ChoosePixelFormat No libGL on this box - disabling OpenGL support ! err:wgl:X11DRV_wglMakeCurrent No libGL on this box - disabling OpenGL support ! I modified opengl.c to see whether SONAME_LIBGL was set in as_opengl () and it was. With X11R7.2 (pkg form x.org) wine builds without error. (OpenGL Headers and libs where found) but it seams that libGL has a link to a nonexistent library (/usr/X11/ lib/GL), which crashes openGL32.dll when I run the app. Before I start some more debugging on my system: Do you have any hints? (Is this a linking problem / Anybody knows a working revision of X11 / recent bugs, etc) Txs Mike Intel Wine 0.9.43 OS X 10.4.10

Aug. 21, 2007

Re: WineD3D: fix a null pointer dereference

by Stefan Dösinger

Am Dienstag, 21. August 2007 16:55 schrieb Roderick Colenbrander: > Hi, > > This patch gets Tiberian Sun working in ddraw OpenGL mode. Before it > suffered > > >from a null pointer dereference bug. This patch is ok with me, but there's a bad flaw with opengl'ed ddraw I want to point out Ddraw apps can just create offscreen surfaces and perform blits between them without creating a render target. To do anything in opengl, a context is needed, and a context needs a drawable. So no gl context without a render target in gl. Now the current code checks if the locked surface is a render target, and crashes because the render target array doesn't exist. This patch simply fixes this NULL pointer dereference. The essential problem remains though, that ddraw operations in gl won't work unless the app creates a render target. Currently it works because only operations on render targets use opengl, but there is code to have opengl do offscreen<->offscreen blits. That code(stretch_rect_fbo) is only used for d3d9, but when activated for ddraw apps too, we have to be careful.

Aug. 21, 2007

Re: dinput: Fix compile with old input.h that missing input_absinfo

by Dmitry Timoshkov

"Vitaliy Margolen" <wine-patches(a)kievinfo.com> wrote: > +struct wine_input_absinfo { > + LONG value; > + LONG minimum; > + LONG maximum; > + LONG fuzz; > + LONG flat; > +}; If it's a kernel structure, it's better IMO to use the types that are actually used in the native structure instead of LONG. -- Dmitry.

Aug. 21, 2007

Re: How to Calling PE Dlls on linux??

by Damjan Jovanovic

On 8/21/07, trulyliu <trulyliu(a)gmail.com> wrote: > > > 2007/8/21, Damjan Jovanovic <damjan.jov(a)gmail.com>: > > On 8/21/07, trulyliu <trulyliu(a)gmail.com> wrote: > > > Can I made Arithmetic.dll.so ? And link it against my linux App? > > > > A library function runs in the context of the process that invokes it. > > A library doesn't have its own TEB/memory layout/exception handling > > that works independently of the process that calls it, no matter how > > it is compiled. If the wine plugin API is ever made, it will modify > > the process so it has what the library expects when the library > > functions are called. > > > > Does your Arithmetic.dll.so call any Windows functions? If so, you > > need wine and you will always need wine, plugin API or no plugin API, > > whether you compile it into a DLL or .dll.so. But if you only use ANCI > > C stuff you can compile it into a .so and use it without wine. > > > > If you want something that runs seamlessly on every operating system > > today, IMHO you should consider Java. > > > > > > > Yes, Java may be a good choice for crossing platform. > > As you said, my Arithmetic.dll does not call any windows function. > It's pure ANSI C library. What's the step of make .dll.so ?? > > Use winegcc or gcc ?? Use gcc and make a .so like this: gcc -c arithmetic.c -fPIC gcc arithmetic.o -shared -o arithmetic.so Then put it in /usr/lib and link to it like so: gcc -c application.c gcc application.o -o application -larithmetic > > > -- > > > trulyliu(a)gmail.com > > Damjan > -- > trulyliu(a)gmail.com > Damjan

Aug. 21, 2007

Re: How to Calling PE Dlls on linux??

by trulyliu

2007/8/21, Damjan Jovanovic <damjan.jov(a)gmail.com>: > > On 8/21/07, trulyliu <trulyliu(a)gmail.com> wrote: > > Can I made Arithmetic.dll.so ? And link it against my linux App? > > A library function runs in the context of the process that invokes it. > A library doesn't have its own TEB/memory layout/exception handling > that works independently of the process that calls it, no matter how > it is compiled. If the wine plugin API is ever made, it will modify > the process so it has what the library expects when the library > functions are called. > > Does your Arithmetic.dll.so call any Windows functions? If so, you > need wine and you will always need wine, plugin API or no plugin API, > whether you compile it into a DLL or .dll.so. But if you only use ANCI > C stuff you can compile it into a .so and use it without wine. > > If you want something that runs seamlessly on every operating system > today, IMHO you should consider Java. > > Yes, Java may be a good choice for crossing platform. As you said, my Arithmetic.dll does not call any windows function. It's pure ANSI C library. What's the step of make .dll.so ?? Use winegcc or gcc ?? > > > > > > > > > > > > > > > > -- > > trulyliu(a)gmail.com > > > > Damjan > > > -- trulyliu(a)gmail.com

Aug. 21, 2007

Re: [2/5] WineD3D: Use 0/0/0 as normal if no normal is supplied

by Stefan Dösinger

Am Dienstag, 21. August 2007 12:57 schrieb H. Verbeet: > I'm not sure about this one. Unless explicitly checked for, (0, 0, 0) > will cause a division by zero when trying to normalize it, and I don't > know for sure if GL has well defined behaviour for it. You're right, this patch is asking for problems with normalization. Perhaps we should disable normalization if no normals are provided, but I will double check the lighting equations first for divisions by zero, but afair there's only a cross product and a multiplication there.

Aug. 21, 2007

Re: [5/5] WineD3D: Fix fogstart == fogend with table fog

by Stefan Dösinger

Am Dienstag, 21. August 2007 13:08 schrieb H. Verbeet: > On 21/08/07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > > Feel free to suggest a better way to increase the fogend. My way works, > > but it is not the nicest way. > > Does this really matter? To me, this looks like a rather ugly hack to > get the DCT to shut up. Well, it is d3d's (ugly) definition of a corner case, in the same way gl has a definition of that corner case(d3d has two, actually). Of course we can wait for a game to require this behavior, but will we recognise it as such? Or will we spend a lot of time for debugging, only to find out that it is a well-known problem we deliberately didn't fix? Agreed, some problems are hard/impossible to fix, so we shouldn't fix them just to make the DCT happy, like flat shading or D3DRS_WRAPx. But this fog fix is pretty simple.

Aug. 21, 2007

Re: How to Calling PE Dlls on linux??

by Damjan Jovanovic

On 8/21/07, trulyliu <trulyliu(a)gmail.com> wrote: > Can I made Arithmetic.dll.so ? And link it against my linux App? A library function runs in the context of the process that invokes it. A library doesn't have its own TEB/memory layout/exception handling that works independently of the process that calls it, no matter how it is compiled. If the wine plugin API is ever made, it will modify the process so it has what the library expects when the library functions are called. Does your Arithmetic.dll.so call any Windows functions? If so, you need wine and you will always need wine, plugin API or no plugin API, whether you compile it into a DLL or .dll.so. But if you only use ANCI C stuff you can compile it into a .so and use it without wine. If you want something that runs seamlessly on every operating system today, IMHO you should consider Java. > 2007/8/21, Damjan Jovanovic <damjan.jov(a)gmail.com >: > > On 8/21/07, trulyliu <trulyliu(a)gmail.com > wrote: > > > > > I have tried these code, It works well. Thanks a lot. > > > Could I use gcc/g++ instead of winegcc/wineg++ ??? > > > mplayer use gcc as it's complier？ What's the mystery in it? > > > > > > > gcc/g++ would give you the wrong ABI (eg. 4 bytes per wide char > > instead of 2 bytes), and the special code needed to set up the Windows > > memory layout and the thread extension block and structured exception > > handling wouldn't get executed, leading to segfaults when you call any > > code that tries to access them. That's assuming you can even compile > > and link. > > > > That's why you need winegcc/wineg++. > > > > > trulyliu(a)gmail.com > > > > Damjan > > > > > > > > > > -- > trulyliu(a)gmail.com > Damjan

Aug. 21, 2007

Re: gdi: AddFontResource needs to support a second default directory

by Dan Kegel

On 8/21/07, Alexandre Julliard <julliard(a)winehq.org> wrote: > "Dan Kegel" <dank(a)kegel.com> writes: > > > @@ -1727,6 +1736,22 @@ INT WineEngAddFontResourceEx(LPCWSTR file, DWORD flags, PVOID pdv) > > { > > INT ret = AddFontFileToList(unixname, NULL, NULL, ADDFONT_FORCE_BITMAP); > > HeapFree(GetProcessHeap(), 0, unixname); > > + if (!ret && !strchrW(file, '\\')) { > > + /* http://support.installshield.com/kb/view.asp?pcode=ALL&articleid=Q100057 > > + * suggests that in older versions of Windows, AddFontResource > > + * paths were relative to %WINDIR%/Fonts instead of %WINDIR%/System > > + * Retry assuming that's what went wrong. > > + */ > > This comment is misleading, fonts are in WINDIR/fonts in all Windows > versions, and we never look in WINDIR/system anyway. It sure looks like we're looking in WINDIR/system32 in this case. Without my patch, the installer in bug 9382 fails with: 000e:Call KERNEL32.MoveFileA(0063459c "C:\\windows\\Fonts\\is-S53BH.tmp",00609cd8 "C:\\windows\\Fonts\\4mylover.TTF") ret=00450c93 000e:Ret KERNEL32.MoveFileA() retval=00000001 ret=00450c93 000e:Call gdi32.AddFontResourceA(00616934 "4mylover.TTF") ret=00468788 trace:file:RtlDosPathNameToNtPathName_U (L"4mylover.TTF",0x34ed74,(nil),(nil)) trace:file:RtlGetFullPathName_U (L"4mylover.TTF" 520 0x34eb34 (nil)) warn:file:wine_nt_to_unix_file_name L"\\??\\C:\\windows\\system32\\4mylover.TTF" -> "/home/dank/.wine/dosdevices/c:/windows/system32/4mylover.TTF" required a case-insensitive search trace:file:wine_nt_to_unix_file_name L"\\??\\C:\\windows\\system32\\4mylover.TTF" -> "/home/dank/.wine/dosdevices/c:/windows/system32/4mylover.TTF" trace:font:AddFontFileToList Loading font file "/home/dank/.wine/dosdevices/c:/windows/system32/4mylover.TTF" index 0 warn:font:AddFontFileToList Unable to load font file "/home/dank/.wine/dosdevices/c:/windows/system32/4mylover.TTF" err = 1 My patch and its comment may be confused, but it does let the installer find the fonts and complete successfully. I guess I should write a test to see what the proper behavior is for AddFontResource for files without absolute names. - Dan

Aug. 21, 2007

Re: gdi: AddFontResource needs to support a second default directory

by Alexandre Julliard

"Dan Kegel" <dank(a)kegel.com> writes: > @@ -1727,6 +1736,22 @@ INT WineEngAddFontResourceEx(LPCWSTR file, DWORD flags, PVOID pdv) > { > INT ret = AddFontFileToList(unixname, NULL, NULL, ADDFONT_FORCE_BITMAP); > HeapFree(GetProcessHeap(), 0, unixname); > + if (!ret && !strchrW(file, '\\')) { > + /* http://support.installshield.com/kb/view.asp?pcode=ALL&articleid=Q100057 > + * suggests that in older versions of Windows, AddFontResource > + * paths were relative to %WINDIR%/Fonts instead of %WINDIR%/System > + * Retry assuming that's what went wrong. > + */ This comment is misleading, fonts are in WINDIR/fonts in all Windows versions, and we never look in WINDIR/system anyway. -- Alexandre Julliard julliard(a)winehq.org

Aug. 21, 2007