January 2003 - Wine-Devel - list.winehq.org

what does __leave do?
by Greg Turner Jan. 13, 2003

Jan. 13, 2003

Could someone run the following code under a microsoft compiler for me, and let me know the result? main() { int x = 0; __try { x = 1; __leave; } __finally { x = 2; } printf("x was %d\n", x); } thanks, -- gmt "If everyone is thinking alike then somebody isn't thinking." --George S. Patton

2 2

Sysparams registry tests
by Francois Gouget Jan. 13, 2003

Jan. 13, 2003

Here are the failing user32/sysparams registry tests on Win95, Win98 and NT4. sysparams.c:676:testing SPI_{GET,SET}MENUDROPALIGNMENT sysparams.c:161: Test failed: Wrong value in registry: subKey=Software\Microsoft\Windows NT\CurrentVersion\Windows, valName=MenuDropAlignment, testValue=1, value= sysparams.c:161: Test failed: Wrong value in registry: subKey=Software\Microsoft\Windows NT\CurrentVersion\Windows, valName=MenuDropAlignment, testValue=0, value= -> on Win9x this is in Control Panel\desktop sysparams.c:711:testing SPI_{GET,SET}DOUBLECLKWIDTH sysparams.c:161: Test failed: Wrong value in registry: subKey=Control Panel\Mouse, valName=DoubleClickWidth, testValue=0, value= sysparams.c:161: Test failed: Wrong value in registry: subKey=Control Panel\Mouse, valName=DoubleClickWidth, testValue=10000, value= -> on Win9x this is in Control Panel\desktop sysparams.c:741:testing SPI_{GET,SET}DOUBLECLKHEIGHT sysparams.c:161: Test failed: Wrong value in registry: subKey=Control Panel\Mouse, valName=DoubleClickHeight, testValue=0, value= sysparams.c:161: Test failed: Wrong value in registry: subKey=Control Panel\Mouse, valName=DoubleClickHeight, testValue=10000, value= -> on Win9x this is in Control Panel\desktop sysparams.c:644:testing SPI_{GET,SET}ICONTITLEWRAP sysparams.c:161: Test failed: Wrong value in registry: subKey=Control Panel\Desktop\WindowMetrics, valName=IconTitleWrap, testValue=1, value= sysparams.c:161: Test failed: Wrong value in registry: subKey=Control Panel\Desktop\WindowMetrics, valName=IconTitleWrap, testValue=0, value= -> on NT4 this is in Control Panel\Desktop Notice how this is not even a clean separation between NT OSes and Win9x ones: Win9x aligns with XP for SPI_SETICONTITLEWRAP but not NT4, while for the other settings it's the opposite. Anyway, is it worth keeping these tests? That is making sure that SPI_xxx stores the setting in the registry key we expect? Do we know of applications that depend on these specific settings? If not then I will just submit a patch to remove these checks. Or maybe Wine should store these settings in all known locations? Note that I already removed these tests for SPI_ICONHORIZONTALSPACING and SPI_ICONVERTICALSPACING because for these Windows does not even always store the same value: sometimes it's the value we provide but most of the time that value seems to be multiplied by -15 (resulting in the negative number!). And the -15 changes to anothe value if you change the icon size. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ tcA thgirypoC muinelliM latigiD eht detaloiv tsuj evah uoY

1 0

Re: user32.SendMessageCallback
by Alexandre Julliard Jan. 13, 2003

Jan. 13, 2003

"Robert Shearman" <R.J.Shearman(a)warwick.ac.uk> writes: > ChangeLog: > - Fix SendMessageCallback so that it works in all cases now You can't do it that way, the callback has to be called in the context of the thread that sent the message. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: tests for GetPrinterDriverDirectoryA
by Francois Gouget Jan. 13, 2003

Jan. 13, 2003

On Tue, 7 Jan 2003, Stefan Leichter wrote: > Hello, > > here are some tests for GetPrinterDriverDirectoryA. They should pass on NT4 > and hopefully win95 too. Thanks to Francois Gouget for testing. I see this test has not been committed yet... I tested it and it works on Win95, Win98, NT4 and XP. It's a much better score than some other tests... However it fails on Wine: info.c:25: Test failed: pcbNeeded set to 18 instead of 19 info.c:30: Test failed: pcbNeeded set to 18 instead of 19 info.c:34: Test failed: expected result == 0, got 18 info.c:35: Test failed: pcbNeeded set to 18 instead of 19 info.c:48: Test failed: expected result != 0, got 0 info.c:71: Test failed: expected result != 0, got 0 The easy solution is to just wrap the relevant tests in a 'todo_wine'. The better one is to fix Wine... Or if the fix is too long to do, wrap with todo_wine now so the test can be committed now, and then fix Wine and remove the relevant todo_wine statements after each fix. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ f u kn rd ts, ur wy 2 gky 4 ur wn gd.

