December 2008 - Wine-Devel - list.winehq.org

Re: d3d9: Set IDirect3DDevice9Impl_GetVertexShader return value to NULL on error

by Henri Verbeet

2008/12/23 Stefan Dösinger <stefan(a)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.

Dec. 23, 2008

RE: d3d9: Set IDirect3DDevice9Impl_GetVertexShader return value to NULL on error

by Stefan Dösinger

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-bounces(a)winehq.org [mailto:wine-patches- > bounces(a)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

Dec. 23, 2008

Re: DIB Engine

by Massimo Del Fedele

Austin English ha scritto: > On Tue, Dec 23, 2008 at 10:44 AM, Massimo Del Fedele <max(a)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

Dec. 23, 2008

Re: d3d9/tests: Don't create a Null-shader in d3d9, it will crash.

by Henri Verbeet

2008/12/23 Stefan Dösinger <stefan(a)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.

Dec. 23, 2008

RE: [PATCH] Fix glReadPixels call from read_from_framebuffer (re-redux)

by Stefan Dösinger

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 :-/

Dec. 23, 2008

RE: d3d9/tests: Don't create a Null-shader in d3d9, it will crash.

by Stefan Dösinger

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.

Dec. 23, 2008

RE: Valgrind warning in wined3d/swapchain.c in IWineD3DSwapChainImpl_Destroy

by Stefan Dösinger

Hi, I'm doing an mail purge and stumbled across this mail. Can you try the attached patch? > -----Original Message----- > From: daniel.r.kegel(a)gmail.com [mailto:daniel.r.kegel(a)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> > <kind>UninitCondition</kind> > <what>Conditional jump or move depends on uninitialised > value(s)</what> > <stack> > <frame> > <obj>dlls/wined3d/wined3d.dll.so</obj> > <fn>IWineD3DSwapChainImpl_Destroy</fn> > <dir>dlls/wined3d</dir> > <file>swapchain.c</file> > <line>75</line> > </frame> > <frame> > <obj>dlls/d3d9/d3d9.dll.so</obj> > <fn>IDirect3DSwapChain9Impl_Release</fn> > <dir>dlls/d3d9</dir> > <file>swapchain.c</file> > <line>66</line> > </frame> > <frame> > <obj>dlls/d3d9/d3d9.dll.so</obj> > <fn>D3D9CB_DestroySwapChain</fn> > <dir>dlls/d3d9</dir> > <file>directx.c</file> > <line>427</line> > </frame> > <frame> > <obj>dlls/wined3d/wined3d.dll.so</obj> > <fn>IWineD3DDeviceImpl_Uninit3D</fn> > <dir>dlls/wined3d</dir> > <file>device.c</file> > <line>2426</line> > </frame> > <frame> > <obj>dlls/d3d9/d3d9.dll.so</obj> > <fn>IDirect3DDevice9Impl_Release</fn> > <dir>dlls/d3d9</dir> > <file>device.c</file> > <line>98</line> > </frame> > <frame> > <obj>dlls/d3d9/tests/d3d9_test.exe.so</obj> > <fn>func_visual</fn> > <dir>dlls/d3d9/tests</dir> > <file>visual.c</file> > <line>9960</line> > </frame> > <frame> > <obj>dlls/d3d9/tests/d3d9_test.exe.so</obj> > <fn>run_test</fn> > <dir>dlls/d3d9/tests/../../../include/wine</dir> > <file>test.h</file> > <line>452</line> > </frame> > <frame> > <obj>dlls/d3d9/tests/d3d9_test.exe.so</obj> > <fn>main</fn> > <dir>dlls/d3d9/tests/../../../include/wine</dir> > <file>test.h</file> > <line>502</line> > </frame> > </stack> > </error>

Dec. 23, 2008

Re: DIB Engine

by Austin English

On Tue, Dec 23, 2008 at 10:44 AM, Massimo Del Fedele <max(a)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

Dec. 23, 2008

Re: winecfg: Disable nonfunctional advanced drive settings

by Austin English

On Tue, Dec 23, 2008 at 4:04 AM, M.Kiesel <wine-devel(a)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

Dec. 23, 2008

Re: DIB Engine

by IneedAname

On Tue, 23 Dec 2008 11:44:39 +0100 Massimo Del Fedele <max(a)veneto.com> wrote: > How should I publish it ? http://repo.or.cz/w/wine.git?a=forks

Dec. 23, 2008

Re: DIB Engine

by Massimo Del Fedele

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

Dec. 23, 2008

Re: DIB Engine

by Roderick Colenbrander

> 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

Dec. 23, 2008

d3d9/visual tests timed out

by Rico Schüller

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-… ). Cheers Rico

