April 2008 - Wine-devel - list.winehq.org

Can we remove the rsabase tests?
by Paul Vriens 03 Apr '08

03 Apr '08

Hi, We have only a few (3) tests in the rsabase tests. The same tests are also available in the rsaenh tests. The reason I think they can be removed: - rsaenh seems to be available most platforms. If not then also rsabase is not available (by checking test.winehq.org) - rsabase is not available on XP and above - we forward all rsabase calls to rsaenh anyway -- Cheers, Paul.

2 1

broken mails from forum
by Tomas Kuliavas 03 Apr '08

03 Apr '08

Hi, Could somebody make sure that broken MIME messages are not send to mailing list. 8bit headers are not allowed. 8bit message body needs RFC2045 headers. By default courier-mta corrupts plain rfc822 messages with 8bit message body. -- Tomas

2 1

iTunes ipod support
by Maarten Lankhorst 03 Apr '08

03 Apr '08

Hi all, I submitted the ipod patches to wine-patches. This won't add support for ipod touch or iphones. I expect that all patches will be merged soon. If anyone feels adventurous they can try it. With the amount of people interested in it I decided to post an update on the mailing list so that everyone who picked up on the earlier threads can find it. Instructions: - Apply attached patch - Get a clean wineprefix - Set wine version to vista - Download the installer from itunes.com, and install. - wine net start ipod\ service - run itunes - Hopefully the ipod is detected now. Dapper might have a bug in hald which case it won't detect any usb hard drive that's plugged in. sudo killall hald; sudo hald; wineserver -k; wine net start ipod\ service seems to work as workaround. So far there seems to be some confusion, so for the sake of clarity: This won't add support for ipod touch or iphones. Cheers, Maarten.

1 0

Make test - opengl regression
by Austin English 03 Apr '08

03 Apr '08

Running on my virtualbox feisty vm, seems make test is making some progress: austin(a)austin-desktop:~/wine-git$ cat wine-0.9.58-439-g73bd68c.txt | grep 'make.*Error' make[2]: *** [exception.ok] Error 1 make[1]: *** [ntdll/tests/__test__] Error 2 make[2]: *** [opengl.ok] Error 1 make[1]: *** [opengl32/tests/__test__] Error 2 make[2]: *** [msg.ok] Error 24 make[1]: *** [user32/tests/__test__] Error 2 make: *** [dlls/__test__] Error 2 The visual.c's are skipping properly now for me, but there's a regression in opengl/opengl.c. ../../../tools/runtest -q -P wine -M opengl32.dll -T ../../.. -p opengl32_test.exe.so opengl.c && touch opengl.ok err:wgl:X11DRV_wglCreateContext Cannot get FB Config for iPixelFormat 0, expect problems! opengl.c:248: Test failed: Unable to confirm DONTCARE behavior of unset pixelformatdescriptor flags err:wgl:X11DRV_SetPixelFormat Invalid operation on root_window opengl.c:323: Tests skipped: No suitable pixel formats found make: *** [opengl.ok] Error 1 I haven't ran a regression test yet, but if you want more logs or a regression test, let me know.

1 1

Re: [PATCH 04/10] wined3d: Add ENTER_GL/LEAVE_GL in IWineD3DSurfaceImpl_Release.
by Allan Tong 03 Apr '08

03 Apr '08

Perhaps the call to ActivateContext should be moved outside of the if block since there are other gl calls in the function. Then you could move the glDeleteRenderbuffers block before the gdi section and combine the ENTER_GL/LEAVE_GL blocks into one. - Allan

2 1

Deactivate GL_FRAGMENT_SHADER_ATI before deactivating a context
by Milan Kostić 03 Apr '08

03 Apr '08

I'm use Mesa 7.01 because that version not have this problem (I try fragshader.c test from bug #15269). Bug is introduced earler with this commit, i'm warn about it but nobody listen because i'm not offering good solution: http://gitweb.freedesktop.org/?p=mesa/mesa.git;a=commit;h=e279a0a076b7a3c8d… Also with that commit several other regressions was introduced with r200 DRI driver. Maybe they will listen someone (Stefan:)) from here.

1 0

Re: [4/7] WineD3D: Macroize CheckDeviceFormat to reduce code duplication
by Roderick Colenbrander 03 Apr '08

03 Apr '08

In the end I think something like this is nice to do but not right now. CheckDeviceFormat has changed a lot and it is in good shape now but CreateTexture and friends don't do anything with the capabilities we report. In other words the next step should be to move flags (where possible) over to the pixel format table. E.g. in case of render targets and post pixel shader blending this has been done already. It can be done for a few more. Basically the Check*Capability functions somehow be placed in utils.c and the result would be cached in the pixel format table. Both CheckDeviceFormat and CreateTexture (and friends) would be able to use the information then. The Check*Capability calls in CheckDeviceFormat would then become AND-mask checks on the Flags field of a pixel format. This can all be done in small patches. Roderick > The main idea is to avoid that we have screen-sized code sections in this > function that look exactly the same. This should make navigation in the > code > easier > > Roderick: If you do not like that, just drop a note -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser

1 0

Improving msxml3.dll as GSoC project
by Piotr Caban 03 Apr '08

03 Apr '08

Hi, I thought about improving msxml3.dll as GSoC project. There are some interfaces not implemented at all, some are not fully implemented. I found that there's quite a lot of bugs related to this dll in bugzilla. I have already sent an application. I thought about implementing SAXReader first (there are some applications that fails to install because of it, bugs 9682 and 6303). Afterwards I thought about implementing functions that are used by Photoshop installer (bug 8945, part related to msxml3.dll). I'm not really sure how long it will take but if there's enough time I'm going to fix more bugs (there are 33 bugs in bugzilla related with the dll). Afterwards I can implement more interfaces that are missing. More details can be found in the GSoC application. What do you think about the project idea? Do you have any suggestions? Regards, Piotr Caban

1 0

cygwin and -luuid build error?
by Jeroen Janssen 03 Apr '08

03 Apr '08

Hi, I don't know if building wine with cygwin is/should be supported. However, I get a linker error in dlls/atl with IID_IOleInPlaceSiteWindowless. It seems this symbol is in the uuid library. The "problem" it seems is that this library is linked with EXTRALIBS in Makefile.in and this doesn't result in the correct -L path to be set (essentially the libuuid.a can not be found by the linker). When I move -luuid from EXTRALIBS to IMPORTS, -L../../dlls/uuid is added to the linker and the library is correctly linked. Since it works ok on Linux, moving the -luuid option around is probably not a good solution, but I was wondering if anyone has looked into this before and if so what a good solution would be. Any thoughts on this? Best regards, Jeroen Janssen

2 1

Re: [4/7] WineD3D: Macroize CheckDeviceFormat to reduce code duplication
by Alexandre Julliard 03 Apr '08

03 Apr '08

Stefan Dösinger <stefan(a)codeweavers.com> writes: > The main idea is to avoid that we have screen-sized code sections in this > function that look exactly the same. This should make navigation in the code > easier It would be even better with an array of flag->function mappings and a simple loop over the flags to check. -- Alexandre Julliard julliard(a)winehq.org

1 0