I would like to have some advice about how to port an old C++ program written for MS-DOS in the early 90s.
This program implements a quite complex text-user interface. The interface code is well separated from the logic, and I don't think it would be too difficult to make it use ncurses.
Being a complete novice, I have a few questions:
The DOS program intercepts interrupt 0x33 to handle mouse events. The interrupt handler store events in a FIFO, which the main program pools periodically. (Every element in the FIFO is a C structure containing information about the nature of the event, the position of the mouse and the state of its buttons.) To keep the logic of the code unchanged, I was thinking of firing a thread which calls getch() asynchronously within an infinite loop and fills the FIFO in the same way the old program did. My idea is that this thread, and only this thread, should access stdin, while the main thread would only have the responsibility to access stdout (through add_wch() and similar). Is ncurses safe to use in this way, or do stdin/stdout accesses need to be always done within the same thread?
The way colors are set in this app is quite byzantine, as it uses the concept of "inherited palettes". Basically, a window usually specifies the background and foreground colors, and every widget within that window sets the foreground only (but a few widgets redefine both fg/bg). I understand that ncurses' attr() always wants to specify colors using pairs, which must be initialized using initp(), and this doesn't play nicely with the logic of this program. I am therefore thinking of using tiparm() to directly send setaf/setbf sequences when the program wants to change the fg/bg color, respectively. (I would lose the ability to run the code on terminals which do not support setaf/setbf, but this would not be a huge loss.) Is it safe to send setaf/setbf control sequences and then call functions like add_wch(), or should the latter be used only in association with attr()?
I could write a few test scripts to check that my ideas work, but I would not be sure that this approach is supposed to work always.
Thanks for any help!
There's a lot of possibilities - but the approach described sounds like terminfo (low-level) rather than curses, except for the mention of add_wch. Rather than tiparm, a curses application would use wattr_set, init_pair, start_color, etc.
ncurses I/O has to be in one thread; while ncurses can be compiled to help (by using mutexes in some places), packagers have generally ignored that (and even with that configuration, application developers still would have work to do).
Further reading:
curses color manipulation routines
curses character and window attribute control routines
curses thread support
Due to XIM and XFT usage, I have to use XDisplay sometimes in my XCB based code.
My question, should I open display at the beginning of my program, and close it at end. Or open and close every time I need to use it?
It is better to open once the XDisplay. At least that is the common practice.
IIRC, XOpenDisplay involves setting up a TCP connect to the X11 server and having a few exchanges to initialize, e.g. for X11 atoms which became standard but not predefined (I'm not sure of the last point)
What are the relevant standards, man pages, RFCs or other pieces of documentation when implementing a POSIX-style unicode terminal emulator?
The scope of this question spans everything from handling multi-codepoint unicode characters and other unicode pitfalls, behaviour of the terminal when resizing, control sequences to RGB values associated with certain color codes.
While articles such as the Wikipedia page on ANSI escape sequences might suffice for using a terminal emulator, writing one that will behave correctly for all applications, which includes correctly handling invalid, unknown or user-defined inputs requires actual standard documentation.
My best source so far are ECMA-048, man 3 termios, and the source code of various other terminal emulators.
Obviously, you already added The Unicode Standard to your list of sources. :-)
By a POSIX-style unicode terminal emulator, do you mean a terminal emulator accepting the whole Unicode charset (or a large subset of it), and running on POSIX-compliant operating system? Then since POSIX restricts itself since 2001 on 8-bit chars, this pretty much means a UTF-8 terminal emulator, a restricted case of such emulators where you would not have to deal with various charsets and encodings (definitively a good thing) but where characters are basically multi-byte, which in turn may call for functions like wcwidth(3) (which is not strictly POSIX, only XPG by the way); more generally, rendering problems can be arbitrarily complex with Unicode, including BiDi, Indic scripts with reordering vowels, ...
If you mean something else, please elaborate.
Otherwise, since an emulator also relies on a keyboard, you may encounter interesting content on Wikipedia.
Another source of documentation with a lot of information you might use is the Microsoft Go Global site.
We have an old 32bit PowerBuilder application (3rd party) that was written for Windows XP and, although it runs under Windows 8, we have noticed that the password masking character is a different sized character (XP is a small black circle and Windows 8 is a larger black circle). This is a problem because the application was written to limit the space available in the password field (22 characters in XP but only 13 in Windows_8). Our password policies require 15-character minimum passwords, and obviously these wont fit when we run the application in Windows 8.
Because the character sizes change with the operating system (not application side), we suspect the problem is with a .dll file or a font that is being referenced by the PowerBuilder application. Are there any ideas where the password mask is being called?
As a workaround, maybe you could be able to type more characters if you increase the edit width?
You could give a try with either uuspy or WinCheat.
If it helps, you could then find a mean to script the send of a WM_SIZE to the control or inject a dll to do so...
I'm afraid you're looking for a complicated solution to a simple problem.
I'm guessing this is a DataWindow-independent (i.e. not inside a DataWindow object) SingleLineEdit. There are generally two reasons you can't type all the characters you want (regardless of the Password attribute) into one of these fields:
You have a non-zero value set in the Limit attribute. However, since your limitation is varying, this likely isn't your culprit.
You have the attribute AutoHScroll (automatic horizontal scroll) set to FALSE (or unchecked in the IDE painters). This means when the field fills up graphically, you can't enter more characters. (This also means, with a variable width font, which most are, you fit more i's into the field than W's; this isn't a good way to go when data length is important. In fact, it's seldom a good way to go at all.)
Your symptom sounds like AutoHScroll is turned off (the default is on when you drop and SLE on the window). Check that back to on, optionally set the Limit attribute to something that makes sense (if the original intention was to constrain the number of characters entered, and it was just implemented poorly), and my guess is that you'll be good to go.
Good luck,
Terry
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...