[flagged]
Inside the Windows Console
101–110 of 259 posts
Re: Inside the Windows Console
#102I like the post, it seems like they are good guys doing a good work on an unrewarding application. It is interesting the insight thet are giving with this article: - MS is improving on Windows Console only because of WSL - the design of the Windows Console was flawed since the beginning and remained unchanged to something like 30 years. Flaws includes: - using Console API instead of sending characters / cannot work r…
I didn't get the impression that they consider the Console API in itself a flaw. An API for this is much more robust than an in-band text API that's part of your output. For example, no Windows console application has to even think about whether printing a user-provided string can be a problem. They do note that it's an impediment for porting software to Windows, as well as the problem that the API isn't able to be implemented by any other application, e.g. ConEmu. Those applications have to rely on scraping a hidden console window to work instead of just being an alternative console implementation.
I read it not so much as a testament to the perceived superiority of the Unix model, but rather that with WSL users expect certain things to work more Unix-like, just that they don't work like that right now.
Re: Inside the Windows Console
#103Earlier quoted context omitted.
Thank you for explaining! Please don't take my initial post as criticism of your work. There is just this visible disconnect between approximately 4 years of work and comparatively simple features that have been shown off so far. So there must be a story there. I was not aware of Windows having had different console implementations in the past. Can you elaborate on that point? How did that come to pass? Also,I am cur…
As I understand it Windows 3 ran in DOS, Windows 98 had DOS integrated, Windows NT had it emulated and ME was somewhere in between. It wouldn't surprise me if parts from all four have survived til today for compatibility.
ME wasn't between the least. It was DOS based. There is no inbetween. It's either IO.SYS or NTOSKRNL.EXE. It made using the real mode MS DOS even worse by shipping a special MS DOS which skipped CONFIG.SYS and AUTOEXEC.BAT, hidden the files and removed DOS from the boot menu. To fix this, check http://retrosystemsrevival.blogspot.com/2018/06/dos-for-wind... this -- quite new blog post, just last month, for something this old.
Re: Inside the Windows Console
#104Earlier quoted context omitted.
That bit you've quoted is only half the story. I've written both terminal emulators as well as ported my own UNIX shell to Windows and never resorted to those kind of tricks. However the stuff I've focused on isn't interactive commands (ie just normal POSIX-like file streams). The moment you envoke "del" or other command that prompts "Are you sure you want to delete" (or whatever) then for some odd reason Windows jus…
Is your shell on github?
Indeed. https://github.com/lmorg/murex
However I'd still recommend WSL or Powershell over my shell for Windows use as I haven't invested an great amount of time on the Windows port (and certainly haven't used nor tested it extensively on Windows like I do on Linux and FreeBSD). Though at some point - probably after I've finished documenting the thing - I do plan to go back and revisit the Windows port.
Re: Inside the Windows Console
#105Earlier quoted context omitted.
> There is no CTRL + R to search for the last command On Unix this is typically a shell feature, not a console/terminal feature. The corresponding way to do this in the Windows console would be F8, I think. > autocompletion in cmd doesn't work > I really hate dos batch language None of those have anything to do with the console .
C-r is a feature of the PSReadLine module for PowerShell.
For cmd you can install clink.
Re: Inside the Windows Console
#106Earlier quoted context omitted.
Lol any original devs retired a long time ago, can you imagine what $MSFT shares from 1989 are worth now?
With the recent surge in MSFT, it must be pretty gratifying for the stock options.
The recent surge? A dev getting a bunch of shares in 1988 would have been filthy rich by 1996, already :)
Re: Inside the Windows Console
#107Earlier quoted context omitted.
Lol any original devs retired a long time ago, can you imagine what $MSFT shares from 1989 are worth now?
What the heck is this related to shares? You mean to suggest all original devs are millionaire, and that being a millionaire means you don't code anymore? And you, poor guy, missed out?
Most original Microsoft devs are millionaires, yes. I think Microsoft created the biggest group of billionaires and millionaires, out of any company.
Yup, found it:
> The company's 1986 initial public offering (IPO), and subsequent rise in its share price, created three billionaires and an estimated 12,000 millionaires among Microsoft employees.
12k millionaires! Let that sink in :)
Re: Inside the Windows Console
#108Earlier quoted context omitted.
Thank you for explaining! Please don't take my initial post as criticism of your work. There is just this visible disconnect between approximately 4 years of work and comparatively simple features that have been shown off so far. So there must be a story there. I was not aware of Windows having had different console implementations in the past. Can you elaborate on that point? How did that come to pass? Also,I am cur…
As I understand it Windows 3 ran in DOS, Windows 98 had DOS integrated, Windows NT had it emulated and ME was somewhere in between. It wouldn't surprise me if parts from all four have survived til today for compatibility.
The 9x series and ME use DOS during the boot process but not once booted, except for legacy disk access (if there's no 32-bit Win9x disk driver). Microsoft went to huge pains to make Win9x act as if it was an application on top of DOS for compatibility reasons, but it very much isn't, it's a full-blown OS. This is almost true of Windows 3.x too or Windows/286 and Windows/386.
Re: Inside the Windows Console
#109I like the post, it seems like they are good guys doing a good work on an unrewarding application. It is interesting the insight thet are giving with this article: - MS is improving on Windows Console only because of WSL - the design of the Windows Console was flawed since the beginning and remained unchanged to something like 30 years. Flaws includes: - using Console API instead of sending characters / cannot work r…
X Window has a good design? Only because it allowed competing tool kits on top of it ("Provide mechanism rather than policy. In particular, place user interface policy in the clients' hands.")
Besides the fact that the X libs are almost universally reviled and nobody used them as soon as they could (Motif, Qt, Gtk, etc.). The core concept, that of network part is actively being abandoned right now, see the Wayland efforts.
X Window won because its competitors were proprietary, basically. And then it dragged on because every application was compatible with it.
Win32 is also horrible, but you can kind of get why it was that way: the hardware was abysmal when it was conceived and backwards compatibility was super, super important in the early and cutthroat desktop market.
Re: Inside the Windows Console
#110Earlier quoted context omitted.
Good question. The article says that > Alas, the story here is not a good one: There ARE some great 3rd party Consoles (and server apps) for Windows (e.g. ConEmu/Cmder, Console2/ConsoleZ, Hyper, Visual Studio Code, OpenSSH, etc.), but they have to jump through extraordinary hoops to act like a normal Console would! > For example, 3rd party Consoles have to launch a Command-Line app off-screen at, for example, (-32000…
That bit you've quoted is only half the story. I've written both terminal emulators as well as ported my own UNIX shell to Windows and never resorted to those kind of tricks. However the stuff I've focused on isn't interactive commands (ie just normal POSIX-like file streams). The moment you envoke "del" or other command that prompts "Are you sure you want to delete" (or whatever) then for some odd reason Windows jus…
Actually, the part that you have addressed is half the story.
I wrote about both halves a couple of decades ago.