Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
Windows Microsoft Software

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

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.
This discussion has been archived. No new comments can be posted.

Windows 10 Gets Core Console Host Enhancements

Comments Filter:
  • News for Nerds (Score:5, Insightful)

    by Anonymous Coward on Saturday February 06, 2016 @06:21PM (#51454709)

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

    • Stuff that matters (Score:3, Informative)

      by Anonymous Coward
      This [slashdot.org] is.
    • Re: (Score:2, Interesting)

      by Anonymous Coward

      nerds have already cygwin, msys or something like that. nerds needed this functionality so long that they actualy resigned reminding m$ that terminal is a not a dirty word.
      to paraphrase: a good console is like a good dog - very rare. a good console with a good language is like a dog speaking norwegian,sir - even rarer. i am mentioning this because in windows 10 they actually got cmd.exe so much better, but the underlying bat language feels like yesterday's vomit. i guess, that's where powershell comes in, b

  • by MightyMartian ( 840721 ) on Saturday February 06, 2016 @06:29PM (#51454733) Journal

    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.

    • by mattcoz ( 856085 ) on Saturday February 06, 2016 @06:45PM (#51454807)
      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?
    • by Anonymous Coward on Saturday February 06, 2016 @07:11PM (#51454893)

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

      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

      • by Hadlock ( 143607 )

        Holy hell, someone mod parent up, please.

        • by Hadlock ( 143607 )

          Tons of interesting stuff in that link, totally off topic, but details about rewriting win32 kernel with full unicode support as a realtime OS for Windows CE:

          I do in fact know a little about Windows CE! from what I remember, it's a much simpler, cleaner design. its Win32 is a rewrite of a subset (for one: Unicode only, no ANSI), and the kernel is a hard realtime microkernel with some cool, unique features: for example, inter-process calls temporarily moved the calling thread to the server process, no roundt

    • So let me get this straight. Windows is getting the kind of terminal support *nix has had for nearly 50 years?

      No, Windows has had the kind of terminal support for years, it is just been their own implementations. The difference now is that they are now using the same particular protocol as the *nix world. In other words, they are going from the kind of terminal support to the exact terminal support.

      • Windows had a Telnet server, to be sure. But you had to be pretty damned careful as to which commands you used. We did play around with Cygwin's bash script running in a TTY on Windows 2000, but it was clunky and slow (like everything in Cygwin was, and maybe still is, I dropped it years ago). In the end it just wasn't a very good CLI-based management platform because 1. there was no good native pure CLI-based toolset to administer a system, 2. no good TTY based text editor, and 3. it was bloody Telnet, and

        • by mlts ( 1038732 )

          The Telnet server required an Expect script to use... and yes, you -can- do stuff that way... but it is a relative PITA compared to ssh, Python libraries, and Ansible. As the parent said, sending unencrypted passwords through a link (yes, one -could- do tunnels, but that is another bunch of hoops) was possible... but with SSH (especially with RSA authentication), it is far, far easier.

        • You are right that Telnet is not much use and very insecure, but it was not the only option for remote access.

          Windows has also had Terminal Services (later Remote Desktop Protocol) since Windows NT 4.0, although it required a special server version. Windows 2000 Server had it in standard configuration, and Windows XP had it by default in workstation versions (except for the Home edition). XP also had the WSHContoller object for running Windows Scripting Host scripts remotely, but that was not much use for a

          • So essentially it took until 2009 for Microsoft to even begin to admit that RPC, a few rather crappy scripting host options and RDP were inadequate, but it took them over six more years to finally implement what is pretty much the gold standard of encrypted TTY interfaces.

            Maybe this is part of the turning over a new leaf, but I can't help but imagine that the next version of Microsoft's coursework will announce how innovative all of this, much as it went around declaring how innovative Powershell was, when

            • by Gadget_Guy ( 627405 ) on Sunday February 07, 2016 @08:58AM (#51456521)

              So essentially it took until 2009 for Microsoft to even begin to admit that RPC, a few rather crappy scripting host options and RDP were inadequate, but it took them over six more years to finally implement what is pretty much the gold standard of encrypted TTY interfaces.

              No, they have never stated that their previous technology was inadequate. They are just providing yet another option to their existing solutions. That you think that SSH is the one-and-only answer shows your biases rather than demonstrates any admissions of inadequacy by Microsoft.

              Maybe this is part of the turning over a new leaf, but I can't help but imagine that the next version of Microsoft's coursework will announce how innovative all of this...

              There is no way that they will attempt to claim that they invented SSH. Apart from being so easy to disprove (and thus ridicule), it would also go against the current Microsoft policy of working with standards.

              ...much as it went around declaring how innovative Powershell was, when all it really is is an overly complicated descendant of Bash, inelegant, overly verbose and unnecessarily convoluted.

              Once again you have let your hatred and obvious lack of knowledge get the better of you. The basis of Powershell is that it treats everything as an object and is integrated with .NET so that it has access to virtually the same class structures that low level languages have. How it that being a descendant of bash? As you say, it has a verbose naming scheme for its commands and functions. How is that being a descendant of bash? Sure it has aliases to allow common *nix commands, but it also has them to allow CMD.EXE commands too. They are simply there to provide convenient shortcuts. Apart from those helpful aides, everything about Powershell is all its own.

              I just hope all the Redmondites see the irony of MS sitting around for two decades declaring NT's superiority because, you know, Windows and all, and now essentially reinventing, badly in many cases, what the Unix ecosystem has had for decades.

              For someone who thought that the only remote access that Windows had was telnet and that Powershell was a copy of something that it is almost completely unlike, I think that you need some more education before you can lecture anyone about the shortcomings of Windows.

    • Wait till you find out they'll actually let you resize the terminal window.
    • Well, I think they've decided to finally be useful to developers.

  • by slacka ( 713188 ) on Saturday February 06, 2016 @06:32PM (#51454753)

    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.

    • SSH and docker support will get the MBA types who fear change and spending cash to consider Server 2016.

      I would rather MS innovate than to just EOL good products instead.

      SSH support will go everywhere including the MMC SNMP tools and not just powershell for remote work. FOr any organization with security in mind this will be a HUGE reason to upgrade. Sadly, since Server 2016 is already in preview 4 I doubt this will see hte light of day on that release. It will be 2018 with Server 2016 R2 before we see SSH

      • by guruevi ( 827432 ) <[evi] [at] [smokingcube.be]> on Saturday February 06, 2016 @09:12PM (#51455271) Homepage

        But why in the hell do you want to shell out thousands of dollars on Windows Server ($6k or so to run unlimited virtualized environments?) for something that runs perfectly fine on (free) Linux.

        • Because Microsoft!
        • tools and management. The licenses are a pittance compared the cost of the hardware and the peoples time running them.
        • It is $6,500 plus per core cpu costs for VMWare. Hyper-V comes free with the server license

        • by AmiMoJo ( 196126 )

          Because $6k is s small change compared to the cost of a few admins familiar with Linux. There are far more admins familiar with Windows, so you can pay them less, so your $6k is saved in a few months max.

          Oh, and there is the option to move your virtualized servers into the cloud. Microsoft makes it really easy to migrate, or just buy extra capacity from Azure. I'm sure there are people offering something similar for Linux, but you can bet it's not as good.

      • by Hadlock ( 143607 )

        It's probably an R2 feature, so right, 2018. I can't possibly see them shoe horning something as foundational as SSH in to Windows at the last minute and expecting it to be secure and with low overhead.

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

      Remote shells for Windows have been available for decades. Hell I remember telnet server was included with NT net tools a lifetime ago. A lifetime before that directing command interpreter thru modem ports.

      Multiple vendors offer ssh servers for windows and all of the unix shells have been ported to windows. Anyone who really wanted one would already have one.

      This will make our job much easier. Between all the open source software, github, and stuff like this, I love the new MS.

      You mean the Microsoft that thinks it owns the users computer and can force spying and updates on people unwittingly and or against their will? Yea

      • by slacka ( 713188 )

        Remote shells for Windows have been available for decades. Hell I remember telnet server was included with NT net tools a lifetime ago. A lifetime before that directing command interpreter thru modem ports.... Anyone who really wanted one would already have one.

        Remote shells? Yes! But SECURE, Remote shells? They have never had that built-in. I don't think you realize what a bad idea it is to communicate with you company's servers over plain text. And VPNs aren't always an option. I can always get ssh through, but I've been on plenty of networks that block VPNs. Not to mention needing additional VPN software and hardware key fobs. Give me pure ssh any day!

        • by Gadget_Guy ( 627405 ) on Saturday February 06, 2016 @08:29PM (#51455149)

          Remote shells? Yes! But SECURE, Remote shells? They have never had that built-in.

          Powershell's remote shell is secure [technet.com], and that is built-in to Windows.

        • Remote shells? Yes! But SECURE, Remote shells?

          Everyone used telnet at the time.

          They have never had that built-in. I don't think you realize what a bad idea it is to communicate with you company's servers over plain text.

          As I said in the text you didn't bother quoting multiple vendors offer ssh servers for windows. Anyone who wants ssh access to windows already has it. What does it matter if it is built in or not?

      • You mean the Microsoft that thinks it owns the users computer and can force spying and updates on people unwittingly and or against their will? Yea real swell...

        That would be the Microsoft that lets you pay for the system, then purports to rent it back to you, hoping you'll not notice, yes.

  • Still running the general release 10240 build.

    Allegedly there was some November update that was aborted.

  • I needed that functionality on Win 7, along with other tools.

    Dropped Cygwin onto it, and it works pretty well.

    http://cygwin.com/ [cygwin.com]

  • I applaud them finally embracing a sensible remote shell strategy. I recall many heated debates where MS would say all sorts of nasty things about ssh.

    However, I can't say that implementing decades old terminal function and ssh is 'forward looking'.

    • by arth1 ( 260657 )

      Didn't they already do this, though?
      I seem to remember that Microsoft Services For Unix (SFU) had an optional ssh component too.

  • but why ? (Score:5, Interesting)

    by steveoc ( 2661 ) on Sunday February 07, 2016 @03:32AM (#51456037)

    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.

    • Like?

    • Why? Putting all the privacy shit aside I don't see Windows 10 any different for getting work done than Windows 7. Both of which have the edge over Vista with better window handling.

      There's a lot of things to complain about on Windows 10, getting work done on it is not on that list.

  • Fifteen mentions of Windows on the front page. Is this how slashot is going to re-connect with the technology sector?
  • OpenSSH came out in 1999. We are now in 2016. Which means Windows in 17 years behind the curve. When OpenSSH was available for BSD Windows ME was the new hotness and Windows 2000 did not exist yet, never mind XP and 7.

    What part of "Forward" am I missing?

    • by Ash-Fox ( 726320 )

      I've had OpenSSH running on Windows for many, many years now. I don't know what your problem is?

  • by simpz ( 978228 ) on Sunday February 07, 2016 @09:30AM (#51456611)
    When Windows NT first made an appearance all the Unix people were told your obsession with terminals is so outmoded that we haven't put support into NT.

    I think the Unix guys are getting the last laugh...
  • If it is feature-ful enough to complete with the 3rd party terminal clients companies could save a lot of money when they migrate to windows 10.

I have never seen anything fill up a vacuum so fast and still suck. -- Rob Pike, on X.

Working...