Wine build failed
Hello, building current git tree fails to me on Debian Etch (x86) with: ccache gcc -c -I../../../wine-git/dlls/gdi32 -I. -I../../../wine-git/include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 -o font.o ../../../wine-git/dlls/gdi32/font.c ccache gcc -c -I../../../wine-git/dlls/gdi32 -I. -I../../../wine-git/include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 -o freetype.o ../../../wine-git/dlls/gdi32/freetype.c ../../../wine-git/dlls/gdi32/freetype.c:187: error: expected declaration specifiers or ‘...’ before ‘FT_LcdFilter’ ../../../wine-git/dlls/gdi32/freetype.c: In function ‘WineEngGetGlyphOutline’: ../../../wine-git/dlls/gdi32/freetype.c:4776: error: ‘FT_LcdFilter’ undeclared (first use in this function) ../../../wine-git/dlls/gdi32/freetype.c:4776: error: (Each undeclared identifier is reported only once ../../../wine-git/dlls/gdi32/freetype.c:4776: error: for each function it appears in.) ../../../wine-git/dlls/gdi32/freetype.c:4776: error: expected ‘;’ before ‘lcdfilter’ ../../../wine-git/dlls/gdi32/freetype.c:4777: warning: ISO C90 forbids mixed declarations and code ../../../wine-git/dlls/gdi32/freetype.c:4785: error: ‘lcdfilter’ undeclared (first use in this function) ../../../wine-git/dlls/gdi32/freetype.c:4785: error: too many arguments to function ‘pFT_Library_SetLcdFilter’ ../../../wine-git/dlls/gdi32/freetype.c:4803: error: ‘FT_LCD_FILTER_DEFAULT’ undeclared (first use in this function) ../../../wine-git/dlls/gdi32/freetype.c:4803: error: ‘FT_LCD_FILTER_LIGHT’ undeclared (first use in this function) ../../../wine-git/dlls/gdi32/freetype.c: In function ‘is_subpixel_rendering_enabled’: ../../../wine-git/dlls/gdi32/freetype.c:5923: error: too many arguments to function ‘pFT_Library_SetLcdFilter’ make[2]: *** [freetype.o] Fehler 1 make[2]: Leaving directory `/usr/src/wine/wine-build/dlls/gdi32' make[1]: *** [gdi32] Fehler 2 make[1]: Leaving directory `/usr/src/wine/wine-build/dlls' make: *** [dlls] Fehler 2 ccache gcc -c -I../../../wine-git/dlls/gdi32 -I. -I../../../wine-git/include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 -o font.o ../../../wine-git/dlls/gdi32/font.c ccache gcc -c -I../../../wine-git/dlls/gdi32 -I. -I../../../wine-git/include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 -o freetype.o ../../../wine-git/dlls/gdi32/freetype.c ../../../wine-git/dlls/gdi32/freetype.c:187: error: expected declaration specifiers or â...â before âFT_LcdFilterâ ../../../wine-git/dlls/gdi32/freetype.c: In function âWineEngGetGlyphOutlineâ: ../../../wine-git/dlls/gdi32/freetype.c:4776: error: âFT_LcdFilterâ undeclared (first use in this function) ../../../wine-git/dlls/gdi32/freetype.c:4776: error: (Each undeclared identifier is reported only once ../../../wine-git/dlls/gdi32/freetype.c:4776: error: for each function it appears in.) ../../../wine-git/dlls/gdi32/freetype.c:4776: error: expected â;â before âlcdfilterâ ../../../wine-git/dlls/gdi32/freetype.c:4777: warning: ISO C90 forbids mixed declarations and code ../../../wine-git/dlls/gdi32/freetype.c:4785: error: âlcdfilterâ undeclared (first use in this function) ../../../wine-git/dlls/gdi32/freetype.c:4785: error: too many arguments to function âpFT_Library_SetLcdFilterâ ../../../wine-git/dlls/gdi32/freetype.c:4803: error: âFT_LCD_FILTER_DEFAULTâ undeclared (first use in this function) ../../../wine-git/dlls/gdi32/freetype.c:4803: error: âFT_LCD_FILTER_LIGHTâ undeclared (first use in this function) ../../../wine-git/dlls/gdi32/freetype.c: In function âis_subpixel_rendering_enabledâ: ../../../wine-git/dlls/gdi32/freetype.c:5923: error: too many arguments to function âpFT_Library_SetLcdFilterâ make[2]: *** [freetype.o] Fehler 1 make[2]: Leaving directory `/usr/src/wine/wine-build/dlls/gdi32' make[1]: *** [gdi32] Fehler 2 make[1]: Leaving directory `/usr/src/wine/wine-build/dlls' make: *** [dlls] Fehler 2
d3d9/visual tests timed out
Hi, on my XP machine the visual d3d9 test produces a timeout message, when it is started from the winetest build. Anyone here could run the tests on windows without a timeout (and off course without skipping half of the tests - have to be more than 4k tests)? Also there is no message about a timeout on the test site ( http://test.winehq.org/data/028617b90ba586bdb30723c700eea888c159ada7/xp_rs-xp/d3d9:visual.html ). Cheers Rico
Re: Wine build failed
Stefan Leichter wrote: Hello, building current git tree fails to me on Debian Etch (x86) with: ccache gcc -c -I../../../wine-git/dlls/gdi32 -I. -I../../../wine-git/include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 -o font.o ../../../wine-git/dlls/gdi32/font.c ccache gcc -c -I../../../wine-git/dlls/gdi32 -I. -I../../../wine-git/include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 -o freetype.o ../../../wine-git/dlls/gdi32/freetype.c ../../../wine-git/dlls/gdi32/freetype.c:187: error: expected declaration specifiers or ‘...’ before ‘FT_LcdFilter’ ../../../wine-git/dlls/gdi32/freetype.c: In function ‘WineEngGetGlyphOutline’: ../../../wine-git/dlls/gdi32/freetype.c:4776: error: ‘FT_LcdFilter’ undeclared (first use in this function) ../../../wine-git/dlls/gdi32/freetype.c:4776: error: (Each undeclared identifier is reported only once ../../../wine-git/dlls/gdi32/freetype.c:4776: error: for each function it appears in.) ../../../wine-git/dlls/gdi32/freetype.c:4776: error: expected ‘;’ before ‘lcdfilter’ ../../../wine-git/dlls/gdi32/freetype.c:4777: warning: ISO C90 forbids mixed declarations and code ../../../wine-git/dlls/gdi32/freetype.c:4785: error: ‘lcdfilter’ undeclared (first use in this function) ../../../wine-git/dlls/gdi32/freetype.c:4785: error: too many arguments to function ‘pFT_Library_SetLcdFilter’ ../../../wine-git/dlls/gdi32/freetype.c:4803: error: ‘FT_LCD_FILTER_DEFAULT’ undeclared (first use in this function) ../../../wine-git/dlls/gdi32/freetype.c:4803: error: ‘FT_LCD_FILTER_LIGHT’ undeclared (first use in this function) ../../../wine-git/dlls/gdi32/freetype.c: In function ‘is_subpixel_rendering_enabled’: ../../../wine-git/dlls/gdi32/freetype.c:5923: error: too many arguments to function ‘pFT_Library_SetLcdFilter’ make[2]: *** [freetype.o] Fehler 1 make[2]: Leaving directory `/usr/src/wine/wine-build/dlls/gdi32' make[1]: *** [gdi32] Fehler 2 make[1]: Leaving directory `/usr/src/wine/wine-build/dlls' make: *** [dlls] Fehler 2 You need update freetype2 package. Version 2.3.7-2 from Sid builds without any problems.
Re: Wine build failed
Stefan Leichter sle85...@gmx.de wrote: building current git tree fails to me on Debian Etch (x86) with: ccache gcc -c -I../../../wine-git/dlls/gdi32 -I. -I../../../wine-git/include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 -o font.o ../../../wine-git/dlls/gdi32/font.c ccache gcc -c -I../../../wine-git/dlls/gdi32 -I. -I../../../wine-git/include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 -o freetype.o ../../../wine-git/dlls/gdi32/freetype.c ../../../wine-git/dlls/gdi32/freetype.c:187: error: expected declaration specifiers or ‘...’ before ‘FT_LcdFilter’ Remove a broken patch from your sources, that's not a current git tree. -- Dmitry.
Re: Wine build failed
Dmitry Timoshkov dmi...@codeweavers.com wrote: building current git tree fails to me on Debian Etch (x86) with: ccache gcc -c -I../../../wine-git/dlls/gdi32 -I. -I../../../wine-git/include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 -o font.o ../../../wine-git/dlls/gdi32/font.c ccache gcc -c -I../../../wine-git/dlls/gdi32 -I. -I../../../wine-git/include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 -o freetype.o ../../../wine-git/dlls/gdi32/freetype.c ../../../wine-git/dlls/gdi32/freetype.c:187: error: expected declaration specifiers or ‘...’ before ‘FT_LcdFilter’ Remove a broken patch from your sources, that's not a current git tree. I'm sorry, that patch is really in current git. -- Dmitry.
Re: d3d9/visual tests timed out
On Tue, Dec 23, 2008 at 9:57 PM, Rico Schüller kgbric...@web.de wrote: Hi, on my XP machine the visual d3d9 test produces a timeout message, when it is started from the winetest build. Anyone here could run the tests on windows without a timeout (and off course without skipping half of the tests - have to be more than 4k tests)? Also there is no message about a timeout on the test site ( http://test.winehq.org/data/028617b90ba586bdb30723c700eea888c159ada7/xp_rs-xp/d3d9:visual.html ). Cheers Rico While it's true that it takes some time and says it timed out while running and will attempt to terminate it when you hit OK, I think this dialog appears while the test is still running you don't notice it until after it successfully finishes and exits, so the attempt to terminate does nothing. I have seen this happen on Windows 2008 with GeForce 8 (180.42) and Windows 98 with GeForce 5. -Jeff
DIB Engine
As my DIB engine is becoming usable (I already use it on Autocad for my job), I'm thinking to publish the patches. As it's still not complete, I'm thinking to add a way to enable it on demand with registry and environment variable : export WINEDIB=ON activates it export WINEDIB=OFF deactivates it if no environment variable, it checks a registry key (I'd like to have some suggestion on where to put it). If no environment variable nor registry entry are present it'll be disabled (by now) as is for testing purposes. How should I publish it ? A big unique patch, 2 patches, one with the (small) changes in gdi32 and another big one with the engine itself, or many small patches ? Is it right to put on wine patches list ? Ciao Max
Re: DIB Engine
As my DIB engine is becoming usable (I already use it on Autocad for my job), I'm thinking to publish the patches. As it's still not complete, I'm thinking to add a way to enable it on demand with registry and environment variable : export WINEDIB=ON activates it export WINEDIB=OFF deactivates it if no environment variable, it checks a registry key (I'd like to have some suggestion on where to put it). If no environment variable nor registry entry are present it'll be disabled (by now) as is for testing purposes. How should I publish it ? A big unique patch, 2 patches, one with the (small) changes in gdi32 and another big one with the engine itself, or many small patches ? Is it right to put on wine patches list ? Ciao Max I would say a registry key is fine to turn it on/off but this is a minor detail. The most important thing is that the architecture is 100% correct. Implementing drawing functions in software isn't that hard but getting the design right is very, very hard. I would suggest to post a big patch for review or so. Not to discourage you but I fear that the design might still not be good. Roderick -- Sensationsangebot verlängert: GMX FreeDSL - Telefonanschluss + DSL für nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K1308T4569a
Re: DIB Engine
Roderick Colenbrander ha scritto: As my DIB engine is becoming usable (I already use it on Autocad for my job), I'm thinking to publish the patches. As it's still not complete, I'm thinking to add a way to enable it on demand with registry and environment variable : export WINEDIB=ON activates it export WINEDIB=OFF deactivates it if no environment variable, it checks a registry key (I'd like to have some suggestion on where to put it). If no environment variable nor registry entry are present it'll be disabled (by now) as is for testing purposes. How should I publish it ? A big unique patch, 2 patches, one with the (small) changes in gdi32 and another big one with the engine itself, or many small patches ? Is it right to put on wine patches list ? Ciao Max I would say a registry key is fine to turn it on/off but this is a minor detail. The most important thing is that the architecture is 100% correct. Implementing drawing functions in software isn't that hard but getting the design right is very, very hard. I would suggest to post a big patch for review or so. Not to discourage you but I fear that the design might still not be good. Roderick Thanx for the answer. I'll polish a bit the code and publish a big patch here. BTW, I followed Jesse Allen's and Huw Davies way, as I was told it should be the right one... Ciao Max
Fwd: Linking to a Mac OS X build of Wine from winehq.org/download ?
Begin forwarded message: From: Austin English austinengl...@gmail.com Date: December 22, 2008 6:12:13 PM EST To: Zach Drayer z...@drayer.name Subject: Re: Linking to a Mac OS X build of Wine from winehq.org/ download ? On Mon, Dec 22, 2008 at 5:06 PM, Zach Drayer z...@drayer.name wrote: On Dec 22, 2008, at 10:25 AM, Austin English wrote: It currently has a few 'OS X-isms'. The patch that causes 100% cpu usage on SSL sites in IE6 is reverted, as well as a few x11 hacks. The other main problem is fonts. I think we need to fix the X11 hacks needed before doing considering it 'official' wine. We don't want a flood of bug reports for that problem. The big problem is that OS X's X11 still ships with libGL 1.2 while, iirc, wine requires libGL 1.3. I *believe* (but dont quote me on this) that Mike patches wine to remove this check. What I would like to see is the changes made by Zach and Mike incorporated back into the main Wine code. I don't make any changes to wine; I just build bland wine and stick it in a .bundle application. On Dec 22, 2008, at 10:39 AM, James Mckenzie wrote: Both Mike and Zach have approached building Wine releases in the two structures supported by Apple: Drag and Drop where you grab a pre- built Application object and move it into the Applications folder and the use of the Apple installer with an installable 'package' much like the use of apt or yum. There is great debate as to which is the best approach and, basing this on the struggle within and outside of the OpenOffice.org/ NeoOffice.org MacOSX porting projects, I would like to avoid this problem as best we can. Firefox and Thunderbird use the first approach, but many projects use the latter. Mike's builds work with drag and drop because he builds all the libraries that Darwine requires and sticks them in the bundle. The builds that I create rely on system libraries whenever possible. The reason my builds have an installer is because the system doesn't come with versions of FreeType or FontForge that are reasonably up to date. One notable difference here is that since Mike puts all his builds into the bundle, It has more compatibility (his versions support Tiger and Leopard, mine only works on Leopard). However, it comes at the cost of some features working (iirc, libcups works with my builds, but not his). -Zach I think you meant to send this to wine-devel as well. Yup, sorry about that. Was about to forward it to the right place when i your email.
Re: DIB Engine
On Tue, 23 Dec 2008 11:44:39 +0100 Massimo Del Fedele m...@veneto.com wrote: How should I publish it ? http://repo.or.cz/w/wine.git?a=forks
Re: winecfg: Disable nonfunctional advanced drive settings
On Tue, Dec 23, 2008 at 4:04 AM, M.Kiesel wine-de...@continuity.cjb.net wrote: On Tue, 23 Dec 2008, Austin English wrote: In the winecfg drive tab, advanced drive settings (setting label and serial) seem to be broken currently due to other Wine bugs (see drive.c apply_drive_changes comments). Disable these settings for now since this only confuses users. [...] Rather than disable it and cause more confusion when it does work, focus on fixing the actual bug instead. Sorry, impossible for me. Sure fixing the underlying bug would be nice but I'm far from experienced enough with the Wine code for doing this (if this changes in future I'll happily revert that patch). I think fixing winecfg to show only options that actually do something is something worth doing though for the time being, especially for Wine users. Also, for PR it's not too good that of the few options winecfg actually offers several are just plain broken. The option used to work, but was broken (some ntdll changes IIRC). -- -Austin
Re: DIB Engine
On Tue, Dec 23, 2008 at 10:44 AM, Massimo Del Fedele m...@veneto.com wrote:
As my DIB engine is becoming usable (I already use it on Autocad for my
job), I'm thinking to publish the patches.
As it's still not complete, I'm thinking to add a way to enable it on
demand with registry and environment variable :
export WINEDIB=ON activates it
export WINEDIB=OFF deactivates it
if no environment variable, it checks a registry key (I'd like to have
some suggestion on where to put it).
Go for something similar to our other registry keys:
http://wiki.winehq.org/UsefulRegistryKeys
Maybe HKCU\Software\Wine\X11 Driver\DIB Engine {Y/N}
?
--
-Austin
RE: Valgrind warning in wined3d/swapchain.c in IWineD3DSwapChainImpl_Destroy
Hi, I'm doing an mail purge and stumbled across this mail. Can you try the attached patch? -Original Message- From: daniel.r.ke...@gmail.com [mailto:daniel.r.ke...@gmail.com] On Behalf Of Dan Kegel Sent: Saturday, November 15, 2008 5:30 AM To: Wine Devel Cc: Stefan Dösinger Subject: Valgrind warning in wined3d/swapchain.c in IWineD3DSwapChainImpl_Destroy Hi Stefan, you seem to have been in this code recently, could you have a look? This is a somewhat flaky error that happens about 80% of the time under heavy load on my quad core box. (This is valgrind's xml output format, it's pretty fluffy, sorry.) Thanks, Dan error kindUninitCondition/kind whatConditional jump or move depends on uninitialised value(s)/what stack frame objdlls/wined3d/wined3d.dll.so/obj fnIWineD3DSwapChainImpl_Destroy/fn dirdlls/wined3d/dir fileswapchain.c/file line75/line /frame frame objdlls/d3d9/d3d9.dll.so/obj fnIDirect3DSwapChain9Impl_Release/fn dirdlls/d3d9/dir fileswapchain.c/file line66/line /frame frame objdlls/d3d9/d3d9.dll.so/obj fnD3D9CB_DestroySwapChain/fn dirdlls/d3d9/dir filedirectx.c/file line427/line /frame frame objdlls/wined3d/wined3d.dll.so/obj fnIWineD3DDeviceImpl_Uninit3D/fn dirdlls/wined3d/dir filedevice.c/file line2426/line /frame frame objdlls/d3d9/d3d9.dll.so/obj fnIDirect3DDevice9Impl_Release/fn dirdlls/d3d9/dir filedevice.c/file line98/line /frame frame objdlls/d3d9/tests/d3d9_test.exe.so/obj fnfunc_visual/fn dirdlls/d3d9/tests/dir filevisual.c/file line9960/line /frame frame objdlls/d3d9/tests/d3d9_test.exe.so/obj fnrun_test/fn dirdlls/d3d9/tests/../../../include/wine/dir filetest.h/file line452/line /frame frame objdlls/d3d9/tests/d3d9_test.exe.so/obj fnmain/fn dirdlls/d3d9/tests/../../../include/wine/dir filetest.h/file line502/line /frame /stack /error From 2d553d968be386deacd9998214776e8aa57c98a2 Mon Sep 17 00:00:00 2001 From: Stefan Doesinger ste...@codeweavers.com Date: Mon, 22 Dec 2008 19:31:49 +0100 Subject: [PATCH] d3d9: Properly set AutoRestoreDisplayMode It is set in CreateDevice, but WineD3D passes it back to d3d9 in the CreateAdditionalSwapChain callback, which converts the wined3d structure back to the d3d9 one and the value gets lost. Spotted by valgrind. --- dlls/d3d9/swapchain.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/dlls/d3d9/swapchain.c b/dlls/d3d9/swapchain.c index eabe366..9f86bea 100644 --- a/dlls/d3d9/swapchain.c +++ b/dlls/d3d9/swapchain.c @@ -227,6 +227,7 @@ HRESULT WINAPI IDirect3DDevice9Impl_CreateAdditionalSwapChain(LPDIRECT3DDEVICE localParameters.Flags = pPresentationParameters-Flags; localParameters.FullScreen_RefreshRateInHz = pPresentationParameters-FullScreen_RefreshRateInHz; localParameters.PresentationInterval= pPresentationParameters-PresentationInterval; +localParameters.AutoRestoreDisplayMode = TRUE; EnterCriticalSection(d3d9_cs); hrc = IWineD3DDevice_CreateSwapChain(This-WineD3DDevice, localParameters, object-wineD3DSwapChain, (IUnknown*)object, D3D9CB_CreateRenderTarget, D3D9CB_CreateDepthStencilSurface, SURFACE_OPENGL); -- 1.5.6.4
RE: d3d9/tests: Don't create a Null-shader in d3d9, it will crash.
I never saw this crashing on any of my systems, so it is probably driver dependent. Which Windows driver are you using? If the test crashes on either ATI, Nvidia or Intel it is a good idea to remove it. I don't think we should remove it if it crashes on something like VMWare or other 'noname' cards.
RE: [PATCH] Fix glReadPixels call from read_from_framebuffer (re-redux)
This patch looks good. There's one last thing we should check: It seems that this is the only code that uses GL_PACK_ROW_LENGTH and friends, so the backup and restore is probably not needed. I think for now it is better to add it because I suspect the code in surface_download_data most likely depends on the default settings without properly controlling them. There's some related driver bug on OSX too(no radar filed yet, unfortunately). Using a PBO for glDrawPixels with a negative pixelzoom(wine uses -1 for y) breaks at least on my radeon X1600 with MacOS 10.5.5. I haven't yet tested it with 10.5.6, but if it is still broken there I have to remember to file a bug. It is sort of a follow-up bug to a bug fixed in 10.5.5; Before that glPixelZoom and PixelPos were completely ignored with PBOs. This bug was on my todo list for a long time by the way. I wanted to fix it, got distracted and forgot again :-/
Re: d3d9/tests: Don't create a Null-shader in d3d9, it will crash.
2008/12/23 Stefan Dösinger ste...@codeweavers.com: I never saw this crashing on any of my systems, so it is probably driver dependent. Which Windows driver are you using? If the test crashes on either ATI, Nvidia or Intel it is a good idea to remove it. I don't think we should remove it if it crashes on something like VMWare or other 'noname' cards. The patch is already applied, but I think removing the test is the right thing to do. I only added the test to test what error d3d9 returns when a NULL shader is passed. If it depends on the driver, I doubt we care.
Re: DIB Engine
Austin English ha scritto:
On Tue, Dec 23, 2008 at 10:44 AM, Massimo Del Fedele m...@veneto.com wrote:
As my DIB engine is becoming usable (I already use it on Autocad for my
job), I'm thinking to publish the patches.
As it's still not complete, I'm thinking to add a way to enable it on
demand with registry and environment variable :
export WINEDIB=ON activates it
export WINEDIB=OFF deactivates it
if no environment variable, it checks a registry key (I'd like to have
some suggestion on where to put it).
Go for something similar to our other registry keys:
http://wiki.winehq.org/UsefulRegistryKeys
Maybe HKCU\Software\Wine\X11 Driver\DIB Engine {Y/N}
?
That one seems perfect, thanx !
I think I'll add also an environment variable, so we can switch on or
off the engine on the fly.
Ciao
Max
RE: d3d9: Set IDirect3DDevice9Impl_GetVertexShader return value to NULL on error
Hi, Please write a test for this. This behavior differs from function to function unfortunately. Some functions do not set the value to NULL, and some apps depend on this. I think dlls/d3d9/tests/shader.c is a good place to put this test. -Original Message- From: wine-patches-boun...@winehq.org [mailto:wine-patches- boun...@winehq.org] On Behalf Of Vincent Pelletier Sent: Monday, December 22, 2008 11:25 PM To: wine-patches Subject: d3d9: Set IDirect3DDevice9Impl_GetVertexShader return value to NULL on error When IWineD3DDevice_GetVertexShader fails, set *ppShader to NULL. This fixes Black White 2 here: it used to crash right when first level intro video ended, before seeing the level. With this patch I can play a bit (though there are some graphical glitches remaining, mouse it not so smooth...) -- Vincent Pelletier
Re: d3d9: Set IDirect3DDevice9Impl_GetVertexShader return value to NULL on error
2008/12/23 Stefan Dösinger ste...@codeweavers.com: Hi, Please write a test for this. This behavior differs from function to function unfortunately. Some functions do not set the value to NULL, and some apps depend on this. I think dlls/d3d9/tests/shader.c is a good place to put this test. No, this patch is obviously correct.
RE: d3d9/tests: Don't create a Null-shader in d3d9, it will crash.
The patch is already applied, but I think removing the test is the right thing to do. I only added the test to test what error d3d9 returns when a NULL shader is passed. If it depends on the driver, I doubt we care. This patch was a good idea, yes I'm only afraid of this hypothetical scenario: 1) We remove a test because it breaks on $NONSTANDARDWINDRV 2) $BUGGYGAME depends on the tested behavior, and is broken on above driver on Windows too 3) Some future patch changes this behavior 4) The test doesn't warn us because it was removed 5) $BUGGYGAME is now broken on Wine ???) The test removed in (1) is added again because $BUGGYGAME depends on it and the developer who fixes the regression doesn't know about $NONSTANDARDWINDRV IMHO it is better to use broken() wherever possible, although with a crash that is hard to do.
RE: d3d9: Set IDirect3DDevice9Impl_GetVertexShader return value to NULL on error
No, this patch is obviously correct. Hmm right, the code treats pShader == NULL as 'failure'. Looking at the WineD3D code, it would only fail if ppShader == NULL, which would moot the point of setting *ppShader to NULL anyway. My bad in this case
RE: d3d9/tests: Don't create a Null-shader in d3d9, it will crash.
On Di, 2008-12-23 at 14:24 +0100, Stefan Dösinger wrote:
I'm only afraid of this hypothetical scenario:
1) We remove a test because it breaks on $NONSTANDARDWINDRV
We disable the test with:
if (0) {
/* that crash on $NONSTANDARDWINDRV */
full test here
}
3) Some future patch changes this behavior
4) The test doesn't warn us because it was removed
Of course, the disabled test does not protect us from the scenario
above,
but the test is still available for documentation.
IMHO it is better to use broken() wherever possible, although with a crash
that is hard to do.
using broken() on a crashing test will not prevent the crash
--
By by ... Detlef
Re: MSVCP80 implementation
On Mon, Dec 22, 2008 at 10:31 PM, Dmitry Timoshkov dmi...@codeweavers.com wrote: MSVCP80 is not a part of win32 API, that's a redistributable run-time library supposed to be provided by an application. Does the EULA allow for it to be packaged for use on non-windows systems? If not then thats not an option for Winelib developers. -- Steven Edwards There is one thing stronger than all the armies in the world, and that is an idea whose time has come. - Victor Hugo
Re: MSVCP80 implementation
On Tuesday 23 December 2008 16:22:52 Steven Edwards wrote: On Mon, Dec 22, 2008 at 10:31 PM, Dmitry Timoshkov dmi...@codeweavers.com wrote: MSVCP80 is not a part of win32 API, that's a redistributable run-time library supposed to be provided by an application. Does the EULA allow for it to be packaged for use on non-windows systems? If not then thats not an option for Winelib developers. Winelib developers have the option not to use Visual C++ runtimes at all. If they need to access DLLs or executables installed by some other application then the other program should install MSV*80.DLL itself or the runtimes can be installed if missing just like you would do on Windows. The *other* application needs them and is legal to redistribute them being targeted at the Windows environment. Paul Chitescu
Re: d3d9/tests: Don't create a Null-shader in d3d9, it will crash.
Stefan Dösinger schrieb: I never saw this crashing on any of my systems, so it is probably driver dependent. Which Windows driver are you using? If the test crashes on either ATI, Nvidia or Intel it is a good idea to remove it. I don't think we should remove it if it crashes on something like VMWare or other 'noname' cards. I checked this on 4 different machines with the following cards all on XP - Ati 9700M - Geforce 5700FX - Geforce 8800GTS - Geforce 8800GT Just check the test page to see the d3d9 shader test crashes on all machines which didn't skip the complete test! ( http://test.winehq.org/data/0b3b6e67ea663e853cc6bb93f4da447ab934e50d/#group_XP ) Cheers Rico
Re: DIB Engine
On Tue, Dec 23, 2008 at 3:44 AM, Massimo Del Fedele m...@veneto.com wrote: As my DIB engine is becoming usable (I already use it on Autocad for my job), I'm thinking to publish the patches. As it's still not complete, I'm thinking to add a way to enable it on demand with registry and environment variable : export WINEDIB=ON activates it export WINEDIB=OFF deactivates it if no environment variable, it checks a registry key (I'd like to have some suggestion on where to put it). If no environment variable nor registry entry are present it'll be disabled (by now) as is for testing purposes. A reg key is a good idea with it off by default. The other thing I did was if a packager didn't want to include it then it automatically fell back to winex11 for DIBs to run like before. How should I publish it ? A big unique patch, 2 patches, one with the (small) changes in gdi32 and another big one with the engine itself, or many small patches ? Is it right to put on wine patches list ? My intention to proposing patches would have been in this order. 1. The gdi changes to allow the engine to work. 2. The skeleton of the dib driver. 3. A patch per function with test cases proving the functionality. But my recommendation for your current work is to make one big patch for review so I and others can just give you immediate feedback. We can split it up or put up a git fork later. Jesse
Re: d3d9/visual tests timed out
Jeff Zaroyko wrote: On Tue, Dec 23, 2008 at 9:57 PM, Rico Schüller kgbric...@web.de wrote: Hi, on my XP machine the visual d3d9 test produces a timeout message, when it is started from the winetest build. Anyone here could run the tests on windows without a timeout (and off course without skipping half of the tests - have to be more than 4k tests)? Also there is no message about a timeout on the test site ( http://test.winehq.org/data/028617b90ba586bdb30723c700eea888c159ada7/xp_rs-xp/d3d9:visual.html ). Cheers Rico While it's true that it takes some time and says it timed out while running and will attempt to terminate it when you hit OK, I think this dialog appears while the test is still running you don't notice it until after it successfully finishes and exits, so the attempt to terminate does nothing. I have seen this happen on Windows 2008 with GeForce 8 (180.42) and Windows 98 with GeForce 5. My Atom based netbook with i915 graphics on F10 hits the timeout too. It's a minor nuisance as I have to hit the OK button even though the test will finish just fine. bye michael
[RFC] wined3d: Avoid triggering OPENGL errors when setting point size
(Resent, originally sent to -patches... Sorry)
If WINED3DRS_POINTSCALEENABLE is false and WINED3DRS_POINTSIZE render state is
set to an invalid size, glPointSize will fail.
This happens in Black White 2, causing log/stderr to be flooded with
opengl errors.
I'm not sure if this should be fixed here, or when setting state value.
Also, maybe it should be avoided to double-check against opengl bounds when
WINED3DRS_POINTSCALEENABLE is true.
I would be happy to get some feedback on that patch.
--
Vincent Pelletier
diff --git a/dlls/wined3d/state.c b/dlls/wined3d/state.c
index e4c819d..c494f56 100644
--- a/dlls/wined3d/state.c
+++ b/dlls/wined3d/state.c
@@ -1495,8 +1495,10 @@ static void state_pscale(DWORD state, IWineD3DStateBlockImpl *stateblock, WineD3
WARN(POINT_PARAMETERS not supported in this version of opengl\n);
}
-glPointSize(pointSize.f);
-checkGLcall(glPointSize(...););
+if (pointSize.f GL_LIMITS(pointsize) GL_LIMITS(pointsizemin) pointSize.f) {
+glPointSize(pointSize.f);
+checkGLcall(glPointSize(...););
+}
}
static void state_colorwrite(DWORD state, IWineD3DStateBlockImpl *stateblock, WineD3DContext *context) {
Re: d3d9/visual tests timed out
Michael Stefaniuc schrieb: Jeff Zaroyko wrote: On Tue, Dec 23, 2008 at 9:57 PM, Rico Schüller kgbric...@web.de wrote: Hi, on my XP machine the visual d3d9 test produces a timeout message, when it is started from the winetest build. Anyone here could run the tests on windows without a timeout (and off course without skipping half of the tests - have to be more than 4k tests)? Also there is no message about a timeout on the test site ( http://test.winehq.org/data/028617b90ba586bdb30723c700eea888c159ada7/xp_rs-xp/d3d9:visual.html ). Cheers Rico While it's true that it takes some time and says it timed out while running and will attempt to terminate it when you hit OK, I think this dialog appears while the test is still running you don't notice it until after it successfully finishes and exits, so the attempt to terminate does nothing. I have seen this happen on Windows 2008 with GeForce 8 (180.42) and Windows 98 with GeForce 5. My Atom based netbook with i915 graphics on F10 hits the timeout too. It's a minor nuisance as I have to hit the OK button even though the test will finish just fine. bye michael Thanks for the answers, so nothing to worry about, it's just a little bit annoying. Cheers Rico
Re: bugfix: resend: fix serial_flush
Wolfgang Walter w...@stwm.de writes: Would it be acceptable to call tcdrain directly in NtFlushBuffersFile: Yes, something like that. -- Alexandre Julliard julli...@winehq.org
Re: how to create a broken .tlb file
Michael Karcher w...@mkarcher.dialup.fu-berlin.de writes: a) Include a broken (hand-patched) tlb file as binary file in git b) Include a program that breaks tlb files and call it while building tests c) Include tlb file patching into the testcase (i.e. copy a good tlb, patch it, and perform some tests with the copy, than delete it) Which approach would have the highest chance of getting the fix (including the testcase that tests broken type libraries) included into Wine? c) is the way to go. -- Alexandre Julliard julli...@winehq.org
Symlink vulnerability in winetricks
Hi! Winetricks has a symlink vulnerability, it does (echo $title; echo ; echo $text) /tmp/x_showmenu.txt An attacker can exploit this by creating a symlink called /tmp/x_showmenu.txt and have it point to some file that a winetricks user can write (e.g. ~/Documents/important_stuff.odf). Winetricks will then overwrite that file with its data. To solve this, apply the following patch that simply avoids the creation of a temporary file: --- winetricks 2008-12-18 06:34:42.0 +0100 +++ winetricks 2008-12-23 18:00:17.0 +0100 @@ -207,8 +207,8 @@ args=$args,$1 shift done -(echo $title; echo ; echo $text) /tmp/x_showmenu.txt -xmessage -print -file /tmp/x_showmenu.txt -buttons Cancel,$args | sed 's/Cancel//' +(echo $title; echo ; echo $text) | \ +xmessage -print -file - -buttons Cancel,$args | sed 's/Cancel//' } showmenu() Merry Christmas Stefan
RE: [PATCH] Fix glReadPixels call from read_from_framebuffer (re-redux)
Thanks for reviewing my patch (it sure makes the SHOGO menu much nicer) BTW do you know if I need to resubmit my other SHOGO patch ([PATCH] Fix ddraw surface version setting)? Concerning negative pixelzoom and drawpixels on R500 Please file a radar on that (and email the mac-opengl mailing list) - Nick From: ste...@codeweavers.com To: wine-devel@winehq.org Subject: RE: [PATCH] Fix glReadPixels call from read_from_framebuffer (re-redux) Date: Tue, 23 Dec 2008 13:30:40 +0100 This patch looks good. There's one last thing we should check: It seems that this is the only code that uses GL_PACK_ROW_LENGTH and friends, so the backup and restore is probably not needed. I think for now it is better to add it because I suspect the code in surface_download_data most likely depends on the default settings without properly controlling them. There's some related driver bug on OSX too(no radar filed yet, unfortunately). Using a PBO for glDrawPixels with a negative pixelzoom(wine uses -1 for y) breaks at least on my radeon X1600 with MacOS 10.5.5. I haven't yet tested it with 10.5.6, but if it is still broken there I have to remember to file a bug. It is sort of a follow-up bug to a bug fixed in 10.5.5; Before that glPixelZoom and PixelPos were completely ignored with PBOs. This bug was on my todo list for a long time by the way. I wanted to fix it, got distracted and forgot again :-/
Re: Wine build failed
On Tue, Dec 23, 2008 at 3:43 AM, Stefan Leichter sle85...@gmx.de wrote: Hello, building current git tree fails to me on Debian Etch (x86) with: ccache gcc -c -I../../../wine-git/dlls/gdi32 -I. -I../../../wine-git/include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 -o font.o ../../../wine-git/dlls/gdi32/font.c ccache gcc -c -I../../../wine-git/dlls/gdi32 -I. -I../../../wine-git/include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 -o freetype.o ../../../wine-git/dlls/gdi32/freetype.c ../../../wine-git/dlls/gdi32/freetype.c:187: error: expected declaration specifiers or '...' before 'FT_LcdFilter' ../../../wine-git/dlls/gdi32/freetype.c: In function 'WineEngGetGlyphOutline': ../../../wine-git/dlls/gdi32/freetype.c:4776: error: 'FT_LcdFilter' undeclared (first use in this function) ../../../wine-git/dlls/gdi32/freetype.c:4776: error: (Each undeclared identifier is reported only once ../../../wine-git/dlls/gdi32/freetype.c:4776: error: for each function it appears in.) ../../../wine-git/dlls/gdi32/freetype.c:4776: error: expected ';' before 'lcdfilter' ../../../wine-git/dlls/gdi32/freetype.c:4777: warning: ISO C90 forbids mixed declarations and code ../../../wine-git/dlls/gdi32/freetype.c:4785: error: 'lcdfilter' undeclared (first use in this function) ../../../wine-git/dlls/gdi32/freetype.c:4785: error: too many arguments to function 'pFT_Library_SetLcdFilter' ../../../wine-git/dlls/gdi32/freetype.c:4803: error: 'FT_LCD_FILTER_DEFAULT' undeclared (first use in this function) ../../../wine-git/dlls/gdi32/freetype.c:4803: error: 'FT_LCD_FILTER_LIGHT' undeclared (first use in this function) ../../../wine-git/dlls/gdi32/freetype.c: In function 'is_subpixel_rendering_enabled': ../../../wine-git/dlls/gdi32/freetype.c:5923: error: too many arguments to function 'pFT_Library_SetLcdFilter' make[2]: *** [freetype.o] Fehler 1 make[2]: Leaving directory `/usr/src/wine/wine-build/dlls/gdi32' make[1]: *** [gdi32] Fehler 2 make[1]: Leaving directory `/usr/src/wine/wine-build/dlls' make: *** [dlls] Fehler 2 ccache gcc -c -I../../../wine-git/dlls/gdi32 -I. -I../../../wine-git/include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 -o font.o ../../../wine-git/dlls/gdi32/font.c ccache gcc -c -I../../../wine-git/dlls/gdi32 -I. -I../../../wine-git/include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 -o freetype.o ../../../wine-git/dlls/gdi32/freetype.c ../../../wine-git/dlls/gdi32/freetype.c:187: error: expected declaration specifiers or ‘...’ before ‘FT_LcdFilter’ ../../../wine-git/dlls/gdi32/freetype.c: In function ‘WineEngGetGlyphOutline’: ../../../wine-git/dlls/gdi32/freetype.c:4776: error: ‘FT_LcdFilter’ undeclared (first use in this function) ../../../wine-git/dlls/gdi32/freetype.c:4776: error: (Each undeclared identifier is reported only once ../../../wine-git/dlls/gdi32/freetype.c:4776: error: for each function it appears in.) ../../../wine-git/dlls/gdi32/freetype.c:4776: error: expected ‘;’ before ‘lcdfilter’ ../../../wine-git/dlls/gdi32/freetype.c:4777: warning: ISO C90 forbids mixed declarations and code ../../../wine-git/dlls/gdi32/freetype.c:4785: error: ‘lcdfilter’ undeclared (first use in this function) ../../../wine-git/dlls/gdi32/freetype.c:4785: error: too many arguments to function ‘pFT_Library_SetLcdFilter’ ../../../wine-git/dlls/gdi32/freetype.c:4803: error: ‘FT_LCD_FILTER_DEFAULT’ undeclared (first use in this function) ../../../wine-git/dlls/gdi32/freetype.c:4803: error: ‘FT_LCD_FILTER_LIGHT’ undeclared (first use in this function) ../../../wine-git/dlls/gdi32/freetype.c: In function ‘is_subpixel_rendering_enabled’: ../../../wine-git/dlls/gdi32/freetype.c:5923: error: too many arguments to function ‘pFT_Library_SetLcdFilter’ make[2]: *** [freetype.o] Fehler 1 make[2]: Leaving directory `/usr/src/wine/wine-build/dlls/gdi32' make[1]: *** [gdi32] Fehler 2 make[1]: Leaving directory `/usr/src/wine/wine-build/dlls' make: *** [dlls] Fehler 2 A fix was committed today, please retest. -- -Austin
Re: [06/10] wintrust: Implement CryptCATOpen and CryptCATClose.
Hi Juan and Hans, Juan Lang schreef: Hi Hans, Maarten, do you remember what the code to store attribute certs was needed for? I'd like to address Juan's concern by either adding a test or taking the code out. I wouldn't worry about it. The code looks correct to the eye, it's just calling part of crypt32 that's stubbed out (and on my list.) Mainly I was curious if you'd managed to test with native crypt32 somehow, as that's something I've never managed to make work (on Linux.) I was working on some code that needed it, The specific functions were stubbed out (crossover proprietary advantage (TM)) so it's not used, but the correct implementation of CryptCATGetCertAttr/CryptCATEnumCertAttr would need the attributes. Cheers, Maarten.
Trouble compiling today's git.
Is anyone else having trouble compiling today's git? Or is it just my flu-addled brain? make[1]: Entering directory `/home/susan/wine/server' ../tools/makedep -C. -S.. -T.. async.c atom.c change.c class.c clipboard.c completion.c console.c context_alpha.c context_i386.c context_powerpc.c context_sparc.c context_x86_64.c debugger.c device.c directory.c event.c fd.c file.c handle.c hook.c mach.c mailslot.c main.c mapping.c mutex.c named_pipe.c object.c process.c procfs.c ptrace.c queue.c region.c registry.c request.c semaphore.c serial.c signal.c snapshot.c sock.c symlink.c thread.c timer.c token.c trace.c unicode.c user.c window.c winstation.c make[1]: Leaving directory `/home/susan/wine/server' make[1]: Entering directory `/home/susan/wine/server' ../tools/makedep -C. -S.. -T.. async.c atom.c change.c class.c clipboard.c completion.c console.c context_alpha.c context_i386.c context_powerpc.c context_sparc.c context_x86_64.c debugger.c device.c directory.c event.c fd.c file.c handle.c hook.c mach.c mailslot.c main.c mapping.c mutex.c named_pipe.c object.c process.c procfs.c ptrace.c queue.c region.c registry.c request.c semaphore.c serial.c signal.c snapshot.c sock.c symlink.c thread.c timer.c token.c trace.c unicode.c user.c window.c winstation.c make[1]: Leaving directory `/home/susan/wine/server' make[1]: Entering directory `/home/susan/wine/tools' make[2]: Entering directory `/home/susan/wine/tools/widl' ../../tools/makedep -C. -S../.. -T../.. client.c expr.c hash.c header.c proxy.c server.c typegen.c typelib.c utils.c widl.c write_msft.c parser.y parser.l make[2]: Leaving directory `/home/susan/wine/tools/widl' make[2]: Entering directory `/home/susan/wine/tools/widl' ../../tools/makedep -C. -S../.. -T../.. client.c expr.c hash.c header.c proxy.c server.c typegen.c typelib.c utils.c widl.c write_msft.c parser.y parser.l make[2]: Leaving directory `/home/susan/wine/tools/widl' make[2]: Entering directory `/home/susan/wine/tools/winebuild' ../../tools/makedep -C. -S../.. -T../.. import.c main.c parser.c relay.c res16.c res32.c spec16.c spec32.c utils.c make[2]: Leaving directory `/home/susan/wine/tools/winebuild' make[2]: Entering directory `/home/susan/wine/tools/winebuild' ../../tools/makedep -C. -S../.. -T../.. import.c main.c parser.c relay.c res16.c res32.c spec16.c spec32.c utils.c make[2]: Leaving directory `/home/susan/wine/tools/winebuild' make[2]: Entering directory `/home/susan/wine/tools/winedump' ../../tools/makedep -C. -S../.. -T../.. debug.c dos.c dump.c emf.c le.c lib.c lnk.c main.c minidump.c misc.c msc.c msmangle.c ne.c output.c pdb.c pe.c search.c symbol.c make[2]: Leaving directory `/home/susan/wine/tools/winedump' make[2]: Entering directory `/home/susan/wine/tools/winedump' ../../tools/makedep -C. -S../.. -T../.. debug.c dos.c dump.c emf.c le.c lib.c lnk.c main.c minidump.c misc.c msc.c msmangle.c ne.c output.c pdb.c pe.c search.c symbol.c make[2]: Leaving directory `/home/susan/wine/tools/winedump' make[2]: Entering directory `/home/susan/wine/tools/winegcc' ../../tools/makedep -C. -S../.. -T../.. utils.c winegcc.c make[2]: Leaving directory `/home/susan/wine/tools/winegcc' make[2]: Entering directory `/home/susan/wine/tools/winegcc' ../../tools/makedep -C. -S../.. -T../.. utils.c winegcc.c make[2]: Leaving directory `/home/susan/wine/tools/winegcc' make[2]: Entering directory `/home/susan/wine/tools/wmc' ../../tools/makedep -C. -S../.. -T../.. lang.c mcl.c utils.c wmc.c write.c mcy.y make[2]: Leaving directory `/home/susan/wine/tools/wmc' make[2]: Entering directory `/home/susan/wine/tools/wmc' ../../tools/makedep -C. -S../.. -T../.. lang.c mcl.c utils.c wmc.c write.c mcy.y make[2]: Leaving directory `/home/susan/wine/tools/wmc' make[2]: Entering directory `/home/susan/wine/tools/wrc' ../../tools/makedep -C. -S../.. -T../.. dumpres.c genres.c newstruc.c readres.c translation.c utils.c wrc.c writeres.cparser.y parser.l make[2]: Leaving directory `/home/susan/wine/tools/wrc' make[2]: Entering directory `/home/susan/wine/tools/wrc' ../../tools/makedep -C. -S../.. -T../.. dumpres.c genres.c newstruc.c readres.c translation.c utils.c wrc.c writeres.cparser.y parser.l make[2]: Leaving directory `/home/susan/wine/tools/wrc' ../tools/makedep -C. -S.. -T.. -I/usr/include/freetype2 fnt2bdf.c fnt2fon.c make_ctests.c makedep.c relpath.c sfnt2fnt.c make[1]: Leaving directory `/home/susan/wine/tools' ./tools/makedep -C. -S. -T. make[1]: Entering directory `/home/susan/wine/tools' make[1]: `makedep' is up to date. make[1]: Leaving directory `/home/susan/wine/tools' make[1]: Entering directory `/home/susan/wine/libs' make[2]: Entering directory `/home/susan/wine/libs/port'
RE: [PATCH] Fix glReadPixels call from read_from_framebuffer (re-redux)
Why not create a texture and draw a quad instead of using glDrawPixels (as it is deprecated in gl3)?Reference -- ogl 3 spec -- (http://www.opengl.org/registry/doc/glspec30.20080811.pdf)Under E.1 Profiles and Deprecated Features of OpenGL 3.0Pixel drawing - DrawPixels and PixelZoom (section 3.7.4). However, the language describing pixel rectangles in section 3.7 is retained as it is required for TexImage* and ReadPixels. - Nick From: adge...@hotmail.com To: ste...@codeweavers.com; wine-devel@winehq.org Subject: RE: [PATCH] Fix glReadPixels call from read_from_framebuffer (re-redux) Date: Tue, 23 Dec 2008 11:11:08 -0800 Thanks for reviewing my patch (it sure makes the SHOGO menu much nicer) BTW do you know if I need to resubmit my other SHOGO patch ([PATCH] Fix ddraw surface version setting)? Concerning negative pixelzoom and drawpixels on R500 Please file a radar on that (and email the mac-opengl mailing list)- Nick From: ste...@codeweavers.com To: wine-devel@winehq.org Subject: RE: [PATCH] Fix glReadPixels call from read_from_framebuffer (re-redux) Date: Tue, 23 Dec 2008 13:30:40 +0100 This patch looks good. There's one last thing we should check: It seems that this is the only code that uses GL_PACK_ROW_LENGTH and friends, so the backup and restore is probably not needed. I think for now it is better to add it because I suspect the code in surface_download_data most likely depends on the default settings without properly controlling them. There's some related driver bug on OSX too(no radar filed yet, unfortunately). Using a PBO for glDrawPixels with a negative pixelzoom(wine uses -1 for y) breaks at least on my radeon X1600 with MacOS 10.5.5. I haven't yet tested it with 10.5.6, but if it is still broken there I have to remember to file a bug. It is sort of a follow-up bug to a bug fixed in 10.5.5; Before that glPixelZoom and PixelPos were completely ignored with PBOs. This bug was on my todo list for a long time by the way. I wanted to fix it, got distracted and forgot again :-/
Re: Trouble compiling today's git.
On Tue, Dec 23, 2008 at 5:13 PM, Susan Cragin susancra...@earthlink.net wrote: Is anyone else having trouble compiling today's git? Or is it just my flu-addled brain? make[1]: Entering directory `/home/susan/wine/server' ../tools/makedep -C. -S.. -T.. async.c atom.c change.c class.c clipboard.c completion.c console.c context_alpha.c context_i386.c context_powerpc.c context_sparc.c context_x86_64.c debugger.c device.c directory.c event.c fd.c file.c handle.c hook.c mach.c mailslot.c main.c mapping.c mutex.c named_pipe.c object.c process.c procfs.c ptrace.c queue.c region.c registry.c request.c semaphore.c serial.c signal.c snapshot.c sock.c symlink.c thread.c timer.c token.c trace.c unicode.c user.c window.c winstation.c make[1]: Leaving directory `/home/susan/wine/server' make[1]: Entering directory `/home/susan/wine/server' ../tools/makedep -C. -S.. -T.. async.c atom.c change.c class.c clipboard.c completion.c console.c context_alpha.c context_i386.c context_powerpc.c context_sparc.c context_x86_64.c debugger.c device.c directory.c event.c fd.c file.c handle.c hook.c mach.c mailslot.c main.c mapping.c mutex.c named_pipe.c object.c process.c procfs.c ptrace.c queue.c region.c registry.c request.c semaphore.c serial.c signal.c snapshot.c sock.c symlink.c thread.c timer.c token.c trace.c unicode.c user.c window.c winstation.c make[1]: Leaving directory `/home/susan/wine/server' make[1]: Entering directory `/home/susan/wine/tools' make[2]: Entering directory `/home/susan/wine/tools/widl' ../../tools/makedep -C. -S../.. -T../.. client.c expr.c hash.c header.c proxy.c server.c typegen.c typelib.c utils.c widl.c write_msft.c parser.y parser.l make[2]: Leaving directory `/home/susan/wine/tools/widl' make[2]: Entering directory `/home/susan/wine/tools/widl' ../../tools/makedep -C. -S../.. -T../.. client.c expr.c hash.c header.c proxy.c server.c typegen.c typelib.c utils.c widl.c write_msft.c parser.y parser.l make[2]: Leaving directory `/home/susan/wine/tools/widl' make[2]: Entering directory `/home/susan/wine/tools/winebuild' ../../tools/makedep -C. -S../.. -T../.. import.c main.c parser.c relay.c res16.c res32.c spec16.c spec32.c utils.c make[2]: Leaving directory `/home/susan/wine/tools/winebuild' make[2]: Entering directory `/home/susan/wine/tools/winebuild' ../../tools/makedep -C. -S../.. -T../.. import.c main.c parser.c relay.c res16.c res32.c spec16.c spec32.c utils.c make[2]: Leaving directory `/home/susan/wine/tools/winebuild' make[2]: Entering directory `/home/susan/wine/tools/winedump' ../../tools/makedep -C. -S../.. -T../.. debug.c dos.c dump.c emf.c le.c lib.c lnk.c main.c minidump.c misc.c msc.c msmangle.c ne.c output.c pdb.c pe.c search.c symbol.c make[2]: Leaving directory `/home/susan/wine/tools/winedump' make[2]: Entering directory `/home/susan/wine/tools/winedump' ../../tools/makedep -C. -S../.. -T../.. debug.c dos.c dump.c emf.c le.c lib.c lnk.c main.c minidump.c misc.c msc.c msmangle.c ne.c output.c pdb.c pe.c search.c symbol.c make[2]: Leaving directory `/home/susan/wine/tools/winedump' make[2]: Entering directory `/home/susan/wine/tools/winegcc' ../../tools/makedep -C. -S../.. -T../.. utils.c winegcc.c make[2]: Leaving directory `/home/susan/wine/tools/winegcc' make[2]: Entering directory `/home/susan/wine/tools/winegcc' ../../tools/makedep -C. -S../.. -T../.. utils.c winegcc.c make[2]: Leaving directory `/home/susan/wine/tools/winegcc' make[2]: Entering directory `/home/susan/wine/tools/wmc' ../../tools/makedep -C. -S../.. -T../.. lang.c mcl.c utils.c wmc.c write.c mcy.y make[2]: Leaving directory `/home/susan/wine/tools/wmc' make[2]: Entering directory `/home/susan/wine/tools/wmc' ../../tools/makedep -C. -S../.. -T../.. lang.c mcl.c utils.c wmc.c write.c mcy.y make[2]: Leaving directory `/home/susan/wine/tools/wmc' make[2]: Entering directory `/home/susan/wine/tools/wrc' ../../tools/makedep -C. -S../.. -T../.. dumpres.c genres.c newstruc.c readres.c translation.c utils.c wrc.c writeres.cparser.y parser.l make[2]: Leaving directory `/home/susan/wine/tools/wrc' make[2]: Entering directory `/home/susan/wine/tools/wrc' ../../tools/makedep -C. -S../.. -T../.. dumpres.c genres.c newstruc.c readres.c translation.c utils.c wrc.c writeres.cparser.y parser.l make[2]: Leaving directory `/home/susan/wine/tools/wrc' ../tools/makedep -C. -S.. -T.. -I/usr/include/freetype2 fnt2bdf.c fnt2fon.c make_ctests.c makedep.c relpath.c sfnt2fnt.c make[1]: Leaving directory `/home/susan/wine/tools' ./tools/makedep -C. -S. -T. make[1]: Entering directory `/home/susan/wine/tools' make[1]: `makedep' is up to date. make[1]: Leaving directory `/home/susan/wine/tools' make[1]: Entering directory `/home/susan/wine/libs' make[2]: Entering directory `/home/susan/wine/libs/port' ../../tools/widl/widl -I. -I.
Re: Wine t-shirts?
Looks like the poll is pretty dead, and unless somebody wants to link it somewhere, I suppose we should start getting some conclussion White T-shirt wins 17-11 over white and red, but designs A and B are drawn, so our designer will choose (and she really disliked option A :P) About the slogan, there are 5 for no slogan at all and 4 for run windows applications etc, and I see the drunk penguin T-shirt more suitable with either an informal slogan or just with the project name and website. So according to the poll (if nobody else wants to vote, the poll is still open) we have cute drunk penguin D with no slogan, Wine name, www.winehq.org somewhere and white T-shirt. When we are able to get more Wine T-shirts going, we will use design A and run windows applications etc slogan. Anything else?
re: Symlink vulnerability in winetricks
Stefan Nordhaus wrote: Winetricks has a symlink vulnerability... Fixed in today's winetricks (20081223), thanks! - Dan
Re: [Wine] Re: MacOS X cocoa and carbon for Linux?
Richie wrote: James McKenzie wrote: hahomir4ev wrote: You might find a friendly discussion somewhere else on the implementation of Cocoa/Carbon on Linux, but this is not a topic of discussion here. James McKenzie Of cource it would be a completely unrelated project. Therefore the wine forum is not the right place for such a project. BUT: Up to now there is no McWine or MINE project. Sad to say, but there IS a project for porting Wine to the PowerPC platform: Darwine. It has stalled and really could use help. It has forked so that there are two paths of development and the Intel fork is being worked back into the main Wine project. That leaves the PowerPC fork to be worked on to incorporate Qemu, an x86 emulator for the PowerPC. As to the Aqua 'look and feel' there is an effort to do this as well that may or may not need assistance. The goal in that project is to remove all Object C code and replace it with 'c' code equivalents. You can ask the status of that project on the Wine Development list. Again, this is not the area for discussing development of Wine. Let's move this to the appropriate venue. Thank you. James McKenzie
Regression: Sound broken in PoP series
Hi! The following commit breaks sound in (at least) Prince of Persia SoT and PoP TWW. Reece, let me know how I can help with that. commit ce06de420874b9983324508f8257a580fee341ca Author: Reece Dunn mscl...@googlemail.com Date: Mon Dec 22 13:33:43 2008 + dsound: Correct the dsound fraglen calculations. Regards
Re: Regression: Sound broken in PoP series
See http://bugs.winehq.org/show_bug.cgi?id=16607 On Wed, Dec 24, 2008 at 4:53 AM, M.Kiesel wine-de...@continuity.cjb.net wrote: Hi! The following commit breaks sound in (at least) Prince of Persia SoT and PoP TWW. Reece, let me know how I can help with that. commit ce06de420874b9983324508f8257a580fee341ca Author: Reece Dunn mscl...@googlemail.com Date: Mon Dec 22 13:33:43 2008 + dsound: Correct the dsound fraglen calculations. Regards - JL -- Adys
Combining Fuse and Wine - What's the best way?
I'm writing a program in which I have a Windows DLL that I need to load. The DLL contains a function that returns a pointer to some data, and I want to expose that data as file data in a Fuse file system. My first thought was that I could have the program load the DLL using winelib, but I'm not sure what's involved in this and whether the resulting program could also use the Fuse libraries. I'm a bit of a novice to Wine, and Linux programming in general, so I'd appreciate any expert opinions you guys have about the best way to do this. Thanks in advance, Richard
Re: Testing DIB Engine (second part)
On Wed, Dec 24, 2008 at 11:23 AM, Massimo Del Fedele m...@veneto.com wrote: Here the second part, it contains winedib.drv code and changes to Makefiles. Still no way to enable/disable the engine, besides of deleting the .so inside dlls/winedib.drv. I'll wait for some feedback before going fourther. Ciao Max Instead of deleting it, you could simply set winedib.drv to disabled in winecfg? -Jeff
