Apparently, one of the undocumented gotchas for DirectInput is that you might not get Ctrl+Break events, ever. I'd never encountered this because I use window messages for keyboard input in my own programs. An example is dynamic vertex/index buffers in Direct3D9, which seem easy, until you find out that occasionally on mode switches Lock() hands back an invalid pointer while still returning D3D_OK. uh oh.ĭirectX, like most Windows APIs, has a lot of unwritten lore that still isn't really documented after a decade, basic stuff that you need to know but end up learning the hard way. Let's see, no WM_KEYDOWN handler, which means it's probably using DirectInput, so let's set a breakpoint on the DirectInput code. Luckily, I built the SDL library in Debug configuration from source, so I can debug into it. In fact, no keyboard events are arriving at all when I press Ctrl+Break. That was easily fixed, but I noticed that Ctrl+Break was never arriving from the UI, either. Okay, we probably just need to check for the analogous SDL constant for VK_CANCEL, which appears to be SDLK_BREAK. Sure enough, when I dug into the keyboard emulation code, it was always sending the scan codes for the pause key. Therefore, somewhere along the line, it's likely that this difference wasn't being emulated. This anomaly is often reflected in higher level APIs, and in Win32, this manifests as your window handler getting a WM_KEYDOWN message with VK_CANCEL instead of VK_PAUSE. One of them is Pause, which magically turns to Break when Ctrl is also pressed. (I'm actually not a fan of the "fix it yourself it's open source" mentality, and I don't have any good memories of 16-bit real mode x86, but scuttle four Colonization games in a row and I will launch the debugger.) Now, I already had a suspicion as to what was causing this: there's an anomaly in the PC keyboard where certain scan codes change depending on modifier keys. I'd had luck doing this previously, when I tracked down the bug where the keyboard would suddenly stop working if you pressed Ctrl+Esc. I finally got annoyed enough about this to try to diagnose it myself. Unfortunately, one of the old programs I occasionally run is QBasic, and there's a long standing problem where Ctrl+Break doesn't work in QBasic under DOSBox. Therefore, I've been making greater use of DOSBox in the few cases where I need to run such programs, since it integrates a little better than virtualization. While this is usually attributed to Microsoft cleaning legacy house, it's also due to a hardware limitation: the original x86-64 specification prohibited VM86 mode under long mode. One of the problems with switching to a 64-bit version of Windows is that you can't run 16-bit DOS programs, due to the removal of NTVDM. ¶Why Ctrl+Break doesn't work with QBasic in DOSBox
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |