{"id":16413,"date":"2009-10-12T07:00:00","date_gmt":"2009-10-12T07:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/2009\/10\/12\/the-classical-model-for-linking\/"},"modified":"2009-10-12T07:00:00","modified_gmt":"2009-10-12T07:00:00","slug":"the-classical-model-for-linking","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20091012-00\/?p=16413","title":{"rendered":"The classical model for linking"},"content":{"rendered":"

\nCommenter Adam wonders\n\nwhy we need import libraries anyway<\/a>.\nWhy can’t all the type information be encoded in the export table?\n<\/p>\n

\nThis goes back to the classical model for linking.\nThis model existed for decades before Microsoft was even founded,\nso at least this time you don’t have Bill Gates to kick around.\n(Though I’m sure you’ll find a way anyway.)\n<\/p>\n

\nBack in the days when computer programs fit into a single\nsource file, there was only one step in producing an executable\nfile:\nYou compile it.\nThe compiler takes the source code, parses it according to the rules\nof the applicable language, generates machine code,\nand writes it to a file,\nready to be executed.\n<\/p>\n

\nThis model had quite a following,\nin large part because\n\nit was ridiculously fast\nif you had a so-called one-pass<\/i> compiler<\/a>.\n<\/p>\n

\nWhen programs got complicated enough that you couldn’t\nfit them all into a single source file,\nthe job was split into two parts.\nThe compiler still did all the heavy lifting:\nIt parsed the source code and generated machine code,\nbut if the source code referenced a symbol that was\ndefined in another source file, the compiler doesn’t know\nwhat memory address to generate for that reference.\nThe compiler instead generated a placeholder address\nand included some metadata that said,\n“Hey, there is a placeholder address at offset XYZ\nfor symbol ABC.”\nAnd for each symbol in the file, it also generated some\nmetadata that said,\n“Hey, in case anybody asks, I have a symbol called BCD\nat offset WXY.”\nThese “99%-compiled” files were called object modules<\/i>.\n<\/p>\n

\nThe job of the linker was to finish that last 1%.\nIt took all the object module and glued the dangling bits together.\nIf one object module said\n“I have a placeholder for symbol ABC,”\nit went and looked for any other object module that said\n“I have a symbol called ABC,”\nand it filled in the placeholder with the information\nabout ABC, known as resolving the external reference<\/i>.\n<\/p>\n

\nWhen all the placeholders got filled in, the linker could\nthen write out the finished executable module.\nAnd if there were any placeholders left over,\nyou got the dreaded\nunresolved external<\/i> error.\n<\/p>\n

\nNotice that the only information about symbols\nthat is provided in the object module is the symbol name.\nOlder languages trusted the programmer to get everything else right.\nIf your FORTRAN program\ndefined a common block with two integers and a real,\nand you referenced it from another source file,\nit was simply a language requirement that when you access the\ncommon block, you must treat it as having two integers and a real.\nThe compiler was not under any obligation to verify that your\nuses of the common block were consistent.\nSimilar, if\n\nyour C program took a function returning long<\/i>\nand redeclared it as a function returning int<\/i><\/a>,\nthe compiler merely agreed to your little subterfuge,\nand you were on the hook for the consequences.\n<\/p>\n

\nGiven the classical model for linking, that’s pretty much\nall the language specification could do.\nAll that was shared between object modules was symbol names.\nAnd back in the old days,\nsymbol names were restricted to a maximum of eight characters\nconsisting of uppercase letters or digits.\n<\/p>\n

\nThe C++ language came up with a workaround:\nThey encoded the type information in the symbol name,\na technique known as decoration<\/i>.\nYour function which is named Resolve<\/code> in the source code\nends up with the name\n?Resolve@@YG_NPAGI_N@Z<\/code>\nin the object module,\nso that it can be matched up against the placeholders which ask\nfor a function named\n?Resolve@@YG_NPAGI_N@Z<\/code>.\nThe C++ language folks could get away with this because\nby the time the C++ language rolled around, the maximum length for a symbol\nwas far greater than 8, and the repertoire of valid characters\nhad grown significantly.\nAnd if you were one of the dinosaurs using an older system with the\n8-character uppercase-only limitation, then you were just out of luck.\n<\/p>\n

\nBut even the greater symbol name length doesn’t solve all type mismatches.\nFor example, symbols for structures and unions are not decorated with\nthe members of the structure or union.\nYou can have one C++ file declare a structure called S<\/code>\nas\n<\/p>\n

\nstruct S {\n int i;\n float f;\n};\n<\/pre>\n
\nand have another C++ file declare it as\n<\/p>\n
\nstruct S {\n float f;\n int i;\n};\n<\/pre>\n
\nand most compilers won’t catch the mismatch.\n<\/p>\n
\nWith that historical background, we can begin addressing\nAdam’s question next time.\n<\/p>\n
\nSidebar<\/b>:\nFor those interested in nonclassical linking, there’s this article on\n\nchanges to linker scalability in Visual C++ 2010<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"
Commenter Adam wonders why we need import libraries anyway. Why can’t all the type information be encoded in the export table? This goes back to the classical model for linking. This model existed for decades before Microsoft was even founded, so at least this time you don’t have Bill Gates to kick around. (Though I’m […]<\/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":[26],"class_list":["post-16413","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-other"],"acf":[],"blog_post_summary":"
Commenter Adam wonders why we need import libraries anyway. Why can’t all the type information be encoded in the export table? This goes back to the classical model for linking. This model existed for decades before Microsoft was even founded, so at least this time you don’t have Bill Gates to kick around. (Though I’m […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/16413","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=16413"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/16413\/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=16413"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=16413"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=16413"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}