Windows 10 Gets Core Console Host Enhancements (nivot.org)

x0n writes: As of Windows 10 TH2 (10.0.1058), the core console subsystem has support for a large number of ANSI and VT100 escape sequences. This is likely to prepare for full Open SSH server/client integration, which is already underway over on github. It looks like xterm is finally coming to Windows. OpenSSH was previously announced (last year) by the very forward-looking PowerShell team. The linked article provides some context, and explains that the console host isn't the same as either cmd.exe or powershell.exe, but there is a lot of overlap in functionality.

Comments

News for Nerds

[Anonymous Coward]

Is it just me, or is this actually news for nerds?

So Let Me Get This Straight

[MightyMartian]

So let me get this straight. Windows is getting the kind of terminal support *nix has had for nearly 50 years? Wow, I mean, how fucking innovative of MS.

Fuck fuck fuck.

Re: So Let Me Get This Straight

[mattcoz]

Why does it have to be innovative to be a good thing? Should they just not do it if it has already been done by someone else?

Re:So Let Me Get This Straight

[fnj]

I just have to ask all you clever little MS types. As Microsoft moves Windows Server closer to a CLI-based operating system, what exactly is the point of Windows now, other than, I suppose Exchange?

Exchange Server is one of the killer points, yes. The other one is Domain Login with the attendant domain-wide security model. As a *nix booster, I must say those two continue to absolutely show up *nix to this day. Those two give more than enough of a "point".

Re:So Let Me Get This Straight

[Anonymous Coward]

This is actually a pretty big deal. Stolen from this post by a ReactOS developer:

why is command prompt so, command prompty i guess

it all goes back to a terrible, terrible architectural choice they made way back in Windows NT 3.1

Win32 consoles are implemented in user mode. god knows why simple, safe consoles are a user mode thing, while a ton of badly written GUI poo poo was violently forced down kernel mode's throat, but they probably hoped that text consoles were going to be a fad? nevermind. this alone wouldn't be an issue, in fact if anything it would make providing multiple implementations of console windows very easy, but they had to double down on the awful, and make console windows run in the user-mode part of the win32 subsystem (basesrv.dll), which runs in a hyper-privileged process, csrss.exe. how privileged?

