coapp-developers team mailing list archive

[Garrett Serack <garretts@xxxxxxxxxxxxx>]

In the original discussion, the installation directory (where libraries and their associated files) are installed has absolutely zero effect on binding choices for picking up the actual DLL used for a particular shared library.  The directory layout is actually a convenience for a *developer* who wishes to simply use the latest, CoApp packaged version.

Shared library binding is handled by WinSXS, where a developer chooses a particular version of a library to bind to. So, for example let's say that you want to compile up Python with OpenSSL  0.98h . You can specifically choose the path for the import library by including the version, and you are bound to that version. Now, there is one slight caveat.

WinSXS allows a publisher of a shared library to set the policy of the shared library so that if they put in a bug fix, but do alter the binary interface (ABI) then at run time, the application picks up the latest ("Most recommended") *binary compatible* version of the library. 

This means that you bind Python to OpenSSL 0.98h. A bug is found, the publisher of OpenSSL releases 0.98k, and since the ABI hasn't changed, the major & minor versions haven't changed [0][98], just the revision [k]. So once the new library is installed, Python will use it. 

*This is the behavior we want*

However, when OpenSSL 0.99a ships, by virtue of having the minor # changed [98]->[99] the policy should not forward use on to the new version, and Python would continue to use 0.98k.

This is extremely important, because when we're using shared libraries, it's the author's/publisher's  responsibility to provide security and bug-fix updates in a binary compatible way, and it's the consumer's responsibility to use the libraries in a consistent fashion so we preserve that intent.

Yes, this relinquishes control from the consumer to the publisher, but that is a better balance anyway.

So, if you really really really need to bind to a very specific version, and you are dead set against preserving the shared library model, while it is possible to force bind dynamically to a specific version, what you are really wanting is to be statically bound. 

Lemme say that again: If you don't' intend to work with shared libraries in the prescribed way, you really want to be statically bound, and should select the foo_a.lib. You will actually gain additional performance, and will still be able to work in-process with other applications using the dynamic library version without collision.

Shared libraries need to be used in a shared-responsibility fashion.

>> This is an interesting discussion point, I think.  I can understand the 
>> rationale for having a non-versioned, well-known path pointing to the latest 
>> version of something (i.e. openssl symlink to openssl-0.98j).  However, I 
>> also think there's a case for projects that would never want to rely on an 
>> arbitrary version of a component they depend upon.

>> Take Python, for instance.  For every Windows release, I can tell you exactly 
>> which version of SQLite, OpenSSL, zlib etc that was used, because we version 
>> control all our dependencies (http://svn.python.org/view/external/), and are 
>> explicit about which versions get used in a given release.

>> The reason this is important is because that all testing and development is 
>> done with everyone using the exact same version of dependencies.  If you 
>> happen to build a local copy of a Python release but drop in a different 
>> version of SQLite, you end up with a release that's divergent from the 
>> 'official' build (at the very least, it'll be untested).

>> So, I'd argue there's a use case for projects to be explicit about which 
>> versions of other components they rely upon for a given release, and that 
>> there should be a way for CoApp to support that.

>> If we move towards building, signing and distributing projects on behalf 
>> of their owners, perhaps one of our pre-requisites would be that the project 
>> needs to elicit the exact version of their dependencies that they did all 
>> their release testing/development against.

Thoughts?

Garrett Serack | Open Source Software Developer | Microsoft Corporation 
I don't make the software you use; I make the software you use better on Windows.


-----Original Message-----
From: coapp-developers-bounces+garretts=microsoft.com@xxxxxxxxxxxxxxxxxxx [mailto:coapp-developers-bounces+garretts=microsoft.com@xxxxxxxxxxxxxxxxxxx] On Behalf Of Gordon Schumacher
Sent: Wednesday, April 14, 2010 6:38 AM
To: coapp-developers@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Coapp-developers] Another kind of package

On 4/14/2010 6:58 AM, Trent Nelson wrote:
> So, I'd argue there's a use case for projects to be explicit about 
> which versions of other components they rely upon for a given release, 
> and that there should be a way for CoApp to support that.
> If we move towards building, signing and distributing projects on behalf of their owners, perhaps one of our pre-requisites would be that the project needs to elicit the exact version of their dependencies that they did all their release testing/development against.
>   

I can certainly see the value in that, on one hand... but on the other hand, the last project I was on had a substantial list of third-party library dependencies.  The obvious "building block" libraries got pulled in by quite a number of different components - libpng, libxml, MySQL, OpenSSL, and Qt all depend on it.  I was also building some of the tools we needed, so that they too would be in the self-contained toolchain, so Subversion, Ruby, Perl, and indeed Python also all had a zlib dependency.  For the sake of sanity I explicitly did not want to attempt to deal with multiple versions of these libraries - not least because some of these libraries could get shipped to the customer, potentially over a slow online update.

I actually ended up doing quite a fair bit of "extra" work in order to /not/ use the pre-bundled versions - in some cases, it was more or less enforced by the project's Win32 build system, hence why a great lot of my script was running "sed" or some such against build scripts!

_______________________________________________
Mailing list: https://launchpad.net/~coapp-developers
Post to     : coapp-developers@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~coapp-developers
More help   : https://help.launchpad.net/ListHelp