Comment by frankohn | Hacker News Reader

Comment by frankohn | Hacker News Reader

I 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 remotely - the shell and the terminal are not clearly separated: the OS will open automatically a console for some kind of executables / cannot attach a shell to an arbitrary console

It seems to me that it shows a few things.

First, unix design was better as it was more flexible and lasted over time and computers evolution. Windows' design was sort of wrong since the beginning but they didn't change anything and developers were left to use one of their horrible APIs. This is similar to the difference between X Window and Win32 GUI API.

Second, MS does not care about developers except for the user of their flagship product Visual Studio. They put 30 years of developer effort solely on Visual Studio and nothing else. Compare with Apple, they at least cared of implementing an excellent terminal and contributed greatly to the wonderful LLVM compiler infrastructure.

So, okay some improvements might lands on Windows 10 at some moment but I personally don't care. At work we still use Win 7 and I think we will keep using it for a long time. The Windows Console is just horrible to use and propram for and a testament to the MS awful software and APIs that developers are forced to use because of Windows dominance.

We're certainly not improving the console only because of WSL - WSL has highlighted a lot of functionality that we could improve upon, yes, but we're improving the console because the console needs improving.

I'd say that we're conceding that the linux commandline application model (having two streams of characters) is more portable and cross-platform compatible. The Windows Console API isn't particularly well designed and it's incompatible with *nix terminals, so instead of us trying to force our shitty API on them, we'll just adopt theirs.

I certainly care about developers. I know everyone on my team does. I know that there's not a tom of goodwill between Microsoft and external developers, but there are a lot of people at Microsoft who are working really hard to try and fix that.

So... I think the Windows model is superior in these respects:

     - object handles >> file descriptors
     - security descriptors >> {owner, group, mode, [acl]}
     - access tokens >> [gs]et[e]?[ug]id(), [sg]etgroups(), initgroups()

But everything-is-a-file makes things generic, which means they can be remoted (as you put it), which means I/O redirection in shells is trivially transparent to the programs being run , etcetera. This is a very big deal.

Now, not everything is really a file on Unix. There are ioctls for some things -- lots even. And the limited and non-standardized representation of processes as files is obnoxious, but whatever, it works.

The Windows model of console as ioctl-/API-based is simply an utter disaster of calamitous proportions. It's the reason Unix users/devs hate the Windows experience, and it has held Windows back in some ways. The success of Windows as a whole has papered this over, and it's probably the reason that the console got no love from MSFT for thirty years, but the problems are real.

Another thing that is shockingly bad on Windows is the C run-time. The lack of a single C run-time DLL, the fact that the C run-time is statically linked into every DLL, and the total lack of love that MSFT has shown the C run-time, is atrocious. Doing portable code development, where by portable one means "runs on various Unix and Unix-like OSes _and_ Windows", is rather hard, and the hard part is always Windows. Invariably this involves writing C code with lots of #ifdef WIN32 spaghetti. The only good thing about this is that it has forced some memory management discipline on library APIs that might otherwise not have happened.

If there is any chance that you could get MSFT to fund a similar project for revamping the C run-time, that would be fantastic. Because there are so many discrete portions of the C run-time to fix up, such a project could probably scale to more than three developers -- perhaps three core developers, two developers to improve a variety of individual and peripheral functions, and two test engineers. Please mate.

Look up the "universal CRT". It's already happening.

Oh I'm certainly not conceeding that Linux as a whole is better than Windows - there are pros and cons to each. But I've found that writing console applications with VT sequences to be a generally preferable experience to the Console API. Now that we've added support for VT sequences, writing a cross-platform commandline application is pretty trivial - just use VT on every platform.

I feel you pain with the CRT, though I agree with the sibling comment, the uCRT is a way better experience. I know there is a team of pretty talented people working on that, but I think way below the level that's able to influence the allocation of developer resources - otherwise the console would have a lot more than 3 people on it :P

I don't think anyone who has suffered fixing their termcap, terminfo and stty settings would think Unix has much to boast about in the terminal space. Even today, whole swathes of key combinations have no distinct escape sequences, forcing a different experience for apps like Emacs that can run both native and in terminal.

FWIW, I worked at Borland back in the day, and it simply isn't the case that MS only cared about VS users.

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.

The most obvious problem of their design is that there's no serialisation mechanism for their API calls, so apps don't remote over low bandwidth connections. Which is one of the big advantages of terminal apps to begin with.

Microsoft did objects better later on with COM and DCOM: you can imagine a better console API if COM had come first, but even then, DCOM network protocol was not good and had numerous problems that would have meant ssh still beat it. But trying to do OO API in 1989 with their tech stack wasn't a good idea.

You're conflating two things here:

Remote Procedure Calls have many implementations. CORBA and Java implement RMI, Microsoft implemented DCOM. And for serializing API calls, they do great.

However, what's REALLY hard about remote object systems like CORBA, COM+, etc. is reliably managing object lifetime semantics. It turns out that trying to manage stateful object lifetime via an inherently unreliable network connection is tricky, if not impossible.

All the reliability semantics, security infrastructure, etc. layered on top add considerable processing cost.

By comparison sending text back and forth via networks, and/or tunneling pipes (e.g. ssh) is a piece of cake.

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.

I don't think Win32 UI API is terrible. It's basically message passing object orientation before its time.

The API idioms are clumsy to code against, but OTOH it's much more viable to avoid linking libc into your app, whereas in Unix land, the only portable API is defined largely in terms of a C worldview. And some things are just leagues better, like signals vs structured exception handling.

> 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.")

Yes only this simple thing made a much better design. It can be used to provide a modern and beautiful desktop environment even 35 years after its creation.

> Besides the fact that the X libs are almost universally reviled and nobody used them as soon as they could (Motif, Qt, Gtk, etc.).

You are not supposed to use Xlibs directly to program user interface. They just provide the primitive APIs to create windows, process events and draw on the screen. It is normal to use a toolkit like Qt that use Xlib as a backend.

I agree that programming Xlib directly is not very sexy but it sort of make sense and is yet better than Win32 programming.

> The core concept, that of network part is actively being abandoned right now, see the Wayland efforts.

The fact that this is a good choice is still to be demonstrated.

> 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.

Yes, you can excuse them for creating Win32 at the time but they have no excuse for not providing qnything better after 30 years. Oh yes, you can create beautiful UI if you only use Visual Studio, you get use to all the warts and limitations, if you forget cross-platform, it will works only on windows, if you use visual studio installer and ship all the zillions of DLLs that you may need with the most baroque distribution system.

On windows I am still looking for a decent way of programming UIs without embracing all the MS bullshit.

Even when compared against Amiga toolkits and Win16, Xlib with Athena or Motif were anything but pleasant.

X Windows is the main reason of "The Year of Desktop Linux" failure.

It is quite telling that ChromeOS and Android have ditched it.

Also the only UNIX that was actually a pleasure to code for was NeXTSTEP, guess what, it also didn't care for X Windows other than compatibility purposes.

> X Windows

... doesn't exist, of course.

Funny guy, everyone understood that I meant The X Window System™.

Well, it goes to demonstrating expertise, doesn't it?

Hard to know something if you don't know what it's called, innit?

If it makes you feel better, by all means.

We can do better than ignorant condescension here.

That’s ridiculous. The full name is super cumbersome and not really intuitive. Most people just call it X...

> The full name is super cumbersome and not really intuitive.

... how is X more cumbersome than "X Windows"?

> Most people just call it X

Right. Because that's its name.

> X Window has a good design?

X does. "X Window" might not, but it probably isn't in widespread use.

> X Window

X.

Reply on news.ycombinator.com