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

Re: wordpad: Add initial printing support
by Stefan Dösinger Aug. 23, 2007

Aug. 23, 2007

Am Donnerstag, 23. August 2007 01:52 schrieb Alexander Nicolaysen Sørnes: > wordpad: Add initial printing support I usually don't read non-d3d patches, but when I saw the wordpad patches I decided to see what wordpad looks like today, and I am really impressed :-) Good work! This makes me wonder if Wine does or should register mime types for wordpad, notepad, regedit, msiexec or .bat files? We really don't have to be ashamed of our wordpad implementation, it is a nice lightweight editor for .rtf files.

2 1

Re: [PATCH try3 5/5] wininet: When sending INTERNET_STATUS_HANDLE_CLOSING make sure the freed handle is not yet available.
by Alexandre Julliard Aug. 23, 2007

Aug. 23, 2007

Misha Koshelev <mk144210(a)bcm.edu> writes: > + /* As on native when the equivalent of WININET_Release is called, the handle > + * is already invalid, but if a new handle is created at this time it does > + * not yet get assigned the freed handle number */ > if( info ) > WININET_Release( info ); > > + EnterCriticalSection( &WININET_cs ); > + > + if( WININET_dwNextHandle > handle ) > + WININET_dwNextHandle = handle; > + > + LeaveCriticalSection( &WININET_cs ); This is wrong, the handle could have been reused by then, you can't assume it is still free. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [1/5] WineD3D: Fall back to drawStridedSlow if fog coords are used
by Ivan Gyurdiev Aug. 23, 2007

Aug. 23, 2007

Stefan Dösinger wrote: > Up to now we've been lucky that all the games requireing manual fog coords > haven't used vertex buffers, thus we always went through drawStridedSlow. > Make sure that the fog also works with vertexbuffers > > As for the rejected patches from yesterday, I've moved them back to the bottom > of the queue when I fixed them, so I will resend them later. > > ------------------------------------------------------------------------ > > This patch is probably fine, but it makes me look into the surrounding code [ software blending, changing the strided data ], which is still incredibly misleading. That should go into its own function, with the FIXVBO macro removed (since all such macros are evil, without exception), and a big comment should be added that named access to the strided data is only valid in the fixed function pipeline and will not work in the shader pipeline. Maybe it makes sense to use two different structures to make this clearer - not sure.

2 1

Re: user32: static controls should have a clipping region set whilesending the WM_CTLCOLORSTATIC (with testcase, fixes bug #9195)
by Dmitry Timoshkov Aug. 23, 2007

Aug. 23, 2007

"Mikolaj Zalewski" <mikolajz(a)google.com> wrote: > Photoshop ImageReady depends on it. You have added an explicit clipping to STATIC_PaintTextfn, but since you are working on it, please test other static styles as well. Btw, if you are keen on writing a test (or making your test generic) for button control, that would help in investigating and fixing the bug 7569 which suffers from the same problem. -- Dmitry.

1 0

New winetricks: updated fakeie6, added sha1 checksums
by Dan Kegel Aug. 23, 2007

Aug. 23, 2007

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 )

1 0

re: Using pthread_create within Wine
by Dan Kegel Aug. 22, 2007

Aug. 22, 2007

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

1 0

re: gphoto2.ds: remove camera import UI
by Dan Kegel Aug. 22, 2007

Aug. 22, 2007

Lei wrote: > ... > The alternative is to keep the GUI. It is useful in the case where > there's many pictures on the camera, and the user just want to import > a few of them. We would need to: > > - modify the GUI to fix the crash > - do not automatically generate download thumbnails, but rather, > present the user with the options to download thumbnails, or just go > ahead and import all pictures > - perhaps add a winecfg option to turn off the GUI Rather than remove all that nearly-working code, how about keeping it, adding the winecfg option, and making it default to off for now? (i.e. leave fixing the bug for later.) That should be a smaller, less violent patch... - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

2 3

Using pthread_create within Wine
by Phil Lodwick Aug. 22, 2007

