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

Re: wintrust/tests: make sure return values are used (LLVM/Clang) (1/4)

by Austin English

On Thu, Feb 3, 2011 at 20:16, Juan Lang <juan.lang(a)gmail.com> wrote: > Hey Austin, > > + ok(ret == S_FALSE, "Expected S_OK, got %08x\n", ret); > Copy/pasto. Thanks, resent. -- -Austin

Feb. 4, 2011

Re: wintrust/tests: make sure return values are used (LLVM/Clang) (3/4)

by Austin English

On Thu, Feb 3, 2011 at 20:19, Juan Lang <juan.lang(a)gmail.com> wrote: > 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? No, good catch. Too little caffeine -> copy/paste error. Resending, thanks. -- -Austin

Feb. 4, 2011

Re: wintrust/tests: make sure return values are used (LLVM/Clang) (3/4)

by Juan Lang

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

Feb. 4, 2011

Re: wintrust/tests: make sure return values are used (LLVM/Clang) (1/4)

by Juan Lang

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

Feb. 4, 2011

Re: Wine FAQ edits

by Vitaliy Margolen

On 02/03/2011 09:17 AM, Albert Lee wrote: > The instructions were intended to give some context for users who > might not be familiar with the ~ expansion. Then mention that if you must. "~" is used in number of other places in FAQ, and all over the net. Please keep it simple. > It's a fairly trivial one-liner as it is Which will blow away most windows users who have no concept of expansions and redirections. You not writing developer's guide, you writing FAQ for clueless windows users who want Wine do what they need. Vitaliy.

Feb. 4, 2011

[PATCH] winegcc - do not create .exe.so

by Pali Rohár

Hello, I created patch which implement correct _start section in ELF shared libraries/binaries which generate winegcc. Into _start section this patch add calling execve syscall which start wine with all arguments. So it is not needed to generate shell wrapper and .exe.so binary. This replace code on: http://wiki.winehq.org/Winelib_binaries_as_ELF_executables_not_.exe.so $ winegcc app.c --> generate only a.exe (shared object ELF binary), no aditional a.exe.so $ ./a.exe --> start binary correctly without shell wrapper -- Pali Rohár pali.rohar(a)gmail.com

Feb. 4, 2011

updated LLVM/Clang static analysis results (and valgirind :-))

by Austin English

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

Feb. 4, 2011

Re: Re: user32/tests: Test for behavior of WM_SETTEXT handler (try 2)

by Marvin

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

Feb. 4, 2011

Re: Re: user32/tests: Test for behavior of WM_SETTEXT handler

by Marvin

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

Feb. 4, 2011

Re: Correction to crash inside RtlCaptureStackBackTrace() + test case

by Alexandre Julliard

Janne Hakonen <joyer83(a)live.fi> writes: > The test cases at http://source.winehq.org/patches/ are still in > pending state. Should I improve them somehow, or leave them as they > are? I'm not sure that there's a good way of testing this. You can't use exception handlers in tests, and you can't assume that ebp is pointing to the current frame either, unless you do the whole function in assembly. -- Alexandre Julliard julliard(a)winehq.org

Feb. 3, 2011

Re: RFC: Adding Mac support to secur32/schannel.c

by Charles Davis

On 2/3/11 11:46 AM, Henri Verbeet wrote: > On 3 February 2011 18:58, Alexandre Julliard <julliard(a)winehq.org> wrote: >> It shouldn't have hacks, but I don't think it's unreasonable to use >> platform-specific services for things that don't have widely accepted >> standards. >> > That was mostly in reply to the general idea of only using Apple > provided libraries for no good reason. In fact, if you bring that to > its logical conclusion OS X users shouldn't use Wine at all, since > those are non-Apple libraries as well. Sounds like what I said came out wrong. I guess what I really want is not necessarily to totally eliminate external dependencies in Wine but to minimize them. I'd also like to improve system integration, for which using system-provided libraries may or may not help. > The part I'm personally not so convinced of is that this is going to > benefit Wine in any way. I'm not buying the argument that it's going > to simplify things much for Wine users on OS X. If someone is capable > of getting Wine to build and run successfully on OS X, I don't think > GnuTLS is going to be much of a problem either. I don't have the > impression most OS X users compile Wine themselves anyway though. The real problem with external dependencies is that right now, if someone were to put together a Wine distribution for Mac OS X, they'd have to go to the trouble of building a number of requisite libraries (which takes additional time), and of maintaining those libraries along with Wine itself. It's just additional work, not to mention the security implications, as Francois Gouget brought up. Judging from the lack of official Mac binaries, few people are willing to put in that work. (Mike Krönenberg is apparently willing, but instead of putting his effort into improving Wine itself, he's decided to make a fancy GUI that the forum people can't support. More power to him, but I'd like to see official Wine binaries. And yes, I have thought about doing that myself, and I know that you're going to say "Then do it" anyway.) I guess that Henri is right, and this would affect users (except those who do compile Wine themselves) only indirectly, if it does at all. Reducing external dependencies would make it easier on package maintainers, but all users really care about is what they see on the outside. (That would certainly explain why so many Mac Wine users use WineBottler.) I must have lost track of that along the way. I suppose then that what I really want to see in Wine is total system integration. The end user shouldn't really know or care that he's using Wine. When he double-clicks on a Windows EXE in the Finder, it should just work. (IMHO, It should work that way on Linux, too, and elsewhere.) Chip

