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

New winetricks: updated fakeie6, added sha1 checksums

by Dan Kegel

Winetricks 1.27 is available for download at 1. Add sha1sums for most downloads 2. Note a few downloads are no longer available (replacements, anyone?) 3. Note mono11 is deprecated 4. Add Mikołaj's nifty fakeie changes (see http://bugs.winehq.org/show_bug.cgi?id=9036) As always, it's up at http://kegel.com/wine/winetricks Share and enjoy (TM)! - Dan (Share and Enjoy is a registered trademark of the Sirius Cybernetics Corp. See http://en.wikipedia.org/wiki/Sirius_Cybernetics_Corporation http://www.zootle.net/afda/share-and-enjoy.shtml )

Aug. 23, 2007

re: Using pthread_create within Wine

by Dan Kegel

Phil wrote: >The Wine socket implementation has problems when it comes to select. >A fix for this problem is not currently on anybody's radar. > http://www.winehq.org/pipermail/wine-devel/2006-February/044588.html Hmm. You never filed a bug at http://bugs.winehq.org for this, it seems. Could you, please? Incidentally, I ported your test app to Unix, and on Linux, it prints out THIS IS WINE. I'm not sure why you can't adapt your code to deal with the difference in select behavior -- is the problem third party code you have no source for? - Dan

Aug. 22, 2007

Re: gphoto2.ds: remove camera import UI

by Alexandre Julliard

"Dan Kegel" <dank(a)kegel.com> writes: > Would that setting be persistant? > If so, wouldn't we want a way to flip that option back later? > Winecfg is the logical place for that. It would be persistent in the registry, so regedit could be used to reset it. -- Alexandre Julliard julliard(a)winehq.org

Aug. 22, 2007

Re: Using pthread_create within Wine

by Alexandre Julliard

"Phil Lodwick" <Phil.Lodwick(a)EFI.COM> writes: > My initial test of creating two threads, one that is Win32-aware and then > synchronizing between the two of them appears to work. Does anybody know why > this might be a bad idea? It's not a bad idea, except maybe for performance reasons. As long as you don't make Win32 calls from the pthread-created thread things should work fine. A better way would be to override pthread_create to create a proper Win32 thread; we already do that for kthreads support so it shouldn't be too hard to do the same thing for pthreads. -- Alexandre Julliard julliard(a)winehq.org

Aug. 22, 2007

RE: Using pthread_create within Wine

by Phil Lodwick

> Could you please elaborate on what kind of problems you have when trying > to use the Windows version of your library under Wine? The Wine socket implementation has problems when it comes to select. A fix for this problem is not currently on anybody's radar. http://www.winehq.org/pipermail/wine-devel/2006-February/044588.html > Is there any particular reason you do not want to build a pure > Linux application that links in the Linux library, therefore > bypassing Wine entirely? The application uses libraries that are only available on Windows. > Your explanation sounds as if you do not have access to the source code > of the library, and you are therefore trying to use libraryfile.a to > link into a Wine .so file. Is this correct? If so, is the Windows > version of the library a .lib file, or a .dll file? Am I right to guess > your Linux version of the library resides in a .a file, not a .so file ? No, the Linux version is a .so. However, now that I have two threads with synchronization between them, all seems good: EXE <--> Wine DLL (Win32-aware thread) ^ | | Synchronization between threads. | v Wine DLL <--> Linux .so (pthread_create thread) Phil

Aug. 22, 2007

Re: Compositing GL

by Chris Robinson

On Wednesday 22 August 2007 12:58:18 pm Stefan Dösinger wrote: > I think for applications like css, we shouldn't activate that code at all. > css renders to a top level window, so it doesn't have any clipping > problems. The pixel format problem should be fixed in other ways, like > making it safe to recreate X11 windows, as it seems to be needed for other > things too. It would be simple to do this on WGL's end and let it render directly to a window after recreating it with the proper visual, although the actual recreation may be tricky. As it is though, it can already use the window directly if the requested format matches the visual, and it wouldn't be hard to add a Wine-specific GL extension for WineD3D to use, if present, to get the current format. > I have tested this with a few apps. Simple d3d8 and d3d7 demos work nicely, > but the mfctex and mfcfog samples crash with a GLXBadDrawable in > X_GLXMakeCurrent. A whole bunch of GLX errors will need to be ignored, especially in the case of GLXPixmaps (where the current method to resize is very crude, given the lack of a method to resize pixmaps like you can windows). I didn't get those in my testing though, so I didn't know if which needed to be ignored yet. > Wine also complains about missing > GLX_MESA_copy_sub_buffer, but it does that in both working and broken > demos. That extension is generally required for the GLXPixmap method to work, since the GLX specs say that glXSwapBuffers has no effect on them. However, both MESA and nVidia's binary drivers seem to have an effect anyway (others may also as well). Obviously we can't rely on that, but it should work as-is for (future) single-buffered modes, and I plan on attempting to use other methods and extensions to get a more reliable swap effect.

