Showing tag results for Other

When I wrote that the symbolic name for the imported function table entry for a function is called , the statement was "true enough" for the discussion at hand, but the reality is messier, and the reason for the messy reality is function name decoration. When a naive compiler generates a reference to a function, the reference is decorated in a ma...

Now that we've learned what the declaration specifier does, what if you get it wrong? If you forget to declare a function as , then you're basically making the compiler act like a naive compiler that doesn't understand . When the linker goes to resolve the external reference for the function, it will use the stub from the import library, and ever...

I noted last time that you can concoct situations that force the creation of a stub for an imported function. For example, if you declare a global function pointer variable: then the C compiler is forced to generate the stub and assign the address of the stub to the variable. That's the best it can do, since the loader will patch up only the ...

If a function is declared with the declaration specifier, this instructs the Visual Studio C/C++ compiler that the function in question is an imported function rather than a normal function with external linkage. With this additional information, the compiler generates slightly different code when it needs to reference an imported function, since...

An import library resolves symbols for imported functions, but it isn't consulted until the link phase. Let's consider a naive implementation where the compiler is blissfully unaware of the existence of imported functions. In the 16-bit world, this caused no difficulty at all. The compiler generated a far call instruction and left an external reco...

Over the past few days we've learned how 16-bit Windows exported and imported functions from DLLs and that the way functions are exported from 32-bit DLLs matches the 16-bit method reasonably well. But the 16-bit way functions are imported simply doesn't work in the 32-bit world. Recall that in 16-bit Windows, the fixups for an imported functio...

Last time, we saw how the way Win32 exports functions is pretty much the same as the way 16-bit Windows exports functions, but with a change in emphasis from ordinal-based exports to name-based exports. This change in emphasis is not expressed anywhere in the file format; both 16-bit and 32-bit DLLs can export either by name or by ordinal (or by ...

The designers of 32-bit Windows didn't have to worry quite so much about squeezing everything into 256KB of memory. Since modules in Win32 are based on demand-paging, all you have to do is map the entire image into memory and then run around accessing the parts you need. There is no distinction between resident and non-resident names; the names of ...

Whenever I write an article explaining that programs should avoid doing X, I can confidently rely on a comment saying, "Well, Microsoft Product Q does this!" as if to say, "Gotcha, you hypocrite!" But they're saying "gotcha" to the wrong person. Because, and I'm sure it's a shock to many people to read this, I did not personally wr...

When operating with the Windows shell, you will almost certainly find yourself at some point working with a pointer to an item ID list, known also as a "pidl" (rhymes with "middle"). On the other hand, when working with OLE you may find yourself having do deal with monikers. In a sense, they both do the same thing. They let you refer to some sort o...