Dec. 23, 2008

DIB Engine

by Massimo Del Fedele

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

Dec. 23, 2008

Re: d3d9/visual tests timed out

by Jeff Zaroyko

On Tue, Dec 23, 2008 at 9:57 PM, Rico Schüller <kgbricola(a)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-… > ). > > 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

Dec. 23, 2008

Re: Wine build failed

by Dmitry Timoshkov

"Dmitry Timoshkov" <dmitry(a)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.

Dec. 23, 2008

Re: Wine build failed

by Dmitry Timoshkov

"Stefan Leichter" <sle85276(a)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.

Dec. 23, 2008

Re: Wine build failed

by Nikolay Sivov

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.

Dec. 23, 2008

Wine build failed

by Stefan Leichter

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

Dec. 23, 2008

how to create a broken .tlb file

by Michael Karcher

Hello developers, while debugging problems with and old version of Sonic Stage, I found that sonic stage includes broken type libraries, i.e. the TYPEFLAG_FDISPATCHABLE bit is generally missing. As widl (and probably midl too) set this bit automatically, I have some problems in creating a .tlb file for a test case for my one-line patch that also misses this bit. There are some possibilities to get around the problem: 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? Regards, Michael Karcher

Dec. 23, 2008

Re: cryptui(0/24)

by Juan Lang

> If all of this is accepted, this is one lengthy and needed functional > implementation. Good job, Juan! Good job Seattle for having lots of snow and cancelling my flight. I had extra time on my hands :) Thanks! --Juan

Dec. 23, 2008

Re: cryptui(0/24)

by James McKenzie

Juan Lang wrote: > This patch series implements the remaining portions of > CryptUIWizImport, and calls it from the certificate dialog. > > If all of this is accepted, this is one lengthy and needed functional implementation. Good job, Juan! James McKenzie

Dec. 23, 2008

Re: winecfg: Disable nonfunctional advanced drive settings

by M.Kiesel

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. BTW I don't quite understand how the nonfunctional winecfg code showed up in the first place. Can I submit some "Perfect Windows compatibility" checkbox for winecfg and then tell the one trying to revert that to please just fix the underlying bug? :-) Regards

Dec. 23, 2008

Re: MSVCP80 implementation

by James Mckenzie

>"James McKenzie" <jjmckenzie51(a)earthlink.net> wrote: > >>>> I'm attempting to get software to run which requires some functions in >>>> MSVCP80 to be implemented. >>>> >>> You need to install msvc2005 redistributable runtime. The simplest way is >>> using winetricks: http://wiki.winehq.org/winetricks >>> >>> Implementing all that is a huge waste of time. >>> >>> >> Legally speaking, we should start implementing all of the functions in >> the Win32/Win64 API. > >MSVCP80 is not a part of win32 API, that's a redistributable run-time >library supposed to be provided by an application. > Dimtry: Thank you for the clarification on its use and where it should come from. I will correct then: Get it through Winetricks or insure that it is packaged with the executable. James McKenzie

Dec. 23, 2008

Re: MSVCP80 implementation

by Dmitry Timoshkov

