[l3m0ndr0p]

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.

[jdmichal]

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.

[0] https://technet.microsoft.com/en-us/library/cc753194%28v=ws....

[mmebane]

> `mklink` [0] has existed since Windows Vista for NTFS file system. No settings toggling required.

There are several limitations in the Windows/NTFS implementation, however:

1. You have to specify the target type (file or directory) at link creation time.

2. Creating symbolic links requires either being an Administrator user, or having the "Create symbolic links" group policy enabled for your account.

3. No real directory hard links. (EDIT: For some reason, I forgot that Linux doesn't have these, either. Maybe I was thinking of bind mounts.)

[dsp1234]

3. No real directory hard links. Junction points are close, but still distinguishable from

Windows isn't the only OS that disallows creating directory hard links.

http://askubuntu.com/questions/210741/why-are-hard-links-not...

[mmebane]

Huh, I wonder why I misremembered that. Thanks for the correction.

[wtallis]

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

[jdmichal]

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?

[wtallis]

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.

[jdmichal]

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.

[ygra]

> if you run the ISE instead of the cmd-based terminal

PowerShell depends (or is based) in no way on cmd.

[ygra]

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.

[NetStrikeForce]

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.

[tubs]

a) That's nothing to do with the kernel.

b) http://mridgers.github.io/clink/ is bloody fantastic.

[asveikau]

> 1. The use of drive letters A-Z for file system access.

NT has a root directory like Unix does. Drive letters are symbolic links inside a directory called \DosDevices.

Granted, this is not user-visible but an implementation detail. The needs of Win32 applications dictate a lot of user-visible behavior.

> 2. Creating symbolic links to files and folders,

NT supports symbolic links. Open cmd and type "mklink".

[slededit]

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.

[sz4kerto]

None of these are kernel-related.

You can create hard and soft links. PowerShell is great, just different. UAC is not sudo, but works very well. It's a different OS.

[tremon]

UAC is not sudo, but works very well.

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.

[bigger_cheese]

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.

[asveikau]

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.

[JdeBP]

> I'm not sure if this is a kernel or filesystem issue.

It's neither. It's a common misconception. See https://news.ycombinator.com/item?id=11415366 .

[pjmlp]

Sane OSes don't let people modify files without permission from other users.

Windows isn't the only OS having file locking implemented at kernel level.

[wfunction]

> or maybe this is not part of the NT Kernel

> 1. The use of drive letters A-Z for file system access.

Indeed it is not. The kernel sees a single root for the object namespace, not drive letters.

[detaro]

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.

4. exists, both in GUI and commandline.

[UK-AL]

A-z drive letter is just a win32 thing.

Symbolic links is supported by NTFS, just not exposed to normal users.

That's just your opinion about powershell...

UAT, and runas?

[stordoff]

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

[ygra]

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.

[yread]

4. Shift+Right click or CPAU http://www.joeware.net/freetools/tools/cpau/ for command line