The Old New Thing
Practical development throughout the evolution of Windows.
Latest posts
The implementation of anonymous methods in C# and its consequences (part 1)
First we'll look at how they're implemented.
C# nested classes are like C++ nested classes, not Java inner classes
When you declare a class inside another class, the inner class still acts like a regular class. The nesting controls access and visibility, but not behavior. In other words, all the rules you learned about regular classes also apply to nested classes. The keyword in an instance methods of a class (nested or not) can be used to access members of that class and only those members. It cannot be used to access members of other classes, at least not directly. (And the can be omitted when it would not result in ambiguity.) You create an instance of a class (nested or not) by saying where are the parameters to an...
Christmas gift idea for your favorite glasses-wearing geek
Yes, I'm talking about Christmas gifts (or "winter solstice gifts" if you prefer) in July. I'm one of those people for whom buying Christmas gifts is a brain-wracking ordeal, and I'm always on the lookout all year round for the "perfect gift". Last Christmas, a friend of mine gave me a micro-fiber lens-cleaning cloth that comes in a pouch you can attach to a keychain. Example 1. Example 2. (I have no affiliation with those two sites; I just hunted around looking for a picture.) Best gift ever. I use it several times a day. My keychain has only four things on it: The aforementioned cleaning cloth, a ...
Just because I don't write about .NET doesn't mean that I don't like it
Some people have inferred that I don't write about .NET because I don't like it. That's not true. I use it myself. The reason I don't write about .NET is because I'm not an expert on it and there are plenty of other .NET blogs out there, written by people who are actual experts. (Such as Maoni Stephens, whose little finger contains more knowledge about garbage collection than most people have in their entire brain.) No point adding to it with my non-expert view. Indeed, when I hit upon an interesting .NET topic or puzzle, I usually just forward it off to Brad for him to put on his blog. Because people looking ...
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;...