Feb. 3, 2011

Re: RFC: Adding Mac support to secur32/schannel.c

by James Mckenzie

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 > >

Feb. 3, 2011

Re: Wine FAQ edits

by Albert Lee

On Thu, Feb 3, 2011 at 12:32 PM, David Laight <david(a)l8s.co.uk> wrote: > On Thu, Feb 03, 2011 at 11:17:39AM -0500, Albert Lee wrote: >> >> > >> >> ?It's exec(2)'ed so it doesn't matter what the program is. >> > >> > Basically run in a shell. So you need an extra wrapper (env) why? >> >> To handle PATH search, since Wine requires an absolute path. This is a >> common trick used for locating interpreters for e.g. Python as well. > > It does depend on 'env' being installed in a standard place! > It is also rather a side effect of env's real purpose - sanitising > the environment. > Absolutely, and I'll admit that /usr/bin/env is not quite as universal as /bin/sh, but this is the second example after one that just uses the simple absolute path to the executable. -Albert

Feb. 3, 2011

RE: Correction to crash inside RtlCaptureStackBackTrace() + test case

by Janne Hakonen

Ah, I see you had already corrected the stack overflowing, and found better way even. :) I tested the correction with the test cases and they passed. I also tried AwesomiumGL and I couldn't get it to crash, so looks to me that this bug is fixed. The test cases at http://source.winehq.org/patches/ are still in pending state. Should I improve them somehow, or leave them as they are? Thanks for help! Janne

Feb. 3, 2011

Re: RFC: Adding Mac support to secur32/schannel.c

by Henri Verbeet

On 3 February 2011 18:58, Alexandre Julliard <julliard(a)winehq.org> wrote: > Henri Verbeet <hverbeet(a)gmail.com> writes: > >> On 3 February 2011 18:01, Charles Davis <cdavis(a)mymail.mines.edu> wrote: >>> 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 >> I think Wine should have as few OS X (or Ubuntu for that matter) >> specific hacks as possible. > > It shouldn't have hacks, but I don't think it's unreasonable to use > platform-specific services for things that don't have widely accepted > standards. > That was mostly in reply to the general idea of only using Apple provided libraries for no good reason. In fact, if you bring that to its logical conclusion OS X users shouldn't use Wine at all, since those are non-Apple libraries as well. I'm not opposed to using platform specific libraries where appropriate. However, there's certainly a maintenance and support cost there. From what I've seen in the patch Ken posted it should be possible to do right on the technical side, although this version of that patch isn't quite it. It does mean you know have two implementations to support on Bugzilla etc. though. The part I'm personally not so convinced of is that this is going to benefit Wine in any way. I'm not buying the argument that it's going to simplify things much for Wine users on OS X. If someone is capable of getting Wine to build and run successfully on OS X, I don't think GnuTLS is going to be much of a problem either. I don't have the impression most OS X users compile Wine themselves anyway though.

Feb. 3, 2011

Re: RFC: Adding Mac support to secur32/schannel.c

by Alexandre Julliard

Henri Verbeet <hverbeet(a)gmail.com> writes: > On 3 February 2011 18:01, Charles Davis <cdavis(a)mymail.mines.edu> wrote: >> 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 > I think Wine should have as few OS X (or Ubuntu for that matter) > specific hacks as possible. It shouldn't have hacks, but I don't think it's unreasonable to use platform-specific services for things that don't have widely accepted standards. What really matters is that the platform-specific bits need to be small and well isolated, that's why we'd want others dlls to use schannel instead of going straight to OS libraries for instance. But having a small chunk of platform-specific code inside schannel with a clean interface doesn't seem problematic to me. -- Alexandre Julliard julliard(a)winehq.org

Feb. 3, 2011

Re: RFC: Adding Mac support to secur32/schannel.c

by Juan Lang

> It sounds like things aren't nearly as murky as other licenses, but if > we were in the position where we had to ship OpenSSL ourselves we > might run into a problem. We don't, we load it dynamically. --Juan

Feb. 3, 2011

Re: RFC: Adding Mac support to secur32/schannel.c

by Brian Vincent

On Mon, Jan 31, 2011 at 6:08 PM, Juan Lang <juan.lang(a)gmail.com> wrote: >> As Henri said, it's that it's a set of external dependencies (not just one; GnuTLS has its own dependencies) and that they are security-related. To the greatest extent practical, security-related libraries should come from one's distro or OS vendor. > > Sure, I can buy that. I'll note that OpenSSL is also available for > the Mac, and already loaded by wininet and winhttp. It could be > appropriate to move from GnuTLS to OpenSSL for schannel, so we'd only > have a single implementation for both Linux and Mac in schannel. Just to be clear, legal issues were raised once before with OpenSSL. See here for Geoff Thorpe's reply regarding this issue: http://www.winehq.org/pipermail/wine-devel/2004-July/028061.html It sounds like things aren't nearly as murky as other licenses, but if we were in the position where we had to ship OpenSSL ourselves we might run into a problem. -Brian