"James McKenzie" <jjmckenzie51(a)earthlink.net> wrote: >>> I'm attempting to get software to run which requires some functions in >>> MSVCP80 to be implemented. >>> >> You need to install msvc2005 redistributable runtime. The simplest way is >> using winetricks: http://wiki.winehq.org/winetricks >> >> Implementing all that is a huge waste of time. >> >> > Legally speaking, we should start implementing all of the functions in > the Win32/Win64 API. MSVCP80 is not a part of win32 API, that's a redistributable run-time library supposed to be provided by an application. -- Dmitry.

Dec. 23, 2008

Re: winecfg: Disable nonfunctional advanced drive settings

by Austin English

On Tue, Dec 23, 2008 at 2:36 AM, M.Kiesel <wine-devel(a)continuity.cjb.net> 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. > > Changelog: > winecfg: Disable nonfunctional advanced drive settings > > > Rather than disable it and cause more confusion when it does work, focus on fixing the actual bug instead. -- -Austin

Dec. 23, 2008

Re: Patchwatcher offline?

by James McKenzie

Austin English wrote: > On Sat, Dec 20, 2008 at 7:03 PM, Francois Gouget <fgouget(a)free.fr> wrote: > >> On Sat, 20 Dec 2008, Paul Vriens wrote: >> >> >>> IneedAname wrote: >>> >>>> Looks like Patchwatcher has being offline from 09-Dec-2008. >>>> Did I miss something or did someone trip over the mains cable? >>>> >>>> >>>> >>> http://www.winehq.org/pipermail/wine-devel/2008-December/071059.html >>> >> Well, obviously that's more than a day (I'm not complaining, just saying >> the above post may not explain everything). >> >> -- >> Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ >> There are 10 types of people in the world... >> those who understand binary and those who don't. >> >> >> >> > > I had asked Dan a couple days ago, he's been busy with work, sick kid, > holidays, etc. Probably needs a few days for things to calm down, and > a nice cold beer :-). > > I'd be willing to help with the last item. :-) Kids, I'm not so good with, especially sick ones. BTW, I passed the exam at the end of four weeks of classes, that means I'm certified... James McKenzie

Dec. 23, 2008

Re: MSVCP80 implementation

by James McKenzie

Vitaliy Margolen wrote: > louis(a)museresearch.com wrote: > >> Hi all, >> I'm attempting to get software to run which requires some functions in >> MSVCP80 to be implemented. >> > You need to install msvc2005 redistributable runtime. The simplest way is > using winetricks: http://wiki.winehq.org/winetricks > > Implementing all that is a huge waste of time. > > Legally speaking, we should start implementing all of the functions in the Win32/Win64 API. Louis: If you feel that you have the technical capabilities and can understand the method of implementing code in a clean room environment, please go ahead and start working on this. Remember, test cases first that prove what the Win32/64 API does with this dll as implemented through Windows and then code the dll's functions. Remember: You cannot do this if you EVER looked at Windows code for this dll or attempt to reverse engineer it. There are many legal reasons for this, the biggest is that Microsoft can attempt to shutdown this project. For now, Vitally's suggestion is what we are using to implement this dll's functionality. James McKenzie

Dec. 23, 2008

Re: MSVCP80 implementation

by Vitaliy Margolen

louis(a)museresearch.com wrote: > Hi all, > I'm attempting to get software to run which requires some functions in > MSVCP80 to be implemented. You need to install msvc2005 redistributable runtime. The simplest way is using winetricks: http://wiki.winehq.org/winetricks Implementing all that is a huge waste of time. Vitaliy.

Dec. 23, 2008

Re: bugfix: resend: fix serial_flush

by Wolfgang Walter

