- Wine-Devel - list.winehq.org

[RFC] wintab dll design: how to intergrate with current X11 code.
by Robert North Dec. 22, 2002

Dec. 22, 2002

Ok, I'm about to start some serious implementation on the wintab dll. What I need now is some giudance as to how to proceed, regarding integration with X11 code. Please comment on anything mentioned below. If this is too concise, please ask for further clasification. *****Requirement for interfacing with X11***** To access the graphics tablet, the dll must access the XInput extension to X11. Therefore it needs some level of cooperation/integration with x11_drv. The reqirements are: Access to an XDisplay object. Event dispatch code similar to event.c It must be able to claim XInput events, and expose them through the wintab32.dll interface. Wintab32.dll is defined as having it's own event dispatch system, totally distinct from the win32 system. Access to an X window that contains the wine/win32 window client area. This is available in a win32 property named: __wine_x11_client_window. It is also accessible through x11_drv internals. If necessary, could always use the DefaultRootWindow(display)!. *********Assumptions****** It is bad practice/impossible to call functions from one dll in another, if they are not defined in the .spec file. I'm also assuming the same applies to variables. A call to XOpenDisplay(NULL) will ensure the same display is accessed as in X11_Drv. It is a good idea to call XInput functions in the wintab32.dll. It is a good idea to access the X11 windows needed by the Win32 window's propery. will reqire that the GetProp and GlobalFindAtom functions in wine. Wintab can be given it's own version of WaitForMultipleObjectsEx that will deal solely with XInput events. I'm also assuming that there is no reason why XInput events should occur in ***********Questions******* Is function X11DRV_MsgWaitForMultipleObjectsEx really the place where all X11 events enter the system before being translated into win32/16 events? It appears to be a principle of wine design that all X11 code should live in the x11_drv dll. Therefore, when complete, where should XInput code live? *************Design principles********** Genericity. I would like anything in X11_drv to be as generic as possible. So, Initially, I'd like to keep code in X11_drv to a minimun. Therefore, Given the ideas above, all XInput code is in wintab32.dll! ********** And that's it! *********** Well that's the lot, Please comment Cheers -Rob.

1 1

Conditional to support Solaris
by Robert Lunnon Dec. 22, 2002

Dec. 22, 2002

I need to introduce a compile time conditional to better facilitate Solaris, in particular the macro ADDRESS_SPACE_LIMIT in virtual.c. I understand HAVE_SOLARIS is frowned upon so can anyone suggest a more targetted alternative (Could use __sysv__ but who knows whether all SYSV implementations need to define ADDRESS_SPACE_LIMIT the same way !) Bob

2 2

wine + eBay's auction-tool "MisterLister"
by KatjaundSiegfried.Haas＠t-online.de Dec. 21, 2002

Dec. 21, 2002

Hello everybody - I am not a "developer, but I choose this way to make a suggestion! I tried to start eBay's auction-tool "MisterLister", which allows to edti the auctions offline and do an upload of 100 auctions in one time, with wine - but it doesn't work. I asked at eBay, if other systems then "Windows" are supported in anyway, but they told off. That's quiet unlucky, because that is the only remaining reason for me, to leave the "Windows-partition" on my system! Is there a possibility to start "MisterLister" with wine? I think, that would be a realy useful project, and i guess, a lot of Linux-user would be happy about a soliution "MisterLister-working-on-Linux"?! Thank's for reading and perhaps someone thinks about it Greatings Siegfried

4 3

Re: Conformance tests failing
by chrismorgan＠rcn.com Dec. 21, 2002

Dec. 21, 2002

