{"id":15243,"date":"2010-01-18T07:00:00","date_gmt":"2010-01-18T07:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/2010\/01\/18\/its-fine-to-rename-a-function-in-your-def-file-but-when-you-do-you-have-to-link-to-that-function-by-its-new-name\/"},"modified":"2010-01-18T07:00:00","modified_gmt":"2010-01-18T07:00:00","slug":"its-fine-to-rename-a-function-in-your-def-file-but-when-you-do-you-have-to-link-to-that-function-by-its-new-name","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20100118-00\/?p=15243","title":{"rendered":"It's fine to rename a function in your DEF file, but when you do, you have to link to that function by its new name"},"content":{"rendered":"

\n\nJeffrey Riaboy<\/a>\nasks why,\n\nif he renames a function in his DEF file,\nattempts to link to the function by its old name fail<\/a>.\n<\/p>\n

\nWell, um, yeah, because you renamed it.\n<\/p>\n

\nLet’s take the situation apart a bit;\nmaybe it’ll make more sense.\nI’m going to ignore a lot of details\n(dllimport\/dllexport<\/code>,\ncalling conventions)\nsince they are not relevant to the discussion\nand would end up just being distracting.\nI’m also going to assume we are running on an x86-class machine,\njust for concreteness.\nThe same discussion works for other platforms; you just have to\nadjust the conventions accordingly.\n<\/p>\n

\nFirst, here is some source code for a DLL,\nlet’s call it FRED.DLL<\/code>:\n<\/p>\n

\nint Dabba()\n{\n  return 0;\n}\nint Doo()\n{\n  return 1;\n}\n<\/pre>\n
\nAnd here is the DEF file for FRED.DLL<\/code>:\n<\/p>\n
\nEXPORTS\n Yabba=Dabba\n Dabba=Doo\n<\/pre>\n
\nWhen you compile this DLL, the result will be something like this:\n<\/p>\n
\nFRED.DLL:\n Yabba -> return 0;\n Dabba -> return 1;\n<\/pre>\n
\nThe function exported as Yabba<\/code> returns 0<\/code>\nbecause the DEF file said,\n“I want to export a function with the exported name Yabba<\/code>;\nwhen somebody calls the function, I want control to go to the\nfunction I called Dabba<\/code> internally.”\n<\/p>\n
\nSimilarly, the function exported as Dabba<\/code> returns 1<\/code>\nbecause the DEF file said,\n“I want to export a function with the exported name Dabba<\/code>;\nwhen somebody calls the function, I want control to go to the\nfunction I called Doo<\/code> internally.”\n<\/p>\n
\nRemember that symbolic information disappears during linking.\nThe names of the functions and variables in the original source\ncode are not stored anywhere in the DLL.\nThe names exist only so that the linker can resolve symbolic\nreferences between object files.\nOnce that’s done, the names are discarded: Their work is done.\n(See\n\nThe classical model for linking<\/a>\nfor a discussion of how linking works under the classical model.)\n<\/p>\n
\nExported functions are also a mapping between labels and functions,\nbut this mapping is not used when linking the DLL;\nrather, it is just a table the linker produces under the direction\nof your DEF<\/code> file.\nTo reduce confusion for the programmer writing the DLL,\nthe name in the exported function table usually matches the name\nin the object files, but that is merely a convention.\nAn entry in the export table that doesn’t perform renaming is\njust a shorthand for “I would like the exported name for this function\nto be the same as its internal name.”\nIt’s a convenient typing-saver.\n<\/p>\n
\nBy analogy,\nMicrosoft employees have one email address for use inside the company,\nand\n\na different email address for use outside the company<\/a>.\nSome employees choose to have their external email address be the same\nas their internal one,\nbut that is hardly a requirement.\n<\/p>\n
\nMeanwhile, the import library for our DLL looks something like this:\n<\/p>\n
\nFRED.LIB:\n __imp__Yabba -> FRED.Yabba\n __imp__Dabba -> FRED.Dabba\n _Yabba@0<\/a> -> jmp [__imp__Yabba]<\/a>\n _Dabba@0 -> jmp [__imp__Dabba]\n<\/pre>\n
\nAs we saw before,\neach exported function\n\nresults in two symbols in the import library<\/a>,\none with __imp_<\/code> prepended to the exported name,\nwhich represents the import table entry,\nand one containing a stub function for the benefit of a naïve\ncompiler.\n<\/p>\n
\nNow let’s look at a program that wants to call some functions from\nFRED.DLL<\/code>:\n<\/p>\n
\nint Flintstone()\n{\n Yabba();\n Dabba();\n Doo();\n}\n<\/pre>\n
\nLet’s say that these functions were not declared as\ndllimport<\/code>, just for the sake of concreteness.\n(The discussion works the same if they were declared as\ndllimport<\/code>, making the appropriate changes to the\nsymbol names.)\nWhen the linker goes to resolve the call to Yabba@0<\/code>,\nit will find the entry in FRED.DLL<\/code> that says,\n“I’ve got a function called Yabba@0<\/code>; the code for it\nis the single instruction jmp [__imp__Yabba]<\/code>.”\nWhen the program calls this function, the jmp<\/code>\ninstruction will jump through the import table entry for\nFRED.Yabba<\/code>,\nwhich will wind up at the function in FRED.DLL<\/code>\nexported under the name Yabba<\/code>.\nIf we look inside FRED.DLL<\/code>, we see that this\nis a function that returns 0<\/code>\n(because it is the function which was called Dabba<\/code>\nin the original source code, although that information was lost\na long time ago).\n<\/p>\n
\nSimilarly, when the linker resolves the call to Dabba@0<\/code>,\nit finds the entry in FRED.DLL<\/code> which pulls in the\none-line stub function which jumps through the import table\nentry for Dabba@0<\/code>.\nThis leads to a function that returns 1<\/code>,\na function which was called Doo<\/code>\nin the original source code.\n<\/p>\n
\nHowever, that last call to Doo<\/code>\nraises a linker error because it cannot find a function called\nDoo<\/code> in the FRED.LIB<\/code> import library.\nThat’s just the internal name for a function in the source code\nfor FRED.DLL<\/code>,\na name which was lost during linking.\nIf you want to call the function which had been called Doo<\/code>\nin the original source code,\nyou have to import it by its new name,\nDabba<\/code>.\n<\/p>\n
\nIn Jeffrey’s case, he took a function which was internally\nreferred to by a decorated name\n(?Dispose@MyClass@@QAEAAV1@XZ<\/code>)\nand renaming it to an undecorated name\n(MC_Dispose<\/code>).\nBut when other modules tried to use the library, they got the error\nsaying that\n“?Dispose@MyClass@@QAEAAV1@XZ” is not found.\nWhich is correct:\n?Dispose@MyClass@@QAEAAV1@XZ<\/code>\nwas not found because it no longer exists under that name.\nYou renamed it to MC_Dispose<\/code>.\nThose modules need to link to the function\nMC_Dispose<\/code> if they want to call the\nfunction\n“formerly known as ?Dispose@MyClass@@QAEAAV1@XZ”.\n<\/p>\n
\nActually, Jeffrey’s situation is more complicated than I described\nit because\n?Dispose@MyClass@@QAEAAV1@XZ<\/code>\nundecorates to\npublic: class MyClass & __thiscall MyClass::Dispose(void)<\/code>;\nthis is a method not a static function.\nI don’t believe there’s a way to override the name decoration\nalgorithm for instance methods;\nthe compiler is always going to generate a reference to\n?Dispose@MyClass@@QAEAAV1@XZ<\/code>.\nSo renaming the export doesn’t buy you anything because you don’t\ncontrol the name on the import side.<\/p>\n","protected":false},"excerpt":{"rendered":"
Jeffrey Riaboy asks why, if he renames a function in his DEF file, attempts to link to the function by its old name fail. Well, um, yeah, because you renamed it. Let’s take the situation apart a bit; maybe it’ll make more sense. I’m going to ignore a lot of details (dllimport\/dllexport, calling conventions) since […]<\/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-15243","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
Jeffrey Riaboy asks why, if he renames a function in his DEF file, attempts to link to the function by its old name fail. Well, um, yeah, because you renamed it. Let’s take the situation apart a bit; maybe it’ll make more sense. I’m going to ignore a lot of details (dllimport\/dllexport, calling conventions) since […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/15243","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=15243"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/15243\/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=15243"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=15243"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=15243"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}