I really enjoyed listening to your hilarious rant about Direct2D on the Jeff and Casey show. It was exactly the antidote I needed after struggling to use Direct2D all day to do trivial tasks!

So true, d.

# this needs to be escaped 4 times unline the usual 5 times…
my_dev_env=c:\\\\\\\\dev\\\\\\\\project

Your description of how problems germinate in platform vendor’s product, and then bloom in the work of every developer who works above that level squarely captures the scale of the impact:

it’s a sacrifice that’s not just made by us, but by thousands of teams on thousands of projects every year […] when you consider that this same work has to be done by every other developer, too. It’s really thousands of zero-sum games being played, all across the industry, and the end result is universally worse software because the underlying platforms take up too much effort.

In a somewhat-related technical context, I was speaking to a sysadmin and former colleague of mine who worked for a large company, where he was part of a team that managed that company’s 220,000-desktop user base.

One of their internally-developed frameworks was used by a number of their critical operations management applications, and it had an occasional processing stall that would unreliably surface to impact several thousand users across their global network every couple of weeks.

People would complain, but because it rarely impacted more than a few persons at a time in any particular local office, no one really had a sense of the scale of the problem across 340 offices on six continents.

For a long time, it was nearly impossible to focus developer resources on corralling and taming this bug, since the framework was technically nobody’s responsibility anymore.

A newer developer with little to do his first few weeks became enamored by the bug and set out to calculate the person-hour impact to the company from these cumulative stalls. After adding the needed instrumentation wrapper to a key library, he found that in a given month, there were nearly 44 person-days of wasted time caused by this stall–a staggering amount, and a staggering cost to the company given that some of the people whose work this stall affected were very costly employees.

After realizing that this was a “hundred-thousand dollar bug”, it was relatively easy to get the people who could fix it to fix it. But the practical fact remains that stuck in the low-level framework, out of sight and out of mind of most application developers, it was impactful in non-obvious ways.

Thanks again for your writeup.

If you ever find that the talk by Gill Pratt on “the static discipline” is online anywhere, I’d welcome a link.

(There was a similar concept espoused by early engineers in the Internet community: “be liberal in what you accept, conservative in what you send out”, which assured that a broad range of user-level applications on the Internet would just ‘work’ despite poorly-formatted messages and protocol violations because even if somebody sent you garbage, it was your responsibility to clean it up before you sent it along to the next recipient.)

Tricia: You can always use CTRL-ESC, which was the previous way to do this before the Windows key was added to keyboards. It is a much more sane way for games to allow this behavior, because nobody can really hit CTRL-ESC by accident. It should work in all games, too, as I don’t think there are ways to disable it, although admittedly I have never tried. I, like you, appreciate the need to have a way to switch from a game to the Start menu, and CTRL-ESC seems like a good way to do that, so I would never go out of my way to try to disable it, nor recommend that others do so.

– Casey

I realize that accidental presses are an issue for some gamers, but I wanted to suggest that you add a minimize button for convenience’s sake.

I also wanted to mention that I find these programming articles to be quite interesting, and that I really appreciated your article about Window’s monopoly on releases on Windows 8. I was entirely unaware of the new requirements.

Yeah, that seems like a good idea. If a WINE dev has already gone through this process trying to properly emulate Windows, then you can piggyback on that and save yourself a lot of time I bet… I should install the WINE source here on my laptop, it’s a Linux Mint machine.

– Casey

It’s also worth pointing out that this is a contribution anyway: often a webpage like this comes up when you search for an MS API related problem, and judging by the last decade of MSDN, it’s also more likely to stick around and be visible.

I gave up searching MSDN directly years ago; by default I now google search my problems and if a page ranks higher than the MSDN doc page, 90% of the time it’s a page like this that actually addresses the problem more usefully.

Thanks for the breakdown, btw. I’ve run into the problem before and had to go the disable the hook route because I didn’t have time to dissect it. If I ever see it again, I’ll know where to come back for reference.