2 2

Re: Re: The version info patches + d3d question
by fenix＠club-internet.fr Jan. 13, 2003

Jan. 13, 2003

----Message d'origine---- >Date: Mon, 13 Jan 2003 16:04:10 +0100 >De: Lionel Ulmer <lionel.ulmer(a)free.fr> >A: fenix(a)club-internet.fr >Copie à: farmboy1(a)subdimension.com, wine-devel(a)winehq.com >Sujet: Re: The version info patches + d3d question > >> >the problem is they dont run even with the patches because they cant get >> >version info from d3dim.dll and probably other d3d dlls. >> >since wine doesnt have these dlls how can wine give these programs the needed >> >info or is it planned to split ddraw in a ddraw and a d3d component? >> >> actually, we are speaking about d3d architecture, but it will be possible to implement d3dim.dll (minors d3d calls) into near future using the "new" codebase. >> And d3d component (for version 3..7) is contained into ddraw.dll > >I don't even know WHAT d3dim.dll is :-) What does it contain for API ? d3dim.dll - D3DFree - D3DMalloc - D3DRealloc - Direct3DCreateDevice - Direct3DCreateTexture - Direct3DGetSWRastZPixFmts - Direct3DCreate - Direct3D_HALCleanUp - FlushD3DDevices2 - FlushD3DDevices - PaletteAssociateNotify - PaletteUpdateNotify - SurfaceFlipNotify d3dim700.dll - D3DFree - D3DMalloc - D3DRealloc - Direct3DCreateDevice - CreateTexture - D3DBreakVBLock - D3DTextureUpdate - DestroyTexture - Direct3DCreate - Direct3D_HALCleanUp - FlushD3DDevices - GetLOD - GetPriority - PaletteAssociateNotify - PaletteUpdateNotify - SetLOD - SetPriority - SurfaceFlipNotify >I know about D3DRM.DLL (that won't be supported) for the 'retained mode' API >but I thought that all 'immediate mode' API was in ddraw.dll and not in a >separate library. yes, you are right. d3dim is only some utilities functions and interfaces for d3d immediate mode. (with d3d8 most of the code of d3dim and d3dxof was moved into d3dx8) >Why not first test with an empty DLL with just the version ressources in it >and see if it's enough ? maybe with only emtpy stubs now :) > Lionel Raphael

1 0

Re: The version info patches + d3d question
by fenix＠club-internet.fr Jan. 13, 2003

Jan. 13, 2003

----Message d'origine---- >De: Enrico Horn <farmboy1(a)subdimension.com> >A: wine-devel(a)winehq.com >Sujet: The version info patches + d3d question >Date: Mon, 13 Jan 2003 14:47:31 +0100 > >Hi, Hi, >The patches add version info to directx libraries. >some games(for instance lucasarts games) wont run without finding a valid >version of the directx files. thanks, maybe you can do the same for d3d8 :) >the problem is they dont run even with the patches because they cant get >version info from d3dim.dll and probably other d3d dlls. >since wine doesnt have these dlls how can wine give these programs the needed >info or is it planned to split ddraw in a ddraw and a d3d component? actually, we are speaking about d3d architecture, but it will be possible to implement d3dim.dll (minors d3d calls) into near future using the "new" codebase. And d3d component (for version 3..7) is contained into ddraw.dll >Have fun >Enrico Regards, Raphael

2 1

The version info patches + d3d question
by Enrico Horn Jan. 13, 2003

Jan. 13, 2003

Hi, The patches add version info to directx libraries. some games(for instance lucasarts games) wont run without finding a valid version of the directx files. the problem is they dont run even with the patches because they cant get version info from d3dim.dll and probably other d3d dlls. since wine doesnt have these dlls how can wine give these programs the needed info or is it planned to split ddraw in a ddraw and a d3d component? Have fun Enrico

1 0

Direct3D/OpenGL compilation error
by Francois Gouget Jan. 13, 2003

Jan. 13, 2003

