Hmmmmmm … I’m very sorry but I can’t help feeling that the most appropriate response to the above post could well be:
while(true != false) {
printf(“mostly wrong ! n”)
}
… as no doubt is the above code fragment I suspect 
Unfortunately I’ve already installed various versions of the VC* distributables and done numerous tests and so on. I must freely admit in advance that what follows may well also be somewhat wrong due to me misunderstanding things because all of this is very much outside of my field of knowledge. However, it is how my somewhat uneducated eye sees the current situation after finding many reports of very similar issues, having a good look at the VC* distributables packages, finding references to known bugs in VC* and seeing what the Audacity code makes direct reference to.
As can quite clearly be seen from the Audacity code extracts I quoted previously:
(1) The Audacity executable was apparently compiled using VC2008 but even if it wasn’t, it does make specific reference to the DLLs relevant to VC2008 (i.e. V9.0.21022.8)
(2) The manifest being supplied with ‘new’ versions of Audacity was apparently produced using VC2008/SP1 and the associated DLLs appear to be those supplied with SP1 (i.e. V9.0.30729.1)
I would therefore suggest that it is fundamentally wrong to state that installing VC2008/SP1 distributables is required in order to run Audacity. In any case that is apparently exactly what is being supplied in the Audacity zip files that I’ve been using of course. Audacity will not work using the supplied VC2008/SP1 distributables. What is apparently required before running Audacity as it stands at the moment is to install the VC2008 distributables which is presumably what should have been supplied in the Audacity zip files. Audacity needs to be recompiled to correctly reference VC2008/SP1 distributables if that is what’s intended to be used and/or what is actually required by the code.
In principle, one would think that a higher version DLL /ought/ to be acceptable. HOWEVER, that may well not be the case of course. It is equally possible that by design, version numbers must match precisely not just be greater than or equal to those used when an application was compiled. I have no idea what the official requirement actually is because I have no knowledge of Visual C++ … but it seems to me from what I’ve been doing here that the versions MUST match exactly and a local copy of a greater version is simply not acceptable. This mis-match in version numbers appears to be precisely what is causing the “not a valid app” error. Apart from any other consideration, there’s no point whatsoever in having different versions and specifically referencing them if it doesn’t actually matter that much in reality. Audacity really wants to use V9.0.21022.8 DLLs but it can’t find any. It can only find V8.0.* DLLs on the system and V9.0.30729.1 DLLs locally … so it either falls over or WinXP intervenes and objects but either way the end result is a “not a valid app” error. Other applications and other OSs can (and often do) produce different error messages but the end result is always the same - the application doesn’t run. Hacking the manifest apparently works quite simply because it fools Audacity and/or Windows into believing the V9.0.30729.1 DLLs that it’s actually going to use are really V9.0.21022.8 DLLs !
The bottom line however is that the version required by an application and that provided with an application quite obviously should match exactly. There is absolutely no excuse for this not to be the case needless to say. BUT WITH AUDACITY IT DOES NOT !! Audacity will therefore run IFF the ‘right’ version DLLs just so happen to be found lying around somewhere on the target system. Whether the ‘right’ version is that used when the application was compiled, that referenced within the application or that specified by the associated manifest is anyone’s guess. Likewise, whether the application will work entirely correctly and as designed with one DLL version and/or the other is also anyone’s guess.
What a bl**dy mess 
and it has to be said, a very good demonstration of how an almost total lack of control in software development in general frequently causes end-users no end of unwanted and totally unjustified grief. Whilst the root cause of this problem appears to be solely down to Billy Gates & Co not fixing known bugs, it’s apparently also an issue that’s been around for several years and one that’s well known to developers. Much as I have the utmost respect for those who are developing Audacity and many other excellent applications … there does appear to be a fundamental lack of version control here and a bit of Quality Control involvement most certainly wouldn’t go a miss and all that 
If I can find any good links that explain the problem(s) far better than I possibly can then I’ll post them later. However, someone with good level of technical knowledge might want to have a quick look at Visual C++ bug report #361682 which I stumbled across as it relates to this sort of problem and also reveals that it was blatantly closed without any sensible action being taken to rectify it. I think someone certainly needs to look in some detail and understand fully the real-world implications when code is being released that requires the use of specific versions of the distributables. The right version(s) need to be supplied or the end-user needs to be correctly informed of what needs to be installed in advance.
[rant]
(definitely not specifically aimed at the Audacity team but rather towards ALL software developers in general because this kind of nonsense wasting extraordinary amounts of my time really p****s me off !)
A quick search will reveal that there is absolutely no shortage of users reporting problems very similar to what I’ve raised here involving many different applications and various other OSs. In every single case I’ve looked at, the only support suggestions have been corrupt files, malware, system problems etc. resulting in lots of b*ggering around for the end-user and no real solution being found in most cases. Nowhere have I seen any positive and particularly helpful suggestions. Nowhere have I seen any reference to what I can now see is a very well known development issue where incorrect DLLs are often being referenced by or provided with applications developed using Visual C++. The number of man-hours/days/weeks/months/years being wasted due to the inevitably lengthy periods of general messing around and in some cases due to end-users being told to reinstall or upgrade their OS must be astronomical. And all because of well known MS bugs that no one apparently either understands fully the implications of, has any desire to fix properly and permanently or even wants to freely confirm the existence of in public to those who actually NEED to know about them. It’s no surprise to me that developers always have a seemingly insatiable desire to hide all of their code in an anonymous executable installation package so that the end-user has absolutely no idea exactly what’s going on and what it actually contains. All they know is that running the installation package either works as intended and has the desired results … or doesn’t. If it fails for any reason whatsoever then they have absolutely no way of working out why and resolving whatever the problem might be or of properly cleaning up the mess generally left behind by a failed installation.
… and breathe
[/rant]
Although I fully accept that I might well be 100% wrong of course and this is just a hack so please do note the quite intentional " 