It looks like my NT4 machine is setup differently than the ones running those tests, or perhaps all default windows installs. The issue is that for LOCALE_SYSTEM_DEFAULT the default format that we are looking for is "h:m:s tt", the one that on the testing machines is "HH:m:s", this results in "8:46 AM" -> "08:56" for TIME_NOSECONDS and "8AM" -> "08" for TIME_NOMINUTESORSECONDS. Not sure what the correct way to resolve this is as it appears the default can change, maybe we shouldn't be testing against the defaults? Afaik these tests pass under wine so maybe wine has incorrect default nls values? Chris > > From: Paul Millar <paulm(a)astro.gla.ac.uk> > Date: 2002/12/20 Fri AM 07:10:27 EST > To: Development to WINE <wine-devel(a)winehq.com> > Subject: Conformance tests failing > > Hi everyone, > > The extra support added by Chris in: > http://cvs.winehq.com/patch.py?id=6743 > doesn't seem be enough for wine to pass all of his new conformance tests > added in: > http://cvs.winehq.com/patch.py?id=6744 > A few of them failed, caused WRT reported: > > locale.c:164: Test failed 1 of 1 time (100%): > [test instance 1] > locale.c:164: Test failed: GetTimeFormat: got 6 instead of 8 > > locale.c:146: Test failed 1 of 1 time (100%): > [test instance 1] > locale.c:146: Test failed: GetTimeFormat got '08' instead of '8 AM' > > locale.c:147: Test failed 1 of 1 time (100%): > [test instance 1] > locale.c:147: Test failed: GetTimeFormat: got 3 instead of 5 > > locale.c:163: Test failed 1 of 1 time (100%): > [test instance 1] > locale.c:163: Test failed: GetTimeFormat got '08:56' instead of '8:56 AM' > > for 95, 98, me, NT, Win2k, ... (the database is still updating at the > moment) > > Details of the build are available at: > http://www.astro.gla.ac.uk/users/paulm/WRT/buildinfo.php?id=271 > > ---- > Paul Millar > > > > >

2 1

Fwd: Get rid of W->A calls: GetPrinterDriverDirectory
by Stefan Leichter Dec. 21, 2002

Dec. 21, 2002

