Here are some, or maybe this is not part of the NT Kernel...
1. The use of drive letters A-Z for file system access.
2. Creating symbolic links to files and folders, like you can in Unix/Linux. You have to set a setting somewhere to enable this, but there's a security risk.
3. Standard functional/usable non-gui terminal application like Unix/Linux ssh. PowerShell doesn't come close.
4. Ability to SUDO or su Admin like Unix/Linux.
Maybe these are not kernel related above, but the OS specific layer.
1. The use of a multi-root hierarchy vs. a single root hierarchy is pretty arbitrary. Drive letters in turn are just an arbitrary way to define the multi-root hierarchy.
2. `mklink` [0] has existed since Windows Vista for NTFS file system. No settings toggling required.
3. What is your argument against PowerShell? In what ways does it fall short? I have been pretty successful with using it for various tasks.
4. This is about the only legit claim. Windows always requires full credentials to execute as another user. Windows does provide `runas.exe`, but you must provide the target user's full credentials.
> 3. What is your argument against PowerShell? In what ways does it fall short? I have been pretty successful with using it for various tasks.
Powershell is an acceptable scripting language. It's a horrible interactive shell. They shoudn't have made "shell" part of its name if they weren't going to at least include basic interactive features like readline compatibility and usable tab completion.
I'm not familiar with what you mean by readline compatibility. I see a GNU Readline library with history functions, but I'm not sure what that means being integrated into a shell, and what features you would expect to see.
My experience with tab completion in PowerShell is great. It completes file paths, command names, command parameter names, and even command parameter values if they're an enumeration. Could you describe what else you would expect to see?
Powershell's completion is worthless for the most common use case of saving keystrokes. Since it fills in the entire remaining command name and cycles through the possibilities in alphabetical order instead of completing just what's unambiguous and presenting a list of the possibilities from there, it doesn't help with typing out common prefixes and if you find yourself cycling through an unreasonably large number of possibilities you have to backspace get rid of the unwanted completion (often very long, given the naming conventions) before you can refine your search.
They took a code completion technique that works alright for an IDE and put it on the command line, losing some key usability in the process when they could have just implemented the paradigm that has been standard in the Unix world for decades.
Yes, it does a great job of identifying what the completion possibilities are in almost every context. That's good enough for an IDE, but only half the job when you're making an interactive command line shell.
As for other readline features: it's really annoying to only partially implement a well-known set of keyboard shortcuts.
See, and I personally dislike the system you mention. It bugs me to no end to have only a couple options, but the system will only fill in the common prefix. Now I have to look, figure out what's there already, figure out what the next letter is, hit it, then hit tab again. If I want to save key strokes, that what aliases and symlinks are for, not tab completion.
Also, at least in PowerShell 5, if you run the ISE instead of the cmd-based terminal, it shows an IDE-like overlay of completions while you're typing.
I am fairly certain that they use the same console system. For instance, right-clicking on the title bar gives the exact same options as in `cmd.exe`. I was perhaps a little overzealous in calling it cmd-based; that's a slip-up on my part simply because `cmd.exe` was the only program to use that system before. Thanks for keeping me honest.
Both use the Windows console host, effectively what a terminal emulator is on Unix-likes. It provides the window and a bunch of other functionality (character grid with attributes, history, aliases, selection, drag&drop of files into the window, etc.).
It's just that every console application on Windows uses that host. This includes cmd, PowerShell, Far Manager, or even vi. Sorry, I may have seen it conflated with cmd too often. It just nags me. For Linux users it's probably when everyone starts calling a terminal (emulator) "bash".
https://github.com/lzybkr/PSReadLine perhaps. Personally I find it nice, but it requires a bunch of tweaking to feel comfortable, but maybe less so to people who are used to readline.
Tab completion works nicely and you can even rotate through the different values a parameter can take. Also, ctrl+space lists all the options (parameters, values, files, folders) available at your cursor's position.
I would call it something more than acceptable scripting language. It is object oriented and it can easily use C# libraries, which is pretty neat.
You are confusing the win32 subsystem with the NT kernel. They are not the same, the win32 layer acts as a translation. Also symbolic and hard links are supported by NTFS, they are just not exposed in the UI. There are utilities to create them if you really want to.
The shell itself and the rest of userland has very little to do with the kernel. It seems its the userland you are upset with. Swapping out the kernel won't fix that.
For some values of well. If you logon interactively and start a powershell session, you do not have administrative powers and cannot get them without opening a new shell. If you logon via PS remoting, you have administrative powers by default and cannot lose them.
UAC is a GUI kludge, and is very grating especially in Powershell.
My biggest pet Peeve about Windows is the way it accesses files I'm not sure if this is a kernel or filesystem issue. But when a remote user has a file open as long as that file is open other users are prevented from updating or replacing the file. It happens all the time at my work and I know of no obvious way to work out who has the file open because as far as I can tell nothing like lsof exists.
This is probably the number one cause of me banging my head against the desk and wishing Windows behaved more like Linux.
What you can do while it's open is partially defined by the dwShareMode parameter in CreateFile. Unfortunately a lot of people look at the daunting documentation, shrug, and put 0 there, which is the least permissive mode. A lot of libraries do that too.
OTOH there are other limits that are not dictated by dwShareMode. Such as deleting files while handles are open - this blocks a new file with the same name from being created until all handles are closed. That's probably the worst one. There are some other crappy ones involving directory handles that I don't care to enumerate.
2. Filesystem feature, supported by NTFS for quite a while in differen styles. It has a security policy because a lot of userland software doesn't know about them. I use them all the time and they work, even if you move things like /Users/.
3. Userland issue. You can compile bash and an ssh server for Windows if you want. PowerShell is quite different, yes.
> 1. The use of drive letters A-Z for file system access.
Why is this a problem? As a user, I've always preferred to have drive letters - it makes it immediately clear if, for example, I'm moving files between different physical drives.
Considering mount points, reparse points, and things like subst, I doubt you can ever really know that. Granted, the deviations from the normal scheme are your own making as a user, but so are the places where you mount volumes from different physical drives in a single root hierarchy.
Curious why you claim this? What's outdated about the NT Kernel?