From what I can tell, the notion of "Shift", "Alt", and "Control" are pretty well hard coded from the keyboard itself right through the OS APIs. Sometimes I see the Windows key used as a modifier, but it doesn't seem to register as a "real" modifier key, any more than any key on the keyboard would.
But could a person add a new modifier key? Maybe in a wild and insane effort to bring back the space cadet keyboard? Aside from a physically modified keyboard (or maybe just remapping some unused keys), what else would it take? New drivers? New APIs calls? A complete rewrite of the OS?
I guess this kind of thing would be a lot easier to do on an open source OS than on Windows as well, yes?
Well, there's benefit in having a standard for keyboards and mice. It makes things "work" without needing special drivers or operating system patches. But that implies that keyboards and mice have to be standardized themselves in order to have them "just work".
So, if you wanted to add an extra key to the keyboard - whether it is a modifier key or not - you have to somehow make it useful which means that applications need to be aware of it and they need a way to be notified of this key's state. Fortunately, Windows and other operating systems Open Source or not, provide an extensible and also standard mechanism for this: drivers.
So, in short you would need to provide a driver to extend the standard functionality of the standard keyboard much like you would need a driver if you bought one of those fancy mice that come with 19 special buttons and 3 scroll wheels instead of the standard two-or-three buttons and one scroll wheel.
And finally, you would need applications that are aware of your special keyboard. What use would it be to have this modded-keyboard after all if you application were ignorant of it's superpowers? The only thing you'd be able to do with your special keyboard would be to create hot-keys that incorporate your special modifier..
I am curious about your reason. Do you actually wish to utilize and fully integrate the use of an additional modifier key in your daily computer usage? If so, in what way? (This is pure curiosity on my part; I'm fascinated by the reasons or events leading up to your query! And I will explain why.)
Let me first state that I can not fully answer the question you asked (what exactly would be involved with adding a modifier to the OS) other than to say that it would take much more work than what I believe any individual could accomplish—even within several years (except for some true computer genius); but depending on your reasons for asking, I can show you that it probably wouldn't be required for your purposes (although that's obviously speculation). And actually, technically, more modifiers actually exist but they are virtually undocumented and very rarely used.
I have had been toying with this question for quite a while now. My first meaningful introduction to using personal computers was with a Mac during their early years. Macs have always had at least two, genuine "character" modifier keys; as well as two "command" modifier keys. I think this distinction is an important one, although it is not typically, explicitly explained or mentioned. In the modern era Macs can functionally have up to 5 modifier keys; although there are some limitations on how they may be effectively utilized for various purposes. *nix OSes can support a whopping 8 modifiers, I believe. However, making use of them with a modern keyboard would require some remapping.
However, most of my personal computers have been Windows based, and when it comes down to it, Windows really only seems to support 1 true character modifier key: Shift. This is an absolutely unacceptable state of affairs for me! Why? I need to type WAY more characters than that!
Why? Because I have a strong interest and background in foreign languages, linguistics, phonetics and writing systems. I need to be able to type (without excessive difficult) many more characters and symbols than Windows seems to support. This is mostly for fun though, so it hasn't been crucially urgent. And I've been able to gain access to a Mac when I need to create/edit documents containing virtually any language besides English.
So, in Windows the Alt key is internally referred to as the Menu Key because it was initially used to access and navigate the command menus of applications in the days before Windows had adopted the use of a mouse. And it still functions in this capacity. Technically, it can only function as a modifier key if used in conjunction with Control. ISO Keyboards (European/foreign keyboards) often have a key called AltGr instead of the "right side" Alt key; it stands for Alternate Graphics and it is used to map the additional symbols and accented letters required by other languages to a "regular" keyboard by making accessible another whole layer or two of the whole keyboard, which effectively doubles (or even triples or quadruples) the number of characters that can be typed. Technically, the AltGr key is merely the one key which triggers the Alt and Control key simultaneously for the convenience of typists fingers.
You don't actually need an ISO keyboard in order to use AltGr and to access those additional characters; however, they make it much easier since they generally have have a the characters each key can produce printed on the key itself, like we do. All you really need to do is activate a keyboard layout for one of those languages (which are built into all versions of Windows). And you'll probably need to print out a diagram of the keyboard you choose to use. Or make stickers to put on your keyboard until you learn how to type all the symbols you need.
By the way, the Windows key IS a fully fledged modifier key, but its use is restricted for Microsoft to delegate as they see fit. (Actually, they designated that combinations using numbers as "free game" for OEMs to specify on their systems). It is designed as a modifier key on the hardware level.
The technology which supports most keyboards generally works just fine for standard usage of the keyboard (which typically does not include gaming) for typing, inputting text/data, research and so on. But, in order to safe costs and simplify they are designed so that the keys to be used as modifiers can be pressed together and recognized, along with at least one or two other keys. However, you quickly run into problems if you try to move modifiers to other keys on the keyboard and still hope to trigger "chorded" hotkeys (2, 3 or more keys pressed at once) because those keys weren't designed and given the hardware to function as modifier keys. The Windows key—even though it isn't used in that way in Windows (so far); it has the technical requirements.
Furthermore, Windows keyboards can be plugged into a Mac and and will work just fine. The Windows key corresponds to the Apple Command key; which is used extensively by most apps for triggering complex hotkeys/keyboard shortcuts— and it does this without issue.
So, despite the claims in another response; it is actually much easier to "add an extra key"- or several to your keyboard. Without the need for custom drivers, or even anything but the built-in OS driver. All you need to do is designate the key as one of the handful of additional keys found (and recognized natively by Windows) on various foreign keyboards.
There are three prominent keyboard types: ANSI (American), ISO (European) and JIS (Japanese); another common variant is the Brazilian keyboard; generally referred to as Abnt (which actually refers to the underlying "name" of the extra keys found on those keyboards: VK_ABNT_C1 and C2).
Technically, there are one or two unique keys found on ISO keyboards (known as VK_OEM_8, and VK_OEM_102). And Japanese keyboards can have more than 8 additional keys; however, they typically have 5-6 additional keys two of which are special keys used in the various methods of translating the few dozen key presses on a keyboard into one of several thousand complex ideograms. The other is a MODIFIER key! Korean keyboards feature it as well. It works like CapsLock, but instead of switching to upper case, it switches to the Korean alphabet or the Japanese syllabaries (because all computers still require a keyboard capable of typing Latin for passwords, etc. as far as I know). But it becomes very tedious and frustrating for users who switch writing systems constantly to have to switch the keyboard layout back and forth. So, they solved the problem with a locking modifier key that often has an LED light, just like CapsLock, to provide simple, instant visual cues as to which writing system will be produced.
Another type of Japanese keyboard was developed especially for ease and speed of typing. Although it never really took off (there were lots of different ideas and models in the 80s & 90s before anything was standardized), this keyboard by Fujitsu remains popular and a favorite for writers and anyone who much produce large amounts of text in Japanese.
Its special quality is that it has 3 large key which replace the space bar, only the smaller center key produces spaces, the other two are "thumb modifier keys" which are very convenient to use without finger acrobatics; they can even be combined with shift fairly comfortably and thus provide an extra large inventory of physically type-able characters. Technically they two modifiers are supported by Windows as well! Although, the support is scant and documentation virtually non-existent (at least outside of Japan).
However, it is still possible to make use of these keys in various ways if you remap and re-purpose a few keys on your keyboard- especially if you have a full keyboard with a number pad.
It's actually possible in Windows to have as many as 15 layers on your keyboard (including the base level) each of which must be activated by a unique combination of modifier keys. Actually, there are something like 48 possible (valid) combinations with: shift, control, Alt-Control, kana, loya and roya; so can't use anywhere near the theoretical possibility.
I've been using a special keyboard layout I developed that uses all those keys and has 15 layers which allow me to easily compose text in any language using the Latin alphabet (including any accented or modified letters), as well as the International Phonetic Alphabet (IPA) which is used to precisely document in written form any language or dialect on Earth. I also several layers dedicated to typing Ethiopic (I lived there as a kid); plus I have layers for rudimentary Greek, Hebrew and Arabic as well as a layer for symbols. Additionally, I have lots of deadkeys programmed into my keyboard—which are ideal for accented letters (first you press the key for a particular accent marking, but nothing happens until the next (or sometimes 3-5 keys) are pressed (if the deadkeys are "chained" to add several marks to a single letter, like Vietnamese does to an extreme degree); when the actual letter is typed it will have all those accents or marks stacked up/applied if possible.
What YOU need to make this possible?
A little piece of software called KbdEdit (the Premium version) which is VERY reasonably priced (IMHO).
There is a trial version you can check out for free of course; the website is PACKED with useful, fascinating and often obscure information on keyboards.
Other (free) software which allows you to do all sorts of things, including making use of all the modifier keys MUCH more freely for virtually any purpose is available as well. It is called AutoHotKey. I have been using it for years to do all sorts of nifty things (it's actually part of my system for remapping my keyboard for 3 additional modifier keys (it lets me "double use" keys so I don't lose functionality. For instance, I have physically remapped the two Japanese thumb modifiers to my Alt keys. I never use the Alt keys to access the menus in windows apps; however, I use software that does make use of keyboard shortcuts that contain Alt. However, as you may recall, Alt must always be used with Control to do anything other than navigate the menu. So, I didn't use any combinations of Control with the thumb modifiers on my custom keyboard layout (which posed no challenges). And I have AutoHotKey configured to convert simultaneous pressing of control and either thumb modifier to "control-alt" and if I happen to need just Alt by itself, pressing Windows+either thumb modifier is translated to Alt (since I've never encountered any shortcuts that required both Windows and Alt that created no conflicts.
I also DESPISE the trackpad on my laptop; trying to use to scroll is erratic and infuriating; furthermore, it is incapable of producing a middle click which I use extensively. So, I re-purposed that key that nobody uses that opens the "context menu" (because it's much easier just to "right click" to open that menu), usually called the "Application Key". If I'm holding it down (like a custom modifier), it translates arrow-key presses into scroll-wheel movement (in up-down or left-right axes), and it converts a space bar tap to a middle click. I also have some function or button programmed to be triggered by all of the other keys I can easily reach with that hand while holding that "faux" custom modifier. I'm able to control my media apps by simulating media keys that my little laptop doesn't have, and a host of other cool things.
AutoHotKey would probably be able to accommodate for most any reason you would want to add an additional modifier key to your keyboard, without actually going through all that rigmarole!
Windows W32 API defined Virtual-Key Codes. It is 8-bit, it provides 256 values and there is some gaps in table.
WM_KEYDOWN message operates on these codes.
Modern keyboards allow to detect up to 6 simultaneous key press but there are N-Key Rollover and Key Ghosting problems that you should be aware.
.Net API expose only Alt/Shift/Control as modifier.
In nutshell - many core APIs provided by Microsoft relay on Alt/Shift/Control as modifier even if modern keyboards allow near 5 simultaneous modifiers in addition to key press.
I don't know specifically about modifier keys, but many gaming keyboards now come with programmable keys and key macros, that could give you the extra functionality you're looking for.
Another possibility, if you're comfortable with programming at the level of C++, is to use the Windows Raw Input API, and plug in a second USB keyboard which your program could read a completely different set of input from.
https://learn.microsoft.com/en-us/windows/win32/inputdev/about-raw-input?redirectedfrom=MSDN
A third option might be to get a Raspberry Pi or Arduino to plug your keyboard into, and program it to read certain keys as your additional modifiers and send the desired output (as standard keyboard output) to your PC, with the Pi / Arduino acting as a "go-between" and emulating the keyboard. Maybe you could create your own Space-Cadet Keyboard this way.
I think the gaming keyboard with programmable keys will probably do what you're looking for, at the lowest cost and least time spent...
Related
I'm trying M-w (command -w) on my mac Air, but get requests to terminate my terminal process.Then I found on internet that on some computer it uses option. I tried that but still not working.I'm trying to copy file.
If you're using the Terminal, there is an option under Terminal Settings > Keyboard to "Use Option As Meta key". Select that and you'll be able to use the option key for things like M-w. Personally, I find that I want to have both CTRL and META on both sides of the keyboard, so I map the "command" key to be "control" and "control" to be "command" using the System Preferences Keyboard pane, leaving the "option" key to be a "Meta" on both sides of the spacebar. This allows me to work fluidly without having to strike two keys with one hand, which saves me a lot of ergonomic distress.
Some people like to use the caps lock as a control key, which has the advantage of increased ease of access to the control key on the left side, but it has three major disadvantages in my view. First, it gives an asymmetry, which I find reduces fluidity of typing. Second, it costs you a caps lock key, which I use for example when I have to type out a named constant (rather than holding down a shift key to type out something like SELECTION_CATEGORY_RESTRICTION_ELEMENT, which I would prefer to be able to touch-type). Third, it tends to encourage the use of certain left-hand key chords, which in my experience has led to extremely painful repetitive strain injuries.
Because of the latter, in particular, I do not recommend remapping the caps lock key to CTRL, but your mileage may vary.
I'm using the keyboard to enter multi-lingual text into a field in a form displayed by a Web browser. At an O/S-agnostic and browser-agnostic level, I think the following events take place (please correct me if I'm wrong, because I think I am):
On each keypress, there is an interrupt indicating a key was pressed
The O/S (or the keyboard driver?) determines the keycode and converts that to some sort of keyboard event (character, modifiers, etc).
The O/S' window manager looks for the currently-focused window (the browser) and passes the keyboard event to it
The browser's GUI toolkit looks for the currently-focused element (in this case, the field I'm entering into) and passes the keyboard event to it
The field updates itself to include the new character
When the form is sent, the browser encodes the entered text before sending it to the form target (what encoding?)
Before I go on, is this what actually happens? Have I missed or glossed over anything important?
Next, I'd like to ask: how is the character represented at each of the above steps? At step 1, the keycode could be a device-specific magic number. At step 2, the keyboard driver could convert that to something the O/S understands (for example, the USB HID spec: http://en.wikipedia.org/wiki/USB_human_interface_device_class). What about at subsequent steps? I think the encodings at steps 3 and 4 are OS-dependent and application-dependent (browser), respectively. Can they ever be different, and if yes, how is that problem resolved?
The reason I'm asking is I've run into a problem that is specific to a site that I started to use recently:
Things appear to be working until step 6 above, where the form with the entered text gets submitted, after which the text is mangled beyond recognition. While it's pretty obvious the site isn't handling Unicode input correctly, the incident has led me to question my own understanding of how things work, and now I'm here.
Anatomy of a character from key press to application:
1 - The PC Keyboard:
PC keyboards are not the only type of keyboard, but I'll restrict myself to them.
PC Keyboards surprisingly enough do not understand characters, they understand keyboard buttons. This allows the same hardware used by a US keyboard to be used for QEWERTY or Dvorak and for English in any other language that uses the US 101/104-key format (some languages have extra keys.)
Keyboards use standard scan codes to identify the keys, and to make matters more interesting keyboards can be configured to use a specific set of codes:
Set 1 - used in the old XT keyboards
Set 2 - used currently and
Set-3 used by PS/2 keyboards which no one uses today.
Sets 1 and 2 use make and break codes (i.e. press down and release codes). Set 3 uses make and break codes just for some keys (like shift) and only make codes for letters this allows the keyboard itself to handle key repeat when the key is pressed for long. This is good to offload key repeat processing from the PS/2 8086 or 80286 processor but rather bad for gaming.
You can read more about all this here and I also found a Microsoft specification for scan codes in case you want to build and certify your own 104 key windows keyboard.
In any case we can assume a PC Keyboard using set 2, which means it sends to the computer a code when a key is pressed and one when a key is released.
By the way the USB HID spec does not specify the scan codes sent by the keyboard it only specifies the structures used to send those scan codes.
Now since we're talking about hardware this is true for all operating systems, but how every operating system handles these codes may differ. I'll restrict myself to what happens in Windows, but I assume other operating systems should follow roughly the same path.
2 - The Operating System
I don't know exactly how exactly Windows handles the keyboard, which parts are handled by drivers, which by the kernel and which in user mode; but suffice to say the keyboard is periodically polled for changed to key state and the scan codes are translated and converted to WM_KEYDOWN/WM_KEYUP messages which contain virtual key codes.
To be precise Windows also generates WM_SYSKEYUP/WM_SYSKEYDOWN messages and you can read more about them here
3 - The Application
For Windows that is it, the application gets the raw virtual key codes and it is up to it to decide to use them as is or translate them to a character code.
Nowadays nobody writes good honest C windows programs, but once upon a time programmers used to roll out their own message pump handling code and most message pumps would contain code similar to:
while (GetMessage( &msg, NULL, 0, 0 ) != 0)
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
TranslateMessage is where the magic happens. The code in TranslateMessage would keep track of the WM_KEYDOWN (and WM_SYSKEYDOWN) messages and generate WM_CHAR messages (and WM_DEADCHAR, WM_SYSCHAR, WM_SYSDEADCHAR.)
WM_CHAR messages contain the UTF-16 (actually the UCS-2 but lets not split hairs) code for the character translated from the WM_KEYDOWN message by taking into account the active keyboard layout at the time.
What about application written before unicode? Those applications used the ANSI version of RegisterClassEx (i.e. RegisterClassExA) to register their windows. In this case TranslateMessage generated WM_CHAR messages with an 8 bit character code based on the keyboard layout and the active culture.
4 - 5 - Dispatching and displaying characters.
In modern code using UI libraries it is entirely possible (though unlikely) not to use TranslateMessage and have custom translation of WM_KEYDOWN events. Standard Window controls (widgets) understand and handle WM_CHAR messages dispatched to them, but UI libraries/VMs running under windows can implement their own dispatch mechanism and many do.
Hope this answers your question.
Your description is more or less correct.
However it is not essential to understand what is wrong with the site.
The question marks instead of characters indicate a translation between encodings has taken place, as opposed to a misrepresentation of encodings (which would probably result in gibberish.)
The characters used to represent letters can be encoded in different ways. For example 'a' in ASCII is 0x61, but 0x81 in EBCDIC. This you probably know, what people tend to forget is that ASCII is a 7 bit code containing only English characters. Since PC computers use bytes as their storage unit, early on the unused top 128 places in the ASCII code where used to represent letters in other alphabets, but which one? Cyrillic? Greek? etc..
DOS used code page numbers to specify which symbols where used. Most (all?) of the DOS code pages left the lower 128 symbols unchanged so English looked like English no matter what code page was used; but try to use a Greek code page to read a Russian text file and you'd end up with Greek and symbols gibberish.
Later Windows added it's own encodings some of the with variable length encodings (as opposed to DOS code pages in which each character was represented by a single byte code,) and then Unicode came along introducing the concept of code points.
Under code points each character is assigned a code point identified by a generic number, i.e. the code point is identified by a number not a 16 bit number.
Unicode also defined encodings to encode code points into bytes. UCS-2 is a fixed length encoding that encodes the code point numbers as 16 bit numbers. What happens to code points with more than 16 bits, simple they cannot be encoded in UCS-2.
When translating from an encoding that supports a specific code point to one that doesn't the character is replaced with a specified character, usually the question mark.
So if I get a transmission in UTF-16 with the hebrew character aleph 'א' and translate it to say latin-1 encoding which has no such character (or formally latin-1 has no code point to represent the unicode code point U+05D0) I'll get a question mark character instead '?'
What is happening in the web site is exactly that, it is getting your input just fine but it is being translated into an encoding that does not support all the characters in your input.
Unfortunately, unlike encoding misrepresentations which can be fixed by manually specifying the encoding of the page there is nothing you can do to fix this on the client.
A related problem is using fonts that do not have the characters shown. In this case you'd see a blank square instead of the character. This problem can be fixed on the client by overriding the site CSS or installing appropriate fonts.
I need to send some keys to another program, and I tried keystroke in AppleScript. Everything worked well until I found that when I sent numbers to a Windows program running in Parallels virtual machine, it didn't work, but instead, it change the position of cursor.
Then I use program keyboardSee to find what's wrong, and I found that all numbers and some symbols are mapped to the keys on numeric keypad, not the numeric line. So maybe the NumLock is off in the virtual machine, and the keys mapped to keypad trigger not numeric but control keys.
I found some people says that use key code can solve this problem, but I cannot find a perfect char-to-keycode table, and I also notice that people said key code could be different for the same character in different keyboard layout.
So how can I solve this problem perfectly, means how can I make it always map numbers to numeric line, and perform the same in no matter what keyboard layout?
I'm afraid to say that I don't think this is possible at the moment. In general, Mac apps know that macs don't even have the same characters on their Numberpads that PCs do (no arrows, no num lock, etc), so the distinction is meaningless. Some poorly ported Mac apps do make a distinction though, such as World of Warcraft (although it isn't the worst port out there by any means). I believe parallels has a num lock in its menus somewhere (if I recall correctly), so you should be able to get around it that way.
How can I simulate a keypress in a game window (using any programming language in Windows)?
AutoHotKeys Scripts and .NET SendKeys functions do not work...
Using AutoIt!3 (which is quite similar to AutoHotKeys), you'd use Send() (http://www.autoitscript.com/autoit3/docs/functions/Send.htm), but make sure to have the game window active (WinActivate()) before you do.
I've used this to interact with Second Life (which uses OpenGL) succesfully. You may require a Sleep() period between simulated key presses, since not all games implement good keyboard buffers.
If this doesn't work, the game is probably accessing the hardware drivers directly, and your only option is to hook into the keyboard drivers.
If the game is polling asynchonously, you want to use the down and up modifiers flags:
Send("{left down}") ; hold down the LEFT key
Sleep(10) ; keep it pressed for 10 milliseconds
Send("{left up}") ; release the LEFT key
Figuring out how long to keep the key pressed depends entirely on how frequently the program you're trying to control is polling the keyboard; no way to know for sure.
Any programming language? My recommendation is to write up a little app in C or C++ (although you could also do this in a .NET app with P/Invoke).
Specifically, you're looking for the SendInput function from the Win32 API, which can send low-level keyboard and mouse input to an application. It does this in terms of an INPUT structure that contains the information you want to send.
Of course, use of this function is subject to UIPI, which means that the application you're injecting input into must be running at an equal or lesser integrity level than the application that is doing the injecting.
However, since this function is generally what SendKeys uses under the covers, that last little caveat might be why it isn't working. It's hard to say exactly; you don't tell us what you mean by "do not work".
I am looking to implement a simple registration key system. There will be printed codes, and we'd like users to type their code into our system.
This code will be used around the world, and we want to avoid any problems with confusing codes.
We're already doing the following:
using numbers and upper case letters
leaving off 2 and Z, Q and 0 and O, 5 and S, B and 8, U and V, and 7 and 1 and I
breaking up the code into four-digit chunks, so it's easier to digest
Is there better guidance online about common printed registration code pitfalls? I know this can be an annoying process for users and I want to make it as easy as possible in my system.
Put it on a durable, movable medium
Things that annoy me are
weak paper stickers glued permanently to hardware
small labels you don't know where to put
There is no ideal format, really. I'd suggest something similar to a business card - durable paper, in a size for which "containers" (carry boxes, folders, laminating cards) are readily available.
Allow Copy & Paste
Make sure I can copy and paste the key as a whole.
Your input should of course indicate the groups of characters, but when "Paste" only transfers the first group, I am a very unhappy customer.
Barcode
If you stick to print mostly, consider adding a bar code. Depends on your customer base, but it's a worthwhile option if some of them are already expected to have a barcode scanner, and might be expected to enter such a number more than once.
Unfortunately, they are much longer than the numbers, so that might be a format issue. (If you make it to small, scanners won't recognize it, if you make it to big hand scanners can't read it).
For mobile apps e.g. on a phone with camera, you could use image recognition of one of those fancy "square barcodes". (I'd expect libraries for that to be readily available).
Do you insist on print?
Allow the keys to be stored in a (e.g. text) file, give them a specific file extension that is registered for your program.
This way, you can attach a licence to an e-mail, the user just double clicks the attachment, gets a message box
Do you want to install the following licence:
dnord's GreatApp Pro - Evaluation licence (30 days)
[yes] [no]
We use a modified system to (a) have additional data in a licence file, and (b) bundle multiple licences (for separate modules/apps) into one package that can be installed at once.
At least it's an alternate to entering a key for each purchase, welcomed especially by our larger customers.
We never had support calls because of problems receiving or installing the custom file type, though this might be different if you have a consumer product. At least, no support calls because of mistyped keys :-)
General
Have a plan how to deal with "lost licences".
There's no recipe here, I guess with pure software solution you might have to show some lenience to not alienate paying users.
(We usually bind to 19" rackmounted hardware that's hard to lose, so we happily create new licences for a customer as often as he likes).