Hello, is there any reason why this patch did not made it into CVS & 20021219? Stefan ---------- Weitergeleitete Nachricht ---------- Subject: Get rid of W->A calls: GetPrinterDriverDirectory Date: Sun, 15 Dec 2002 10:24:44 +0100 From: Stefan Leichter <Stefan.Leichter(a)camLine.com> To: wine-patches(a)winehq.com Hello, after spending some days fixing the read-write errors on my DDYS-T18350 disk here a new patch Changelog ------------ moved implementation of GetPrinterDriverDirectory from ascii to unicode Index: dlls/winspool/info.c =================================================================== RCS file: /home/wine/wine/dlls/winspool/info.c,v retrieving revision 1.61 diff -u -r1.61 info.c --- dlls/winspool/info.c 12 Nov 2002 02:22:24 -0000 1.61 +++ dlls/winspool/info.c 15 Dec 2002 08:40:09 -0000 @@ -41,6 +41,7 @@ #include "winbase.h" #include "winerror.h" #include "winreg.h" +#include "winternl.h" #include "wine/windef16.h" #include "wine/unicode.h" #include "wine/debug.h" @@ -2390,23 +2391,23 @@ } /*************************************************************************** ** - * GetPrinterDriverDirectoryA [WINSPOOL.@] + * GetPrinterDriverDirectoryW [WINSPOOL.@] */ -BOOL WINAPI GetPrinterDriverDirectoryA(LPSTR pName, LPSTR pEnvironment, +BOOL WINAPI GetPrinterDriverDirectoryW(LPWSTR pName, LPWSTR pEnvironment, DWORD Level, LPBYTE pDriverDirectory, DWORD cbBuf, LPDWORD pcbNeeded) { DWORD needed; - TRACE("(%s, %s, %ld, %p, %ld, %p)\n", pName, pEnvironment, Level, - pDriverDirectory, cbBuf, pcbNeeded); + TRACE("(%s, %s, %ld, %p, %ld, %p)\n", debugstr_w(pName), + debugstr_w(pEnvironment), Level, pDriverDirectory, cbBuf, pcbNeeded); if(pName != NULL) { - FIXME("pName = `%s' - unsupported\n", pName); + FIXME("pName = `%s' - unsupported\n", debugstr_w(pName)); SetLastError(ERROR_INVALID_PARAMETER); return FALSE; } if(pEnvironment != NULL) { - FIXME("pEnvironment = `%s' - unsupported\n", pEnvironment); + FIXME("pEnvironment = `%s' - unsupported\n", debugstr_w(pEnvironment)); SetLastError(ERROR_INVALID_ENVIRONMENT); return FALSE; } @@ -2414,10 +2415,16 @@ WARN("Level = %ld - assuming 1\n", Level); /* FIXME should read from registry */ - needed = GetSystemDirectoryA(pDriverDirectory, cbBuf); + needed = GetSystemDirectoryW( (LPWSTR)pDriverDirectory, cbBuf/sizeof(WCHAR)); + /* GetSystemDirectoryW returns number of TCHAR without '\0' + * adjust this now + */ needed++; + needed*=sizeof(WCHAR); + if(pcbNeeded) *pcbNeeded = needed; + TRACE("required <%08lx>\n", *pcbNeeded); if(needed > cbBuf) { SetLastError(ERROR_INSUFFICIENT_BUFFER); return FALSE; @@ -2427,25 +2434,41 @@ /*************************************************************************** ** - * GetPrinterDriverDirectoryW [WINSPOOL.@] + * GetPrinterDriverDirectoryA [WINSPOOL.@] */ -BOOL WINAPI GetPrinterDriverDirectoryW(LPWSTR pName, LPWSTR pEnvironment, +BOOL WINAPI GetPrinterDriverDirectoryA(LPSTR pName, LPSTR pEnvironment, DWORD Level, LPBYTE pDriverDirectory, DWORD cbBuf, LPDWORD pcbNeeded) { - LPSTR pNameA = NULL, pEnvironmentA = NULL; + UNICODE_STRING nameW, environmentW; BOOL ret; - - if(pName) - pNameA = HEAP_strdupWtoA( GetProcessHeap(), 0, pName ); - if(pEnvironment) - pEnvironmentA = HEAP_strdupWtoA( GetProcessHeap(), 0, pEnvironment ); - ret = GetPrinterDriverDirectoryA( pNameA, pEnvironmentA, Level, - pDriverDirectory, cbBuf, pcbNeeded ); - if(pNameA) - HeapFree( GetProcessHeap(), 0, pNameA ); - if(pEnvironmentA) - HeapFree( GetProcessHeap(), 0, pEnvironmentA ); + DWORD pcbNeededW; + INT len = cbBuf * sizeof(WCHAR)/sizeof(CHAR); + WCHAR *driverDirectoryW = NULL; + + if (len) driverDirectoryW = HeapAlloc( GetProcessHeap(), 0, len ); + + if(pName) RtlCreateUnicodeStringFromAsciiz(&nameW, pName); + else nameW.Buffer = NULL; + if(pEnvironment) RtlCreateUnicodeStringFromAsciiz(&environmentW, pEnvironment); + else environmentW.Buffer = NULL; + + ret = GetPrinterDriverDirectoryW( nameW.Buffer, environmentW.Buffer, Level, + (LPBYTE)driverDirectoryW, len, &pcbNeededW ); + if (ret) { + ret = WideCharToMultiByte( CP_ACP, 0, driverDirectoryW, -1, + pDriverDirectory, cbBuf, NULL, NULL); + *pcbNeeded = WideCharToMultiByte( CP_ACP, 0, driverDirectoryW, -1, + NULL, 0, NULL, NULL); + } else + *pcbNeeded = pcbNeededW * sizeof(CHAR)/sizeof(WCHAR); + + TRACE("provided<%ld> required <%ld>\n", cbBuf, *pcbNeeded); + + if(driverDirectoryW) + HeapFree( GetProcessHeap(), 0, driverDirectoryW ); + RtlFreeUnicodeString(&environmentW); + RtlFreeUnicodeString(&nameW); return ret; } -------------------------------------------------------

1 0

Wine 0.9 TODO v0.7
by Dimitrie O. Paun Dec. 21, 2002

Dec. 21, 2002