Alright, hit me. Post the code sample for C# that disables the Windows keys. Is it one line like it should be?

– Casey

Because I don’t get paid to make Microsoft’s products better? They are a $231 billion company. They could hire fifty people to do nothing but search the web for posts like this, check the source code, and update their MSDN pages to have correct information, and it wouldn’t even make a line item in their quaterly report.

I, on the other hand, am an independent developer on a independent project that squeaks by on the savings of a principal or two. If I’m going to spend my time doing something, it’s going to be improving the community for The Witness, not improving the community of Microsoft, the company that constantly costs _us_ time and resources because they couldn’t be bothered to do their job.

And that’s why I spend what precious little free time I have writing posts for this blog and answering the comments on it instead of spending my time fixing Microsoft’s erroneous documentation.

– Casey

Totally disagree. C# and the .NET framework is the best development environment for a huge range of common software that exists today. We use it for all our internal tools – including lots of realtime apps doing heavy-duty stuff. I think C# is one of the best-designed languages in the world, and the .NET framework is one of the most expressive and clear standard libraries around. Performance is only really a problem in situations of serious computation – you wouldn’t use C# for super heavy-duty number-crunching.

Some object to both based on “bloatware” bugbears but those are irrelevant to anyone who’s not OCD. Hard drives are massive now and RAM is cheap, and the tradeoff for the development time it buys you back (to your point about that!) is absolutely worth it. Our expert C# devs who have decades of C and C++ experience say that their default is everything not on an embedded platform should be C# unless there’s a particularly good exceptional reason to use C/C++, and usually there isn’t.

No, RIDEV_NOHOTKEYS does not block CTRL-ALT-DELETE and ALT-TAB, etc., so you still have plenty of ways to get out of the application if for some reason it becomes unresponsive. It’s only the Windows logo keys that are being suppressed here.

– Casey

If my interpretation is correct, this is a case of the MSDN authors including information that would be obvious to most people, while explaining it so badly that it’s worse than leaving it out. My memories of “Old New Thing” suggest they have a tendency to repeat technical explanations that they don’t fully understand and that weren’t meant to be documentation.

While I appreciate the fact that Windows hotkeys tend to be a little obtuse, there are actually already hotkeys that do the same thing as a single press of the Windows key which are not dangerous as far as accidental keystrokes. CTRL-ESC, for example, brings up the Start menu, just as a single press of the Windows key will, and that key combination will still work in Witness. But you are unlikely to ever hit it by accident.

– Casey

Love it!

I’m just saying, if the game is slow-paced, and the main controls aren’t near the Windows key, some people may actually *want* a functioning Windows key (I’ll accept that I’m probably in the minority here).

In case of path separators, it was actually Unix that went against the flow. The other OSs of the time used forward slashes for passing arguments to programs, and DOS followed in their footsteps. Windows simply had to be compatible with DOS.

Really, most backwards things you find in Windows are due to their compatibility efforts.

Eschewed it from the start, that is, apart from implementing the standard library. They didn’t have a lot of choice there (if they did, I’m sure we’d have a read() that took a variable-length context structure with members filled with pointers to an array of fixed-size buffers, or some such nonsense).

More than anything else I think what’s crucial to great API design is choosing the perfect amount of abstraction. When you stop and really think about them (or even better, try to design your own in an environment without them) you begin to see that a lot of standard library functions are nothing short of sublime. *nixes have kept a lot of that design philosophy to this day, whereas Windows eschewed it from the start. The more cross-platform development you do, the more this shows.

On the Microsoft side, the one that comes to mind is XInput. It’s pretty reasonable. There’s probably a few things I’d do differently, but it’s not the kind of thing I’d get in a fuss about.

