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

Re: wintrust/tests: make sure return values are used (LLVM/Clang) (resend)
by Paul Vriens Feb. 4, 2011

Feb. 4, 2011

On 02/04/2011 09:32 AM, Austin English wrote: > - ret = funcs->pfnObjectTrust(&data); > + funcs->pfnObjectTrust(&data); > + ok(ret == S_FALSE, "Expected S_FALSE, got %08x\n", ret); This doesn't look correct (you are removing the assignment and then check it). I know that this code path will never be taken, but still. -- Cheers, Paul.

2 1

Re: wintrust/tests: make sure return values are used (LLVM/Clang) (1/4)
by Juan Lang Feb. 4, 2011

Feb. 4, 2011

Hey Austin, + ok(ret == S_FALSE, "Expected S_OK, got %08x\n", ret); Copy/pasto. --Juan

2 1

Re: wintrust/tests: make sure return values are used (LLVM/Clang) (3/4)
by Juan Lang Feb. 4, 2011

Feb. 4, 2011

Hey Austin, ok(ret, "WintrustSetRegPolicyFlags failed: %d\n", GetLastError()); size = sizeof(flags1); r = RegQueryValueExA(key, State, NULL, NULL, (LPBYTE)&flags1, &size); - ok(flags1 == flags3, "Got %08x flags instead of %08x\n", flags1, flags3); + ok(!r || r == ERROR_FILE_NOT_FOUND, "RegQueryValueEx failed: %d\n", r); + if (!r) + ok(flags1 == flags3, "Got %08x flags instead of %08x\n", flags1, flags3); It seems to me that the introduction of ERROR_FILE_NOT_FOUND weakens the test. (Testing r should be done, thanks for fixing that.) I assume that, since WintrustSetRegPolicyFlags should have succeeded, the registry value should now exist. Is there a test failure you're also trying to fix? Thanks, --Juan

2 1

updated LLVM/Clang static analysis results (and valgirind :-))
by Austin English Feb. 4, 2011

Feb. 4, 2011

Original results: Date: Thu Jan 20 22:59:57 2011 All Bugs 2922 Argument with 'nonnull' attribute passed null 99 Idempotent operation 154 Dead assignment 1464 Dead increment 155 Dead initialization 22 Array subscript is undefined 5 Assigned value is garbage or undefined 96 Branch condition evaluates to a garbage value 10 Called function pointer is null (null dereference) 6 Dereference of null pointer 757 Dereference of undefined pointer value 8 Division by zero 12 Function call argument is an uninitialized value 49 Garbage return value 9 Result of operation is garbage or undefined 74 Undefined allocation of 0 bytes 2 New results: All Bugs 2817 Argument with 'nonnull' attribute passed null 100 Idempotent operation 156 Dead assignment 1368 Dead increment 152 Dead initialization 22 Array subscript is undefined 4 Assigned value is garbage or undefined 96 Branch condition evaluates to a garbage value 9 Called function pointer is null (null dereference) 6 Dereference of null pointer 757 Dereference of undefined pointer value 8 Division by zero 12 Function call argument is an uninitialized value 46 Garbage return value 7 Result of operation is garbage or undefined 72 Undefined allocation of 0 bytes 2 Available at: http://austinenglish.com/logs/clang_analyzer/index.html and valgrind logs: http://austinenglish.com/logs/valgrind/ if you've looked at valgrind logs and see errors that should be suppressed, please email me and I'll add them. Cheers, Austin

1 0

Re: Re: user32/tests: Test for behavior of WM_SETTEXT handler (try 2)
by Marvin Feb. 4, 2011

Feb. 4, 2011

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=8839 Your paranoid android. === W7PROX64 (64 bit msg) === Timeout

1 0

Re: Re: user32/tests: Test for behavior of WM_SETTEXT handler
by Marvin Feb. 4, 2011

Feb. 4, 2011

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=8838 Your paranoid android. === WNT4WSSP6 (32 bit msg) === msg.c:5649: Test failed: WM_SETTEXT on a button: 3: the msg 0x0138 was expected, but got msg 0x8000 instead === W7PROX64 (64 bit msg) === Timeout

1 0

Re: RFC: Adding Mac support to secur32/schannel.c
by James Mckenzie Feb. 3, 2011

Feb. 3, 2011