Hi folks, The next version of the 0.9 TODO is way past due, so I've decided to release it today: http://www.dssd.ca/wine/Wine-0.9-TODO-0.7.html ChangeLog * Bill finished moving CVS docu from User Guide to Devel Guide (B3) * Alexandre implemented import libraries (D3), finished winebuild (D4) * I fixed header location (mostly done by Alexandre :)) (E9) * Status update from Jaco (C2), and Ender (E7) * Brand new Introduction * New tasks added (D5, D6, D7) Check it out, it's fun! :) -- Dimi.

4 5

shlwapi/clist test error on NT4
by Francois Gouget Dec. 21, 2002

Dec. 21, 2002

OPn NT4 the clist shwlwapi test fails on the first call to SHLWAPI_166 (on line 478 here). That call triggers wat looks like an internal check which pops up a nice error window: Debug Error! Program: ...dlls\shlwapi\tests\Output\Win32_MSVC_Headers\shlwapi_test.exe Module: File: i386\chkesp.c Line: 42 The value of ESP was not properly saved accross a function call. This is usually a result of calling a function declared with one calling convention with a function pointer declared with a differen calling convention. (Press Retry to debug the application) Could it be a problem with the way IDummyStream is declared? Maybe the virtual function pointer is off? I noticed that no 'COM' macro was used which sees a bit strange. Or maybe it's a problem with the prototype of SHLWAPI_166? Could someone more knowledgeable with shlwapi investigate this? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Hiroshima '45 - Czernobyl '86 - Windows '95

1 0

Re: Listview report mode tweaks #2
by Dimitrie O. Paun Dec. 20, 2002

Dec. 20, 2002

On December 20, 2002 01:02 pm, Duane Clark wrote: > So the only fix to LISTVIEW_GetSubItemRect that remains is to change the > offset that is applied. This looks great. Another small nit: + if (!(uFormat & (DT_RIGHT | DT_CENTER))) + { + if (himl && lvItem.iImage >= 0 && !IsRectEmpty(&rcIcon)) rcLabel.left += 2; + else rcLabel.left += 5; + } + else if (uFormat & DT_RIGHT) rcLabel.right -= 5; It seems this "5" is the same, so maybe a symbolic constant would be better. Also, it seems the 2 has to do with IMAGE_PADDING which you changed to 0, so maybe a small rearangement can make this thing more clear. What I mean is that you disabled image padding, and you achive it some other way using explicit numbers (2, 5, etc). Turning the logic inside out, maybe we can give meaning back to IMAGE_PADDING. If not, we should remove it and introduce another meaningful constant. -- Dimi.

1 0

Re: rpcdce.h fixes
by Ove Kaaven Dec. 20, 2002

Dec. 20, 2002

On Fri, 20 Dec 2002, Dimitrie O. Paun wrote: > MinGW has them defined this way, and wxWindows likes them like this. > Can someone please check that this matches the Windows headers? It does, but it was more difficult to get things (rpcrt4 in particular) to compile without warnings (or huge piles of typecasts) this way, so I decided to just use LPSTR/LPWSTR instead in the rpc headers. Didn't think it would cause problems. > RPCRTAPI RPC_STATUS RPC_ENTRY > - RpcStringFreeA(LPSTR* String); > + RpcStringFreeA(unsigned char** String); > RPCRTAPI RPC_STATUS RPC_ENTRY > - RpcStringFreeW(LPWSTR* String); > + RpcStringFreeW(unsigned short** String); > #define RpcStringFree WINELIB_NAME_AW(RpcStringFree)

3 3

ThunkTheTemplateHandle and Kazaa
by Ender Dec. 20, 2002

Dec. 20, 2002

Hi all. Trying to run any recent version of Kazaa (Lite) under WINE fails for me, as it trys to call an unimplemented krnl386.exe stub... ordinal 538 (ThunkTheTemplateHandle). After doing a little minimal debugging, all I could see that ordinal doing was messing with some segment pointers and calling ordinal 630 (C16ThkSL). I really have no idea what any of this stuff does (*cough*), although copying the line for ordinal 630 into ordinal 538 makes Kazaa work for me :) I don't suppose anybody with a little more knowledge of this bit of Windows knows what actually goes on here? It'd be nice to see this fixed (properly :) in CVS, as Kazaa is a fairly popular application. Cheers, Ender

2 3