Re: [Audacity-devel] The right way to install VC redist stuff

[Vaughan J. <va...@au...>]

My recollection is that the Microsoft runtime installer is huge, larger 
even than the (current) Audacity installer because it includes lots of 
DLLs we don't need. So -1 from me on that point -- I don't think we 
should more than double the size of the installer and put more cruft on 
users systems than absolutely necessary.

Microsoft has been continually making DLL Hell worse over the years, all 
the time saying they're fixing it. Adding their installer is just 
relying on them in a different way, and per your SNAFU comment, I think 
we can count on this to just be another layer on how they can screw it up.

Please remind me why we got back into DLL Hell. I thought we had it 
settled out with the trick I figured out on the manifest and SP1.

For many years, we just linked Audacity to the VC runtimes statically, 
because that was the best way to control exactly what goes in our 
installer, keep the size small, and ignore the (often) multiple copies 
of runtimes in the system folder. My recollection is we went to dynamic 
linking as part of the move to modules, but we could revert to static 
linking for the VC runtimes and link to everything else dynamically. 
That's what we did with LAME, for example, when we were static-linking 
the VC libs.

- Vaughan


On 3/2/2010 9:30 AM, Al Dimond wrote:
> On Tuesday 02 March 2010 03:08:23 Markus Meyer wrote:
>    
>> Al,
>>
>> while that's exactly what we do for our commercial programs in the
>> company, I'd rather like it if we would not depend on having the
>>   runtime installed. I know many people who use Audacity either from
>>   a network drive or from an USB stick (there's even a "Portable
>>   Audacity" distribution on the net).
>>
>>      
> I guess that's fair. My Unix side (which is my bigger side by far)
> wants to say, "if you're packaging Audacity in unusual ways it's your
> responsibility to handle dependencies, ours only to report them." I'm
> sure the people making Portable Apps have lots of experience hunting
> down dependent DLLs.
>
> There are reports that Microsoft's redistributable CRT installers
> cause really long delays during the install process and scatter temp
> files on the root of your HD. Which is kind of ridiculous -- the
> installer is responsible for 3 files. On that count, if we can get away
> with copying 2 DLLs to the app folder it's a much better user
> experience.
>
>    
>> I think it should be easy to test whether we ship the right DLLs
>>   e.g. using a clean Windows XP or (better yet) Windows 2000 install
>>   in a VM.
>>
>>      
> I don't think WinXP or Win2k are as picky about their DLL versions as
> Vista and 7 -- I'm pretty sure that as long as you have DLLs named
> msvcr90.dll and msvcp90.dll in the search path (pwd, app directory,
> PATH, and maybe some stuff listed in the registry somewhere) and they
> export the right symbols it'll let you by. With the "side by side"
> loading system of Vista/7 you have to have the version called for by
> the embedded manifest.
>
> It isn't that hard to check the DLL versions and manifest versions
> from your dev system. I've had some weird stuff going on on mine, where
> VS is depending on multiple CRT versions, but most people haven't had
> that problem. But I think if we really wanted to test we'd need a
> clean Vista or 7 system.
>
>   - Al
>
>    
>> Markus
>>
>> Am 01.03.2010 22:02, schrieb Al Dimond:
>>      
>>> Background: In order for Audacity to run on Windows the VC++
>>> runtime must be installed. When most people build it needs the VC
>>> 2008 RTM version, when I build it needs both that and the SP1
>>> version. The current SDK ships with just the newer one, which
>>> causes problems for everybody.
>>>        
>> -------------------------------------------------------------------
>> ----------- Download Intel® Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> audacity-devel mailing list
>> aud...@li...
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>
>>      
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> audacity-devel mailing list
> aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
>