2/20/2018 0 Comments Microsoft .net Active Template Library Atl Module: full version free software download![]() Nov 04, 2013 Special Microsoft files are required on runtime. Visual C++ runtime libraries and the Microsoft.NET Active Template Library (ATL) module. Windows Template Library: Still Alive and Kicking. Library was Microsoft's most successful attempt at providing a C++. The newer Active Template Library. The Active Template Library (ATL) in Microsoft Visual Studio.NET 2003 SP1. This module exploits a memory corruption vulnerability within versions 10 and 11 of the Office Web Component Spreadsheet ActiveX control. This module was. NET DLL memory technique by Alexander Sotirov and Mark Dowd and should. The latest version of this topic can be found at Active Template Library. A new feature in Visual C++.NET. Discusses the module classes new for ATL 7.0. To simplify COM development, Microsoft introduced ATL (Active Template Library) for C++ developers. ATL provides for a higher-level COM development paradigm. It also shields COM client application developers from the need to directly maintain reference counting, by providing smart pointer objects. Other libraries and. ![]() Hi, In our organization, we are planning to upgrade Powerbuilder12.6 to Appeon Powerbuilder 2017 on Window 2008 R2 machines. Can someone please help with below info - • Which is the stable Powerbuilder 2017 version which should be used/installed? As per Appeon site the latest available for PB is Build 1681. • When Powerbuilder 2017 R2 will be getting released? As per keynote presentation, it was scheduled for release around Mid Jan 2018, does anyone have exact details about the same? • In the Appeon 2017 installation guide, under Visual C++ Runtime and the Active Template Library, it's mentioned that - When you deploy the core PowerBuilder runtime files, make sure the msvcr100.dll and msvcp100.dll Microsoft Visual C++ runtime libraries and the Microsoft.NET Active Template Library (ATL) module, atl80.dll, are present on the user’s computer or server. Whereas in Powerbuilder manuals, I found below - When you deploy the core PowerBuilder runtime files, make sure the msvcr100.dll and msvcp100.dll Microsoft Visual C++ runtime libraries and the Microsoft.NET Active Template Library (ATL) module, atl100.dll, are present on the user’s computer or server. Is it really required to have atl80.dll for PB 2017 installation or atl100.dll will suffice? If atl80.dll is required then does it needs to be installed separately or comes as part of PB 2017 runtime packager itself? Microsoft visual studio 2010 is already installed on the machines which contains msvcr100.dll, msvcp100.dll and atl100.dll Regards, Abhijit Question Tags: • •. Hi The PB Help was a little confusing in PB 2017. However, Appeon have clarified this in the PB2017R2 release, as follows (from the R2 Help): When you deploy the core PowerBuilder runtime files, you must also deploy the msvcr80.dll (for 32-bit only), msvcp80.dll (for 32-bit only), msvcr100.dll, and msvcp100.dll Microsoft Visual C++ runtime libraries and the Microsoft.NET Active Template Library (ATL) module, atl80.dll (for 32-bit only) and atl100.dll, if they are not present on the user's computer. The PowerBuilder runtime files have a runtime dependency on these files HTH Regards. Hello, On Tuesday 28 July we released guidance and updates to assist developers using our Active Template Library (ATL) to prevent creating controls or components with potential security vulnerabilities. Vulnerabilities in libraries are a rare, but industry wide issue, that requires broad collaboration and action by the community at large to effectively resolve. Developers who have built controls using the ATL should take immediate action to review their control to identify if it is vulnerable and take appropriate action to rebuild their control using the updated ATL library and distribute a non-vulnerable version of their control to their customers. If you develop any controls with ATL then please take a look at the detailing the steps required to identify and address affected controls. Also, we cover the issue in a. Thanks Damien Visual C++. Hello The recent ATL Security Update targets two different customer scenarios: 1) end-users and 2) developers. Here an “end-user” can be categorized as anyone who has the VC Redistribute package installed in a standard location (see note below) and which can be installed directly by a user or as a result of installing another product. A “developer” is anyone who has Visual Studio installed. Here is a quick synopsis of what gets installed for each scenario: *End-user experience* a.A new version of atlXX.dll (where XX matches a specific version number) is installed in the Fusion Cache (a.k.a. Windows SxS folder) WindowsWinSxS*atl* Developer experience a. A new vcredist.exe – that contains: 1) the latest version of the CRT, ATL, MFC and OpenMP libraries 2) Matching pdbs for the new libraries that support multiple architectures (X86, X64, IA64) 3) And for completeness/correctness, some headers from CRT, ATL, MFC, and import libs 4) New CRT, ATL, MFC, OpenMP libraries in the Fusion Cache (this is different to the end-user experience – see above) *Why?* In these scenarios the end-user experience is as small as possible while the developer experience is as compete as possible. Thanks George and Damien Please note: The standard location can vary based on your operating system but its exact location is immaterial to this description. Hello David Thanks for taking the time to send us your comment/question. My first question to you would be “why would you want to?” Assuming you deploy the referenced version of the CRT with your application (which is our strong recommendation) then the relevant CRT version would therefore be on the target machine? That said, you can work around it if you want (caveat emptor), see here for one example of how to do that: Just for completeness I should point out that VS2005 and VS2008 have different semantics when binding to CRTs, see this post from George for more details: (these may also be of interest too: and ). Thanks Damien. I think you can replace #define _BIND_TO_CURRENT_VCLIBS_VERSION 1 with #define _BIND_TO_CURRENT_ATL_VERSION 1 #define _CRT_ASSEMBLY_VERSION '9.0.30729.1' #define _MFC_ASSEMBLY_VERSION '9.0.30729.1' #define __OPENMP_ASSEMBLY_VERSION '9.0.21022.8' to use the latest version of the ATL DLL and explicitly reference the previous versions of the other DLLs (on my machine there is no SP1 version of the OpenMP DLL, only the RTM version). It’s better to put the equivalent definitions in your project preprocessor settings than in a header file. I don’t think any of this is supported by Microsoft though and I haven’t actually tried it myself. Why do I always have to learn something new when some idiots make a new version of the software? Is it not easy enough to copy everything from the previous working version and LET IT BE as it is! Just improve what is needed but don’t alter anything because the work to learn everything again is making everybody angry. We have here already hands full of work with our own programs. We don’t want to have anything additional just to use some new version of software! And learn lot of unnessesary changes only because the developers are idiots! KEEP IT STABLE! What would you think of a car that had to be driven backwards only because some team of idiots want to make changes!?! Nobody would want to use that car! Car manufacturers just change a bit the way the new model looks but keep it the same otherwise. Is it too much to ask to do less and be better! Hello Janne Thanks for your feedback and sorry for the inconvenience we have caused you. So in general the model here should be relatively straight forward, whenever you build/rebuild your software, you need to ship your binaries (exes/dlls) and the redistributable for the libraries you are built against (i.e. This is the reason we have/ship the VC Redistributable and this has not changed recently. We have made changes in how libraries are found on the disc (fusion/sytem32) or which version you target by default (RTM/Current) but the same guidance/process – ship the redistributable for the libraries you are built – stays the same. Is there an issue with this design that does not work in your situation? Thanks Damien. Our process involves checkin driven automatic builds of ~100 Visual Studio project files. We have another ~20 projects that are built on demand due to their large size and infrequent modification. Finally, we have prebuilt 3rd party libraries and DLLs that are integrated into the code. We don’t have source code to those modules; in fact, we would be hard pressed to convince some of the vendors to give us a hotfix (let alone a new build). Modifying every source file over this large of a project (including open source projects) is not feasible. Using 4053 and 762 at same time does not appear possible either (there are reports saying that having them in the same manifest is bad and should be fixed). Getting new versions of libs and dlls from vendors (more than 20 in several different countries) is also not something that can be done terribly quickly (especially when you’re minimizing change during late stage development). Upgrading the runtime library will require a complete new release cycle/test which will delay the release by at minimum a month. We do NOT use ATL/MFC anywhere but are forced to do this because the CRT runtime is also upgraded. We have automatic updates disabled and have not applied the patch given the impact. It is also worth noting that some of our developers have had trouble getting the patch to install as it crashes due to missing.msp files. Is there a way to install the patch without all the.msp files or original media? Beyond this, what is the most reasonable way to deploy a patch like this on such a large project? It doesn’t look like there are many options without the uber-recompile. We use VS2005 sp1 with InstallAnywhere (no MSI) with the msv*.dll files and *.manifest files in our directory. Rgreen – at – voxeo.com. This bit me yesterday. I was making one of the final builds of a new version of the application that is running inside one of our lighting control systems. Suddenly, our beta testers around the world started to complain that the new build didn’t even start on their computers and lighting control boards! (And since you just get the useless 'Invalid configuration' error message, it doesn’t give you much of a hint.) I almost paniced because we are supposed to go public with this version on Friday this week. After hours of seeking, I realized that there must have been some automatic update on my development machine that replaced the libraries. When making the new build, VS2005 silently started to refer to the new library. Our testers and our XPEmbedded control systems didn’t have the update (of course) so they couldn’t run. I find the whole idea of silently changing to a new library version horrible. This happened during the very last days of our beta testing. Even if I know what happened now, I cannot simply throw in a completely new version of the core runtime libraries in the very last minute (looking at the change in the build number, there must be a lot of changes). This needs to go through heavy testing before we can start using the new library in a mission-critical system! It seems like you have little experience in how things are used in the field. Rob Green (above) seems to have pretty much the same experience as I do but on a larger scale. I am sure that there are lots of frustrated users out the now. Also, I still haven’t been able to force the compiler into using the old 762 build of the DLLs. I have tried the various tricks that have been suggested. Could I just uninstall the patch? Quote: 'Thanks for taking the time to send us your comment/question. My first question to you would be “why would you want to?” ' 1. Echoing others, we have a set of third party libs built against SP1 that we don’t want to recompile right now. We want to do this at an appropriate point in the release cycle. For example, in Trunk, not on a stable Branch the day before a release. Currently, our build machines have not had the windows update applied, yet most of our development machines have. You could argue that this is wrong, but I’m sure this is not unusual. All machines have VS2008 SP1 of course. I really think that this should have been part of a Visual Studio service pack allowing us more control whether to adopt the new CRT. Regards, David. I’m having a different problem but one that is related. After patching our build machines with the security update (VS 2005) we started having trouble with the setups for our products (generated by InstallShield). Even after I made sure InstallShield was using the updated merge modules for MFC, ATL, etc., when I run the installer it does *not* install the 4053 assemblies (and our applications will not launch). However, after I run the vcredist on the target system the 4053 versions are installed and the application works fine. This may be more of an InstallShield bug than anything. But how is it that merge modules provided by Microsoft don’t seem to be actually gathering in the correct DLLs when the setup is compiled? Hello David Thanks for taking the time to send me more information – it definitely helps us understand your scenario better. Let me walk through your two points to see if I understand them as I still have (yet more) questions: Re: your point 1) you do not have to have these third party binaries recompiled if you do not want to – you can just keep using the versions you have. [A couple of sub-points however:] 1) If they have the security issue that the update addresses and are potentially vulnerable then you may want to have them recompiled – but since I do know the specifics I would not know if this would be an issue 2) Regardless of point 1, the third party binaries will probably be rolled forward to running on the new libraries anyhow, if they run on an end-user machines with them installed (via auto-update for example), but this should be no issue. Are the end-user machines some type of dedicated machines without automatic updating? [End of sub-points.] Re: your point 2) building on different configurations to those you develop on is again your choice (and given a large organization with many developers occasionally seems inevitable to some degree) – but I am not sure I see the issue here, if the build machines are consistent then they will reference only one version of the libraries and if you ship the redistributable with your application then it will all work – the only issue here I see here is if you do not to ship the redistributable – and that is definitely not a supported scenario. I should just clarify too, when I say 'ship the redistributable', you have a few ways to do this – VC Redistributable, MSMs, app-local and even static linking (although there are some issue with static linking) but all will get the new libraries on to the end-user system. Let me know if am getting closer to understanding the scenario here? Thanks George and Damien. Hello Anders Your situation (or at least the questions I would ask about it) seem similar to those I asked David but I suspect you will have some different answers (since your end-user systems may be closed box dedicated machines if I read your situation correctly.) Personally I am less familiar with the XPEmbedded scenarios so I may have a few more question for you however. Re: your comment: Our testers and our XPEmbedded control systems didn’t have the update (of course) so they couldn’t run. So I assume you are saying that it does not make sense for you to (and therefore you do not) ship the VC Redistributable (or the new version of it) with your application to these systems? Is that because you have “closed-box” system with the XPEmbedded control systems? If the answer is yes and yes then it may not make sense to have your development machine auto-updating if this will move them out of sync with your target platforms. Would that sound correct? Do your target systems ever update our libraries then? And if so how? > Could I just uninstall the patch? Our general advice is to never uninstall Security Update but if you provide a “closed-system” device that does not have access to auto-updating and is sealed then you may be able to determine that an uninstall is safe for you but you need more information than just this to make a decision. Thanks George and Damien. Hello Rob If you have automatic updates turned off on your developer/build machines then you will not see the new CRT (therefore your binaries will not reference it) and all your end-users will just work (many of your end-users will be auto-updated but regardless nothing will break.) There is no way to install the update without the msp. Not sure why you are seeing an issue installing the patches, is there anything “different” about your setup? (We have tested the install on VS2005 to verify it and it is definitely working for us.) Unfortunately, if you need the Security Update then you probably need the “uber-recompile”. Feel free to follow up directly if you want, my email is my_first_name at you_know_where (and this is Damien typing ) Thanks George and Damien. Hello George and Damien I think I meet the same problem with David. I have built something.exe before install this package, and have copied microsoft.vc90.crt.manifest, microsoft.vc90.mfc.manifest, mfc90.dll, mfc90u.dll, mfcm90.dll, mfcm90u.dll, msvcm90.dll, msvcp90.dll, msvcr90.dll to the same directory with something.exe, and put all of them to a custom’s pc with neither VC redistributable package nor service pack installed. Something.exe works! I open the something.exe with UltraEdit, and cound find that both the CRT and the mfc version which were referenced are 9.0.30729.1 in the assembly information. Of course I have defined #define _BIND_TO_CURRENT_VCLIBS_VERSION 1. BUT NOW, after installed this update, the new version 9.0. CRT, MFC and so on have been installed in to WinSXS. After I re-build the something.exe, I will reference CRT 9.0.30729.1 and reference MFC 9.0. And Dependency CRT 9.0. And something.exe won’t work in the custem’s pc. I have try to overwrite the CRT, MFC files with the new version 9.0., but no effect. Sorry for my poor english, any question please let me know. Please advise me how to do, thank you very much! Nicholas Wang. Our story and comment. Months of beta testing and everything is going smooth, the day before going to duplication. One minor change is made to program and recompiled and released for internal testing. User emailing to R & D that program won’t come up. Look into Vista event log shows side by side conflict. Where did version 4053 come from Hunting. Find culprit security updateDuplicator is asking for final release. End user must install release by 8/26/09 or application stops working. What do we do? Not enough time to try suggested changes. The fear of un-installing. Head ache of dealing with a patient with knife pulled out and trying to sew them back together. Scratching our head what to do to beat the deadline. Looked under desk. Found old computer taken offline one year ago. No security update installed with VS 2005 SP1. Got the program compiled. Build final release and hand off to duplicator. Ready for FedEx pickup to go to customer. Blood pressure comes down Since 2006 8.0.50727.762 was untouched and sent out with our program. Then comes thru a backdoor is a security update that everyone loads due to fear of virus attack and changes our compiler and runtimes. This should have come down thru a service pack and not a security update. People would have been more cautious to load a service pack. Giving others time install it learn about the conflicts and warn other programmer about this. Instead of just blasting it out to the masses in a security update. Now we think twice about installing those security updates. Hi, Ted Thank you for your information! My EXE is a very simple, I don’t think so there is any library included by it. BUT I have resolved this issue after the following change: in the file 'C:Program FilesMicrosoft Visual Studio 9.0VCincludecrtassem.h' ——————- #ifndef _CRT_ASSEMBLY_VERSION #if _BIND_TO_CURRENT_CRT_VERSION //#define _CRT_ASSEMBLY_VERSION '9.0.30729.1' // to be commented #define _CRT_ASSEMBLY_VERSION '9.0.' // to be added #else #define _CRT_ASSEMBLY_VERSION '9.0.21022.8' #endif #endif ———————- Rebuild the exe, and copy CRT & MFC runtime files with 4148 to the same dir with exe, It seems all things work. > So I take it from your comments that you do not ship the “VC Redistributable” with your application – can I ask why not? And what is your process to see that the correct runtimes get on to end-user machines? I think you’re missing the point. The problems are that: 1) People didn’t know that they needed to deploy a new version of the CRT, because they reasonably expected that an ATL security update only updates ATL, and because they don’t equate 'I want to protect my machine against security threats' with 'I want to be forced to deploy a new version of the CRT and ATL right now.' This update installed silently on machines and then left people scratching their heads as to why other people suddenly couldn’t run their builds, but they still could. 2) You can’t expect everyone to instantly switch dependencies and deployment to a new version. Many reasons have been given already for this, including testing, need to obtain updated libs or installer packages from vendors, need to start a new regression testing cycle, restrictions in patch deployment to end users, etc. Nobody wants to take a dependency change the day before they ship. In addition, the tools for diagnosing this problem are lacking. The error message displayed to the user on XP systems — 'the application configuration is incorrect' — is very poor. I spent some time tracking down CRT mixups today and the only way I was able to track down the offender was to run 'strings' on each lib and grep the output. This could have been mitigated if: – The security update were installed separately from part of the update that affects build processes. – The part that affects build processes were an optional update. – The ATL update was labeled to also indicate a CRT update. – The VC++ Team Blog had a warning about the update BEFORE the portion affecting builds was pushed out. – The Visual Studio IDE displayed an indicator on the next startup that deployment requirements had changed. – The linker or manifest tool issued a warning when the merged application manifest references more than one version of the same DLL. – There were greater awareness as to the manifest mechanism, the symptoms and tools for diagnosing manifest-based load errors, and the CRT rebinding mechanisms. > So I take it from your comments that you do not ship the “VC Redistributable” with your application – can I ask why not? We do not ship VCRedist* with our application either – rather we use the merge modules. We do this due to the advice on this very blog that the 'VC Redistributable' should only be used for ClickOnce deployment: ‘“Click Once” will use a custom built installer package called “VCRedist_.exe” to install the libraries for you. DO NOT use the VCRedist_.exe installer packages for any other purpose.’ [] Does this statement no longer apply? Hello Paul Thanks for your posting. My first point here is that when I say 'ship the redistributable' (or something similar), I am not advising using one particular method over the others; this from previously in this thread where I said: I should just clarify too, when I say 'ship the redistributable', you have a few ways to do this – VC Redistributable, MSMs, app-local and even static linking (although there are some issue with static linking) but all will get the new libraries on to the end-user system. All means of “shipping the redistributable” have advantages and disadvantages, my meta-point here is that just that you should ship it one way or another with your application. I will look at the other post when I get in to work and see what guidance we gave there (and why specifically). Thanks for your follow-up and question – will get back to you as soon as I can. Thanks Damien. Hello Paul Once again, thanks for your question and pointing me to the previous post. I read what Ben said on the previous post and have two general comments. Firstly, in sprit I think Ben’s post is still consistent with the major piece of advice we have stated here and that is that you always need to deploy/ship the “VC runtime libraries” you depend on with your application and doing this is your first/best means to ensure your application runs successfully on end-user machines (and surely this is the ultimate goal). (Un-)Fortunately you have a couple of mechanisms to do this and need to choose one. My comments on this current post are generally about trying to find reasons why people prefer not to (or cannot) follow this guidance (and to be clear I am sure there are valid reasons, I just want to capture them and their scale, I am not saying that such reasons would never exist.) Secondly, as you can see form the other posting, Ben’s (and therefore our) guidance at the time was to prefer one method (MSMs) over others but again he speaks of advantages and disadvantages of all the different methods provided. You can also see on the thread that Stephan replied said that he preferred a different method to Ben (and I see Phaeron and others replied too with different opinions – nice to see Phaeron is still active on our blog.) The decision needs to be made by individual developers based on their application’s/user’s requirements/configurations – and I think that is really the best/only advice. Now to be clear (and for those who want me to take a stand), my personal preference, which I guess subliminally comes through when I post through the terminology I use, is definitely for VCRedist as the default, but of course I would not claim that this is the best/only solution in all cases. Redistribution issues aside, I think Michael’s post on August 21 and Phaeron’s post on August 26 hit the nail on the head. In my industry, development environments and tools versions are under strict configuration management and control. The prospect that our compilers can be updated at any time without our knowledge or consent creates a configuration management nightmare. Although I have Windows Automatic Updates disabled on my PC, our IT department forces anything labeled as a security patch through Landesk. The decision to deploy these fixes as a Windows Update instead of a Visual Studio Service pack was an unfortunate one. Nevertheless, we are where we are. Could you please advise as to how I can prevent these silent updates from taking place in future. Thanks and regards. Hello Frank > This currently keeps us from delivering service packs for our product, since InstallShield does not provide an updated merge module. Thanks for sending this question on to us. I assume there may be a typo in the sentence above, InstallShield does not provide the updated MSMs, we (VC) do. And the update does provide these, the location on your machine should be something like: C:Program Files (x86)Common FilesMerge Modules Let me know if they do not exist after you install. Thanks Damien. This update causes major problems for those who have distributed applications based on the merge modules and wish to later patch their application. Once an application is distributed, you must obey the rules required for a minor update (no product code change), and this does not allow for installation redesign. Normally, you don’t care to devote time to installation restructuring and testing in minor updates as well (which means you typically don’t want to move to vcredist). Therefore, you need to be able to specify the version of the CRT in your build so that the installation package can continue to use the original merge modules and allow the automatic updating to get the newer versions installed. Therefore, it may not be that you want to use the old CRT, but rather that you have to use it for expediency. Alternatively, you could conceptually merge all merge modules (e.g., RTM, SP1, and updated versions) into the installer for your minor upgrade as this would not violate any minor upgrade rules since it only adds new components from the new merge module. This would keep the previous compiler versions on the system after an upgrade is made but would remove them when the last referencing application is uninstalled. However, due to a problem in the VC++ merge modules that is trivial to fix (see ), this cannot be done either. This actually would be a good solution to this problem if this fix was made. Hello Thanks for the great feedback and comments. Just one further personal observation, I am not sure how much you gain (if you gain anything at all actually) by reverting the runtime libraries on your dev/test machines if you then deploy your binaries to customers who have machines accessing the internet or on which customers are installing other products. I am adding my comment only because I as yet do not see any responses from this blog’s authors that represent an understanding of the issue. There is a fundamental difference between applying security fixes to software and changing development environments. It is unacceptable that a security patch updates other applications development environments. I found reading this blog entry and the nonresponse to the central issue very frustrating. I would like to read that Microsoft understands their mistake and that they will never do this again. Bottom line Microsoft now has a trust issue. Until I hear Microsoft acknowledge this and pledge to change, the only alternative is to disable Windows Update to protect against these damaging updates. Make no mistake changes that invalidate testing, cause support issues, wasted time researching, reading and responding to blogs, and the delayed releases, etc. That have mentioned in this blog it is obviously a damaging update. Does Microsoft get that? I will echo the previous posters in that the blog’s authors do not seem to understand the issue. We are ONE DAY away from releasing our next version of software, and quietly, unexpectedly, and sneakily, Microsoft go and mess with our development environment behind our backs. Suddenly a build that worked perfectly a few days ago is filled with errors and worse, we can’t explain why. Please do not ever do this again. You simply cause trust issues – we will now be deactivating automatic updates across all machines simply to avoid this issue ever happening again. Is that really the response you wanted? Is that really how you want your critical updates viewed? Have you perhaps forgotten that people need to update installers as well to fix this mess, and that doesn’t happen by magic? Just to follow up on this specific reply 'Re: your point 2) building on different configurations to those you develop on is again your choice (and given a large organization with many developers occasionally seems inevitable to some degree) – but I am not sure I see the issue here, if the build machines are consistent' They aren’t in all cases. Large software projects inevitably pull in plenty of third party (sometimes internal) libraries that were built for VS2005 RTM or SP1 and cannot be rebuilt at a whim (major costs involved). Thanks to this update, Visual Studio then proceeds to embed a default manifest referring to both CRTs/MFCs, which certainly seems incorrect (please say if it is correct, because there’s advice out there to the contrary), and the entire thing occurred with no warning until our automated tests broke because we had no idea that we needed new redistributables! I’d be the first person to say I appreciate bugfixes and updates in older products, but the lack of proper communication over this is completely unacceptable. Phaeron hit it on the head with his list of failures so I won’t repeat them. I think Visual Studio needs to be prepared before those updates can take place without hassle: 1) Make the runtime selectable from the project settings, graphically, e.g. A combobox, not only by defines which nobody finds if one does not know they exist. A runtime security patch should never ever change that project setting. So only the project owner decides if any newer runtime should be used. 2) For being able to target different runtimes and create setups for and with those runtimes the VS setup and patches should allow 'side by side runtimes' (libs, dlls, pdbs, merge modules and vcredist) so that on each machine you always have all versions of the runtime available, not only the latest. So I would expect each set of runtime files to be put in its own redist subdirectory, so no newer runtime replaces an older one – I do not talk about windowsWinSxS but about the VS files under programfiles. 3) With the above 'versioned' runtime directories the built in setup projects could find their correct runtime merge modules as well, so neither new builds nor new setups cause any change in runtime distribution. With the above prerequisites I would not mind too much to get new runtimes installed by windows update. 'Large software projects inevitably pull in plenty of third party (sometimes internal) libraries that were built for VS2005 RTM or SP1 ' to add to JeffH’s reply, I can give a real world example: ActivePDF, which provides ISVs with PDF capability for their apps, ships a redistributable DLL that is hard linked (in the DLL’s manifest) into the 762 versions of VC2005SP1. With policy redirection, etc, it should be ok (can’t be 100% sure though), but I obviously don’t like having mixed references across binaries in a shipping app. Yet another dissatisfied customer. 1) My app is linked against the installed VS CRT. I ship the installed VS CRT. My exe requires, and is distributed with, 3rd party DLLs which are built by the supplier. The 3rd party DLLs reference a specific CRT verision which is supposed (!!!) to match my VS2005SP1 CRT. If the CRT version silently changes then I have two problems: (a) I’m shipping DLLs whose manifests require a different CRT version from my exe, (b) I’m only shipping one CRT version but I now have a dependency on 2 versions. 2) I do not expect an automatic security update to silently break my build deliverables. And I have just been bitten by this a second time in a month. Once again my beta testers are complaining of broken builds. Somehow the update is back even after I disabled autoupdates, perhaps some OneCare issue? Hello JeffH and others Thanks for your input and your feedback. Many of us are reading the replies here and we do take your comments very seriously when reviewing our procedures and processes. In order to provide our feedback I wanted to state that, at this stage, I see nothing here that will cause us to make any changes to our processes for handling VC runtime library security updates going forward. This means that if we find high priority potential security vulnerability in one of our libraries we will update the libraries and release update(s). We feel we have a paramount duty here to protect users and those who ask for updates (either manually or automatically) will receive them – this is generally our highest priority. This action will normally not affect binaries currently running on end-user machines – these binaries will run on updated VC libraries but we strive for no “breaking changes”, as we achieved with the ATL Update, and everything should just work for existing binaries. Yes, we may make a mistake with this from time to time but if so please let us know and we will fix it if at all possible. Of course sometimes the Update may force a breaking change – but again if that is the only way to address a security issue then that may be what we have to do. If anyone did get broken in this scenario with the ATL Update (their already deployed applications broke) then we are sorry and we would like to know about it. The other salient point is for binaries built after the update with the new VC runtime libraries had been applied to a development machine, here I want to restate that we only support a model where the libraries on the development/test/end-user machines are synchronized. Here synchronized can mean that downstream you can have later versions but you must ensure that at a minimum they are all the same version. You can achieve this a number of ways (different mechanisms come with different requirements and risks) but you must ensure that this condition is satisfied. Our general recommendation that is you deploy the VC runtime libraries that you build your binaries with alongside those binaries– in this case you should always be fully protected. With regards to the ATL Update case, the update to developers’ machine should only have trigged warnings/errors if you have code which potentially exposed the vulnerability. If you got build breaks then you were at risk. Sorry if you got caught in the last few days of development but I think it could have been worse. Testing/deployment breaks can only occur if you build on an updated version of the runtime libraries but did not synchronize them on to your test/end-user machines. Again if you followed our recommendations we believe you would have been fine in this scenario too however if you have experienced an issue then please let us know. With security updates we do follow a set of procedures related to disclosure. We do have to balance exposing the issue (to both the good and bad guys), along with the current level of exploitation of the issue, along with the risk of the exploit being publicly exposed by a third party. Without going into the details we followed our normal process here of issuing an Advanced Notification three working days before deployment in this case. On the day of issuing the Security Update we released numerous online details about the update (blogs, videos, etc. – the links are throughout the thread here.) As always, please post any follow up comments you may have here and we will read them. Thanks Damien. > In order to provide our feedback I wanted to state that, at this stage, I see nothing here that will cause us to make any changes to our processes for handling VC runtime library security updates going forward. I strongly urge you to reconsider your position. By distributing a critical security patch and installing a redirect to that version you would have already accomplished the goal of protecting users. All you have done by forcing a dependency upgrade during the compile process is break builds across the globe. Doing this is directly counter to your stated goal of protecting users because (a) you have convinced people that accepting automatic updates is an unacceptable risk and (b) you have made the statically linked version of the runtime libraries a more attractive option, which you cannot service. Hello Ross Thanks for the feedback – again sorry that this causing you such pain, it is definitely not our intention. For issue 1, if you ship the latest VC Runtime Libraries with your application you should be fine; all the libraries your application depends on will be rolled forward to the latest minor version for all dependencies. (See my somewhat related previous comment: “Installing any later/higher minor version of a major version of the VC runtime libraries, either by MS doing an update or customers installing another product (or by customers just installing a later vc_redist* themselves too), will cause your application to run on the later/higher minor runtimes (regardless of what you build/tested against.)”). Again if you break with the latest version then please let us know, we aim for no breaking changes when we do updates but we can make mistakes. For issue 2, the VC Runtime Libraries you build against (or a later version of the same) need to be installed on the test/end-user machines for deployment to work. This is the only model we support. If you deployed the relevant version with your application and it fails then we would like to know. Thanks Damien. Hello Phaeron I really do appreciate you taking the time to raise your comments/concerns and as I said we are discussing this internally and value your feedback and input. By the way, I did not mean to imply that anything I say is absolutely final. I just wanted to be clear that at this stage we were not changing the process – I think we also need to be transparent and give you direct feedback – but do not take that as we will never change the process. Obviously many of you feel quite passionately about this. Thanks Damien. Hi Damien Thanks for your attention. I’m going to put aside my opinions of your management of this issue and try to help you understand my requirements. I ship an exe bundled with 3rd party DLLs. As I understand it, all exe+dll manifests need to reference the same crt version. At the moment, the way I achieve this is to use the correct version of MSVC (in my case 2005sp1) to build my exe. Until this update, using my versioning method of using the correct MSVC version gave the desired effect (my exe referenced msvcrt 8.0.50727.762). After the update, my exe msvcrt versioning was broken. A basic fact of my use-case (and many others) is that I do not have the ability to determine the msvcrt version referenced by the 3rd party dlls I use. Since (afaik) the SxS mechanism requires all dlls+exes to reference the same msvcrt version, I need a way to achieve this goal. — more to the point, I need MSVC to allow me to specify what version of the crt I use. This update breaks the previous widespread assumption that installing a specific MSVC version (including specific service packs) would give me msvcrt manifest compatibility with other dlls built elsewhere based on the same MSVC version. With your update I need to use 3rd party DLLs referencing VC2005Sp1+kb971090 (which don’t exist). I think one possible solution for this issue would be for MSVC to support multiple side-by-side installed crt versions for development (multiple.libs etc) instead of just one version which gets blown away with each update. That way I would have the option of referencing a specific msvcrt version in my builds if needed (or just using the latest version by default). I think this would be an improvement over your current approach and one I would like you to seriously consider for the future. I notice you reference this blog post above: Is this method documented in any Microsoft documentation? It seems like it might partially solve my problem. From what you say, if I make my exe manifest reference msvcrt 8.0.50727.762 using this method, but ship 8.0. Then I should be ok. Is that correct? Can I use that method even if msvc links my exe against 4035? Hello Ross So George and I had a look at this again today and wondered if your deployment scenario hits one of these configurations (or a variant thereof): Scenario 1: You are using AppLocal deployment of the CRT and there are no installations of the CRT in WinSxS (for example on a clean machine.) App.exe manifest references CRT V9.0.1 Abc.dll manifest references CRT V9.0.2 In this scenario the question is which version of the CRT can be deployed AppLocal? The solution here is to use a config file for the files with the lower versions to redirect to the newer version (config file causes app.exe to be redirected to CRTV9.0.2) Scenario 2: You are using WinSxS deployment of the CRT via payload MSMs (these have the actual dlls) without the policy redirection MSMs (these are the redirection xml config files) – these are separate files. App.exe manifest references CRT V9.0.1 Abc.dll manifest references CRT V9.0.2 In this scenario the question is which version of the CRT can be deployed to the WinSxS? The solutions here are 1) install the later version of the MSMs along with their corresponding redirection MSMs or 2) to install both versions of the CRT via the two payload MSMs (not preferred – be careful as you end up with two versions of the CRT loaded in your process.) Of course you may not be using AppLocal or MSMs. George and I would be happy to have a call with you on this. You can email me at my_first_name at Microsoft dot com and we can set up a time. Thanks Damien. Just wanted to note that I’ve been hit too. -Build a setup some days ago and customer installed it on his machine. -Customer reported a bug, which could be easily fixed. -Installed the critical update. -Fixed the bug just recompiled the specific DLL and told the customer that he can just replace the DLL and doesn’t need to do the setup again, since our setup requires rebeoot Bang! Looking and trying to find the cause. Looking, looking, looking Since I’m sort of old school guy I opened the old and the new version of the dll in hexviewer and saw they are referencing different CRT versions! Please don’t change my headers/lib behind my back without telling me.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. Archives
March 2018
Categories |