Slashdot Mirror
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.
I can only hope you can run a native version of Bash with a set of GNU or Posix versions of the toolset, and I can send Powershell to the shithole that horrible scripting language belongs.
The world's burning. Moped Jesus spotted on I50. Details at 11.
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.
This, friends is how you break SSH security.
You use Windows to SSH , and Windows 10 "telemetries" to Microsoft, thereby given them access to the encrypted traffic. What do you call this strategy where you fool people into initiating secure communications on an insecure device?
Entia non sunt multiplicanda praeter necessitatem.
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
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.)
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, but this dog speaks hungarian and i have no true will to learn yet another language specific for some minor platform.
so 2016 will be the year of the console on windows, a bit ironic
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.
The world's burning. Moped Jesus spotted on I50. Details at 11.
Gosh, what did we ever do before Windows 2000? Authentication by clay tablet?
It's the egocentric nature of MS's claims, that somehow computing couldn't be done without its products, that pisses me off the most. It denies an absolute vast amount of work done in these areas for decades before derivative technologies like AD even existed
Just like how Redmondites are doubtless cheering the innovation of giving Windows admins what everyone else has had for decades. This isn't a moment for pride at Redmond, but the moment when if fully recognizds just how shabbily it treated people stuck trying to do automation on its amazingly incoherent platform.
The world's burning. Moped Jesus spotted on I50. Details at 11.
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.
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
_just_ ? Try setting setting up IPA sometime. That's just LDAP and Kerberos too. Have fun...
LDAP is really easy. Well, it is for me:
From the OpenLDAP commit logs:
===
1.1.4.1 Sat Aug 8 23:05:28 1998 UTC; 17 years, 6 months ago by kurt
CVS Tags: FreeBSD_3_3; Branch: FreeBSD
Changed since 1.1: +0 -0 lines
Diffs to 1.1 (colored diff)
Import of FreeBSD LDAP 3.3 Port
---
1.1 Sat Aug 8 22:43:17 1998 UTC; 17 years, 6 months ago by kurt
Initial revision
---
1.1.3.1 Sat Aug 8 22:43:17 1998 UTC; 17 years, 6 months ago by kurt
CVS Tags: LDAP_3_3+prerelease, UMICH_LDAP_3_3, BOOLEAN_LDAP, LDAP_POSTE, LDAPworld; Branch: UMICH ; Branch point for: RAGE
Changed since 1.1: +0 -0 lines
Diffs to 1.1 (colored diff)
Import of Umich LDAP 3.3
===
See that 1.1.4.1? Those are my patches to get OpenLDAP working from UMich LDAP sources. It added about 40 platforms. OpenLDAP started with the UMich LDAP, added my patches, and then went on from there. Originals of the (120K of) patches are HERE:
http://www.freebsd.org/~terry/...
Just because something is hard for you, doesn't make it hard for the rest of us. Some of us have been doing this for nearly two decades.
For me Powershell's absurdly verbose naming scheme is as good a sign as any that Microsoft has never really understood CLI work.
Once upon a time in a galaxy long long ago there was an operating system that had batch scripting and short terse commands like: DEL, DIR, TYPE, CD, ATTRIB, COPY, ECHO... It ran on machines that had 640K of memory because that ought to be enough for anyone...
I think Microsoft did actually understand at one time but somehow that was lost somewhere along the way...
We'll make great pets