I\'m writing a screen saver type app that needs to stop the user from accessing the system without typing a password. I want to catch/supress the various methods a user migh
To add to what Shog9 said, if your application could intercept ctrl+alt+del, then your application would be able to pretend to be the Windows Login dialog, and by doing so trick the end-user into typing their credentials into your application.
If you do want to replace the Windows Login dialog, see Winlogon and GINA (but this says, "GINA DLLs are ignored in Windows Vista", and I haven't heard what's what for Vista).
if someone asked I'd not tell them they can't.
More specifically, your "application software" can't: instead, by design, only "system software" can do this; and it isn't that you're not allowed to or not able to write system software, but your OP seemed to be quite clearly asking how to do it without writing system software ... and the answer to that is that you can't: because the system is designed to prevent an application from hooking these key combinations.
Can you give me direction to writing the system things.. I actually think this would be better if it were system level.. It's for an OEM so kind of the point really. Also if I wrote it system level, I could write an app to control it.
A keyboard filter device driver, or a GINA DLL, for example, would be considered system software: installed by an administrator (or OEM) and run as part of the O/S.
I don't know about GINA beyond its name; and I've already (above) given a link it in MSDN. I expect that it's Win32 user-mode code.
Device drivers are a different topic: e.g. Getting Started on Driver Development.
Is there a way to remap the keyboard so that delete isn't where it was?
I still not sure that you and/or your boss have the right idea. IMHO you shouldn't be an application which prevents the user from pressing Ctrl-Alt-Del. If you want to stop the user from accessing the system without typing a password, then you ought to lock (password-protect) the system, as if the user had pressed Ctrl Alt Del and then selected "Lock this computer". To unlock the computer they would then need to press Ctrl Alt Del and enter their credentials into WinLogon.
However, ignoring what you ought to do and concentrating instead on what you're capable of doing, if you want to intercept the keyboard, apparently it can be done. I haven't studied keyboards myself, but this post and this post claim success, by writing a "Keyboard Filter Driver" (which is a kind of kernel-mode, not Win32, device driver). If you write one of these though you may get some push-back, e.g. like this reaction from a DDK MVP, or this reaction from an anti-snooping product.
You can't. The whole point of Ctrl+Alt+Del is that only the system gets to handle it, 'cause that way the system can always handle it.
Fortunately, Windows has built-in support for password-protected screensavers (available as the "On resume, password protect" option in Display Properties, or via group policy). Just use that.
As this seems to be a good collection spot for the accrual of various means with which to "intercept" the three key psuedo-break control alt delete, here is something I encountered yesterday that may be of use.
http://cuinl.tripod.com/Tips/enablectrldel.htm
In my opinion, when it seems that the only practical and timely option is to cut the power (i.e. MECHANICAL removal of the battery of an overloaded android-like handheld computer) to halt whatever procession or malfunction results in rather solid and complete ( or long enduring) irresponsiveness-- it appears that a dangerous and frustrating lineage continues--- and continues to get worse.
Especially with the removal of sensible and straightforward things like mechanical speaker volume controls. ( sure, bulky, more material, but of course that is just the thing, what good to an individual or being is infinite and perfect consciousness without a handle on it or it's experience?)
It is a lineage of approaches to designing the -environment that is responsible for the responsiveness to the user- part of a critical and truly meaningful technological interface. ( The only?)
I say put some buttons --direct-to-hardware-control-- back on the things --at least until the software aspects of these technologies become fully adapted to artificial soft interfacing, which I account for in an exhaustive accounting of all heuristical provisionings.
Even in the mechanics of the universe I bet there's a handy reset, restore, suspend, halt type of function(s) for the safety and fundamental viability of the presence of what would constitute as the designer of all that follows the initiating perpetual mystery of existence: INTELLIGENT AWARENESS and WILL.
Ok.. I'm not going to post the code here But the gyst is this
create a keyboard hook. when the user presses ctrl || alt || delete set bools to true.. if they press anything else set them all to false.
switch (p_key)
{
default: Clear(); break;
case Keys.LMenu: altHit = true; break;
case Keys.RMenu: altHit = true; break;
case Keys.LControlKey: ctrlHit = true; break;
case Keys.RControlKey: ctrlHit = true; break;
case Keys.Delete: delHit = true; break;
when the screen has focus looses it to the task manager, close the bloody thing. The screen flashes so fast the user never notices it. And I can do what ever I want.
I'll admit this is a kludge, but it does result in the desired effect. (OH I wish I didn't have to do this)
You can still intercept Ctrl + Alt + Del in windows 7.
This is the way Process explorer does it:
http://mygreenpaste.blogspot.com/2005/07/image-file-execution-options-good-evil.html
"Process Explorer" by Mark Russinovich (http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx) does it, and it had been doing before Sysinternals was bought by Microsoft.
This article from 2002 updated in 2006 explains one way to do it without writing a keyboard driver. http://www.codeproject.com/KB/system/preventclose.aspx?msg=1666328