October 3, 2015 1 Comment
Recently a serious bug in the Universal CRT was discovered that breaks all MFC apps due to MFC’s use of _sntscanf_s in its DDX_Text routine for doubles.
This raises an interesting point. The bug is in the Universal CRT. No longer can you just grab a new vcredist_x86.exe or new runtime DLL and plop it into your app folder (along with an applocal MFC of course) You now have to worry about the fact that this bug is in a system component, ucrtbase.dll. This is due to the “great refactoring” of the CRT:
So then, how do we service ucrtbase.dll? Do we just wait for it to show up in Windows Update? Get the Universal CRT SDK and build a redist?
One possible answer lies here:
Answer is: applocal distribution (in the same folder as your app) They originally prohibited this from applocal distribution, but then change their minds. This is a problem for apps that have multiple folders.
Note: in order to do this applocal distribution properly, you cannot simply just include ucrtbase.dll. You have to include a series of 23 other flies, named api-ms-win-core.*.dll, a list of which can be found here. Ugly, but it works.
But, according to Microsoft, from the second comment on this blog post:
“On Windows 10, the real Universal CRT in the system directory will always be used, even if you have the Universal CRT DLLs included app-locally”
So on Windows 10 how do I fix a bug in ucrtbase.dll? Do I require a Windows Update to get that serviced? Seems like it. In other words not possible to ship an app that’s totally self contained and has all bug fixes.
Can we call this DLL Hell 3.0?