November 2006 - Wine-devel - list.winehq.org

Re: oledlg: Cast-qual warnings fix
by Huw Davies 09 Nov '06

09 Nov '06

On Wed, Nov 08, 2006 at 09:56:54PM +0000, Andrew Talbot wrote: > @@ -666,16 +672,20 @@ > if(psA->cPasteEntries > 0) > { > UINT i; > - for(i = 0; i < psA->cPasteEntries; i++) > + > + for(i = psA->cPasteEntries; i != 0;) Was there any need for this? Huw.

2 1

Re: kernel32: Add basic OpenProcess test, make it pass under Wine
by Alexandre Julliard 08 Nov '06

08 Nov '06

Dmitry Timoshkov <dmitry(a)codeweavers.com> writes: > diff -up a/server/protocol.def b/server/protocol.def > --- a/server/protocol.def 2006-11-06 18:35:52.000000000 +0800 > +++ b/server/protocol.def 2006-11-06 21:57:22.000000000 +0800 > @@ -335,6 +335,7 @@ struct token_groups > /* Retrieve information about a process */ > @REQ(get_process_info) > obj_handle_t handle; /* process handle */ > + unsigned int access; /* wanted access rights */ > @REPLY > process_id_t pid; /* server process id */ > process_id_t ppid; /* server process id of parent */ Enforcing the proper access rights for a given operation is the server's job, it doesn't make sense to allow the client to specify its own access rights. -- Alexandre Julliard julliard(a)winehq.org

1 0

DIBs with negative width/height
by Damjan Jovanovic 08 Nov '06

08 Nov '06

Hi Does anyone know (or know where to find) what it means for biWidth and/or biHeight for a DIB section's BITMAPINFOHEADER to be negative? It seems largely undocumented. The MSDN says a negative biHeight is a top-down bitmap (the normal positive biHeight is bottom-up), so does a negative biWidth mean scanlines run from right to left? Thank you Damjan

1 0

subclass test for comctl32
by Paul Vriens 08 Nov '06

08 Nov '06

Hi, There are no tests run on Wine (or win98/nt4/w2K) when running the subclass tests for comctl32. test.winehq.org shows that tests are run for XP and W2K3. It look like SetWindowSubclass, RemoveWindowSubclass and DefSubclassProc are exported by name on XP and W2K3 and by ordinal on the other ones. How should/can we deal with this? Should we export by name as well? (get rid of the -noname). Or do we need to change the test to first try by name and then by ordinal (or only by ordinal)? Cheers, Paul.

2 1

Re: usp10 #1/2: create HandleTables to keep track of memory allocation.
by Jeff L 08 Nov '06

08 Nov '06

Rob, as the HandleTable was your suggestion, could you provide a comment on whether these patches are a practical way forward? Jeff Latimer Jeff Latimer wrote: > These 2 patches implement HandleTables for tracking memory usage for > the SCRIPT_STRING_ANALYSIS pointer. The problem is that the ssa can > be copied to another pointer and NULL'ing the pointer is not a > reliable means of de-allocating the pointer. The use of HandleTables > looks like a solution to the problem but it depends on whether storing > a handle in the ssa pointer is acceptable. The table is of fixed size > which is another potential problem but tests indicate that the number > of handles in use will remain relatively small by comparison to the > table size. > > Advice is welcome. > > Jeff Latimer > > Changelog: > Create HandleTables to keep track of memory allocation > --- > dlls/usp10/Makefile.in | 2 + > dlls/usp10/usp10.c | 71 > +++++++++++++++++++++++++++++++++++++++++++++++- > 2 files changed, 70 insertions(+), 3 deletions(-) > ------------------------------------------------------------------------ > > diff --git a/dlls/usp10/Makefile.in b/dlls/usp10/Makefile.in > index 9d716d5..edef33a 100644 > --- a/dlls/usp10/Makefile.in > +++ b/dlls/usp10/Makefile.in > @@ -4,7 +4,7 @@ SRCDIR = @srcdir@ > VPATH = @srcdir@ > MODULE = usp10.dll > IMPORTLIB = libusp10.$(IMPLIBEXT) > -IMPORTS = gdi32 kernel32 > +IMPORTS = gdi32 ntdll kernel32 > > C_SRCS = \ > usp10.c > diff --git a/dlls/usp10/usp10.c b/dlls/usp10/usp10.c > index 9fd6c1e..4b15047 100644 > --- a/dlls/usp10/usp10.c > +++ b/dlls/usp10/usp10.c > @@ -30,6 +30,7 @@ #include "wingdi.h" > #include "winuser.h" > #include "winnls.h" > #include "usp10.h" > +#include "winternl.h" > > #include "wine/debug.h" > > @@ -73,17 +74,83 @@ typedef struct scriptcache { > HDC hdc; > } Scriptcache; > > +typedef struct _CACHE_HANDLE > +{ > + RTL_HANDLE RtlHandle; > + void * Cache_Address; > +} CACHE_HANDLE; > + > +DWORD TlsIndex; /* Adress of shared memory */ > + > /*********************************************************************** > * DllMain > * > + * In this DllMain storage is allocated to each thread so that a HandleTable can > + * be created and maintained thread safe. > + * > + * NOTES > + * The Tls functions (TlsAlloc, TlsSetValue, TlsGetValue and TlsFree) provide > + * access to the local thread storage. > + * > + * LocalAlloc and LocalFree are used as in the Microsoft examples to access > + * local thread storage. > + * > + * RtlInitializeHandleTable initialises the handle table to a fixed size of > + * entries to contain the addresses of the cache pointers used in the > + * ScriptString... functions. This function is fairly light weight as the > + * space for the handle table entries is not allocated at this time but waits > + * until the first RtlAllocateHandle call. Hence only the functions that need > + * the handles incur the additional expense. > */ > BOOL WINAPI DllMain(HINSTANCE hInstDLL, DWORD fdwReason, LPVOID lpv) > { > + RTL_HANDLE_TABLE *Cache_HandleTable; > + BOOL Return_flag; > + > switch(fdwReason) { > + /* > + * When the dll is loaded obtain a TlsIndex so that the HandleTable > + * pointer can be stored there uniquely for each thread. > + */ > case DLL_PROCESS_ATTACH: > - DisableThreadLibraryCalls(hInstDLL); > - break; > + if ((TlsIndex = TlsAlloc()) == TLS_OUT_OF_INDEXES) > + return FALSE; > + /* Fall though to THREAD_ATTACH as loading a DLL only drives > + * DLL_PROCESS_ATTACHand not DLL_THREAD_ATTACH. Here we allocate space > + * for the HandleTable from the thread local storage, save the pointer in > + * the Tls and intialise the table. > + */ > + case DLL_THREAD_ATTACH: > + Cache_HandleTable = LocalAlloc(LPTR, sizeof(RTL_HANDLE_TABLE)); > + if (Cache_HandleTable) > + { > + Return_flag = TlsSetValue(TlsIndex, Cache_HandleTable); > + RtlInitializeHandleTable(0x3FFF, sizeof(CACHE_HANDLE), Cache_HandleTable); > + } > + break; > + /* > + * At exit from a thread, clean up HandleTable which includes freeing the > + * associated memory for handles and the HandleTable. > + */ > + case DLL_THREAD_DETACH: > + Cache_HandleTable = TlsGetValue(TlsIndex); > + if (Cache_HandleTable) > + { > + RtlDestroyHandleTable(Cache_HandleTable); > + LocalFree(Cache_HandleTable); > + } > + break; > + /* > + * As for DLL_THREAD_DETACH but includes freeing the TlsIndex. > + */ > case DLL_PROCESS_DETACH: > + Cache_HandleTable = TlsGetValue(TlsIndex); > + if (Cache_HandleTable) > + { > + RtlDestroyHandleTable(Cache_HandleTable); > + LocalFree(Cache_HandleTable); > + } > + TlsFree(TlsIndex); > break; > } > return TRUE; > > > ------------------------------------------------------------------------ > > >

1 0

Big regressions in latest CVS version
by Mirek 07 Nov '06

07 Nov '06

Hi, there is big regression in latest CVS version, i dont know which patch caused it, but it was ok in release 0.9.24. The first regression is in 3DMarks (i tried only 2005 and 2006), startup logo is completly broken, and selection of tests too, second bigger regression is in nvidia SDK demos, all opengl demos are not working now with log like this: athlon64:/usr/games/nvidiaSDK/DEMOS/OpenGL/bin/Release# cvswine glsl_physics.exe err:wgl:process_attach X11DRV or GDI32 not loaded. Cannot create default context. err:module:LdrInitializeThunk "opengl32.dll" failed to initialize, aborting err:module:LdrInitializeThunk Main exe initialization for L"G:\\usr\\games\\nvidiaSDK\\DEMOS\\OpenGL\\bin\\Release\\glsl_physics.exe" failed, status c0000142 athlon64:/usr/games/nvidiaSDK/DEMOS/OpenGL/bin/Release# Tomorow i am going to try find which patch caused such regression. Mirek

4 4

Re: [PATCH 2/2] comctl32: Switch to a Nx4 tiling.
by Kirill K. Smirnov 07 Nov '06

07 Nov '06

> This patch breaks http://angusj.com/sudoku/ This patch breaks toolbars in almost every application, e.g. comdlg32.GetOpenFileName. But Winword 97 was not affected though.

2 1

Re: [PATCH 5/5] winspool.drv: Associate a printer driver with each printer, rather than share a common one between all printers.
by Detlef Riekenberg 07 Nov '06

07 Nov '06

On Di, 2006-11-07 at 14:43 +0000, Huw Davies wrote: > + dep_file[] = "<dependend files?>" REG_MULTI_SZ need a second '\0', but I prefer to remove the Junk and use an empty string. (I have no Idea, if a NULL works on windows, because I have no tests for the AddDriver* - Functions yet) -- By by ... Detlef

1 0

Re: [PATCH 4/5] winspool.drv: Fix AddPrinterDriverA so that the strings actually get written.
by Detlef Riekenberg 07 Nov '06

07 Nov '06

On Di, 2006-11-07 at 14:37 +0000, Huw Davies wrote: > RegSetValueExA(hkeyName, "Dependent Files", 0, REG_MULTI_SZ, > + (LPBYTE) di3.pDependentFiles, > lstrlenA(di3.pDependentFiles) + 1); Hi Huw. Thanks for working on winspool.drv again, but: "lstrlenA(di3.pDependentFiles) + 1" is not correct for REG_MULTI_SZ I suggest: LPSTR ptr; DWORD total; .... total = 0; ptr = di3.pDependentFiles; if (ptr) { while (ptr[0]) { len = lstrlenA(ptr) + 1; /* actual string */ total += len; ptr += len; } total++; /* extra '\0' for REG_MULTI_SZ - termination */ } -- By by ... Detlef

1 0

Re: wined3d: Use width while converting surfaces.
by Stefan Dösinger 07 Nov '06

07 Nov '06

Hi, > - for (x = 0; x < pitch / 2; x++ ) { > + for (x = 0; x < width / 2; x++ ) { This is not quite correct. pitch / 2 was used because in D3DFMT_R5G6B5 pitch = 2* width(Used to be, before my alignment patches). So this line should be for (x = 0; x < width; x++ ) {

1 0