download cracks and keygens

Ctrl2cap Crack With License Key Latest

People that migrated to NT from UNIX are used to having the control key located where the caps-lock key is on the standard PC keyboard, so a utility like this is essential for our editing well-being.

With Ctrl2cap, a kernel-mode device driver, you can filter the system's keyboard class driver in order to convert caps-lock characters into control characters.

Install Ctrl2cap running the command "ctrl2cap /install" from the directory into which you've unzipped the Ctrl2cap files. To uninstall type "ctrl2cap /uninstall". If you are running on 64-bit Windows run ctrl2cap64.exe instead.

Ctrl2cap requires ntddkbd.h from the ddksrcinputinc directory, so you must first copy that file to the ctrl2cap directory. To build a standard NT 4 driver type "buildnt4" and to build a Win2K WDM driver type "buildnt5". Output files are placed in the release subdirectory.

On NT 4 Ctrlcap is actually quite trivial. It simply attaches itself to the keyboard class driver so that it will catch keyboard read requests. For each request, it posts an I/O completion callback, at which point it takes a peek at the scancode that is being returned. If it happens to be a caps-lock, ctrl2cap changes it into a left-control.

On Win2K Ctrl2cap Keygen is a WDM filter driver that layers in the keyboard class device's stack above the keyboard class device. This is in contrast to the Win2K DDK's kbfiltr example that layers itself between the i8042 port device and the keyboard class device. I chose to layer on top of the keyboard class device for several reasons:

It means that the Ctrl2cap IRP_MJ_READ interception and manipulation code is shared between the NT 4 and Win2K versions.

I don't need to supply an INF file and have the user go through the Device Manager to install Ctrl2cap - I simply modify the appropriate Registry value (the keyboard class devices's HKLMSystemCurrentControlSetControlClass UpperFilters value). See the source code to Ctrl2cap.exe for more information.

The disadvantage of my approach is (and this an advantage or disadvantage depending on your point of view):

Because I don't install with an INF file via the Device Manager, the user is not warned that the Ctrl2cap driver file is not digitally signed by Microsoft. In this particular case I felt that the advantages outweigh the disadvantages. However, before you model a Win2K keyboard filter on Ctrl2cap I strongly suggest that you study the kbfiltr example from the Win2K DDK. Kbfiltr's interception point in the key input sequence makes it very easy for kbfiltr to inject keystrokes into the input stream, something that would be more difficult using the Ctrl2cap source base.