The only reason it’s “slightly scarey” (as I said in the article) is not because of the API design, but because it has (had? they may have fixed some in more recent versions) a bad bug in it where if you poll a gamepad that isn’t connected, it takes a big CPU hit (ie., see my post about it here: http://mollyrocket.com/forums/viewtopic.php?t=487).

– Casey

Casey, could you point to an API that you do consider well-designed?

Probably because every PC game written in the last ten years explicitly disables the windows keys. The key itself must be nearly 20 years old, so you’d have to have been gaming for at least that long to have gone through the trauma that was losing a game because there’s now a button of doom between ctrl and alt.

I’ve seen and heard of this time and time again, in ten years of PC gaming — and even done it myself once or twice (usually on a new keyboard). Not all of us have had the privilege of playing only the most well-programmed games. ;)

If you’ve never heard of anyone hitting the Windows key by mistake, you probably don’t read many gaming publications :)

http://howto.cnet.com/8301-11310_39-20079677-285/how-to-disable-your-keyboard-windows-key/

http://forum.worldoftanks.com/index.php?/topic/56287-how-to-disable-the-windows-key/

http://forums.totalwar.org/vb/archive/index.php/t-21518.html

http://dev.dota2.com/archive/index.php/t-901.html

http://us.battle.net/wow/en/forum/topic/3393370279

http://webcache.googleusercontent.com/search?q=cache:bdD9fFnHMB0J:boards.cityofheroes.com/archive/index.php/t-132764.html+&cd=7&hl=en&ct=clnk&gl=us

http://www.bytegems.com/ihatethiskeydeluxe.shtml

http://lairoflurdane.wordpress.com/programming/winblocker/

I could go on and on and on, but hopefully that makes the point :)

– Casey

I suspect that you an I have very different opinions of what makes a good API if you thnk Windows Run Time (Metro) is a good platform.

– Casey

I can’t really speak to the Linux side of things yet, because I’ve only just begun to work on that platform. Talk to me in a few years when I have more Linux experience and I’ll have a worthwhile perspective on that, hopefully!

– Casey

That could certainly be the reason, but unfortunately the .NET one is even worse, because it’s a poorly designed API _and_ it’s slower.

– Casey

That situation is a real annoyance, though it’s easy to generalize from programming or MS: No matter what environment you work or live in, you are bound by its flaws, problems, and limits – say politics in general, or tax policy, or (institutionalized or just cultural) racial/gender discrimination, and so on. Or even pesky natural laws like gravity…
But I guess as long as it’s human-made, we should (and could, in theory if not in practice) try to fix these issues as far as possible.

But on that point, is there actually any OS that’s genuinely great and hassle-free to program for? I guess if the answer to that one was universally “yes”, then everybody would use it…

Windows operates partially on a message architecture, where threads in the system have queues of messages that can come from other threads and so on. These messages are things like WM_MOUSEMOVE, or WM_SIZE, which are messages that tell the thread that one of the windows it has created is having the mouse moved over it, or being resized, respectively.

Some of these messages, like WM_KEYDOWN, are keyboard events. Normally they begin life somewhere in a device driver that has actually communicated with a keyboard, and Windows will see to it that the message gets moved from that origination point through to the thread that owns the window that currently has the keyboard focus. This is the way that input works on Windows, in a nutshell, although the actual chain of command is much more complicated (as you might imagine).

One of the things Windows lets applications do is to “hook” into this chain of events in between where the messages originate and where they eventually end up. A “keyboard hook” is a piece of code that you write that you ask Windows to put _in between_ the originator of a message and its recipient. So when the user presses a key on the keyboard, and the device driver sees that, and tells Windows that it’s time to send a keyboard event, instead of Windows putting a WM_KEYDOWN event directly into the queue of some application, it first calls the hook code. The hook code can look at the event and decide what to do with it. One of the things it can do, as was the case in the article, is tell windows _not_ to dispatch the event at all.

In this way, keyboard hooks can effectively suppress keypresses entirely, so that the application with the keyboard focus never actually sees them.

Does that make sense?

– Casey

Seems to me a good waste of time. Low level keyboard hooks in games – now I’ve seen everything!:)