Re: [GD-Windows] Terminating a program

[Jon W. <hp...@mi...>]

> While letting the OS (XP, 2000 or NT) clean up the process is generally
> quick, there are dangers with device states, as in your example with the
> sound.  While the OS can enforce its own issues relatively well (memory
> heap, file handles, GDI handles, etc), resources allocated and
> configured by drivers are beyond the direct control of the kernel, and
> as such can very often be left in unstable states when an app is
> terminated.

This should simply not be true. The interface between the kernel and a 
device is, at its core, simple:

- open device
- close device
- read device
- write device
- control device

A device doesn't have to know whether "close" is because the application 
called close explicitly, or whether the kernel called close because it 
had to remove all device handles that belonged to a dying process.

However, in the Windows device model (especially the older models), 
there were reasons to go outside this basic model, and even within the 
basic model, a driver may have bugs (such as sequencing bugs) that make 
it not work right.

It's been my experience that a prime cause of bugs are all the "extras" 
that an OEM wants to add to their device: decoration of sound output; 
special throughput statistics windows for network cards; that kind of thing.

> my own experience is that it is very wise to clean up your devices
> before you close - for example, properly de-allocate and shut down
> DirectX or OpenGL, DirectSound/DirectShow, network resources, etc.  Not
> doing so could certainly leave some PC's in a less than stable state.

The reason that you have to do this (and we do when we terminate 
normally) is because of bugs in the implementation of the drivers. 
Sadly, such bugs are so common, that they contribute to the perception 
that Windows is unstable and computers just crash all the time. Grandma 
really won't have a good computer until the pace of hardware evolution 
slows down enough to let the drivers mature. This, in turn, is caused by 
the "good enough" rule -- if you're going for "perfect" then your 
competitors will ship six months before you do, as well as be cheaper, 
so as a hardware vendor, you're highly motivated to ship as soon as you 
have something that might work for a few minutes after boot.


Cheers,

			/ h+


-- 
-- The early bird gets the worm, but the second mouse gets the cheese.