The Old New Thing
Practical development throughout the evolution of Windows.
Latest posts
The Seattle Monorail has two trains, and they collided
Murphy's Law vindicated again. The Seattle Monorail has two trains, and last year they managed to collide. To get this to happen was particularly tricky, since the trains run on separate tracks, and there is only one spot on the entire line where a collision could occur—and they found it. You can read about it in this Associated Press article that describes the monorail as a "mile-high, 43-year-old elevated line". Wow, a mile high. Those must've been really long ladders to get people down. It was supposed to resume operation a few weeks ago, but the reopening was delayed due to a glitch in the emergency...
The efficiency of ordinal-based imports while still being name-based
Reader Tom brought up the interesting point that ordinal-based imports are slightly faster than name-based, though not by much. But if even that tiny fraction of a percentage bothers you, you can still get the benefits of ordinal-based imports while still being name-based. People are more familiar with the first half of the "rebase and bind" duo than the second. But it's binding that speeds up import table resolution. When a DLL is "bound" to another DLL, information about the target DLL is cached in the original DLL. Specifically, the timestamp of the target (so that the loader can detect whether the cache is ...
Handy tip: If you're going to break into vehicles, the police vehicle service center is probably a bad place
And you probably shouldn't fall asleep in the van you break into.
Index to the series on DLL imports and exports
For reference.
Names in the import library are decorated for a reason
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 manner consistent with its architecture, language, and calling convention. (Some time ago, I discussed some of the decorations you'll see on x86 systems.) For example, a naive call to the function results in the compiler generating code equivalent to (on an x86 system;...
Real Madrid (i.e., proper football) comes to Seattle
Hot off the presses. Real Madrid (with David Beckham, Ronaldo, and other stars) will play an exhibition match against D. C. United in Seah^H^H^H^HQuest Field on Wednesday, August 9th. I wonder if it'll be anything like the last soccer match I saw. At least let's hope they're ready to play instead of having tired themselves out playing video games. Tickets go on sale today.
What happens when you get dllimport wrong?
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 everything will work as before. You do miss out on the optimization that enables, but the code will still run. You're just running in naive mode. (There are still some header files in the Platform SDK that neglect to use the declaration specifier. As a result, anybody wh...
If you know German, the world is, well, slightly more confusing
While it may be true that if you know Swedish, the world is funnier, I have to admit that my knowledge of German only served to create momentary confusion. When I saw the headline that the head of BetonSports was arrested, I thought to myself, "Who the heck would have a web site devoted to sports in concrete?" That's because the German word Beton means "concrete" (the construction material) in English, and the German word Sport means the same as in English. It took me a few moments to realize that the company's name is "Bet on Sports".
Issues related to forcing a stub to be created for an imported function
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 imported function address table; it won't patch up anything else in the data segment. The C++ compiler, on the other hand, can take advantage of some C++ magic and secretly generate a "pseudo global constructor" (I just made up that term so don't go around using it li...