Aug. 22, 2007

Re: Compositing GL

by Stefan Dösinger

Am Mittwoch, 22. August 2007 20:57 schrieb H. Verbeet: > > This solution is the best way to go. Luckily Microsoft made similar > > changes in Vista. > > Conceptually its probably correct, but I think the speed hit is pretty > large, and it's not like we've got a lot of performance to spare. As > for the Vista comparison... Vista isn't exactly well known for it's > OpenGL performance either. What is the performance hit for something > like the CSS stress test? That should be a bit more representative > than dx9 swapchains. > > I'm certainly not saying it's not a good idea, but I do think the > performance hit shouldn't be quite as noticeable. I think for applications like css, we shouldn't activate that code at all. css renders to a top level window, so it doesn't have any clipping problems. The pixel format problem should be fixed in other ways, like making it safe to recreate X11 windows, as it seems to be needed for other things too. I have tested this with a few apps. Simple d3d8 and d3d7 demos work nicely, but the mfctex and mfcfog samples crash with a GLXBadDrawable in X_GLXMakeCurrent. Wine also complains about missing GLX_MESA_copy_sub_buffer, but it does that in both working and broken demos. I also tried the warcraft 3 map editor, it fails with the bad drawable error too, and windows media player 10. The alchemy visualization doesn't crash, but it doesn't update the screen either. But it looks very promising. The apps that work look nice now :-)

Aug. 22, 2007

Re: Using pthread_create within Wine

by Alex Villacís Lasso

Phil Lodwick escribió: > Greetings, > > > > I have a proprietary library that has both Windows and Linux ports. The > Windows DLL has problems running on Wine, so I have created a builtin version > of this DLL in Wine. This has worked fine, except for one function that > basically creates a new thread and fires back events to the calling Window > application. I believe I have traced this down to the Linux version of the > library creating the new thread with pthread_create. > > > Could you please elaborate on what kind of problems you have when trying to use the Windows version of your library under Wine? Is there any particular reason you do not want to build a pure Linux application that links in the Linux library, therefore bypassing Wine entirely? Your explanation sounds as if you do not have access to the source code of the library, and you are therefore trying to use libraryfile.a to link into a Wine .so file. Is this correct? If so, is the Windows version of the library a .lib file, or a .dll file? Am I right to guess your Linux version of the library resides in a .a file, not a .so file ? If your library is really a .lib file, then what happens if you build (under Windows) a .dll file which links in your .lib file, and then build a test program that exercises the newly created .dll file? Does it work correctly in Windows? Just to check, your library might not support being loaded as dynamic code. -- perl -e '$x=2.4;print sprintf("%.0f + %.0f = %.0f\n",$x,$x,$x+$x);'

Aug. 22, 2007

Re: Compositing GL

by Roderick Colenbrander

On Wednesday 22 August 2007 21:10, H. Verbeet wrote: > On 22/08/07, Roderick Colenbrander <thunderbird2k(a)gmx.net> wrote: > > There are two distinct cases. You have programs that use a toplevel for > > GL/D3D rendering (in general this is the case for games). Further you > > have 'windowed' programs e.g. programs that mix GL/D3D with a GDI gui. > > The use of GL Composition is limited to these 'windowed' programs. So the > > performance hit is also only limited to those programs. In my case the > > hit in the dx9 swap chains and the dx8 dolphin demo is about 1/3th but > > still there's a hit. As I said before in cpu limited cases I don't expect > > problems. > > I thought it was required in both cases to get additional pixel formats? Right now there's still only a single pixelformat. We would like to add more pixelformats but toplevel windows are the problem right now. The proper way to support more pixelformats on it is to recreate windows. Though doing this is not trivial but it must be done. Roderick

Aug. 22, 2007

Re: include: add some definitions to winioctl.h (patch)

by Mikolaj Zalewski

I've sent a fixed version. Thank you for finding it.

Aug. 22, 2007