Juan Lang juan.lang@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
On 2/3/11 9:22 AM, James Mckenzie wrote:
- 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
On 3 February 2011 18:01, Charles Davis cdavis@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.
Henri Verbeet hverbeet@gmail.com writes:
On 3 February 2011 18:01, Charles Davis cdavis@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.
On 3 February 2011 18:58, Alexandre Julliard julliard@winehq.org wrote:
Henri Verbeet hverbeet@gmail.com writes:
On 3 February 2011 18:01, Charles Davis cdavis@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.
On 2/3/11 11:46 AM, Henri Verbeet wrote:
On 3 February 2011 18:58, Alexandre Julliard julliard@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
-
Alexandre Julliard -
Charles Davis -
Henri Verbeet -
James Mckenzie