{"id":1273,"date":"2014-04-11T07:00:00","date_gmt":"2014-04-11T07:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/2014\/04\/11\/windows-is-not-a-microsoft-visual-cc-run-time-delivery-channel\/"},"modified":"2014-04-11T07:00:00","modified_gmt":"2014-04-11T07:00:00","slug":"windows-is-not-a-microsoft-visual-cc-run-time-delivery-channel","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20140411-00\/?p=1273","title":{"rendered":"Windows is not a Microsoft Visual C\/C++ Run-Time delivery channel"},"content":{"rendered":"

\nThere’s a DLL in the system directory called\nMSVCRT.DLL<\/code>,\nand from its name, you might think that it is the\nMicrosoft Visual C\/C++ Run-Time library.\nThat is a perfectly reasonable guess.\n<\/p>\n

\nBut it would also be wrong.\n<\/p>\n

\nThe Microsoft Visual C\/C++ Run-Time libraries go by names\nlike\nMSVCR71.DLL<\/code> or\nMSVCR80.DLL<\/code> or\nMSVCR90.DLL<\/code> or\nMSVCR100.DLL<\/code>,\nand the debugging versions have a D<\/code> in there, too.\nAnd\n\nlike MFC<\/a>,\nthese binaries might be on your machine as a side effect\nof the implementation of a particular Windows component,\nbut they are not contractual.\nIf your program requires the\nVisual C\/C++ Run-Time library,\nthen your program needs to install the appropriate version.\n(There are redistributable packages you can\ninclude with your application.)\n<\/p>\n

\nOkay, so what’s with the DLL with the misleading name\nMSVCRT.DLL<\/code>?\nThe unfortunate name is a consequence of history.\n<\/p>\n

\nBack in Windows 95,\nMSVCRT.DLL<\/code> was<\/i> the\nMicrosoft Visual C\/C++ Run-Time library,\nor at least it was the runtime library for Visual C\/C++ 4.2.\nAs each new version of Visual C\/C++ came out, the Windows team\nhad to go update their copy of MSVCRT.DLL<\/code>\nto match.\nAnd if the Windows team wanted to fix a bug in\nMSVCRT.DLL<\/code>,\nthey had to make sure that the Visual C\/C++ team made the corresponding\nchange in their version.\n<\/p>\n

\nThis high degree of coördination became untenable,\nespecially since it required the Windows team to do things like\npush a new version of MSVCRT.DLL<\/code> to all downlevel\nplatforms whenever a new version of Visual C\/C++ came out.\n(Good luck doing this in the days before Windows Update!)\n<\/p>\n

\nAnd sometimes these fixes caused compatibility problems.\nFor example, I remember there was a fix for a Y2K problem\nwhich\n\ncaused one application to crash<\/a>\nbecause the fix\naltered the stack usage in such a way that exposed an\nuninitialized variable bug.\n<\/p>\n

\nOne serious problem with the MVSCRT.DLL<\/code>\n“one runtime to rule them all” model is that\nmultiple versions of Visual C++ would all use the same library,\nand keeping one DLL compatible with all versions of Visual C++\nwas a maintenance nightmare.\nFor example, if a new C++ language feature required a change\nto the ostream<\/code> class,\nyou had to be careful to design your change so that the\nclass was still binary-compatible with the older version\nof the class.\nThis meant not changing the size of the class (because somebody\nmay have derived from it)\nand not changing the offsets of any members,\nand being careful which virtual methods you call.\nThis was in practice not done, and the result was that (for example)\nWindows 95 and Windows 98 both had DLLs called\nMSVCRT.DLL<\/code> that were not compatible with each other.\n<\/p>\n

\nAnd of course there was the problem of some application installer\nunwittingly overwriting the existing copy of\nMSVCRT.DLL<\/code> with an older one,\ncausing the entire operating system<\/i> to stop working.\n<\/p>\n

\nAt some point, the decision was made to just give up\nand declare it an operating system DLL,\nto be used only by operating system components.\nAll newer versions of Visual C\/C++ used specifically-numbered\nDLLs for their runtime libraries.\n(Giving different names to each version of the run-time library\nsolves the problem of trying to make one DLL service multiple\nversions of clients,\nas well as addressing the accidental downgrade<\/i> problem.)\n<\/p>\n

\nAlthough MSVCRT.DLL<\/code> has been an operating system DLL\nfor a long time,\n\nand has been documented as off-limits to applications<\/a>,\nthere are still\n\na lot of people<\/a>\nwho\n\ntreat it as a C runtime delivery channel<\/a>,\nand those programs create a lot of grief for the product team.\n<\/p>\n

\nI remember one change that the runtime library folks made to\nMSVCRT.DLL<\/code> that had to be backed out and revisited\nbecause they found an application that not only linked to\nMSVCRT.DLL<\/code> instead of the runtime library the\ncompiler intended,\nbut also groveled into an internal array and manipulated\nprivate members.\n(I was one of the people who investigated this compatibility\nissue, but I was not the one who solved it.)\n<\/p>\n

\n\/\/ Note: The issue has been simplified for expository purposes\nstruct SomethingInternal\n{\n    int widget;\n    short widgetFlags;\n    char widgetLevel;\n    int needs_more_time;\n};\nSomethingInternal InternalArray[80];\n<\/pre>\n
\nThe runtime library folks added a new member to the structure:\n<\/p>\n
\nstruct SomethingInternal\n{\n    int widget;\n    short widgetFlags;\n    char widgetLevel;\n    int needs_more_time;\n    int needs_more_cowbell<\/a>;<\/font>\n};\n<\/pre>\n
\nThis change increased the size of the\nSomething­Internal<\/code> structure,\nwhich in turn meant that when the application did\n<\/p>\n
\n\/\/ Redeclare this internal structure in MSVCRT.DLL\n\/\/ so we can poke the needs_more_time member to get more time.\nstruct SomethingInternal\n{\n    int widget;\n    short widgetFlags;\n    char widgetLevel;\n    int needs_more_time;\n};\nextern SomethingInternal InternalArray[80];\n...\n    InternalArray[i].needs_more_time = 1;\n...\n<\/pre>\n
\nit ended up poking the wrong byte because the structure\nsize didn’t match.\n<\/p>\n
\nThe runtime library folks had to go back and squeeze the cowbell\nflag into the structure in a way that didn’t alter the size\nof the Something­Internal<\/code> structure.\nI don’t remember exactly what the fix was,\nbut one way they could’ve done it was by squeezing the flag\ninto the one byte of padding between\nwidgetLevel<\/code> and\nneeds_more_time<\/code>.\n<\/p>\n
\nstruct SomethingInternal\n{\n    int widget;\n    short widgetFlags;\n    char widgetLevel;\n    char needs_more_cowbell;<\/font>\n    int needs_more_time;\n};\n<\/pre>\n
\nBonus chatter<\/b>:\nThe application had an easy time messing with the internal array\nbecause the source code to the C runtime library\nis included with the compiler,\nSo much for “All these compatibility problems would go away\nif you published the source code.”\nPublishing the source code makes it easier<\/i> to introduce\ncompatibility problems,\nbecause it lays bare all the internal undocumented behaviors.\nInstead of trying to reverse-engineer the runtime library,\nyou can just sit down and read it,\nand if you want to do something sneaky,\nyou can just\ncopy the\ndeclaration of the internal array\nand\n\nparty on<\/a>\nthe\nneeds_more_time<\/code> member.<\/p>\n","protected":false},"excerpt":{"rendered":"
There’s a DLL in the system directory called MSVCRT.DLL, and from its name, you might think that it is the Microsoft Visual C\/C++ Run-Time library. That is a perfectly reasonable guess. But it would also be wrong. The Microsoft Visual C\/C++ Run-Time libraries go by names like MSVCR71.DLL or MSVCR80.DLL or MSVCR90.DLL or MSVCR100.DLL, and […]<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[25],"class_list":["post-1273","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
There’s a DLL in the system directory called MSVCRT.DLL, and from its name, you might think that it is the Microsoft Visual C\/C++ Run-Time library. That is a perfectly reasonable guess. But it would also be wrong. The Microsoft Visual C\/C++ Run-Time libraries go by names like MSVCR71.DLL or MSVCR80.DLL or MSVCR90.DLL or MSVCR100.DLL, and […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/1273","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=1273"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/1273\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=1273"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=1273"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=1273"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}