Juan Lang <juan.lang(a)gmail.com> wrote: I'll make this quick and address a comment here from Juan from the viewpoint of someone building Wine from scratch using one of the porting services: Fink. > >Besides, I'm still not convinced that GnuTLS on the Mac is such an >onerous problem. This is not just a Codeweavers' problem but a problem that: 1. MacOSX provides native TLS support. 2. Building ANYTHING Unix'y on a Mac may require 'hacky' patches to get around some of the code issues. Both of the known UNIX to MacOSX porting projects provide GnuTLS but have to patch it to build and work on MacOSX without stepping on the existing capabilities. Interfacing the existing TLS capabilities to appear as the GNU product may be a solution to this. I tend to agree with Ken Thomases for MacOSX we should be using the native code vice adding a package that may not provide full TLS functionality and moving towards schannel functionality to the higher levels of code in Wine. Thank you for reading this. James McKenzie

4 5

Re: RFC: Adding Mac support to secur32/schannel.c
by James Mckenzie Feb. 3, 2011

Feb. 3, 2011

Charles Davis <cdavis(a)mymail.mines.edu> wrote: > >On 2/3/11 9:22 AM, James Mckenzie wrote: >> 2. Building ANYTHING Unix'y on a Mac may require 'hacky' patches to get around some of the code issues. Both of the >>known UNIX to MacOSX porting projects provide GnuTLS but have to patch it to build and work on MacOSX without stepping on >>the existing capabilities. >What are you talking about? MacPorts doesn't need patches for GnuTLS anymore. Looking at GnuTLS's Portfile, there are no >patch files pulled in and no reinplace (i.e. sed -ie) operations. It was my understanding that MacPorts did have them. I'll look at Fink tonight and see if there still is a patch file needed with the latest version. In any case, Mac users should be using build in functionality and as few as possible (none if possible) external 'Unix' add-on packages. For a while, they will be needed. >> I tend to agree with Ken Thomases for MacOSX we should be using the native code vice adding a package that may not provide full TLS functionality and moving towards schannel functionality to the higher levels of code in Wine. >I'm for that. In fact, my humble opinion is that Wine on Mac should only use libraries that are part of the OS (i.e. only >dylibs in /usr/lib and frameworks in /System/Library/Frameworks). There are a whole host of benefits, not the least of >which is that it makes binary distribution easier (to date, Mac OS is one of the few platforms that does not have >an official binary distribution) and it could potentially expand our user-base (since users would no longer have to have >MacPorts or Fink or Gentoo Prefix or use a third-party distro just to run Wine). +1 :) It would be a great thing if we did not have to have 'special' builds for MacOSX and we could send out either an installable package or a disk image as the project. James McKenzie > >We've got a long way to go in that department, unfortunately. :( > >Chip > >

1 0

RFC: Adding Mac support to secur32/schannel.c
by Ken Thomases Feb. 3, 2011

Feb. 3, 2011

Hi, I'm planning to add an alternative implementation of schannel (SSL/TLS) support for the Mac. The current implementation is based on GnuTLS. That library is not typically found on Mac OS X. Although packagers can build it and ship it and its dependencies with Wine for Mac OS X, I think it's better (especially for security-related functionality) to use the system-provided library. I'm attaching a patch. It is _not_ intended as a proposed commit. It's just a proof-of-concept that shows the direction that I'm going. I plan to introduce a new internal interface (the schan_imp_* stuff in my patch) and incrementally refactor the code to hide uses of GnuTLS behind that interface. Then, I'm thinking of breaking the GnuTLS implementation out into a separate module, schannel_gnutls.c. Then, I'd add a second implementation module, schannel_mac.c, based on the Mac Secure Transport API (as shown in the patch). Each of the two modules would be made "empty" by preprocessor conditionals, as appropriate. I'd appreciate a review of this general plan. Thanks, Ken

8 18

Re: user32/tests: Test for behavior of WM_SETTEXT handler
by Alexandre Julliard Feb. 3, 2011

Feb. 3, 2011

Alexander LAW <exclusion(a)gmail.com> writes: > + { WM_CTLCOLORSTATIC, sent|parent|optional}, /*Windows sends it, Wine doesn't*/ > + { WM_CTLCOLORSTATIC, sent|parent|optional}, /*Windows sends it, Wine doesn't*/ > + { WM_APP, sent|wparam|lparam, 0, 0 }, > + { WM_PAINT, sent }, > + { WM_NCPAINT, sent|defwinproc|optional }, /* FIXME: Wine sends it */ You can't add 'optional' to hide Wine bugs; if the message is sent on Windows it should be a todo_wine. -- Alexandre Julliard julliard(a)winehq.org

1 0

RE: gdi32: Upper 24 bits of a character range must be same.
by Greg Geldorp Feb. 3, 2011

Feb. 3, 2011

Hi, I'm sure you've noticed that this change causes some failures on a Simplified Chinese-language test machine, see http://test.winehq.org/data/5ae2b0f219cb5aed2bdf32746a57a699a32767a2/xp_wtb… Can you take a look at that please? I'm wondering if it wouldn't make more sense to use GetCharABCWidthsW instead of the Ansi version for this test? Thanks, Greg.

2 1

Re: msvcrt: Partially implement type_info::name_internal_method()
by Alexandre Julliard Feb. 3, 2011

Feb. 3, 2011

Nikolay Sivov <nsivov(a)codeweavers.com> writes: > @@ -260,3 +307,24 @@ int CDECL _atoflt( _CRT_FLOAT *value, char *str ) > { > return _atoflt_l( value, str, NULL ); > } > + > +/********************************************************************* > + * ?_name_internal_method(a)type_info@@QBEPBDPAU__type_info_node@@@Z (MSVCR90.@) > + */ > +DEFINE_THISCALL_WRAPPER(MSVCRT_type_info_name_internal_method,8) > +const char * __thiscall MSVCRT_type_info_name_internal_method(type_info * _this, struct __type_info_node *node) > +{ > + /* this is a forward to type_info::name() */ > +#ifdef __i386__ > + static const char *typeinfo_name = "?name(a)type_info@@QBEPBDXZ"; > + void* (WINAPI *p)(void*); > +#else > + static const char typeinfo_name[] = "?name(a)type_info@@QEBAPEBDXZ"; > + void* (__cdecl *p)(void*); > +#endif > + static int once; > + > + if (node && !once++) FIXME("type_info_node parameter ignored\n"); > + p = (void*)GetProcAddress(GetModuleHandleA("msvcrt.dll"), typeinfo_name); > + return call_func1(p, _this); > +} I think it would be better to duplicate the implementation after all. Sorry for misleading you with the GetProcAddress suggestion, I hadn't realized that it would require the thiscall mess. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 2/5] winex11.drv: Complain a bit about missing s3tc support.
by Henri Verbeet Feb. 3, 2011

Feb. 3, 2011

On 3 February 2011 01:00, Tobias Jakobi <liquid.acid(a)gmx.net> wrote: > *bumping* > > This patch never went into master, although it's _very_ important. Wine > users see a lot of D3D problems (mostly missing textures) since mesa drivers > don't support s3tc "out-of-the-box" (libtxc_dxtn needs to be available). > This leads to a lot of 'false' bug reports, which are in fact driver issues. > > Requesting to finally push this to master. > I'm not entirely sure on how to do this properly. Making it an ERR would be too loud for applications that never use s3tc textures, as a WARN it's never going to be seen unless you look at the debug channel. Printing a message in wined3d in CreateSurface() would probably work, but the resulting check would end up being pretty ugly because we'd have to check 5 different formats. You can't do much more than a WARN for a generic check either, because some formats may be legitimately missing / unimplemented. Note that the situation with floating point formats isn't much better.

2 1

Re: wined3d: Update clip planes when switching to/from offscreen rendering.
by Stefan Dösinger Feb. 2, 2011

Feb. 2, 2011

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 31.01.2011 um 15:13 schrieb Matteo Bruni: > It should fix http://bugs.winehq.org/show_bug.cgi?id=25877 > <0001-wined3d-Update-clip-planes-when-switching-to-from-offs.txt> If we change the shader code to write gl_ClipVertex and result.clip before applying the y inversion then we should be able to avoid this. That should also make it more compatible to fixed function vertex processing - here the clipping is performed before the projection matrix is applied. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJNRssNAAoJEN0/YqbEcdMwZv8P+wbbhcamRsg42fMzJ02jKLcT s4p19OqKPZEdVvzsfQCe4e7KGgGdZUefMWsY2ib9AK21cQXB3R9fnyl5TMDcuxuh EojJvAQCVd/hgnz7tserUJT6rS/W08BPsdHM4dgxdnhRTzi2FAc7l3NgFOONJXpG i8HfcmD2AgaGOam6Wriv3SD8fM0zrfmpZdJDH1moCefqptEEWD9adwWRSMhaMvTl rlj1gDR9cRC9fsxur2U1f5NuXN0AY+a+5VPQHElZV2bP9ulheoa9nYuXU+8F7OhK RyIJ2DO4vpaLpEbXW/amtUWnlBSk0n7k3F9w/fcthOmUvlPHOBY7i2Ukf4j84vQD AhpN7Yf4cFZaSV8q/gww+U9H1udelidiTEL05OKQJUohnM1F9/cRnXbXmmA5Nuia rQlcCnm12cw1ClykdrY7B/hDCqGOPnnmPp580kW1LlEtidYyGbG35seyHxNqcNcQ RWlvVsGwvlzgex7qWf9hT34KOcUzMKZdlehfvtQn0Fjrcf+/3s5EvrtG4Mw6qHNh aBFNaeB8LkV36hu71r/1yxsqHO+taYt1/Ho8poANYbOplV9FCpd0nXeK8n7rqCPx L5TVgSJVd4n354FlguuIUAiFlXxcxFN2CJlN2Hd4dwhZZhGBh+4LH+XhjUtzX4ge 15usBq4VUhhssvv6dVys =urcm -----END PGP SIGNATURE-----

3 5

Wine FAQ edits
by Albert Lee Feb. 2, 2011

Feb. 2, 2011

Hi Vitaliy, I notice you have reverted my edits to the FAQ on the wiki ( http://wiki.winehq.org/FAQ?action=info ). As I was trying to clarify the shell metacharacter information and operating system/platform support, and add new file association instructions, I would like to know why this happened and what changes should be done. -Albert

2 3

re: ntoskrnl.exe: unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces
by Dan Kegel Feb. 2, 2011

Feb. 2, 2011

Qian wrote: >1. If a function is implemented in wine dll as a stup, then usually >this function won't cause crash, >and the wine debug will output "fix:me ...stup" rather then >"Unimplemented function", is it right? I think "stub" is somewhat ambiguous, it can mean either something without an implementation, or something with a very minimal implementation. But yes, if something is listed in dlls/*/*.spec as a stub, you get 'Unimplemented function', and if something is listed in grep FIXME.*stub dlls/*/*.c as a stub, you get "fixme: ... stub". >2. If a function is listed in the Wine API guide, >http://source.winehq.org/WineAPI/ , and marked as stup, >then this function must be implemented as a stup in wine source code, >is it right? The Wine API guide is not a very reliable guide, it might be out of date. Better to just look in the source code. - Dan

2 1

Re: crypt32: Fix quoting-behaviour
by Juan Lang Feb. 1, 2011

Feb. 1, 2011

Hi Christian, I'm afraid this patch is incorrect. In particular, - chars = CertRDNValueToStrA( - rdn->rgRDNAttr[j].dwValueType, - &rdn->rgRDNAttr[j].Value, psz ? psz + ret : NULL, - psz ? csz - ret : 0); + if ((dwStrType & 0x000000ff) == CERT_X500_NAME_STR) + chars = quote_string_a( + rdn->rgRDNAttr[j].dwValueType, + &rdn->rgRDNAttr[j].Value, psz ? psz + ret : NULL, + psz ? csz - ret : 0); + else + chars = CertRDNValueToStrA( + rdn->rgRDNAttr[j].dwValueType, + &rdn->rgRDNAttr[j].Value, psz ? psz + ret : NULL, + psz ? csz - ret : 0); This change (and the corresponding one to CertNameToStrW) is incorrect. I tested a couple of strings with CERT_SIMPLE_NAME_STR, and they are also quoted. I can try to take these over if you like, or you can continue to work on them. Let me know what you prefer. --Juan

1 0

Re: [dlls/shdocvw] Initialize variable (Coverity)
by Nikolay Sivov Feb. 1, 2011

Feb. 1, 2011

On 2/1/2011 17:14, Paul Vriens wrote: > Hi, > > Addresses Coverity #1090. > > If CoCreateInstance() fails we check the uninitialized urlfile variable. Same story with urlobj. In fact it looks better to try CoCreateInstance first, before anything else like lstrcpy and just return earlier on failure.

2 2

Re: gdiplus: C++ fixes for headers
by Paul Chitescu Feb. 1, 2011

Feb. 1, 2011

On Tuesday 01 February 2011 09:49:46 am Iain Arnell wrote: > To fix inclusion of gdiplus.h under C++, this patch: > * adds missing class declaration for GpPen > * adds missing class declaration for CharacterRange > * fixes PenAlignment/GpPenAlignment declaration > * avoids redeclaration of PixelFormat > > Simple testcase: > > cat >test.cpp <<EOF > #include <windows.h> > #include <gdiplus.h> > EOF > wineg++ -c test.cpp > --- > include/gdiplusenums.h | 2 +- > include/gdiplusgpstubs.h | 2 ++ > include/gdiplusimaging.h | 4 ++-- > include/gdiplustypes.h | 25 +++++++++++++++++++++++++ > 4 files changed, 30 insertions(+), 3 deletions(-) > > diff --git a/include/gdiplusenums.h b/include/gdiplusenums.h > index 82f20eb..dc03b29 100644 > --- a/include/gdiplusenums.h > +++ b/include/gdiplusenums.h > @@ -734,7 +734,7 @@ typedef enum StringTrimming StringTrimming; > typedef enum FontStyle FontStyle; > typedef enum StringFormatFlags StringFormatFlags; > typedef enum HotkeyPrefix HotkeyPrefix; > -typedef enum PenAlignment GpPenAlignment; > +typedef enum PenAlignment PenAlignment; > typedef enum PaletteFlags PaletteFlags; > typedef enum ImageCodecFlags ImageCodecFlags; > typedef enum CombineMode CombineMode; > diff --git a/include/gdiplusgpstubs.h b/include/gdiplusgpstubs.h > index 3edc1f4..5a65cd8 100644 > --- a/include/gdiplusgpstubs.h > +++ b/include/gdiplusgpstubs.h > @@ -22,6 +22,7 @@ > #ifdef __cplusplus > > class GpGraphics {}; > +class GpPen {}; > class GpBrush {}; > class GpHatch : public GpBrush {}; > class GpSolidFill : public GpBrush {}; > @@ -92,6 +93,7 @@ typedef WrapMode GpWrapMode; > typedef Color GpColor; > typedef FlushIntention GpFlushIntention; > typedef CoordinateSpace GpCoordinateSpace; > +typedef PenAlignment GpPenAlignment; > typedef PenType GpPenType; > > #endif > diff --git a/include/gdiplusimaging.h b/include/gdiplusimaging.h > index 42a00cb..3e9f6ee 100644 > --- a/include/gdiplusimaging.h > +++ b/include/gdiplusimaging.h > @@ -110,7 +110,7 @@ public: > UINT Width; > UINT Height; > INT Stride; > - PixelFormat PixelFormat; > + INT PixelFormat; /* MSDN: "PixelFormat PixelFormat;" */ > VOID* Scan0; > UINT_PTR Reserved; > }; > @@ -177,7 +177,7 @@ typedef struct BitmapData > UINT Width; > UINT Height; > INT Stride; > - PixelFormat PixelFormat; > + INT PixelFormat; /* MSDN: "PixelFormat PixelFormat;" */ > VOID* Scan0; > UINT_PTR Reserved; /* undocumented: stores the lock mode */ > } BitmapData; > diff --git a/include/gdiplustypes.h b/include/gdiplustypes.h > index 4f97432..b84c74e 100644 > --- a/include/gdiplustypes.h > +++ b/include/gdiplustypes.h > @@ -199,6 +199,31 @@ public: > INT Height; > }; > > +class CharacterRange > +{ > +public: > + CharacterRange() > + { > + First = Length = 0; > + } > + > + CharacterRange(IN INT first, IN INT length) > + { > + First = first; > + Length = length; > + } > + > + CharacterRange& operator=(IN const CharacterRange& rhs) > + { > + First = rhs.First; > + Length = rhs.Length; > + return *this; > + } > +public: > + INT First; > + INT Length; > +}; > + > #else /* end of c++ typedefs */ > > typedef struct Point Wouldn't be better to wrap the offending C with: #ifdef __cplusplus extern "C" { #endif ... #ifdef __cplusplus } #endif

2 1

Re: programs: Add winemsibuilder.
by Joris Huizer Feb. 1, 2011

Feb. 1, 2011

While skimming through the new patches, I found: > +WCHAR *encode_stream( const WCHAR *in ) > +{ > + DWORD c, next, count; > + WCHAR *out, *p; > + > + count = strlenW( in ); > + if (count > MAX_STREAM_NAME) > + return NULL; > + > + count += 2; > + out = HeapAlloc( GetProcessHeap(), 0, count > * sizeof(WCHAR) ); > + p = out; You aren't checking for out-of-memory condition here. As you seem to cover all the other possible errors, I thought to let you know HTH, Joris

1 0

Re: [PATCH 1/5] shell32: Added SHCNRF_InterruptLevel flag support to SHChangeNotifyRegister
by Alexandre Julliard Feb. 1, 2011

Feb. 1, 2011

Piotr Caban <piotr(a)codeweavers.com> writes: > void InitChangeNotifications(void) > { > + watched_directories = 0; > + interrupts_server_terminate = CreateEventW(NULL, FALSE, FALSE, NULL); > + interrupts_server = CreateThread(NULL, 0, interrupts_server_thread, NULL, 0, NULL); > } This needs to be done on demand. You can't create a thread in every process on the off chance that it would use interrupt notifications. Probably you can use the thread pool for this. -- Alexandre Julliard julliard(a)winehq.org

1 0