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

gphoto2.ds: remove camera import UI
by Luke Bratch Aug. 22, 2007

Aug. 22, 2007

--- Alexandre Julliard <julliard at winehq.org> wrote: > > Rather than remove all that nearly-working code, > > how about keeping it, adding the winecfg option, > > and making it default to off for now? > > That option is much too specific to go in winecfg, it's > something most > users don't care about. What you could do though is have a "don't show > this dialog again" option in the dialog itself. How about a registry key? ___________________________________________________________ Want ideas for reducing your carbon footprint? Visit Yahoo! For Good http://uk.promotions.yahoo.com/forgood/environment.html

1 0

Re: [2/5] WineD3D: Refuse to lock locked surfaces
by H. Verbeet Aug. 22, 2007

Aug. 22, 2007

On 22/08/07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Spotted by DCT > I don't know what the DCT actually tests, but should it refuse to lock any locked surface, or only when the rectangles overlap? Of course a test would be nice, considering surface locking behaves somewhat different between ddraw, d3d8 and d3d9.

2 2

Re: [5/5] WineD3D: Fake occlusion queries if the wrong context is active
by H. Verbeet Aug. 22, 2007

Aug. 22, 2007

On 22/08/07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Can't we wait for the other thread & context to become active? Afaik occlusion queries are allowed to block on Windows.

2 1

Changing Bugzilla settings so a single person can't confirm bugs by "popular vote"
by Kai Blin Aug. 22, 2007

Aug. 22, 2007

Hi folks, While working on bug 9405, I realized that all 20 votes on that bug were made by the reporter. I think that's pretty lame, so I've asked the bugzilla folks if there's a way to fix that. They said that the settings should be obvious when editing the product. Can we please fix that? Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

4 4

Re: advapi32: Add more tests for CryptVerifySignatureW, and correct its parameter checking
by Alexandre Julliard Aug. 22, 2007

Aug. 22, 2007

"Juan Lang" <juan.lang(a)gmail.com> writes: > From 53a45e7e2adf3b8591f2c07501e7b37538d95657 Mon Sep 17 00:00:00 2001 > From: Juan Lang <juan.lang(a)gmail.com> > Date: Tue, 21 Aug 2007 15:10:35 -0700 > Subject: [PATCH] Add more tests for CryptVerifySignatureW, and correct its parameter checking This breaks the tests: ../../../tools/runtest -q -P wine -M rsaenh.dll -T ../../.. -p rsaenh_test.exe.so rsaenh.c && touch rsaenh.ok rsaenh.c:1081: Test failed: Expected ERROR_INVALID_PARAMETER error, got 80090006 make: *** [rsaenh.ok] Error 1 Also the indentation is messed up, please fix your tab size. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: How to Calling PE Dlls on linux??
by trulyliu Aug. 22, 2007

Aug. 22, 2007

Hi, Damjan Jovanovic Thank you tired of the answer to my questions. I carefully read the wine part of the code and development document, searched in mail lists, these days. And I got some inspiration from wine plugin API wiki page and wine loader's code. I am considering of an approach. Link preloader and related resource(libwine) with my Linux native App. Do some modify with wine_init function, and call it before main(). This can be implemented by a global C++ objects's constructor. Upper two steps can deal with TEP and FS register. But I there may be another problem. If there was aready an static global C++ object in my App, How can I makde it initiatited after wine_init from in object. Do you have some other expostulate of this idea? BTW, I skim over mplayer and xine's parts of code. They don't dealwith TEB and FS register. They only do sth on LDT and allocat PE header before LoadeLibaray. Why they can run correctly??? 2007/8/22, Damjan Jovanovic <damjan.jov(a)gmail.com>: > > 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: > > > > > > > > > > > > 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 > > > > gcc -c arithmetic.c -fPIC ??? > > I am sorry. I don't have Arithmetic.dll's source code. > > Can I use LoadLibaray() and GetProcAddress > > to get the function which Arithmetic.dll exports. > > No, for the reasons I talked about before. Eg. GetProcAddress() does > look up the current directory, which resides in the TEB, which AFAIK > resides in the FS CPU register on Windows. On Linux the FS register > contains something else, leading to a crash. > > At the moment, you can only use Windows DLLs from Windows applications > or from winelibs, which are Windows applications compiled to be able > to use Linux libraries as well. > > > -- > > trulyliu(a)gmail.com > > > > Damjan > -- trulyliu(a)gmail.com

1 1

Re: [kernel32/tests] Skip some not implemented functions and add a few skip's
by Francois Gouget Aug. 22, 2007

Aug. 22, 2007

On Tue, 21 Aug 2007, Paul Vriens wrote: > Hi, > > GetTempPathW is not implemented on win9x. I did not actually read the test but it sounds like GetTempPathW() is not actually essential to the test. Could we replace it with another way to get the path for a temporary directory? Maybe even hard-code one, maybe adding the process id to make it somewhat unique? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ f u kn rd ts, ur wy 2 gky 4 ur wn gd.

2 1

Re: [1/2] wined3d: Restore a line that got lost
by Stefan Dösinger Aug. 21, 2007

Aug. 21, 2007

Am Dienstag, 21. August 2007 23:22 schrieb H. Verbeet: > This got lost by commit 92ce028a0b3aba513f8fb62d7021533896cd99f6. > > Changelog: > - Restore a line that got lost Actually I think we can remove that whole codeblock now. stateblock::apply and stateblock::capture have the needed states hardcoded now for _ALL, _VERTEX and _PIXEL stateblocks.

1 0

OS X and OpenGL
by Mike Kronenberg Aug. 21, 2007

Aug. 21, 2007

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

1 0

Re: WineD3D: fix a null pointer dereference
by Stefan Dösinger Aug. 21, 2007

Aug. 21, 2007

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.

1 0