4 ms·

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 you

by ygra 8y ago

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.

repolfx 8y ago
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.
- bitcrazed 8y ago
  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.

by ygra 8y ago

repolfx 8y ago

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.

bitcrazed 8y ago
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.