February 2007 - Wine-Devel - list.winehq.org

Bug 4791 - Civ4 crashes because of recent explorer/systray changes
by Fabian Bieler Feb. 6, 2007

Feb. 6, 2007

Hello! I tried to look into Bug 4791 (Civ4 crashes because of recent explorer/systray changes http://bugs.winehq.org/show_bug.cgi?id=4791 ). Pretty early during initialization (before the application creates any windows itsself) a WM_FONTCHANGE message is broadcasted. The only window to which the message gets actually send is the Wine Systray Listener window. The message is immediately pulled by peek_message as a MSG_NOTIFY message. A few seconds later the WM_FONTCHANGE message is pulled from the queue of the Wine Systray Listener window again, this time of the type MSG_CALLBACK. the callback function pointer is a nullpointer resulting in a pagefault. If the Wine Desktop window is set as its own parent (like described in the bugzilla thread), the WM_FONTCHANGE message does not get send to the window and the program starts up fine. Now, I do not really understand the wine messaging system (particularly the difference between notify and callback messages) so I thought maybe somebody here could help me with that or point me to some introduction other than http://winehq.org/site/docs/winedev-guide/c3762#AEN3825 and message.c. Should the fontchange-message really be send to the Wine Systray Listener window? All test were run using wine-0.9.30, civ4 v1.61 with nocd-patch and native msxml3. Fabian

1 1

Presenting at LinuxTag?
by Dan Kegel Feb. 6, 2007

Feb. 6, 2007

David asked if anyone's interested in manning a Wine booth at Linuxtag. A related question: is anybody proposing a Wine talk or tutorial at Linuxtag? The deadline for submitting proposals is Feb 16th. (Here's the CFP: http://www.linuxtag.org/2007/en/conf/cfp/cfp-target.html )

1 0

Daylight saving changes
by Francois Gouget Feb. 6, 2007

Feb. 6, 2007

Quite a few countries seem to be changing their daylight saving rules this year. Also Wine stores timezone information in the registry so won't we need to update the data we store in the registry? While looking at wine's timezone data I also found quite a few differences with Windows' data. Hence the question: Where does wine.inf's current data come from? Where can one find authoritative data for this? Does any one have an opinion on what to do about those? * wine.inf's TZI field does not match Windows for these time zones: Won't this impact email tools? Arabic Standard Time Azores Standard Time Caucasus Standard Time Dateline Standard Time E. South America Standard Time GTB Standard Time Iran Standard Time Israel Standard Time New Zealand Standard Time Newfoundland Standard Time Pacific SA Standard Time * wine.inf is missing some time zones: Ekaterinburg Standard Time Greenland Standard Time Mid-Atlantic Standard Time Nepal Standard Time Sri Lanka Standard Time W. Central Africa Standard Time * wine.inf has an extra time zone: Mexico Standard Time 2 * Wine's display name is not in the same format as the Windows one: For instance for Tonga Standard Time: Windows has: "Display"="(GMT+13:00) Nuku'alofa" Wine has : "Display"="Pacific/Tongatapu" -- Francois Gouget fgouget(a)codeweavers.com

2 1

[PATCH] make CarbonPoker (previously Poker.com) client work.
by Trent Waddington Feb. 6, 2007

Feb. 6, 2007

These changes make the Carbon Poker (www.carbonpoker.com) client work. Run the Carbon Poker installer; then Run c:/windows/system32/Macromed/Flash/GetFlash.exe; then Run c:/windows/CarbonPoker/Poker.exe Screenshot: http://rtfm.insomnia.org/~qg/CarbonPoker-Ubuntu-wine.png If someone would like to implement PKCS7 support in crypt32, this patch could be much cleaner. --- ChangeLog | 15 +++++++++++++++ dlls/crypt32/cert.c | 16 ++++++++++++++++ dlls/crypt32/crypt32.spec | 2 +- dlls/crypt32/main.c | 12 +++++++++++- dlls/crypt32/store.c | 4 ++++ dlls/usp10/usp10.c | 33 +++++++++++++++++++++++++++++++++ dlls/usp10/usp10.spec | 2 +- dlls/wininet/http.c | 4 ++-- 8 files changed, 83 insertions(+), 5 deletions(-) diff --git a/ChangeLog b/ChangeLog index 658036c..297fb08 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,18 @@ +2007-02-06 Trent Waddington <trent.waddington(a)gmail.com> + + * dlls/crypt32/cert.c: + dlls/crypt32/main.c: + dlls/crypt32/store.c: + dlls/crypt32/crypt32.spec: + crypt32: Hacks to make Macromedia's GetFlash.exe not complain about the lack of PKCS7 support. + + * dlls/usp10/usp10.c: + dlls/usp10/usp10.spec: + usp10: Implemented ScriptGetLogicalWidths. + + * dlls/wininet/http.c: + wininet: Implement a feature of HttpOpenRequestA where lpszAcceptTypes can be terminated with an empty string instead of a NULL. + 2007-01-24 Vitaliy Margolen <wine-patches(a)kievinfo.com> * server/token.c: diff --git a/dlls/crypt32/cert.c b/dlls/crypt32/cert.c index b39c3ca..e3ed7e0 100644 --- a/dlls/crypt32/cert.c +++ b/dlls/crypt32/cert.c @@ -130,6 +130,10 @@ BOOL WINAPI CertFreeCertificateContext(PCCERT_CONTEXT pCertContext) { TRACE("(%p)\n", pCertContext); + // HACK for GetFlash.exe + if (pCertContext == 0xdeadbeef) + return TRUE; + if (pCertContext) Context_Release((void *)pCertContext, sizeof(CERT_CONTEXT), CertDataContext_Free); @@ -921,6 +925,12 @@ PCCERT_CONTEXT WINAPI CertFindCertificateInStore(HCERTSTORE hCertStore, TRACE("(%p, %d, %d, %d, %p, %p)\n", hCertStore, dwCertEncodingType, dwFlags, dwType, pvPara, pPrevCertContext); + // HACK for GetFlash.exe + if (hCertStore == 0xdeadbeef) { + ret = 0xdeadbeef; + return ret; + } + switch (dwType >> CERT_COMPARE_SHIFT) { case CERT_COMPARE_ANY: @@ -987,6 +997,12 @@ BOOL WINAPI CertVerifySubjectCertificateContext(PCCERT_CONTEXT pSubject, static const DWORD supportedFlags = CERT_STORE_REVOCATION_FLAG | CERT_STORE_SIGNATURE_FLAG | CERT_STORE_TIME_VALIDITY_FLAG; + // HACK for GetFlash.exe + if (pSubject == 0xdeadbeef || pIssuer == 0xdeadbeef) { + *pdwFlags = 0; + return TRUE; + } + if (*pdwFlags & ~supportedFlags) { SetLastError(E_INVALIDARG); diff --git a/dlls/crypt32/crypt32.spec b/dlls/crypt32/crypt32.spec index 7ee23f4..705fb8f 100644 --- a/dlls/crypt32/crypt32.spec +++ b/dlls/crypt32/crypt32.spec @@ -118,7 +118,7 @@ @ stub CryptGetAsyncParam @ stdcall CryptGetDefaultOIDDllList(long long ptr ptr) @ stdcall CryptGetDefaultOIDFunctionAddress(long long wstr long ptr ptr) -@ stub CryptGetMessageCertificates +@ stdcall CryptGetMessageCertificates(long long long ptr long) @ stub CryptGetMessageSignerCount @ stdcall CryptGetOIDFunctionAddress(long long str long ptr ptr) @ stdcall CryptGetOIDFunctionValue(long str str wstr ptr ptr ptr) diff --git a/dlls/crypt32/main.c b/dlls/crypt32/main.c index dd9e1fb..80567ab 100644 --- a/dlls/crypt32/main.c +++ b/dlls/crypt32/main.c @@ -238,5 +238,15 @@ BOOL WINAPI CryptVerifyMessageSignature(PCRYPT_VERIFY_MESSAGE_PARA pVerifyPara, FIXME("stub: %p, %d, %p, %d, %p, %p, %p\n", pVerifyPara, dwSignerIndex, pbSignedBlob, cbSignedBlob, pbDecoded, pcbDecoded, ppSignerCert); - return FALSE; + return TRUE; +} + +HCERTSTORE WINAPI CryptGetMessageCertificates(DWORD dwMsgAndCertEncodingType, + HCRYPTPROV hCryptProv, DWORD dwFlags, const BYTE* pbSignedBlob, + DWORD cbSignedBlob) +{ + FIXME("stub: %d, %p, %d, %p, %d\n", + dwMsgAndCertEncodingType, hCryptProv, dwFlags, pbSignedBlob, + cbSignedBlob); + return 0xdeadbeef; // HACK for GetFlash.exe } diff --git a/dlls/crypt32/store.c b/dlls/crypt32/store.c index 8c8cda5..c82fcbc 100644 --- a/dlls/crypt32/store.c +++ b/dlls/crypt32/store.c @@ -2431,6 +2431,10 @@ BOOL WINAPI CertCloseStore(HCERTSTORE hCertStore, DWORD dwFlags) TRACE("(%p, %08x)\n", hCertStore, dwFlags); + // HACK for GetFlash.exe + if (hCertStore == 0xdeadbeef) + return TRUE; + if( ! hCertStore ) return TRUE; diff --git a/dlls/usp10/usp10.c b/dlls/usp10/usp10.c index c3b0a17..6f860e0 100644 --- a/dlls/usp10/usp10.c +++ b/dlls/usp10/usp10.c @@ -1553,6 +1553,39 @@ HRESULT WINAPI ScriptStringGetLogicalWidths(SCRIPT_STRING_ANALYSIS ssa, int *piD } /*********************************************************************** + * ScriptGetLogicalWidths (USP10.@) + * + * Returns logical widths from an analysis. + * + * PARAMS + * psa [I] analysis. + * cChars [I] count of logical code points in the run. + * cGlyphs [I] count of glyphs in the run. + * piGlyphWidth [I] array of glyph advance widths. + * pwLogClust [I] array of logical clusters. + * psva [I] visual attributes. + * piDx [O] logical widths returned. + * + * RETURNS + * Success: S_OK + * Failure: a non-zero HRESULT. + */ +HRESULT WINAPI ScriptGetLogicalWidths(const SCRIPT_ANALYSIS *psa, int cChars, + int cGlyphs, const int *piGlyphWidth, const WORD *pwLogClust, + const SCRIPT_VISATTR *psva, int *piDx) +{ + int i; + + TRACE("%p, %d, %d, %p %p, %p, %p\n", psa, cChars, cGlyphs, piGlyphWidth, pwLogClust, psva, piDx); + + for (i = 0; i < cGlyphs; i++) + { + piDx[i] = piGlyphWidth[i]; + } + return S_OK; +} + +/*********************************************************************** * ScriptStringValidate (USP10.@) * * Validate a string analysis. diff --git a/dlls/usp10/usp10.spec b/dlls/usp10/usp10.spec index df07f43..ac1506e 100644 --- a/dlls/usp10/usp10.spec +++ b/dlls/usp10/usp10.spec @@ -8,7 +8,7 @@ @ stdcall ScriptGetCMap(ptr ptr ptr long long ptr) @ stdcall ScriptGetFontProperties(long ptr ptr) @ stdcall ScriptGetGlyphABCWidth(ptr ptr long ptr) -@ stub ScriptGetLogicalWidths +@ stdcall ScriptGetLogicalWidths(ptr long long ptr ptr ptr ptr) @ stdcall ScriptGetProperties(ptr long) @ stdcall ScriptIsComplex(wstr long long) @ stdcall ScriptItemize(wstr long long ptr ptr ptr ptr) diff --git a/dlls/wininet/http.c b/dlls/wininet/http.c index 8a34749..379b03e 100644 --- a/dlls/wininet/http.c +++ b/dlls/wininet/http.c @@ -803,11 +803,11 @@ HINTERNET WINAPI HttpOpenRequestA(HINTERNET hHttpSession, if (lpszAcceptTypes) { /* find out how many there are */ - while (lpszAcceptTypes[acceptTypesCount]) + while (lpszAcceptTypes[acceptTypesCount] && *lpszAcceptTypes[acceptTypesCount]) acceptTypesCount++; szAcceptTypes = HeapAlloc(GetProcessHeap(), 0, sizeof(WCHAR *) * (acceptTypesCount+1)); acceptTypesCount = 0; - while (lpszAcceptTypes[acceptTypesCount]) + while (lpszAcceptTypes[acceptTypesCount] && *lpszAcceptTypes[acceptTypesCount]) { len = MultiByteToWideChar(CP_ACP, 0, lpszAcceptTypes[acceptTypesCount], -1, NULL, 0 ); -- 1.4.4.3

4 5

Re: user32: WM_SETFONT on button doesn't repaint directly
by Dmitry Timoshkov Feb. 6, 2007

Feb. 6, 2007

"Clinton Stimpson" <cjstimpson(a)utwire.net> wrote: > This patch fixes WM_SETFONT on a button to not paint directly. Instead, > it calls InvalidateRect. > A test is included that demonstrates that no paint events come out of > sending a WM_SETFONT. > > > Thanks, > Clinton Stimpson > > ChangeLog: > Setting font on button doesn't repaint directly. I think that your previous version of the test that called UpdateWindow and demonstrated that WM_SETFONT triggers full painting sequence was more correct. I have no idea though why it has not been accepted. Also, as a way to simplify the test there is no need to create a font, I'd suggest to use GetStockObject to retrieve a handle to one of the stock fonts. -- Dmitry.

1 0

It's that time again - time to start thinking about WineConf 2007!
by Jeremy White Feb. 6, 2007

Feb. 6, 2007

So we can ask, once again: when will 1.0 ship!?!?! I'd invite anyone with an interest in attending to subscribe to the Wineconf mailing list: http://www.winehq.org/mailman/listinfo/wineconf I think an approach that makes sense is for us to discuss options as to where to hold it this year on that list, and then present either a consensus or choices back to the wine-devel list once we're done. So please come join us, particularly if you have a suggestion or preference for where it should be held! Cheers, Jeremy p.s. I think Wine will go 1.0 in the same year that is the year of Linux on the Desktop <evil grin>.

5 6

msi patch: Is this too hacky?
by Misha Koshelev Feb. 6, 2007

Feb. 6, 2007

Hi, I submitted the following patch to wine-patches but was thinking about it some more. The problem is that you have the following UI levels and flags: INSTALLUILEVEL_NOCHANGE = 0, INSTALLUILEVEL_DEFAULT = 1, INSTALLUILEVEL_NONE = 2, INSTALLUILEVEL_BASIC = 3, INSTALLUILEVEL_REDUCED = 4, INSTALLUILEVEL_FULL = 5, INSTALLUILEVEL_HIDECANCEL = 0x20, INSTALLUILEVEL_PROGRESSONLY = 0x40, INSTALLUILEVEL_ENDDIALOG = 0x80, INSTALLUILEVEL_SOURCERESONLY = 0x100 and the code to check for the level was: if ( msi_get_property_int(package, szUILevel, 0) >= INSTALLUILEVEL_REDUCED) but the problem is that if any of the flags are set, then immediately this would assume full UI install even though this is not the case for some installers (see bug #6992). I proposed this change: if ( (msi_get_property_int(package, szUILevel, 0) & INSTALLUILEVEL_FULL) >= INSTALLUILEVEL_REDUCED ) It will work because INSTALLUILEVEL_FULL is 4+1 and so doing an AND operation with INSTALLUI_LEVEL FULL will be 4+1 and with INSTALLUILEVEL_REDUCED will be 4, both of which are greater than or equal to four. However, if for some reason these UI levels were to change in the future, or if someone decided to further modify this code and say, try to check for INSTALLUILEVEL_BASIC (3) they would actually be getting a 1 instead by doing INSTALLUILEVEL_BASIC & INSTALLUILEVEL_FULL. So is this too hacky? Is there a simple, better way to do this? Thanks Misha

2 2

Re: msvcrt: implement _mbbtype according to MSDN
by Dmitry Timoshkov Feb. 6, 2007

Feb. 6, 2007

"Juan Lang" <juan_lang(a)yahoo.com> wrote: > /********************************************************************* > + * _mbbtype(MSVCRT.@) > + */ > +int CDECL _mbbtype(unsigned char c, int type) > +{ > + if (type == 1) > + { > + if ((c >= 0x20 && c <= 0x7e) || (c >= 0xa1 && c <= 0xdf)) > + return _MBC_SINGLE; > + else if ((c >= 0x40 && c <= 0x7e) || (c >= 0x80 && c <= 0xfc)) > + return _MBC_TRAIL; > + else > + return _MBC_ILLEGAL; > + } > + else > + { > + if ((c >= 0x20 && c <= 0x7e) || (c >= 0xa1 && c <= 0xdf)) > + return _MBC_SINGLE; > + else if ((c >= 0x81 && c <= 0x9f) || (c >= 0xe0 && c <= 0xfc)) > + return _MBC_LEAD; > + else > + return _MBC_ILLEGAL; > + } Since MSVCRT_mbctype array is not currently being initialized, probably using MSVCRT_current_ctype would be good enough for now. -- Dmitry.

1 0

Dead links
by Francois Gouget Feb. 6, 2007

Feb. 6, 2007

I found some dead links on WineHQ. hat should we do about them? Does anyone want to hunt them down to see if they have simply moved elsewhere? There are also a bunch of dead links related to the Wine mailing lists. We cannot simply remove those :-( On the Wine Press page: http://www.winehq.org/site/press * Luhit July 1, 2006 - CrossOver Wine to join the party with BootCamp & Parallels http://luhit.wordpress.com/2006/07/01/mac-crossover-wine-to-join-the-party-… * OSViews September 13, 2004 - ReactOS - The Open Source Windows NT http://www.osviews.com/modules.php?op=modload&name=News&file=article&sid=14… * OSViews May 30, 2004 - SpecOpS Labs response to Wine Project http://www.osviews.com/modules.php?op=modload&name=News&file=article&sid=14… * OrangeCrate May 20, 2004 - An Interview with Jeremy White, CodeWeavers http://www.orangecrate.com/article.php?sid=710 * OSViews October 28, 2003 - Macromedia and Adobe Graphics Suites to Run on Linux http://www.osviews.com/modules.php?op=modload&name=News&file=article&sid=35… * ConsultingTimes October 17, 2002 - CodeWeavers/Xandros Deal: "Let the Revolution Begin!" http://www.consultingtimes.com/articles/codeweavers/codeweaversxandros.html And another one on the Fun Projects page: http://www.winehq.org/site/fun_projects * http://www.trolltech.com/products/qt/windows.html * http://www.winehq.org/hypermail/wine-devel/2003/01/0153.html * http://www.winehq.org/hypermail/wine-devel/2003/04/0324.html * http://www.winehq.org/hypermail/wine-patches/2002/09/0250.html * http://www.winehq.org/hypermail/wine-cvs/2003/12/0051.html And on the Winelib page there are a bunch of dead hypermail mailing list URLs. Unfortunately there appears to be no easy way to map them to the pipermail archives :-( http://www.winehq.org/site/winelib * http://www.winehq.org/hypermail/wine-devel/2004/04/0192.html * http://www.winehq.org/hypermail/wine-patches/2003/04/0237.html + 6 more * Erwin Wolff http://www.winehq.org/site/erwinwolffnl(a)microformatica.com And on the Resources page: http://www.winehq.org/site/resources * WinDoc http://leb.net/wine/WinDoc/ * X2 http://sunsite.lanet.lv/ftp/mirror/x2ftp/msdos/programming/00Main.html * comp.fonts http://rcum.uni-mb.si/local/fontfaq/cf_1.htm * Internet Font Archive http://rcum.uni-mb.si/local/fontfaq/cf_18.htm#GLOSS6 * Curvesoft http://www.curvesoft.com/tools.html -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ "Lotto: A tax on people who are bad at math." -- unknown "Windows: Microsoft's tax on computer illiterates." -- WE7U

4 5

Donation for your work on Direct 3D
by Mirek Feb. 6, 2007

Feb. 6, 2007

Hi Stefan and Henry, i would like to send you 35 EUR or 45 USD for your work on Direct 3D in wine, how can i do that? Can you send me your account number and prefered currency? Mirek Slugeň Czech Republic

4 3

Re: [Bug 6689] Created links do not reflect WINEPREFIX used
by Lei Zhang Feb. 5, 2007

Feb. 5, 2007

Setting the Exec= line in a .desktop file to: WINEPREFIX=foo wine bar worked in KDE. In Gnome, it works if "run from the terminal" is set. Unfortunately the Freedesktop spec for desktop entries does not specify a way to add environment variables. So yes, it looks like we'll need a wrapper script, or perhaps add a --prefix option to Wine? On 1/27/07, Wine Bugs <wine-bugs(a)winehq.org> wrote: > http://bugs.winehq.org/show_bug.cgi?id=6689 > > > > > > ------- Additional Comments From vitaliy(a)kievinfo.com 2007-28-01 01:49 ------- > This is not going to work - it's not standard compliant. And I think it won't > work on Gnome either. The only way this can be fixed atm is using some wrapper > script. > > -- > Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are the assignee for the bug, or are watching the assignee. > > >

4 4

Re: [msvcrt] properly align struct _stati64's st_size
by Dmitry Timoshkov Feb. 5, 2007

Feb. 5, 2007

"Damjan Jovanovic" <damjan.jov(a)gmail.com> wrote: > In wine's struct _stati64, st_size has an offset of 20 bytes from the > beginning of the struct, unlike mingw's and Window's 24. This breaks > Java 1.4.x pretty badly, it dies on startup complaining about a > truncated class file (#2953). Using #include <pshpack8.h> and #include > <pshpop8.h> around the struct didn't help, so a padding field was used > instead. Does the approach used in winbase.h in declaration of WIN32_STREAM_ID to align the Size field help? #include <pshpack8.h> typedef struct _WIN32_STREAM_ID { DWORD dwStreamId; DWORD dwStreamAttributes; LARGE_INTEGER DECLSPEC_ALIGN(8) Size; DWORD dwStreamNameSize; WCHAR cStreamName[ANYSIZE_ARRAY]; } WIN32_STREAM_ID, *LPWIN32_STREAM_ID; #include <poppack.h> > +static void test_stat( void ) > +{ > + int offset = offsetof(struct _stati64, st_size); > + ok(offset == 24, "struct _stati64's st_size is misaligned, got %d, expected 24\n", offset); > +} This should be a part of auto generated header tests. Have a look at dlls/*/tests/generated.c files. -- Dmitry.

3 6

Re: Synchronize code page 20127 table with Windows one
by Robert Shearman Feb. 5, 2007

Feb. 5, 2007

Dmitry Timoshkov wrote: > The problem is that our translation table for code page 20127 is different from > what Windows has, and the ansi_buf get mangled. Attached patch synchronizes our > code page 20127 table with Windows one and fixes the bug. If you change a codepage from a unicode.org mapping then you need to add the changed .TXT file you generated it from to the build tree and update cpmap.pl to use it. -- Rob Shearman

3 2

Re: [try3]: user32/tests: add tests for WM_SETICON - what's wrong?
by Kirill K. Smirnov Feb. 5, 2007

Feb. 5, 2007

Hi, I've asked before: What's wrong with them? Maybe, unnecessary PeekMessage in tests??? http://www.winehq.org/pipermail/wine-patches/2007-January/035044.html http://www.winehq.org/pipermail/wine-patches/2007-January/035043.html Please, answer! Do not ignore! -- Kirill

1 0

help in debugging
by Ioannis Nousias Feb. 5, 2007

Feb. 5, 2007

Hello Wine developers, I've decided to see what causes floAt's Mobile Agent[1] to fail with wine I checked the wine developers' cheatsheet to help me debug the application, but I'm lost. The application installs but with some error: "C:\Program Files\Fma\sframeword\helper\BramusICQ.dll Unable to register the DLL/OCX: LoadLibrary failed; code 126 Module not found." I click "ignore" and the installation continues. When I try to execute the installed binary "MobileAgent.exe" it fails. I invoke it like this: WINEDEBUG=+seh,+relay WINEPREFIX=/tmp/winetemp wine MobileAgent.exe no error messages are produce by the app itself. on wine's debug log I see the following, just before winedbg starts: 0009:Ret kernel32.SetEvent() retval=00000001 ret=00410759 trace:seh:call_stack_handlers handler at 0x4045c7 returned 1 trace:seh:call_stack_handlers calling handler at 0x477d9a code=eedfade flags=1 0009:Call ntdll.RtlUnwind(0034feb8,0040427c,0034f140,00000000) ret=0040427c 0009: eax=0034f140 ebx=0034eca0 ecx=005acb61 edx=0034feb8 esi=0034feb8 edi=00000001 ebp=0034ecb8 esp=0034ec6c ds=007b es=007b fs=0033 gs=003b flags= 00200246 trace:seh:__regs_RtlUnwind code=eedfade flags=3 trace:seh:__regs_RtlUnwind calling handler at 0x60178400 code=eedfade flags=3 trace:seh:__regs_RtlUnwind handler at 0x60178400 returned 1 0009:Ret ntdll.RtlUnwind() retval=00000000 ret=0040427c 0009: eax=00000000 ebx=0034eca0 ecx=005acb61 edx=0034feb8 esi=0034feb8 edi=00000001 ebp=0034ecb8 esp=0034ec6c ds=007b es=007b fs=0033 gs=003b flags= 00200246 trace:seh:call_stack_handlers handler at 0x4045c7 returned 1 trace:seh:call_stack_handlers calling handler at 0x69ff49 code=eedfade flags=1 trace:seh:call_stack_handlers handler at 0x69ff49 returned 1 trace:seh:call_stack_handlers calling handler at 0x4046b8 code=eedfade flags=1 0009:Call kernel32.UnhandledExceptionFilter(0034ec90) ret=004046dc wine: Unhandled exception 0x0eedfade at address 0x0000:0x6024daa0 (thread 0009), starting debugger... trace:seh:start_debugger Starting debugger "winedbg --auto 8 228" this is not the first "trace:seh". Relatively early in the call stack there is this: 000b:Call user32.SetDeskWallPaper(code=c0000005 flags=0 addr=0x601b044b trace:seh:raise_exception info[0]=00000000 trace:seh:raise_exception info[1]=ffffffff trace:seh:raise_exception eax=ffffffff ebx=6011999c ecx=00000003 edx=0000ffff esi=00000000 edi=ffffffff trace:seh:raise_exception ebp=00117b98 esp=0034f61c cs=0073 ds=007b es=007b fs=0033 gs=003b flags=00010206 trace:seh:call_stack_handlers calling handler at 0x602b5540 code=c0000005 flags=0 trace:seh:__regs_RtlUnwind code=c0000005 flags=2 trace:seh:__regs_RtlUnwind calling handler at 0x602b5400 code=c0000005 flags=2 trace:seh:__regs_RtlUnwind handler at 0x602b5400 returned 1 ffffffff (invalid)) ret=6033e95f which looks suspicious to me. Am I on the right track? Unfortunately I'm not familiar with windows API or wine's underlying architecture. I need some guidance please :) I'm an experienced C/C++ programmer. thanks -Ioannis [1] http://fma.sourceforge.net/index2.htm

3 5

comctl32 kibitzers wanted
by Dan Kegel Feb. 5, 2007

Feb. 5, 2007

I and Lei Zhang, with some help from James Hawkins, are leading a group of 13 UCLA students who are writing conformance tests for comctl32. Each student picked one control, and is now busily writing getter/setter tests. In the coming few weeks we'll also try more interesting tests, like verifying that the right messages are sent in the right order. If you're interested in helping the students in any way (reviewing code before it hits wine-patches, offering suggestions on how to test tricky bits, or whatever), please let me know and I can add you to the project's mailing list. Thanks, Dan

2 1

Re: shell32: shlfileop tests: avoid buffer overflows for paths
by James Hawkins Feb. 5, 2007

Feb. 5, 2007

On 2/4/07, Mikołaj Zalewski <mikolaj(a)zalewski.pl> wrote: > These buffers can contain multiple paths and set_curr_dir_path can make > the paths long resulting in a buffer overflow. > > From 36e05f3140e57bad2af790c56073799d23f7ef60 Mon Sep 17 00:00:00 2001 > From: =?utf-8?q?Miko=C5=82aj_Zalewski?= <mikolaj(a)zalewski.pl> > Date: Thu, 25 Jan 2007 12:17:11 +0100 > Subject: [PATCH] shell32: shlfileop tests: avoid buffer overflows for paths > > --- > dlls/shell32/tests/shlfileop.c | 12 ++++++------ > 1 files changed, 6 insertions(+), 6 deletions(-) > > diff --git a/dlls/shell32/tests/shlfileop.c b/dlls/shell32/tests/shlfileop.c > index b363c5e..23aaeba 100644 > --- a/dlls/shell32/tests/shlfileop.c > +++ b/dlls/shell32/tests/shlfileop.c > @@ -329,8 +329,8 @@ static void test_delete(void) > static void test_rename(void) > { > SHFILEOPSTRUCTA shfo, shfo2; > - CHAR from[MAX_PATH]; > - CHAR to[MAX_PATH]; > + CHAR from[5*MAX_PATH]; > + CHAR to[5*MAX_PATH]; > DWORD retval; > > shfo.hwnd = NULL; > This is really hacky. If this is fixed, it needs to be fixed properly. -- James Hawkins

2 1

Detect screen resolution change errors
by Francois Gouget Feb. 5, 2007

Feb. 5, 2007

When I run the dlls/d3d9/device conformance test on Windows in VMware, I get a trace telling me that IDirect3D9_CreateDevice() failed and returned 0x8876086c. This seems to be because Windows has trouble changing the screen resolution when running in VMware (though it's perfectly capable of doing it when I go through the control panel). But when I run the test in Wine I'm getting a test failure because: * IDirect3D9_CreateDevice() did not change the screen resolution * but it returned success so that the screen size checks fail That's because XRandR fails to change the resolution (for whatever reason, it's irrelevant here). Wine detects that but does not report the information to the upper layers. So I have made a couple of patches: * the first one detects when XRandR, XVidMode or some low level routine fails to change the screen resolution, and propagates this so ChangeDisplaySettingsEx() returns an error * the second one modifies IWineD3DDeviceImpl_CreateAdditionalSwapChain() so it detects when ChangeDisplaySettingsEx() propagates that error upstream too Now the dlls/d3d9/device test succeeds on my machine (all while loudly complaining something is wrong): [...] err:xrandr:X11DRV_XRandR_SetCurrentMode Resolution change not successful -- perhaps display has changed? fixme:d3d9:IDirect3DDevice9Impl_CreateAdditionalSwapChain (0x1c4358) call to IWineD3DDevice_CreateAdditionalSwapChain failed fixme:d3d9:IDirect3D9Impl_CreateDevice (0x171448) D3D Initialization failed for WineD3DDevice 0x174ee8 device.c:741:could not create device, IDirect3D9_CreateDevice returned 0x8876086c device.c: 245 tests executed (0 marked as todo, 0 failures), 0 skipped. I have attached the relevant patches. Does this look ok to the DirectX gurus? -- Francois Gouget fgouget(a)codeweavers.com

3 5

Re: [lostwages] Update download-deb page with better information, error fixes
by Detlef Riekenberg Feb. 4, 2007

Feb. 4, 2007

On Di, 2007-01-30 at 01:09 -0800, Scott Ritchie wrote: > + > +<p>While there is currently no Wine package explicitly designed for > the 64-bit version > +of Ubuntu, there are several hacks that can be used to install the > 32-bit package > +into the 64-bit distribution and have it function normally. See > +<a href="https://wiki.ubuntu.com/I386WineInAmd64">this page on the > Ubuntu wiki</a> > +for more details.</p> IMHO, a link to our own Wiki should be placed on the download-deb page http://wiki.winehq.org/WineOn64bit#head-56206e8bc74083807ffe06ccb471d3f964c… And as a Note on https://wiki.ubuntu.com/I386WineInAmd64 and https://help.ubuntu.com/community/WineForAMD64 The provided automatic installation script includes the sidenet-script. Please include a BIG WARNING, that this is never supported by winehq and the users need a clean wine, before they ask for help on #winehq or wine-users(a)winehq.org You mention sidenet on that page: "If you followed the manual instructions you need to install the Sidenet script" This is wrong. Please remove that line! Even, when the sidenet-script might help some users to run an app, "you need to install the Sidenet script" is wrong! -- By by ... Detlef

3 7

Re: [msvcrt] properly align struct _stati64's st_size
by Francois Gouget Feb. 3, 2007

Feb. 3, 2007

On Sat, 3 Feb 2007, Damjan Jovanovic wrote: [...] > * Added padding so that struct _stati64's st_size has an offset of 24 > bytes from the beginning of the struct like it should. Does the st_size field get the right offset when using Wine's header with the Windows compiler? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ "Only wimps use tape backup: _real_ men just upload their important stuff on ftp, and let the rest of the world mirror it ;)" -- Linus Torvalds

1 0

Re: winetest: add support for http_proxy environment variable
by Detlef Riekenberg Feb. 2, 2007

Feb. 2, 2007

On So, 2007-01-14 at 15:13 +0100, Németh Márton wrote: Welcome to wine. I have some comments about your Patch: > diff -u -r wine-0.9.29.orig/ChangeLog wine-0.9.29/ChangeLog > --- wine-0.9.29.orig/ChangeLog 2007-01-09 16:42:47.000000000 +0100 > +++ wine-0.9.29/ChangeLog 2007-01-14 15:02:31.000000000 +0100 The changelog will be updated during a release with the Informations from the subject. > + > + http_proxy = getenv("http_proxy"); > + if (http_proxy) { > + /* Proxy configuration found */ > + memset(&regex, 0, sizeof(regex)); > + retval = regcomp(&regex, The Idea to support a http-proxy is good, but the Programm must run on Windows. 1. I never saw an environment-variable "http_proxy" on Windows. Most Windows-Applications use the Proxy-Data from IE (Get the settings from there) 2. "regcomp" and friends are posix, but not available on windows Thanks for helping wine. -- By by ... Detlef

1 0

Re: [PATCH] ole32: Add CoWaitForMultipleHandles to spec file do it will be visible to windows apps.
by Paul Vriens Feb. 2, 2007

Feb. 2, 2007

John Morris wrote: > I'm resubmitting the patch without the changelog entry. > > > ------------------------------------------------------------------------ > > From 4c51e49d432eb8342cadb71a3d539b2e8574849b Mon Sep 17 00:00:00 2001 > From: John Morris <mailjohnmorris(a)gmail.com> > Date: Fri, 2 Feb 2007 13:20:34 -0600 > Subject: ole32: Add CoWaitForMultipleHandles to spec file do it will be visible to windows apps. > > --- > dlls/ole32/ole32.spec | 1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/dlls/ole32/ole32.spec b/dlls/ole32/ole32.spec > index d775556..3ae0240 100644 > --- a/dlls/ole32/ole32.spec > +++ b/dlls/ole32/ole32.spec > @@ -76,6 +76,7 @@ > @ stub CoUnloadingWOW > @ stdcall CoUnmarshalHresult(ptr ptr) > @ stdcall CoUnmarshalInterface(ptr ptr ptr) > +@ stdcall CoWaitForMultipleHandles(long long long ptr ptr) > @ stdcall CreateAntiMoniker(ptr) > @ stdcall CreateBindCtx(long ptr) > @ stdcall CreateClassMoniker(ptr ptr) > > > ------------------------------------------------------------------------ > > Hi, I thought we use: @ stub CoWaitForMultipleHandles for functions that should be exported and are not implemented at all, and use @ stdcall CoWaitForMultipleHandles(long long long ptr ptr) where we at least have something in a *.c file (although that could be a simple return): HRESULT WINAPI CoWaitForMultipleHandles(<stuff>) { FIXME("unimplemented stub!\n"); return E_FAIL; <or something alike> } Isn't the first one a stub and the second one a semi-stub, or have I mixed up things? Cheers, Paul.

2 1

Re: Added CoWaitForMultipleHandles to ole32.spec so it will be visible to W indows apps.
by Michael Stefaniuc Feb. 2, 2007

Feb. 2, 2007

Hello John, thanks for the patch. You do not need to add the entry to the ChangeLog file. That is done automaticly using the git changelog entries during the release of a new Wine version. Would you mind resubmitting the patch without that? bye michael John Morris wrote: > From 79b3a4ba86ec3ddbd4b8be7c04bb350d78c78bfa Mon Sep 17 00:00:00 2001 > From: John Morris <mailjohnmorris(a)gmail.com> > Date: Wed, 31 Jan 2007 17:38:04 -0600 > Subject: Added CoWaitForMultipleHandles to ole32.spec so it will be visible to Windows apps. > > --- > ChangeLog | 5 +++++ > dlls/ole32/ole32.spec | 1 + > 2 files changed, 6 insertions(+), 0 deletions(-) > > diff --git a/ChangeLog b/ChangeLog > index 658036c..ce545d0 100644 > --- a/ChangeLog > +++ b/ChangeLog > @@ -1,3 +1,8 @@ > +2007-01-31 John Morris <mailjohnmorris(a)gmail.com> > + > + * dlls/ole32/ole32.spec: > + ole32: Add CoWaitForMultipleHandles to spec file so it will be visible to windows apps. > + > 2007-01-24 Vitaliy Margolen <wine-patches(a)kievinfo.com> > > * server/token.c: > diff --git a/dlls/ole32/ole32.spec b/dlls/ole32/ole32.spec > index d775556..3ae0240 100644 > --- a/dlls/ole32/ole32.spec > +++ b/dlls/ole32/ole32.spec > @@ -76,6 +76,7 @@ > @ stub CoUnloadingWOW > @ stdcall CoUnmarshalHresult(ptr ptr) > @ stdcall CoUnmarshalInterface(ptr ptr ptr) > +@ stdcall CoWaitForMultipleHandles(long long long ptr ptr) > @ stdcall CreateAntiMoniker(ptr) > @ stdcall CreateBindCtx(long ptr) > @ stdcall CreateClassMoniker(ptr ptr) > > > ------------------------------------------------------------------------ > > -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

2 1

Re: comdlg32-colordlg fix bgcolor
by Dmitry Timoshkov Feb. 2, 2007

Feb. 2, 2007

"Ivan Sinitsin" <ivan(a)etersoft.ru> wrote: > The patch corrects background color of a dialogue window " Choose color " at > copying a triangular marker, the user colors and the predetermined colors. > Earlier the background about these elements was more dark than the basic > background of a window. > + SetClassLongPtrW( hwnd, GCLP_HBRBACKGROUND, (LONG_PTR) GetSysColorBrush(COLOR_BTNFACE)); This fix is not correct, think for instance about different color themes. Probably CC_PaintTriangle needs to specify the background color of a triangle explicitly. -- Dmitry.

2 2

Re: Conformance test for bug #7286
by Dmitry Timoshkov Feb. 2, 2007

Feb. 2, 2007

"Misha Koshelev" <mk144210(a)bcm.tmc.edu> wrote: > + /* Now create the notification thread */ > + events[1] = CreateThread(NULL, 0, NotificationThread, (LPVOID)events[0], > + 0, &threadId); > + ok(events[1] != INVALID_HANDLE_VALUE, "CreateThread error: %d\n", GetLastError()); CreateThread returns NULL on error, not INVALID_HANDLE_VALUE. -- Dmitry.

3 3

Re: [PATCH 3/7] server: Implement object's security descriptor check against token.
by Robert Shearman Feb. 1, 2007

Feb. 1, 2007

Vitaliy Margolen wrote: > + res = token_access_check( token, obj->sd, *access, &priv, &priv_count, > + &mapping, access, &status ) == STATUS_SUCCESS && > + status == STATUS_SUCCESS; > + if (!res) > + { > + fprintf( stderr, "access check failed\n" ); > + set_error( STATUS_ACCESS_DENIED ); > + } We don't want anything in the wineserver that can possibly spam the console, so this should be made conditional on debug_level being non-zero. Also, is there any reason you return STATUS_ACCESS_DENIED instead of the statuses returned by token_access_check? Could you try writing a test that creates or opens an object with ACCESS_SYSTEM_SECURITY access and see if it returns STATUS_PRIVILEGE_NOT_HELD or STATUS_ACCESS_DENIED? -- Rob Shearman

2 1

Re: [PATCH 1/7] server: Get the primary group from the token.
by Robert Shearman Feb. 1, 2007

Feb. 1, 2007

Vitaliy Margolen wrote: > list_add_tail( &token->groups, &group->entry ); > + /* Use first owner capable group as an owner */ > + if (!token->primary_group && group->owner) > + token->primary_group = &group->sid; > + } > + /* we really need a primary group */ > + if (!token->primary_group && group_count) > + { > + release_object( token ); > + return NULL; > } > According to documentation from Microsoft, "the primary group only needs to be set if POSIX compatibility is required." Also, the default security descriptor does not require a group - a NULL group is fine. -- Rob Shearman

2 1

Re: [PATCH] rasapi32: RasEnumConnections now returns correct buffer size (zero) when there are zero connections available
by James Hawkins Feb. 1, 2007

Feb. 1, 2007

On 2/1/07, John Smith <xixsimplicityxix(a)gmail.com> wrote: > When RasEnumConnections completes the expected behaviour is to have the > needed buffer size stored in *lpcb. Right now wine just leaves it at > whatever size was passed. The windows 2000 behaviour (tested) for when > they're are zero connections, *lpcb is 0. > > Changelog: > RasEnumConnections the buffersize needed reported is now 0 when the number > of connections is 0 > You need to add a test to the test suite for this. -- James Hawkins

1 0

Office 2003 Installation
by Jan de Mooij Feb. 1, 2007

Feb. 1, 2007

Hi, I have tried to run the office 2003 installation, and in doing that I came across the following issues: - I think we need to undo a patch for msiexec [1]. CommandLineToArgvW does not what we want with slashes in paths followed by an " (this also happens on Windows). Therefore we need to parse the commandline arguments ourselves, what's done by reverting the patch. I can give an example of when it goes wrong if you want. - Office 2003 installation fails with this (from the log): ------------------------ Successfully launched MsiExec.... 2/1/2007 8:30:55 PM Chained install return code: 1603 Exit code was an error. Shutting down chained setup processing. Set Verbose logging for subsequent setup. ------------------------ BUT, when I add WINEDEBUG=+relay,+seh,+tid,+msi,+msiexec, it runs well and installs alright, so I think it's a timing issue. Anyone has experienced this before? What would be the best way to debug this? (I only choose to install Word, I don't know what happens when I select the other Office-applications) Thanks in advance, Jan de Mooij [1] http://source.winehq.org/git/wine.git/?a=blobdiff;f=programs/msiexec/msiexe…

1 0