Windows calculator can only count to 999
-
@robo2:
chcp 1252appears to be working... so I don't why I had so much trouble back then.
-
-
@HardwareGeek said in Windows calculator can only count to 999:
@robo2 said in Windows calculator can only count to 999:
because backwards compatibility, or something.
Windows: Doing things backwards since 1983
Filed under: \
-
@Gąska said in Windows calculator can only count to 999:
@HardwareGeek said in Windows calculator can only count to 999:
@robo2 said in Windows calculator can only count to 999:
because backwards compatibility, or something.
Windows: Doing things backwards since 1983
Filed under: \
I bet there's an Oldnewthing article explaining how that was chosen for CP/M compatibility. Nobody remembers (or ever knew) what CP/M was, but all of Windows ass-backwardness goes back decades to that, in one way or another.
Filed under: back in the day before everything became abandonware after 2 months
-
@topspin said in Windows calculator can only count to 999:
@Gąska said in Windows calculator can only count to 999:
@HardwareGeek said in Windows calculator can only count to 999:
@robo2 said in Windows calculator can only count to 999:
because backwards compatibility, or something.
Windows: Doing things backwards since 1983
Filed under: \
I bet there's an Oldnewthing article explaining how that was chosen for CP/M compatibility.
Yes there is. Except not CP/M but MS DOS 1.0, which didn't have directories at all. But it already used / for command parameters, and so they couldn't use it for directories in MS DOS 2.0, or something.
-
@Gąska said in Windows calculator can only count to 999:
@topspin said in Windows calculator can only count to 999:
@Gąska said in Windows calculator can only count to 999:
@HardwareGeek said in Windows calculator can only count to 999:
@robo2 said in Windows calculator can only count to 999:
because backwards compatibility, or something.
Windows: Doing things backwards since 1983
Filed under: \
I bet there's an Oldnewthing article explaining how that was chosen for CP/M compatibility.
Yes there is. Except not CP/M but MS DOS 1.0, which didn't have directories at all. But it already used / for command parameters, and so they couldn't use it for directories in MS DOS 2.0, or something.
Except, of course, they could have easily used / for both parameters and directory separators, if simply for the fact that there’s no single root.
(The caveat here probably being that it allowed stupid things like multiple parameters not being separated by spaces)
-
PC DOS 1.1 (1982) significantly increased the use of the forward slash. COPY had the /A, /B, and /V switches, DIR had /P and /W switches, while DISCKOMP, DISKCOPY, and FORMAT now had a /1 switch (for one-sided floppy operation). The linker likewise had new options such as /DSALLOCATION, /HIGH, /LINE, /MAP, /PAUSE, and /STACK.
That kind of forward slash usage was no doubt why IBM insisted on keeping it in DOS 2.0. Changing the slash semantics had a clear potential for destroying data, especially when running batch files written for DOS 1.1. Something like ‘COPY FOO + BAR /A’ has rather different semantics when /A is a switch vs. when /A is a file or directory in the disk’s root directory.
-
@Zerosquare That’s the same kind of mentality as the author of a book on Java I once partly read, deplored concerning the
switchstatement: it could (in his opinion: should) have been fixed to be far more convenient when the language was still new, but (IIRC) because there were already a few thousand Java programs at the time this was brought up, it was felt to break too much existing stuff … In 1983, it would have been fairly easy to get people to change theirscriptsbatch files to replace the slashes for switches with, say, hyphens. Now, it’s far too late — even though Windows supports hyphens for switches as well.But now I wonder why PC-DOS used slashes for switches in the first place. Just to be different? CP/M used square brackets around the option:
DIR [EXCLUDE] *.TXTto not list any file with extensionTXTfor example. So are the slashes there only to provide a similar way to that of Unix but without making it seem like a straight copy?
-
It's explained in the article ; the inspiration is likely DEC's TOPS-10.
-
@Zerosquare said in Windows calculator can only count to 999:
That's a well-known problem with the Windows console. It uses DOS code page 437, not Windows-1252 (much less Unicode) ; it doesn't matter for US ASCII, but accented characters are mapped differently.
Actually, it depends on which API you use to write to the console. The one that's usually mapped as standard out and standard error is the one that uses code pages, but if you use the unicode version of the underlying API instead then you can write… well, anything in the BMP at least. Emoji might come out weird.
Of course Windows has several APIs for writing to the console. Why would you have just one?
-
@Gąska said in Windows calculator can only count to 999:
Yes there is. Except not CP/M but MS DOS 1.0, which didn't have directories at all. But it already used / for command parameters, and so they couldn't use it for directories in MS DOS 2.0, or something.
The
/for command options was the bit for CP/M compatibility.
-
@dkf said in Windows calculator can only count to 999:
Emoji might come out weird.
If you're writing Unicode emoji to the console, you deserve weirdness.
-
@Zerosquare said in Windows calculator can only count to 999:
It's explained in the article ; the inspiration is likely DEC's TOPS-10.
Somehow I forgot to look at the article, and now I do, I get the impression I read it a few years ago already, but don’t remember any details of it :)
Did Microsoft invent the slash usage? Of course not.
Take that.
@dkf said in Windows calculator can only count to 999:
The
/for command options was the bit for CP/M compatibility.The CP/M manual I linked to above suggests it wasn’t. Though that is for CP/M v3, maybe earlier versions did use a slash? However, 2.2 doesn’t appear to have had any switches at all for its commands.
-
@Gurth said in Windows calculator can only count to 999:
@Zerosquare That’s the same kind of mentality as the author of a book on Java I once partly read, deplored concerning the
switchstatement: it could (in his opinion: should) have been fixed to be far more convenient when the language was still new, but (IIRC) because there were already a few thousand Java programs at the time this was brought up, it was felt to break too much existing stuffOr the insanity of
makethat didn’t get fixed because (apocryphally?) it already had, like, 10 users.
-
@dkf said in Windows calculator can only count to 999:
Of course Windows has several APIs for writing to the console. Why would you have just one?
Other than the standard streams and the A versions of the W functions, there is just one API. I researched this specific topic very thoroughly once upon the time.
-
@Gąska said in Windows calculator can only count to 999:
it's a huge stretch to call them a different API, as they're all identical functions with identical semantics and literally the only difference is the character type
Except that that's precisely the difference that's coming into play here.
-
@Gąska You can always find the console window handle and use GDI to draw some text yourself
-
@Applied-Mediocrity said in Windows calculator can only count to 999:
@Gąska You can always find the console window handle and use GDI to draw some text yourself
I see that
, but does that actually work (with it being a different subsystem and all)?
-
@topspin Yes and no. Technically I suppose it doesn't count. You would be drawing on the Console Window Host - a window just like any other - which just happens to host your console application.
using System.Drawing; using System.Windows.Forms; ... [DllImport("user32.dll", SetLastError = true, CharSet = CharSet.Unicode)] public static extern IntPtr FindWindow([MarshalAs(UnmanagedType.LPWStr)] string lpClassName, [MarshalAs(UnmanagedType.LPWStr)] string lpWindowName); var WindowHandle = FindWindow(null, Console.Title); if (WindowHandle != IntPtr.Zero) { var Context = Graphics.FromHwnd(WindowHandle); // go to town }
-
@topspin said in Windows calculator can only count to 999:
@Applied-Mediocrity said in Windows calculator can only count to 999:
@Gąska You can always find the console window handle and use GDI to draw some text yourself
I see that
, but does that actually work (with it being a different subsystem and all)?Yes. Console programs can have windows. GUI programs can have consoles. Subsystem only affects the initial setup of the process.
-
@Gąska said in Windows calculator can only count to 999:
@topspin said in Windows calculator can only count to 999:
@Applied-Mediocrity said in Windows calculator can only count to 999:
@Gąska You can always find the console window handle and use GDI to draw some text yourself
I see that
, but does that actually work (with it being a different subsystem and all)?Yes. Console programs can have windows. GUI programs can have consoles. Subsystem only affects the initial setup of the process.
Yes, but can you paint over the console window specifically?
-
@topspin you can paint over the motherfucking taskbar if you want. Window handle + elevated permissions = you're the god.
-
@topspin said in Windows calculator can only count to 999:
Yes, but can you paint over the console window specifically?
If you can find it and have permission to write to it (the permission is usually “allowed to write over windows you don't own”), yes. Keeping the thing you've drawn there when the window scrolls or otherwise changes its content however…
-
@Gąska said in Windows calculator can only count to 999:
@topspin you can paint over the motherfucking taskbar if you want. Window handle + elevated permissions = you're the god.
Ah, maybe I should rephrase that: without elevated permissions and getting around UIPI, but it being your own process.
(I’m going to assume the answer is still yes, but that’s what I meant to ask)
-
@topspin unfortunately, I can't answer that. I'm not well versed in inter-process manipulation in modern Windows. The console window is always out of process, so you need special permissions to draw over it. If you inherit the console from other process - e.g. you're a console program run manually in command line - then you definitely don't have these permissions by default. But if you get a fresh console - e.g. the program is run by double clicking in Explorer - the console host process is spawned as a child of your process, so you get more permissions than usual, but I'm unsure which ones specifically, and I'm unsure which ones you'd need, and I can't find it described on MSDN or whatever it's called now.
-
@robo2 said in Windows calculator can only count to 999:
@remi let's suppose the
is weak today: this hypothesis can be tested. If you change the codepage of your console before running the utility it might actually show the û you hoped for.The console is actually opened by VS when I start my process (I think that there is somewhere deep down where I can configure whether that happens or not, but I'm quite happy that it does so I'm not bothering any further). There may be ways to specify the codepage of that console...
When run by a normal user (i.e. not from VS), we... uh... I thought I knew but actually looking at the code I don't. Apparently there is something in our build system that "makes it so" (
:picard:) that a console gets opened as well. We used to callAllocConsole()explicitly in the main.cpp to do that (and I assume it would then have been possible to change the codepage of that console from the code that created it), but it's commented out now.In any case, I don't really care enough about this to try and fight the
. Though if I did, I would probably, just for 
, go with @dkf's suggestion and print emojis as well. Process failed! ☺should nicely mess up with users...
-
@remi said in Windows calculator can only count to 999:
There may be ways to specify the codepage of that console...
Change default code page of Windows console to UTF-8
Currently I'm running Windows 7 x64 and usually I want all console tools to work with UTF-8 rather than with default code page 850. Running chcp 65001 in the command prompt prior to use of any tools
The real key is that the console itself is Unicode (well, probably WTF-16, which is why non-BMP characters should be avoided) and has been for a long time. That means that what you're actually doing when things are going wrong is fighting through a couple of layers of translation goop, whereas the wide console access API is more direct. But it does mean that stdout, when directed to a console, is going to be horrible because it's defined to be
char-based and Windows's support for UTF-8 has long been a bit shaky. You'd have virtually the same problems on Linux and macOS except those switched to UTF-8 a very long time ago.FWIW, changing the system encoding of an existing system is a very tricky thing. It has impacts all over the place.
-
Update:
Changing HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CodePage\OEMCP value to 65001 appear to make the system unable to boot in my case.
Yeah, I think I'm not even gonna try to fight the
here...
-
@remi said in Windows calculator can only count to 999:
Apparently there is something in our build system that "makes it so" (:picard:) that a console gets opened as well.
There's a field in the .EXE header for setting which subsystem you want to use. Setting it to one of the
_CUIones means you get a console without having to allocate one yourself, but it also handles inheritance and blocking correctly.
-
@Gąska said in Windows calculator can only count to 999:
The console window is always out of process
This is not surprising... A typical xterm or modern equivalent on a Unixalike is also out-of-process for programs running inside it...
-
@Steve_The_Cynic the difference is that Unix process doesn't get the raw handle of its terminal window for low-level manipulation, while Windows process does.
-
@Gąska said in Windows calculator can only count to 999:
@Steve_The_Cynic the difference is that Unix process doesn't get the raw handle of its terminal window for low-level manipulation, while Windows process does.
It can (via
/dev/tty, or one of the file descriptors if they haven't been redirected). But the range of things a unix process can do with that handle is probably more limited than in windows.After all, while that TTY might be in a local GUI window, it may also be a proxy for a putty client in windows, or a full-screen text mode, or for that matter an actual physical VT-100.
Among the range of things possible in a linux TTY is advanced colour control, setting the title of the terminal window, and mouse interaction.
-
@PleegWat said in Windows calculator can only count to 999:
@Gąska said in Windows calculator can only count to 999:
@Steve_The_Cynic the difference is that Unix process doesn't get the raw handle of its terminal window for low-level manipulation, while Windows process does.
It can (via
/dev/tty, or one of the file descriptors if they haven't been redirected).Not quite. Windows has a GetConsoleWindow function that returns a handle not just to the text stream part of the console, but the entire window. Borders. Title. Close button. Dimensions (in pixels, not characters). Raw clicks and other window events. Maximizing, minimizing, bringing to top. Finally, the graphical buffer of the window - not just the characters inside it, but the final pixels too. It has a handle to the window. There's no Unix equivalent of that. I know the reasons why (mainly, there's really no concept of "console window" in Unix spec, so it wouldn't make sense to ask for one), but still.
Edit: note that on Windows, the console handle and the console window handle are two separate things. The former is retrieved with GetStdHandle. If you want to manipulate the characters in console, you need the console handle, not the console window handle.
-
@Gąska said in Windows calculator can only count to 999:
There's no Unix equivalent of that.
Yes, because there's no guarantee at all that there's any such thing there in the first place. In lots of usage scenarios, there simply is no such window at all; terminal windows are merely one option out of many. (I guess there could be a way to ask on D-Bus whether any window knows about this virtual terminal that you're talking to… but there's no real reason why you'd expect to get an answer.)
-
Interestingly enough, I don't think there's a bulletproof guarantee even when using Windows. There was a time when console programs could run fullscreen in actual text mode* (not an emulation in graphics mode) ; I don't know if you still got a window handle in that case, but even if you did, you couldn't do much with it.
*AFAIK, the support for it was eventually removed.
-
@Zerosquare said in Windows calculator can only count to 999:
Interestingly enough, I don't think there's a bulletproof guarantee even when using Windows. There was a time when console programs could run fullscreen in actual text mode* (not an emulation in graphics mode) ; I don't know if you still got a window handle in that case, but even if you did, you couldn't do much with it.
*AFAIK, the support for it was eventually removed.
IIRC it was removed in Windows 95. So the guarantee has been really bulletproof for 25 years.
-
Nah, I think it still worked in Windows XP, at least. But I don't have a working VM handy to check it.
-
@Zerosquare how would you even check it? Emulation would look identical to a real thing.
-
@Gąska said in Windows calculator can only count to 999:
@Zerosquare how would you even check it? Emulation would look identical to a real thing.
Exactly?!
If it works in an XP VM, it’s likely to work in a real XP box too.Anyways, no need to check, I remember it working in XP. It was removed in Vista or maybe 7.
-
Right, though it appears to be a limitation of the new video driver model (MS mentions using a XP video driver as a workaround):
Apparently, in Win10 they added an emulated fullscreen mode:
Open command prompt fullscreen in Windows 10
How to enter the fullscreen command prompt in Windows 10 with a hotkey.
-
@remi said in Windows calculator can only count to 999:
Update:
Changing HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CodePage\OEMCP value to 65001 appear to make the system unable to boot in my case.
Yeah, I think I'm not even gonna try to fight the
here...That post is a bit outdated. Here's more up-to-date advice:
Using UTF-8 Encoding (CHCP 65001) in Command Prompt / Windows Powershell (Windows 10)
I've been forcing the usage of chcp 65001 in Command Prompt and Windows Powershell for some time now, but judging by Q&A posts on SO and several other communities it seems like a dangerous and
-
TL;DR: enabling that setting will make Windows 10 even buggier than it normally is.
-
@Zerosquare You'll be able to use characters like this in the command prompt: 🐞🦋🐝🐜
-
@Zerosquare said in Windows calculator can only count to 999:
make Windows 10 even buggier than it normally is.
-
Port it to a Discourse plugin.
-
-
@HardwareGeek said in Windows calculator can only count to 999:
@dkf said in Windows calculator can only count to 999:
Emoji might come out weird.
If you're writing Unicode emoji to the console, you deserve weirdness.
https://dilbert.com/strip/1995-06-24
-
@topspin said in Windows calculator can only count to 999:
Or, of course, you can do actually practical things with it, like:
rmdiring them again is somewhat problematic, though not impossible, of course.
-
@Gurth This sounds like a post for https://what.thedailywtf.com/topic/23080/big-list-of-software-that-cannot-handle-spaces-or-accents-in-paths
-
Get Old Classic Calculator in Windows 10
Windows 10 introduces the Universal Windows Platform (UWP), which provides a common app platform for every Windows 10 device. This also means that your favorite classic Win32 desktop applications are…
Some 16-bit DOS-based Programs and the Command Prompt will not run in full-screen mode in Windows Vista and in Windows 7 - Microsoft Support