One of the machines I compile on from time to time is an old RedHat 6.2 which is nice because it still has glibc 2.1.3 so the binaries it produces work on all Linux distributions. Anyway, the latest Wine does not compile anymore on that machine. I get: gcc -c -I. -I. -I../../include -I../../include -I/usr/X11R6/include -g -O2 -Wall -gstabs+ -fPIC -D__WINESRC__ -D_REENTRANT -o device.o device.c device.c: In function `SOURCEx_RGB_EXT': device.c:859: `GL_SOURCE2_RGB_EXT' undeclared (first use in this function) device.c:859: (Each undeclared identifier is reported only once device.c:859: for each function it appears in.) device.c:860: `GL_SOURCE0_RGB_EXT' undeclared (first use in this function) device.c:861: `GL_SOURCE1_RGB_EXT' undeclared (first use in this function) device.c:869: warning: control reaches end of non-void function device.c: In function `OPERANDx_RGB_EXT': device.c:872: `GL_OPERAND2_RGB_EXT' undeclared (first use in this function) device.c:873: `GL_OPERAND0_RGB_EXT' undeclared (first use in this function) device.c:874: `GL_OPERAND1_RGB_EXT' undeclared (first use in this function) device.c:882: warning: control reaches end of non-void function device.c: In function `SOURCEx_ALPHA_EXT': device.c:885: `GL_SOURCE2_ALPHA_EXT' undeclared (first use in this function) device.c:886: `GL_SOURCE0_ALPHA_EXT' undeclared (first use in this function) device.c:887: `GL_SOURCE1_ALPHA_EXT' undeclared (first use in this function) device.c:895: warning: control reaches end of non-void function device.c: In function `OPERANDx_ALPHA_EXT': device.c:898: `GL_OPERAND2_ALPHA_EXT' undeclared (first use in this function) device.c:899: `GL_OPERAND0_ALPHA_EXT' undeclared (first use in this function) device.c:900: `GL_OPERAND1_ALPHA_EXT' undeclared (first use in this function) device.c:908: warning: control reaches end of non-void function device.c: In function `IDirect3DDevice8Impl_SetTextureStageState': device.c:3312: `GL_PREVIOUS_EXT' undeclared (first use in this function) device.c:3314: `GL_PRIMARY_COLOR_EXT' undeclared (first use in this function) device.c:3318: `GL_CONSTANT_EXT' undeclared (first use in this function) device.c:3350: `GL_COMBINE_ALPHA_EXT' undeclared (first use in this function) device.c:3350: `GL_COMBINE_RGB_EXT' undeclared (first use in this function) device.c:3409: `GL_RGB_SCALE_EXT' undeclared (first use in this function) device.c:3423: `GL_ADD_SIGNED_EXT' undeclared (first use in this function) So is it just that the OpenGL headers on that machine are hopelessly out of date (mesa 3.3) or is there some configure test that can/should be done? Note that if I compile with --without-opengl Wine compiles ok so it's not so bad. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ f u kn rd ts, ur wy 2 gky 4 ur wn gd.

1 0

Developers current e-mail addresses listed in authors.ent
by Tom Wickline Jan. 13, 2003

Jan. 13, 2003

I am getting ready to update the WINE Packagers Guide See : http://www.winehq.com/Docs/wine-pkg/ And the first thing that I noticed was Andreas & Marcus e-mail address were incorrect. So I then looked at : http://cvs.winehq.com/cvsweb/~checkout~/wine/documentation/authors.ent?rev=… And found that alot of other's were different from my Address Book. I have listed them below Current is what is now there current address in the *authors.ent* file. And below is the addresses that is listed in my address book. There are also a couple DOA addresses listed in this file and there at the bottom. I dont want to change this file and not have people's e-mail correct! So can everyone look over the file and let me know if your e-mail needs to be changed ?? Also a couple people below have multiable addresses can you let me know what address you want listed. Tom Current = ovek(a)winehq.com Ove Kaaven <ovek(a)arcticnet.no Ove Kaaven <ovehk(a)ping.uio.no ovek <ovek(a)transgaming.com --- Current = Marcus.Meissner(a)caldera.de Marcus Meissner <marcus(a)jet.franken.de Marcus Meissner <mm(a)lst.de ---- Current = amohr(a)codeweavers.com Andreas Mohr <andi(a)rhlx01.fht-esslingen.de --- Current = Speeddymon(a)yahoo.com Dustin Navea <Speeddymon(a)sbcglobal.net --- Current = dimi(a)cs.toronto.edu "Dimitrie O. Paun" <dpaun(a)rogers.com --- Current = juergen.schmied(a)metronet.de juergen schmied <juergen.schmied(a)debitel.net DOA addresses Should I leave them or remove them ?? douglas-ridgway "ridgway(a)winehq.com"> john-sheets "jsheets(a)codeweavers.com">

2 2

Re: Bug Fix With Delay load function in Shell32 (version2)
by Dimitrie O. Paun Jan. 12, 2003

Jan. 12, 2003

On January 12, 2003 12:08 pm, Robert Shearman wrote: > Index: shellole.c Please make your patches relative to wine's root. > -HINSTANCE hShellOle32 = 0; > +HINSTANCE g_hShellOle32 = 0; /* global handle to ole32.dll */ Also, please do not introduce ugly naming conventions like the above, especially when the style the DLL is written in does not call for it. In general, we have none of these conventions in Wine, and it's preferable to just avoid them. We have a bunch of others though. :) -- Dimi.

1 0