OSDev.org

After installing and playing with the windows 9x/ME/3.x series on both physical computers and virtual machines, I've noticed that during complete system lockups, i.e. ctrl alt del does nothing, windows won't click, nothing happens. Except for the cursor. Even when the system is "frozen", the cursor still moves. How is this so? For example, windows 98 did not seem to like my imagine 128 vga card and would either be stuck in an infinite BSOD for some 0D exception. Sometimes it would manage to reach the state where the teal background and hourglass is displayed. The login screen never appeared, and not even ctrl alt del would do anything. The mouse could move, but sometimes it would do some weird clicking and rattling sound from the internal speaker. On one very rare occasion that never happened again, some dialog that looked like it was based off the 3.x kernel popped up complaining about some error, but trying to click OK or move the mouse made the PC speaker go insane. Does the mouse interrupt somehow overcome the lockup? Or does something else allow the cursor to move?

Knightshade wrote:Does the mouse interrupt somehow overcome the lockup?

The lockup is just one of OS modes, when key press actions are disabled. But disabling some interrupt handlers doesn't mean disabling all such handlers. So, those handlers that are not disabled still can do something useful.

In particular case of the cursor it is probably the handler, that not depends on some system data in case it was corrupted before BSOD. And also it is probable that code segment is prohibited from writing (can not be corrupted), so if a handler has working code and requires no (possibly corrupted) data, then such handler can work without problems.

The lockup is just one of OS modes

Citation needed? I doubt microsoft explicitly implemented a mode in such a fashion - they have no need for that.

The thing is that many video cards have a dedicated cursor overlay, which means that in most cases you can get away from a mouse interrupt with two writes to some video registers. You probably want to do this straight from the interrupt as it has the least latency (set X and Y in the video driver), and you don't cause overhead by scheduling move-pointer events outside of interrupt context. If you compare that to a keyboard, it has little reason to do things directly from the keyboard handler, as the only thing it really needs to do is post the event, as the place that handles it typically is deep down in userspace.

So the only thing that happens during a "crash" is that there's no process responding to either keyboard or mouse events, and only the interrupt subsystem and it's shortcircuited logic work, giving you only the visual appearance of a moving cursor while in reality actual mouse events are just as dead as any other.

Hi,

Knightshade wrote:Does the mouse interrupt somehow overcome the lockup? Or does something else allow the cursor to move?

I'd assume that normally (e.g. when the mouse hasn't been "grabbed"), the mouse driver tells the video driver about mouse pointer position changes (to reduce latency, etc). Key-presses would take the full path (from keyboard driver to GUI to application and back up). This would imply that if the GUI or application locks up, mouse pointer still works but keyboard doesn't.


Cheers,

Brendan

Combuster wrote: The thing is that many video cards have a dedicated cursor overlay, which means that in most cases you can get away from a mouse interrupt with two writes to some video registers.

Is there any documentation for the vga cursor registes? I tried looking them up but I couldn't find anything.

This is not a VGA register. Each manufacturer handles it differently.

I decided to run the vga.drv from windows for workgroups 3.11 through IDA and interestingly enough it has a MOVECURSOR export. I took a peek in the function and in the initial parts it has a bounds checking (0 <= x < 640), (1(weird coordinant?) <= y < 480) for the new cursor position, and it also checks if the new cursor coordinates against the current ones to make sure it hasn't updated so it doesn't waste time updating it. If it passes, it runs through a couple of subroutines to update it on the VGA hardware which I haven't explored yet, although I see references to the video plane masking controls from the IDA auto comments.

Combuster wrote:

The lockup is just one of OS modes

Citation needed? I doubt microsoft explicitly implemented a mode in such a fashion - they have no need for that.

Blue screen of dead appears when a problem is not contained within an application. Such situation is detectable, at least the BSOD tells us that the Windows crashed and it is the result of a detection and some management efforts. When the situation is detected there is a need to save (or at least to show) some available information. When information is shown it is required to prevent any application and kernel activity from overwriting the information on the screen. What can be the name for such OS behavior? My bet it is "mode".

vga.drv implements the cursor in software. Other drivers will implement it in hardware, if the card supports it.

My Windows 3.1 system sometimes looks up as the desktop appears and on that screen even the cursor doesn't move. Although I seem to think that that is a hardware issue anyway (as in the actual CPU has stopped) because it's intermittent and the same thing happened when I tried booting my operating system on it and a similar thing with OS/2 as well. It seems like that CPU only allows protected mode to function corectly after it's warmed up for about 10 minutes.

onlyonemac wrote:My Windows 3.1 system

If this computer of yours is an early 386, I might want to test some code on it.

Since the full source code for the Windows 3.1 mouse driver and a collection of display drivers is provided in the DDK, I had a quick look at how it works. (Why use IDA when the source is easy to find?)

The mouse driver uses the standard DOS int 21h API to register an interrupt handler (the exact interrupt handler is chosen based on exactly which kind of mouse is in use; the driver supports PS/2 and serial devices directly and can use DOS int 33h drivers).

The interrupt handler calls the "event_proc" provided by Windows with AX, BX and CX set to the status and position of the mouse cursor. I don't know exactly what this procedure contains, but is likely a thin wrapper over the "SetCursor" procedure in the display driver, which updates the position and draws the cursor (the included display drivers support both software and hardware cursors).

It's likely that the entire process, from mouse interrupt to updating the display happens in response to an interrupt and doesn't rely heavily on Windows' event handling code (which makes sense, since Windows wants smooth mouse movement, but only supports co-operative multitasking; just updating the cursor position when an application yields/polls for events would result in very jerky motion).

When Windows 3.x "hangs", it's usually because an application is stuck in an endless loop and isn't yielding/polling for events (these are the same thing in the Windows 3.x API). Windows itself is usually still "working", but because the application is frozen, no new events can be processed (so no keyboard input, no response to clicks, etc.). Since the mouse cursor doesn't rely on event processing, it still works.