* the system is immediately shut down with a fatal hard error if it terminates. regular hard errors (like "put the floppy back in, idiot", "executable imports non-existing function from dll", etc.) are passed from kernel mode back to csrss.exe, which turns them into message boxes (when you use MessageBox with the MB_SERVICE_NOTIFICATION flag, you are actually raising a STATUS_SERVICE_NOTIFICATION hard error); they are even interactive (you surely remember the infamous abort/retry/ignore), as in the thread that raised them is blocked waiting for your answer. the caller can even be a kernel mode driver (see IoRaiseHardError). fatal hard errors (passing OptionShutdownSystem to NtRaiseHardError/ExRaiseHardError) on the other hand can't be sent to anyone and result in an immediate shutdown (pretty fast because only drivers are notified, user mode processes are just killed) followed by a bugcheck. so technically it's wrong to say that terminating csrss.exe causes a BSOD because a BSOD is instant, while when you kill csrss.exe you can e.g. hear the disks flushing. little known fact: before Windows XP, crashing on termination of a critical process wasn't a kernel feature; instead, the startup process (smss.exe) would wait for the termination of csrss.exe and winlogon.exe, and hit you with a hard error if it ever returned from the wait. you'll notice a flaw: nobody watches the watcher (kernel don't gaf). you could totally kill smss.exe and then csrss.exe without a BSOD. back then, the debugging APIs were implemented in user mode for some loving reason, and for an even more inexplicable reason they were a RPC API and smss.exe was the server end, so killing smss.exe would have no visible effect, except breaking debugging until a reboot
* it has direct access to the real-mode address space (lowest 1 MB of physical address space), in fact it's mapped at virtual address 0 and everything. csrss.exe doesn't actually use this, it's a hack for calling the VGA BIOS from video drivers. the driver framework attaches to csrss.exe to get its address space (virtual address 0 is in the user mode range, and kernel processes like System have no user mode virtual memory range, so you need to attach to a user mode process for that) and then I have no idea what happens because I've never done VGA. there's a special flag to RtlCreateUserProcess (low level no-Win32 equivalent of CreateProcess, used to start winlogon.exe, csrss.exe, etc. you can tell a process has been launched by RtlCreateUserProcess instead of CreateProcess because its command line will include the full object namespace path, e.g. \??\C:\WINDOWS\System32\winlogon.exe), RTL_USER_PROCESS_PARAMETERS_RESERVE_1MB, whose entire purpose is to reserve the lowest 1 MB of virtual address space in the target process so that stacks, heaps, environment, etc. will be allocated somewhere else and win32k.sys can map the real-mode address space there (how do you allocate memory at address 0? just pass (PVOID)1 as the desired address to VirtualAlloc/NtAllocateVirtualMemo

Re:So Let Me Get This Straight

[Sarten-X]

The same as it's always been... full integration with the entire line of business-oriented Microsoft products (including Exchange) and support for the vital third-party software that requires Windows.

For many years, Microsoft's business model has been to promote a Microsoft-centric universe. If you use Office, you'll get the best service with an Exchange server, which must run on Windows Server, and really needs Active Directory, which supports your Windows workstations, which integrate with Office. It's not just that Windows is a GUI-based OS. Microsoft products are a part of a whole tangled mess of dependencies, and for years we've been stuck dealing with the downside of that glorious integration.

Every IT admin has a story about the vital business process that involved a human robot. Every day a human logs in, and runs an Excel macro to generate a spreadsheet, that he saves as a CSV file and loads into a third-party program, which generates a RTF document, that needs to be renamed to .txt and moved to a different folder for another program to find and render into a PDF, which the human has to open and read the third line on the fifth page to determine which managers need the report emailed to them. This is a GUI-based process, because the software runs on a GUI-based OS. It can't be automated, because the software doesn't support it. For decades, automation has been a "nice to have" feature, because it never fit into the Microsoft business model, so there was never a good framework to support it built into Windows.

Sure, we had some old tricks... Batch files, DDE, COM, OLE, WSH, VBA... but they never really enjoyed full support from Microsoft. They were supported features, but not supported enough that third-party vendors would feel pressure to support any automation.

Now, with PowerShell and the Core offering of Windows Server, there's the notion that everything should be able to be automated. Sure, we've had that idea from the very first days of Unix, and *nix has embraced the concept to maturity, but *nix still doesn't run every piece of business-critical third-party software. For those of us who are already firmly entrenched in that Microsoft-centric world, this is a much-needed good omen.

Re:So Let Me Get This Straight

[tlambert]

Exchange Server is one of the killer points, yes. The other one is Domain Login with the attendant domain-wide security model. As a *nix booster, I must say those two continue to absolutely show up *nix to this day. Those two give more than enough of a "point".

Both Mac OS X and RedHat Linux have answers to both domain login and domain-wide security. The Linux implementation is somewhat less robust (i.e. it's possible to escape exclusion groups, and there's no external group membership resolver like there is on Mac OS X, so there's still the 16 group limit), but it at least is a proof by existence that the claim is wrong. And you can always install the Samba implementation manually on any Linux or BSD box.

If you want to get technical, had Windows not added the proprietary field, we're just talking a KDC implementation, as in Heimdal Kerberos, or before that, MIT Kerberos, and that's been around since Project Athena, which means early 1980's, which means over 30 years. Microsoft's implementation was 1995 or so, and it was the late 90's before they made it non-interoperable with the proprietary field, so they are predated by at least a decade.

Kerberos was interesting, in that it abused the setgroups() and cr->ngroups to store the Kerberos key in the last two groups field, but at that point you were not really using groups anyway (since you were using remote Andrew FS or similar, and it was doing server side credentials enforcement).

So TL;DR: they absolutely did not, and do not, "show up *nix".

Re:So Let Me Get This Straight

[realmolo]

Full integration with Active Directory, for fine-grained permissions over all aspects of the mail/calendar system.

For example, with Exchange and AD, I can create a distribution group, and delegate "ownership" of that group to a specific user, so they can add/remove users to that group. I can set that group to "open" or "closed", meaning users can either join it/leave it without owner approval, or not.

I can give an arbitrary user access to another users entire mailbox, or give them only permission to "send as" a different user, or distribution group.

I can allow only certain users to send to specific addresses, meaning I can have a "My Entire Company" distribution group that only specific people can send mail to.

And then there are similar permissions/delegation options for calendars, and Public Folders, and even Skype for Business. If you have VoIP phone systems, and compatible phones, you can even access all of your mail/calendar/Skype messages from your phone.

I can set deletion and archive polices for each user, or a group of users. I can set mailbox size limits per user, or per group. I can create a "discovery search", meaning I can allow access to a user's mailbox, but only for mails that meet a specific search criterion.

And of course, there is a cottage industry of add-ons for Exchange to do a million other things. Mimecast, for example, allows automatic off-site archiving of all email (with an Outlook plugin to search the mail), and automatic failover to Mimecast's servers if Exchange goes offline.

It's just endless. Exchange has no real competition. Is it perfect? No. But it's better than anything else for corporate messaging, by a wide margin.

Pooh-Pooh all you want. This is great news!

[slacka]

For those of us that have no choice but to manage Windows and *nix boxes, it's a pain in the ass to have to context switch between RDP and ssh'ing. This will make our job much easier. Between all the open source software, github, and stuff like this, I love the new MS. Of course our real servers will always run FreeBSD.

Re: Turd

[spectrum-]

Powershell has some great features and ideas. And whilst it can be great to script in, it is very long winded to just type and use in an adhoc fashion. Sure there's aliases but its still a bit tedious.

The other thing power shell needs is more social interaction and perhaps just a bit more fun. I guess it's still quite new and evolving. Bash is ancient relatively speaking.

I'd like to see stuff like figlet, write, wall, mutt natively in powershell so it becomes more of a destination than a mere dull workhorse of productivity.

Re: Turd

[Ol Olsoc]

I'd like to see stuff like figlet, write, wall, mutt natively in powershell so it becomes more of a destination than a mere dull workhorse of productivity.

Be patient - they have to get the keylogger working correctly first.

Pity there isn't a -1 ; Conspiracy Theory mod

[Sycraft-fu]

Slashdot needs ones. Seriously, for a community that claims to hate FUD, the OSS types sure like spreading it when it is about the "right" groups. If you actually care about what kinds of things the telemetry communicates back at various settings, the information is all out there for you. No, SSH data isn't one of them. However I am going to imagine you don't, and this is just crap you want to fling at "the bad guys" because you can.

Also a thought for you: Your OS, by definition, has access to anything any program on the system is doing. What would stop it from looking in at any 3rd party SSH server you ran, if you think it does that?

Re: Turd

[ArmoredDragon]

I've done a lot of neat stuff with powershell, for example I created a powershell script that gathered information about one system (using the Get-WmiObject Win32_SystemEnclosure to retrieve i.e. a computer's brand name, serial number, bios version, etc) and opened a TCP socket to feed that information to another system across the network that had a listening server which was also written in powershell.

But yeah, it totally violates the KISS principle. It's hard as fuck to look up certain information about the system because the way it's stored and retrieved is almost never intuitive (for example, you literally have to generate an XML file and then parse said file in order to get some stuff.)

It's also very hard to figure out how to do something you might not have done before, or have done very rarely, because the command names are so long that they're difficult to remember. There are shorter aliases, but they don't have any consistent naming (for example, Get-WmiObject can be shorthanded as gwmi, whereas a command like Add-PSSnapIn is shorthanded as asnp) making them also harder to remember.

I would much rather just have bash, and do that server stuff I did with tools like netcat, which although uses a separate binary, is FAR simpler than the method I used with powershell, while also having tools like dd to be able to manipulate binary blobs, and dummy block devices like /dev/zero, /dev/random, and even the ability to directly read/write to hard disks as if they were ordinary files.

If Microsoft did that, and had a good package manager for command line tools with the ability to add third-party repositories (like aptitude does) with options to compile from source (like portage does) I might actually consider using it for servers now and then. But because it doesn't, I only use it for servers either when an application requires it (as in, no Linux version available, but this is quite rare for applications meant for servers) or for active directory (also only occasionally needed.)

Re: Turd

[MightyMartian]

What do you mean no rhyme or reason? The basic toolset; cat, sh, mv, rm, and so forth are mnemonics. The point being to make the commands as short as possible while retaining some semblance of meaning. For me Powershell's absurdly verbose naming scheme is as good a sign as any that Microsoft has never really understood CLI work.

but why ?

[steveoc]

Not sure why anyone would care ... the whole "Windows 10 experience" is such a horrific platform to try and do any work done on ... fixing the shell is a noble step indeed, but there are so many other show stoppers on that system, that its just a drop in the ocean.