181–190 of 259 posts
Earlier quoted context omitted.
That's Rich for you - He's pretty passionate about everything we do :)
I want to work with more people like Rich! Whatever they may lack in English convention, they more than make up for it in enthusiasm!
edit: Now that I say that, I guess he is Welsh so maybe his english isn't the best... :P
Earlier quoted context omitted.
Oh no, I can say that quite publicly. When I started on the team in 2015, that code was some nightmarish shit. It was hardly componentized, you'd have 70 different places in the code all calling out to GDI to do rendering at seemingly random points in the app's lifecycle. It was painful to get work done in the codebase. After a LOT of refactoring it's finally in a state that's really quite managable, and much more mo…
I hope you updated all that to D2D. I was always deeply offended you forced office to move with Universal but had the gall to link GDI in and keep using it for your own stuff :).
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 r…
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.
They should just replace it with the power shell prompt that wraps the command line.
Earlier quoted context omitted.
Well, the team is small, we're up to three whole devs now. Since 2014 we've been doing a lot of work o help bring our VT implementation up to par (to help enable WSL), as well as implementing new features such as 256/RGB color support, improved accessibility features, and we're even releasing a pty-like API for Windows. Not only that, but since the team was founded we discovered that conhost was not the only console…
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…
> 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?
It's not really something most developers outside the company would have even been aware of honestly. At different points in time, there have been various different teams across Microsoft who had been working on bringing up new pieces of hardware (Xbox, HoloLens, phones, etc) and they found that the existing console didn't work on those minimal Windows OS's. At the time, there was no Console team at all, so whoever was working on that device just implemented their own console that would work on that prototypical device. That prototypical console got re-used and extended for other devices as they were developed, then abandoned as the platforms matured.
Then, in 2014, when the Console team was formed, we found out that not only were we responsible for the desktop console, but these other implementations as well.
> Can we expect improvements in that area as well?
Stay tuned :)
Earlier quoted context omitted.
I hope you updated all that to D2D. I was always deeply offended you forced office to move with Universal but had the gall to link GDI in and keep using it for your own stuff :).
That part comes next ;) Getting all of the rendering calls isolated to one component was a pretty big task in itself, and just isolating and de-duplicating them improved our rendering perf by something like 30%
Hopefully, support for bidirectional text will be added soon. Microsoft needs to lead the way of handling it in console programs. Even in UNIX systems, only a few terminal emulators support bidirectional text properly.
https://wpdev.uservoice.com/forums/266908-command-prompt-con...
I'd say that bi-directional text is a pretty low priority at the moment. We just haven't really heard any asks for it, and like you said it's poorly supported on other platforms (if at all).
Earlier quoted context omitted.
I think his (?) point is that if you don't have the backwards-compatibility goals of Windows, you can afford to be - and perhaps should be - a lot more adventurous. Which is something POSIX systems have summarily failed to be in this respect, for all that they've managed to polish that turd to an acceptable shine.
What exactly are backwards-compatibility goals of Windows? Are they that different from backwards-compatibility goals of POSIX systems? I read the above sentences as: 1) the legacy on $SYSTEMS_I_DONT_LIKE is bad 2) the legacy on $SYSTEM_I_LIKE is there for a reason.
I can still run software written for Windows 95, without recompilation, with a pretty high success rate. As far as I'm aware, only Linux has that level of ABI compatibility and unfortunately it's completely broken by userspace. Often you can't even run the same binary on two different distributions without recompilation.
Very interesting. I learned a lot. The author mentions "re-re-re-implementing" command line history as a disadvantage of using shells in a dumb terminal emulator. But, with respect, I think he's wrong about that. Command line history is a valuable productivity enhancer, and tying the details of its operation to the terminal rather than the shell restricts functionality and flexibility. For example, witness the differ…
I also didn't agree with the points about Console API. I mean sure, he's right that ANSI / VT escape sequences are naff, but they are the standard so we're stuck with them. However as much as I love the idea of a Console API, the fact that they only work on local host is just inexcusable. And I don't say this because "hindsight is 20/20", there was already decades of proven example that remote consoles are worth having before the console API was even written. Why they couldn't have created is a network API (ala rsh) is beyond me. But we are where we are.
Some of the examples given about OOP was just plain wrong too. You can't bunch 20 years of object oriented langaues together and say "they all quickly followed". 20 years is not quick; not in real terms and most definitely not in IT terms.
What surprised me the most when reading that article is that NT was originally command line driven with a GUI added for release. It's amazing just how bad the console sucks even without taking the evolution of NT into account; and now that I know NT was originally command line oriented, well I'm just shocked.
If there was anything good that can be taken from the article, it's that it sounds like they are working on better terminal / shell separation which will enable developers to write better terminal emulators and better alternative shells. Plus potentially allow for a networked shell. My next request after that would be to write a unified way of splitting ARGS because their current method of passing all command line parameters as a single string is just terrible (yes, I get that's DOS legacy and impossible to change due to backwards compatibility, but isn't it about time Windows had a standard API for splitting that ARGS string so, going forward, programs can be written to split parameters in a consistent way meaning command line users know exactly when they can and cannot use quotation marks, spaces and escaped characters, etc.
In general I prefer the WIN32 object-handle model to the Unix file-descriptor model, and I much prefer the WIN32 security descriptor and access token model to the Unix haphazard security model, but very clearly, the everything-is-a-file model is superior at least for remote access: it's easier to design and implement protocols for that since the protocols don't need to know anything about the remote resources' nature. Thus the Windows console cannot be exported via SSH, not without writing a layer that converts text reads/writes into ioctls, because it's not remotely file-like. That the Windows team had to and did write that layer really is fantastic news.