Aug. 22, 2007

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. Windows.exe Call_dll_to_spawn_thread_and_register_callback(MyCallbackfunc); Windows DLL implemented in wine: void * NewThread(void *p) { MyParams *params = (MyParams *)p; for (i = 0; i < 500000; i++) p->Callback(); } void Call_dll_to_spawn_thread_and_register_callback(void (*callback)()) { MyParams *params = (MyParams *)malloc(sizeof(MyParams)); params->Callback = callback; pthread_create(&MyThread, NULL, NewThread, (void *)params); } If instead of using pthread_create I use CreateThread, I never have a problem. I notice no other wine DLLs are using pthread_create and I have seen hints that this might not work. If so, how do I use the Linux library. (Call_dll_to_spawn_thread_and_register_callback is just simulating what the Linux library would do) Do I create a separate thread using CreateThread to communicate back to the Window application, so that Call_dll_to_spawn_thread_and_register_callback effectively creates two threads, one using CreateThread (Wine DLL), one using pthread_create (Linux Library) and then do synchronization between the two? Any help, suggestion, ideas, questions would be greatly appreciated. Phil

4 5

Compositing GL
by Chris Robinson Aug. 22, 2007

Aug. 22, 2007

Over the past several days, I've been working with some people in #winehackers on a way to help solve the problems Wine faces with OpenGL.. namely the lack of useable onscreen pixel formats and broken child windown rendering. Here's a patch for your perusal in hopes to generate feedback. What this does is, it renders GL to an offscreen buffer the size of the window it's rendering to, first trying a redirected window (if you have the Xcomposite extension), then falling back to GLXPixmaps (which may be slower, especially if you don't have AIGLX). The offscreen buffer is then copied to the window it should be displaying on using X, acting in a manner nearly identical to how Vista composites OpenGL (as described here: http://www.opengl.org/pipeline/article/vol003_7/ ). Given that it uses X to do the final composite, it obeys all clipping regions, which means it works even on obscured child windows. And since it's offscreen, it won't interfere with, or be bothered by, Wine's window. It also allows it to use other visuals/pixel formats than Wine's window (not done in this patch yet). There is a speed hit, however. The DX9 swap chains demo, which gets about 280 FPS for me normally, gets about 80 to 90 FPS with the compositing method. It seems to be a ceiling though, as other more GPU intense apps have no extra noticeable slow down. Still, as an optimization, it can render directly to the window when it's being used on the whole window and the selected pixel format matches the current visual (this bit is disabled in the patch since it's for testing offscreen rendering, but it's simple to re-enable). Further, a registry setting (HKCU\Software\Wine\X11 Driver\CompositeGL) can be used to force GL compositing off to give you the current behavior (single onscreen pixel format, broken child window rendering). This obviously isn't the final patch, however it's likely what the final result will be like, forgoing unforeseen issues. Questions and comments are welcome.

4 7

Re: include: add some definitions to winioctl.h (patch)
by Robert Shearman Aug. 22, 2007

Aug. 22, 2007

Mikolaj Zalewski wrote: > -#define IOCTL_STORAGE_GET_MEDIA_TYPES CTL_CODE(IOCTL_STORAGE_BASE, 0x0300, METHOD_BUFFERED, FILE_ANY_ACCESS) > -#define IOCTL_STORAGE_GET_MEDIA_TYPES_EX CTL_CODE(IOCTL_STORAGE_BASE, 0x0301, METHOD_BUFFERED, FILE_ANY_ACCESS) > +#define IOCTL_STORAGE_GET_MEDIA_TYPES CTL_CODE(IOCTL_STORAGE_BASE, 0x0300, METHOD_BUFFERED, FILE_ANY_ACCESS) > +#define IOCTL_STORAGE_GET_MEDIA_TYPES_EX CTL_CODE(IOCTL_STORAGE_BASE, 0x0301, METHOD_BUFFERED, FILE_ANY_ACCESS) > +#define IOCTL_STORAGE_GET_MEDIA_SERIAL_NUMBER CTL_CODE(IOCTL_STORAGE_BASE, 0x0305, METHOD_BUFFERED, FILE_ANY_ACCESS) > The above should be 0x0304 instead of 0x0305. > +#define IOCTL_STORAGE_GET_HOTPLUG_INFO CTL_CODE(IOCTL_STORAGE_BASE, 0x0305, METHOD_BUFFERED, FILE_ANY_ACCESS) > +#define IOCTL_STORAGE_SET_HOTPLUG_INFO CTL_CODE(IOCTL_STORAGE_BASE, 0x0306, METHOD_BUFFERED, FILE_READ_ACCESS) > -- Rob Shearman

2 1