On Monday 22 December 2008, Alexandre Julliard wrote: > Wolfgang Walter <wine(a)stwm.de> writes: > > > @@ -201,7 +202,17 @@ static void serial_flush( struct fd *fd, struct event **event ) > > /* MSDN says: If hFile is a handle to a communications device, > > * the function only flushes the transmit buffer. > > */ > > - if (tcflush( get_unix_fd(fd), TCOFLUSH ) == -1) file_set_error(); > > + /* FlushFileBuffers does NOT have the semantics of tcflush. > > + * Whereas tcflush discards any data not yet transmitted > > + * FlushFileBuffers ensures they are written out. > > + * The POSIX equivalent is tcdrain > > + */ > > + while (tcdrain( get_unix_fd(fd)) == -1) { > > + if (errno != EINTR) { > > + file_set_error(); > > + return; > > + } > > This will block, you can't do that in the server. > > -- > Alexandre Julliard > julliard(a)winehq.org > > Would it be acceptable to call tcdrain directly in NtFlushBuffersFile: ================= NTSTATUS WINAPI NtFlushBuffersFile( HANDLE hFile, IO_STATUS_BLOCK* IoStatusBlock ) { NTSTATUS ret; HANDLE hEvent = NULL; enum server_fd_type type; NTSTATUS status; unsigned int options; int needs_close; int unix_handle; status = server_get_unix_fd( hFile, FILE_WRITE_DATA, &unix_handle, &needs_close, &type, &options ); if (type == FD_TYPE_SERIAL) { while (tcdrain(unix_handle) == -1) { if (errno != EINTR) { return FILE_GetNtStatus(); } } return STATUS_SUCCESS; } SERVER_START_REQ( flush_file ) { req->handle = wine_server_obj_handle( hFile ); ret = wine_server_call( req ); hEvent = wine_server_ptr_handle( reply->event ); } SERVER_END_REQ; if (!ret && hEvent) { ret = NtWaitForSingleObject( hEvent, FALSE, NULL ); NtClose( hEvent ); } return ret; } ================================= Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts Leiter EDV Leopoldstraße 15 80802 München

Dec. 23, 2008

Re: [RFC] wined3d: Avoid triggering OPENGL errors when setting point size

by Henri Verbeet

2008/12/23 Vincent Pelletier <plr.vincent(a)gmail.com>: > 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 think it makes more sense to clamp the value to be within the limits, rather than using whatever was used last.

Dec. 23, 2008

Fwd: Linking to a Mac OS X build of Wine from winehq.org/download ?

by Zach Drayer

Begin forwarded message: > From: "Austin English" <austinenglish(a)gmail.com> > Date: December 22, 2008 6:12:13 PM EST > To: "Zach Drayer" <zach(a)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 <zach(a)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.

Dec. 22, 2008

MSVCP80 implementation

by louis＠museresearch.com

Hi all, I'm attempting to get software to run which requires some functions in MSVCP80 to be implemented. Using the original DLLs is not an option for us. In particular, a couple of the allocator functions are being called (msvcp80.dll.??0?$basic_string(a)DU?$char_traits(a)D@std@@V?$allocator(a)D@2@@std@@QAE(a)XZ to give one such example). I am sure there are more after this is fixed too. Browsing the WINE source, I found references to some similarly mangled functions in MSVCRT (the stream classes), but they did not seem to be actually implemented: in msvcrt/tests/cpp.c there was a demangling test, but I didn't find much else that was directly related. So, my question is how WINE handles calls to any STL or C++ library functions which may be included in these DLLs, and what approach I should use to implement or forward calls to these kinds of functions. Any help would be much appreciated. Thanks in advance, Louis Gorenfeld Muse Research

Dec. 22, 2008

Re: New Gecko package - call for tests

by Jacek Caban

Hi Lei, Lei Zhang wrote: > > (Let me know if you'd prefer to discuss this in the bug report instead) > It doesn't matter for me. > The patch didn't apply cleanly against today's wine-git. Can you > regenerate the patch? That was because it contained a few patches that were committed today. I've attached a new patch. > I tried applying the patch by hand, compiled, > but running wine iexplore causes a crash. Maybe I didn't apply the > patch correctly? > That may be the reason. Thanks! Jacek

Dec. 22, 2008

Re: New Gecko package - call for tests

by Lei Zhang

On Sun, Dec 21, 2008 at 4:49 PM, Jacek Caban <jacek(a)codeweavers.com> wrote: > Hi, > > I've released first (and hopefully last) RC build of new Gecko package > and attached a patch against current Wine Git to bug 16198 > http://bugs.winehq.org/show_bug.cgi?id=16198 > It's critical to make sure, that there will be no regressions due to the > new Gecko, it'd much more work to fix such regression than a usual > regressions. I'd appreciate any help with testing it. Instructions how > to do it are in the bug report. Any application that uses MSHTML is > worth testing, esp ones that extensively use it. > > I will write more about the new release and future plans later in an > other subject. > > Thanks, > Jacek > (Let me know if you'd prefer to discuss this in the bug report instead) The patch didn't apply cleanly against today's wine-git. Can you regenerate the patch? I tried applying the patch by hand, compiled, but running wine iexplore causes a crash. Maybe I didn't apply the patch correctly?

Dec. 22, 2008

Re: ntdll: fix a compiler warning on PC-BSD

by Austin English

On Sun, Dec 21, 2008 at 3:33 AM, Francois Gouget <fgouget(a)free.fr> wrote: > > I'm a bit surprised that PC-BSD/FreeBSD's mkdir() does not take a mode > argument. Are you sure this is really the case? Maybe we > are just mising a #include directive on BSD? > (Unfortunately I don't really have access to a FreeBSD box right now) > > > -- > Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ > You can have my guns when you pry them from my kids cold, dead hands. > I didn't investigate further, Alexandre committed a fix: http://source.winehq.org/git/wine.git/?a=commitdiff;h=921e6624ad63a026b2775… -- -Austin

Dec. 22, 2008

Re: d3d9 patch include a test needs testing in windows

by Austin English

On Sun, Dec 21, 2008 at 10:58 AM, Pauli Nieminen <suokkos(a)gmail.com> wrote: > Hi! > > I have tried to get Civ4 running in my machine and successed with some minor > wine modifications but this patch needs testing in windows how d3d9 handles > this case in there. Preferable test system should be include graphic card > that supports some but not all shader versions. (That means readeon 8500+ > and Geforce 3/4+). I think it should be ok to run in any windows version if > there is just dx9 installed. > > Patch set includes 3 patches but you realy only need to apply the test > portion of 2nd patch. > The latest patch version is available at http://repe.ath.cx/wine/ and bug > report is http://bugs.winehq.org/show_bug.cgi?id=16444 . > > Thanks for help. Pauli > > > > C:\Documents and Settings\Austin\Desktop>d3d9_crosstest.exe shader shader.c:193: SetPixelShaderConstantF was able to set 224 shader constants shader: 16 tests executed (0 marked as todo, 0 failures), 0 skipped. C:\Documents and Settings\Austin\Desktop>d3d9_crosstest_new.exe shader shader.c:96: Test failed: Vertex shader (0xfffe02ff) creation succesed but d3dcaps claim not to support it. hret = 0x0, vshader_ptr = 00259740 shader.c:92: Test failed: Vertex shader (0xfffe0300) creation failed but d3dcaps claim to support it. hret = 0x8876086c, vshader_ptr = 00000000 shader.c:115: Test failed: Pixel shader (0xffff0300) creation failed but d3dcaps claim to support it. hret = 0x8876086c, pshader_ptr = 00000000 shader.c:432: SetPixelShaderConstantF was able to set 224 shader constants shader: 33 tests executed (0 marked as todo, 3 failures), 0 skipped. This was with a Nvidia GeForce 7600 GT. -- -Austin

Dec. 22, 2008

Re: RFC: Proposed new web site design

by Jeremy White

Hey Tom, > That was slick, the mock up listed Bordeaux under third party apps > and when the site went live it was somehow removed :D > > Well, the mockup had a fairly crummy presentation of Bordeaux; I meant to ask Steven to submit a better put together version, with nicer graphics and such, but I forgot. Hopefully this will serve for that. Cheers, Jeremy

Dec. 22, 2008

Re: [06/10] wintrust: Implement CryptCATOpen and CryptCATClose.

by Juan Lang

>> Out of curiosity, how did you test this? > > That would be a question for Maarten since he mostly wrote this code. Well, last he asked me about it, I hadn't had a chance to look at attribute certs in messages yet (they're stubbed out.) That's why I was curious ;-) --Juan

Dec. 22, 2008

Re: [06/10] wintrust: Implement CryptCATOpen and CryptCATClose.

by Hans Leidekker

On Monday 22 December 2008 16:59:29 Juan Lang wrote: > +struct cryptcat > +{ > + DWORD magic; > + HANDLE msg; > > msg's type should be HCRYPTMSG instead. Thanks for catching that. > + for (i = 0; i < cc->attr_count; i++) > + { > + if (!CryptMsgGetParam(hmsg, CMSG_ATTR_CERT_PARAM, i, NULL, &size)) > > Out of curiosity, how did you test this? That would be a question for Maarten since he mostly wrote this code. -Hans

Dec. 22, 2008

Re: [06/10] wintrust: Implement CryptCATOpen and CryptCATClose.

by Juan Lang

Hi Hans, this is a really minor comment: +struct cryptcat +{ + DWORD magic; + HANDLE msg; msg's type should be HCRYPTMSG instead. + for (i = 0; i < cc->attr_count; i++) + { + if (!CryptMsgGetParam(hmsg, CMSG_ATTR_CERT_PARAM, i, NULL, &size)) Out of curiosity, how did you test this? --Juan

Dec. 22, 2008

Re: Linking to a Mac OS X build of Wine from winehq.org/download ?

by James Mckenzie

-----Original Message----- >From: Dmitry Timoshkov <dmitry(a)codeweavers.com> >Sent: Dec 21, 2008 10:45 PM >To: Dan Kegel <dank(a)kegel.com>, Roderick Colenbrander <thunderbird2k(a)gmx.net> >Cc: wine-devel(a)winehq.org, zach(a)drayer.name, ies4osx(a)kronenberg.org >Subject: Re: Linking to a Mac OS X build of Wine from winehq.org/download ? > >"Dan Kegel" <dank(a)kegel.com> wrote: > >> On Sun, Dec 21, 2008 at 8:27 AM, Roderick Colenbrander >> <thunderbird2k(a)gmx.net> wrote: >>>> Say, http://www.kronenberg.org/darwine/ seems to be a popular source >>>> of nearly up to date wine builds for the mac. How about we link to it >>>> from http://winehq.org/download/ ? >>>> >>>> Furthermore, are his packages good enough to support? >>>> If so, how 'bout we ask him to add links to bugzilla and >>>> the appdb from his page? >>> >>> Most importantly we need to get rid of the Darwine name. It causes a lot of unneeded confusion. >> >> Yes, I would like to keep Darwine as the name of the old powerpc project >> that combined an x86 emulator and wine. >> >> Can we convince Mike and Zach to switch names to just plain Wine? > >And change the licencing conditions to LGPL, currently that page states >"Darwine and wine are released under the gpl". They also have to remove >any differences between WineHQ sources and their ones, otherwise it can't >be supported via WineHQ. > Dan and Dmitry: What I would like to see is the changes made by Zach and Mike incorporated back into the main Wine code. 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. The Wine project should pick one as the formally supported installation method and allow others to support the second. I don't have a favorite, as deinstallation of the program is easy and involves an additional step when using the second installation method. Again, restating my first sentence in the last paragraph is that we need to bring back into the Main Wine codebase those changes needed to successfully complete a build on the Intel MacOSX system. Darwine should remain a project for incorporating the x86 emulator, Qemu and Wine. This should reduce MacOSX user confusion and get all of the pieces together. Further work may be required to fully support all functionality of the Wine project, such as font support, as time progresses. James McKenzie

Dec. 22, 2008

Re: Linking to a Mac OS X build of Wine from winehq.org/download ?

by Austin English

On Sun, Dec 21, 2008 at 9:50 AM, Dan Kegel <dank(a)kegel.com> wrote: > Say, http://www.kronenberg.org/darwine/ seems to be a popular source > of nearly up to date wine builds for the mac. How about we link to it > from http://winehq.org/download/ ? > > Furthermore, are his packages good enough to support? > If so, how 'bout we ask him to add links to bugzilla and > the appdb from his page? > > > 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. -- -Austin

Dec. 22, 2008

Re: question about translating winehq.org

by Jeremy Newman

Currently you cannot. Sometime I will look into making the site theme translatable. -Newman Maik Schulz wrote: > Hi, > > how can I translate the top navigation bar ("Forums" would be "Foren" > in German) and the word "Search" (would be "Suche" in German) next to > the search box? > > Cheers, > -Maik > >

Dec. 22, 2008

Re: Functions that should be static

by Christian Costa

Francois Gouget a écrit : > On Sat, 20 Dec 2008, Christian Costa wrote: > [...] > >> If you have a class A (with methods implemented in file 1) that inherits from >> another class B (methods in file B). >> The class A may overrides some methods of B which may become unused if B is >> never instanciated and B methods not reused. >> They will be tracked by your script then. >> We could make these functions static or worst remove then but from object >> programming pov is not good. >> > > I don't see any reason not to make the methods of B static, whether > class A exists or not. Note that 'static' does not prevent a function > from being called from another object file if you give a pointer to them > to that other file (as you do with the virtual table). > > Also the compiler will not complain that these functions are unused > because they are indeed used: you take their address. > > Yes. That's right we can pick the function address from a vtable but in that case we cannot build another one statically as we use to i.e : const IPinVtbl MyInputPin_Vtbl = { InputPin_Vtbl.QueryInterface, <= not a constant MyInputPin_AddRef, ... } The compiler will complain this is not a constant. We could never build a vtable statically except for the top base class. And how could we build a vtable dynamically from another one which is also build dynamically ? I guess, we need to rely on constructor of the parent class which will call in turn his own parent and so on. This is a big change. Maybe it's off topic, but msvcirt exports methods as well as vtables. I don't know how all of this works !

Dec. 22, 2008

Re: Linking to a Mac OS X build of Wine from winehq.org/download ?

by Dan Kegel

On Sun, Dec 21, 2008 at 9:22 PM, Zach Drayer <zach(a)drayer.name> wrote: >>>> Can we convince Mike and Zach to switch names to just plain Wine? > > I'd have no problems switching over to just using Wine instead of Darwine. > Also, maybe Jim White or someone else that actually developed Darwine could > comment? All I do is package it.. and even the, I haven't really had time to > do so recently. FWIW, I'm building 1.1.11 right now though. I asked Jim White (who's an old friend of mine from early LAJUG days) whether I was right to assume that Darwine referred to the original powerpc project with an x86 emulator hooked up to it, and whether Wine for Mac OS X x86 should just be called Wine, and he said: > Yes, of course. Darwine is quite quiescent, but I think it did > some real good in getting the Wine port to Mac started... BTW, Zach, do you apply any patches as you package it? - Dan

Dec. 22, 2008

Re: [07/10] wintrust: Implement CryptCATEnumerateMember.

by Alexandre Julliard

Hans Leidekker <hans(a)codeweavers.com> writes: > On Monday 22 December 2008 14:55:29 Alexandre Julliard wrote: > >> > +static BOOL guid_from_string(const WCHAR *str, GUID *guid) >> > +{ >> > + unsigned int i = 0; >> > + unsigned char *b = (unsigned char *)guid; >> > + const WCHAR *p = str; >> >> Please call one of the existing functions for this instead of >> reinventing the wheel. > > I did that at some point but it seemed overkill to me to import > ole32 for just one function. I'll change it. You can always use RtlGUIDFromString or something like that. -- Alexandre Julliard julliard(a)winehq.org

Dec. 22, 2008

Re: [02/10] wintrust: Convert crypt tests to Unicode.

by Alexandre Julliard

Hans Leidekker <hans(a)codeweavers.com> writes: > On Monday 22 December 2008 14:54:28 Alexandre Julliard wrote: > >> > -static char selfname[MAX_PATH]; >> > -static CHAR CURR_DIR[MAX_PATH]; >> > +static WCHAR selfname[MAX_PATH]; >> > +static WCHAR current_dir[MAX_PATH]; >> >> Is that really useful? It seems to me it will break the tests on Win9x >> for no good reason. > > Well, wintrust is a Unicode only API and we already skip the tests if > wintrust is not fully supported. Wintrust being Unicode doesn't mean the rest of the system has to be. The tests currently run (with some errors) on WinME. -- Alexandre Julliard julliard(a)winehq.org

Dec. 22, 2008

RE: [PATCH] Fix glReadPixels call from read_from_framebuffer (redux)

by Nick Burns

'You are correct sir' I just disabled PBO on my wine build and ran SHOGO The poor menu system was all garbled... (the same issue that the pbo path had) I cleaned-up my patch and made it apply in general (to both paths) Now SHOGO looks good under both paths Good catch and thanks -- I will re-resubmit my patch - Nick ---------------------------------------- > From: stefan(a)codeweavers.com > To: wine-devel(a)winehq.org; wine-patches(a)winehq.org > Subject: RE: [PATCH] Fix glReadPixels call from read_from_framebuffer (redux) > Date: Mon, 22 Dec 2008 13:05:36 +0100 > > Hmm... Wouldn't this bug also affect surfaces without a PBO? > > >> -----Original Message----- >> From: wine-patches-bounces(a)winehq.org [mailto:wine-patches- >> bounces(a)winehq.org] On Behalf Of Nick Burns >> Sent: Sunday, December 21, 2008 12:36 PM >> To: wine-patches(a)winehq.org >> Subject: [PATCH] Fix glReadPixels call from read_from_framebuffer >> (redux) >> >> >> This is a resubmission of my previous patch I fixed the issues Jeff >> found >> 1 - email address in the patch file/git >> 2 - move declartions to block beginning (no warnings now) >> 3 - hotmail spacing (well i think this is as good as I can make it...) >> >> >> This is my last gfx fix for SHOGO (now its quite legible and playable) >> The readpixels call was putting data into the wrong place in the pbo >> (fixed with pixelstore) And the y-flip code was flipping the wrong data >> as well (set the bottom row to the bottom row and not the height'th >> row) >> >> The code handled fullscreen 2d blits (or blts without any colorkey >> masking) correctly However sub-blits had issues (in the pbo path) >> 1 - readpixels read into the wrong part of the pbo (as a line and >> not a rect) >> 2 - the y-flip code would move around the uninited data (from the >> readpixels) and it read from the wrong place >> 3 - After 1 and 2 the pbo is corrupt and the blt code had no >> chance... >> >> This patch fixes 1 and 2 -- letting the blt code shine This can be seen >> in the SHOGO menu (now not corrupt!) >> >> Changelog >> Fix glReadPixels call from read_from_framebuffer >> Fix the call to readpixels so that 2d blts going thru the pbo path >> end up in the right place and get flipped correctly >> >> - Nick

Dec. 22, 2008

Re: [07/10] wintrust: Implement CryptCATEnumerateMember.

by Hans Leidekker

On Monday 22 December 2008 14:55:29 Alexandre Julliard wrote: > > +static BOOL guid_from_string(const WCHAR *str, GUID *guid) > > +{ > > + unsigned int i = 0; > > + unsigned char *b = (unsigned char *)guid; > > + const WCHAR *p = str; > > Please call one of the existing functions for this instead of > reinventing the wheel. I did that at some point but it seemed overkill to me to import ole32 for just one function. I'll change it. -Hans

Dec. 22, 2008