Feb. 3, 2011

Re: Wine FAQ edits

by David Laight

On Thu, Feb 03, 2011 at 11:17:39AM -0500, Albert Lee wrote: > > > > >> ?It's exec(2)'ed so it doesn't matter what the program is. > > > > Basically run in a shell. So you need an extra wrapper (env) why? > > To handle PATH search, since Wine requires an absolute path. This is a > common trick used for locating interpreters for e.g. Python as well. It does depend on 'env' being installed in a standard place! It is also rather a side effect of env's real purpose - sanitising the environment. David -- David Laight: david(a)l8s.co.uk

Feb. 3, 2011

Re: RFC: Adding Mac support to secur32/schannel.c

by Henri Verbeet

On 3 February 2011 18:01, Charles Davis <cdavis(a)mymail.mines.edu> wrote: > 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 I think Wine should have as few OS X (or Ubuntu for that matter) specific hacks as possible.

Feb. 3, 2011

Re: RFC: Adding Mac support to secur32/schannel.c

by Charles Davis

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. > 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). We've got a long way to go in that department, unfortunately. :( Chip

Feb. 3, 2011

Re: user32/tests: Test for behavior of WM_SETTEXT handler

by Alexandre Julliard

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

Feb. 3, 2011

Re: RFC: Adding Mac support to secur32/schannel.c

by James Mckenzie

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

Feb. 3, 2011

Re: Wine FAQ edits

by Albert Lee

On Thu, Feb 3, 2011 at 12:13 AM, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: > On 02/02/2011 09:52 PM, Albert Lee wrote: >> >> I meant 'cd' is the command preceding this one in the block this is a >> part of, if you look at the context. > > Then you should remove that cd instead. Starting instructions from "go to > your home directory" just to jump somewhere else doesn't make much sense. The instructions were intended to give some context for users who might not be familiar with the ~ expansion. > >> It's exec(2)'ed so it doesn't matter what the program is. > > Basically run in a shell. So you need an extra wrapper (env) why? To handle PATH search, since Wine requires an absolute path. This is a common trick used for locating interpreters for e.g. Python as well. > >> It works perfectly fine, thank you. It's not parsed by Wine and none >> of the embedded characters are metacharacters for the registry. That's the >> reason for explicitly calling /bin/sh -c. > > Don't write programs inside registry, especially involving multiple > expansions and output redirection. That's what the shell is for. Keep it > there as a simple 2 line script. It's a fairly trivial one-liner as it is, and doesn't depend on fixed locations for a script which would typically live in a user's home directory. -Albert

Feb. 3, 2011

Re: RFC: Adding Mac support to secur32/schannel.c

by Juan Lang

Hi Francois, > As far as I understand it's not going to be another implementation. But > you're probably right to warn about having multiple backends; that can > be bad too as has been seen with sound. Yes, that's part of my concern. > Not true. Anyone using Wine on Mac OS X will benefit by not having to > hunt down for a non-standard library to either compile or run Wine. That > means Mac users will be more likely to actually have a somewhat > functional schannel. Even those who use a packaged Wine will benefit > because it means they will no longer either receive an outdated GnuTLS > library that contains vulnerabilities with their Wine, or have to hunt > one down on their own, or have no schannel support. Perhaps. I'm not aware of too many apps that actually work with the built-in schannel. You tell me Outlook is one: that's news, although I suspect that primarily affects CodeWeavers' customers. It doesn't work for everyone, either: see bug 20562. Many apps depend on schannel, yet don't work. Google Talk, VMware Infrastructure Client, and Miranda off the top of my head, probably a few that I'm forgetting. > You say that schannel needs a lot of improvement and you say that we/the > community should work on that first. However making schannel perfect > will not make the dependency on GnuTLS any more acceptable on Mac OS X. > So both need to be done it's only a matter of 'in which order'? > > Option 1 > 1) Improve Mac support > 2) Improve schannel > Drawback is (1) makes (2) much harder but this has not been > conclusively proven. No. Tests would help determine the cost. As it is, it's only knowable ex post facto, and that means users suffer if it's true. > Option 2 > 1) Improve schannel until it's 'good enough' > 2) Improve Mac support > This means _most_ Mac users won't get any schannel support for a long > time. And in terms of development it means a big refactoring phase > near the end which may well be pretty disruptive too (hopefully it > wouldn't be as bad as the display backend or DIB engine refactoring). Well, that's why tests are important: they mitigate the risk during migration. Besides, I'm still not convinced that GnuTLS on the Mac is such an onerous problem. If it's an issue for your (CodeWeavers') customers, then your installer needs to be improved. If it's an issue for Wine on Mac users, well, there are already dependencies on non-Mac things, and most users end up using MacPorts or something akin to it to get them. As I see it, your option 2 is a false choice: improving schannel until it's good enough doesn't preclude improving Mac support. --Juan

Feb. 3, 2011