[filereaper]

I found it kinda cool that the foundational difference between Unix and Windows is that Unix returns file-descriptors whereas Windows decided to give out handles.

You can do stuff like putting callbacks on a handle to do async-io when you have a pointer to work with.

[int_19h]

What's the difference between file descriptors and handles? Both are just opaque numeric identifiers. There's no particular reason why there can't be an API to associate a callback with a file descriptor for async I/O.

[asveikau]

There is no huge difference.

One small detail is that HANDLE covers more things with the same table. So for example, a process, a thread, a cross-process semaphore or mutex - those are handles, whereas Unix-like systems have different types for each of those (pid_t, pthread_t, sem_t, etc.).

But then Linux started introducing fds as synchronization primitives too - like signalfd(2) or eventfd(2).

One of the more annoying things about Windows handles is there is no equivalent of dup2(2) - you can't swap the kernel object of an existing HANDLE with another existing HANDLE. This makes imitating certain unix idioms involving redirecting I/O after the process has already started kind of clumsy.

[Worth noting in a discussion of the HANDLE typedef that the type is literally a void pointer, and some user-mode code abuses that to make them pointers to heap objects instead of a proper kernel handle - for example FindFirstFile()'s handle is not a true kernel handle, which is for example why you need to close it with FindClose and not the normal way to close handles.]

[cesarb]

> What's the difference between file descriptors and handles? Both are just opaque numeric identifiers.

The main difference I know of is that file descriptors are sequential, while handles are random. That is, a function like open() will always return the lowest-numbered available file descriptor, while CreateFile() can return any available handle.

Other than that, both are basically identical as far as I know: both are just keys to an in-kernel table which points to the real object.

[int_19h]

> The main difference I know of is that file descriptors are sequential, while handles are random.

Is it an API guarantee, or just an irrelevant implementation detail?

[cesarb]

For file descriptors, API guarantee, specified by POSIX: http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2...

"[...] atomically allocate the lowest numbered available (that is, not already open in the calling process) file descriptor [...]"

[k__]

Did PowerShell really catch on?

Was this difference so good that it was incorporated on other platforms?

I really liked the idea of the PowerShell, but somehow it felt to me that it never really became "a thing" and the Windows Subsystem for Linux move from MS felt like they gave up on the whole shell thing in the end. :\

[MandieD]

It caught on very strongly in the Windows platform operations community - those of us who run Exchange, Active Directory, Windows Server in general for large enterprises. These businesses are just starting to poke at the cloud a bit, and will still have a lot of "traditional" Microsoft infrastructure for several years.

We're generally not as publicly chatty as developers, and don't tend to do Windows platform admin as a hobby. We have varying levels of programming experience.

For us, PowerShell has been nothing short of miraculous, though some people are put off by anything that's not a GUI. It's a shallow initial learning curve and easy enough for semi-automating some very repetitive user management tasks. The more skilled scripters can switch pretty easily into C# once they need the performance, because they already understand the .Net framework from mucking around with it in PowerShell.

And if you're ever at a small conference where Jeffrey Snover is speaking, say hi - he's generally eager to talk with PowerShell users.

[orev]

Never became a thing? You're talking like it's already done and abandoned. You need to recalibrate your perspective to longer timelines. Every release of Windows server removes more and more of the GUI, and nano server can only be setup using powershell commands. MS is completely all-in on this and the WSL is not going to replace it by a long shot.

[k__]

The "removing more and more GUI" part already felt like MS would jump on the Unix/Linux train and abandon their "all can be done via GUI" philosophy.

The PS and WSL story seemed like they tried to do better but gave up.

But what can I say, I'm no Windows guy, just talking from an outside view :)

[electricEmu]

> The PS and WSL story seemed like they tried to do better but gave up.

The PowerShell story is pretty simple: a cross-platform, object oriented shell. Having used it, I attempted to locate a similar Linux solution, to no avail. I'm tired of cutting text and object translation makes my life a great deal more straightforward.

As for WSFL, it seems "Windows can run everything. Docket support is stellar" is a much more likely story than "we gave up and are slowly becoming Linux with a GUI".

[oblio]

They're working on the Linux solution bit: https://github.com/PowerShell/PowerShell

[throwaway7645]

In my small experience no. Linux is super powerful. It is darn simple to pipe commands to each other and always know the output is text. Powershell passes .NET objects, so even if you think you should be able to easily pass the output from one command to another, in reality it doesn't work out nearly so well and puts a lot of cognitive load on me for even simple things. For complex things, the language is much nicer than BASH, but that is irrelevant as most people aren't using BASH for the complex stuff. I use the full range of Linux commands for simple stuff and use Python or Perl for the more complex stuff. I really want to like PS and have put a lot of time into it, but in the end I only see it filling the role of someone scripting the deployment of user permissions and server configurations. So it is great for a very small subset of IT work, but doesn't give the user the power over general OS use like Linux does.

[michel-slm]

For something in-between the two the Xonsh shell might be nice. It's basically a Python-based shell with full access to Python for scripting purposes.

I like Bash but writing anything remotely complex in it is... not recommended

[throwaway7645]

I'll have to check it out, but usually for the easy stuff, the standard commands like grep + Awk is more than enough.

[TomMarius]

CMD is for simple things, PowerShell is made for complex things.

[throwaway7645]

I disagree. CMD can't even do simple things. Sure it can list the files in a directory and write that to a text file, but not much more. I'm exaggerating some, but CMD is so underpowered compared to what you get in any Linux terminal that this isn't a fair comparison.

[TomMarius]

Of course it is underpowered compared to what Linux offers. The main point is that Powershell isn't designed for Bash-like scripting.

[throwaway7645]

I'll cede that. So Windows really has no way for the user to do things easily though. There is no middle ground between CMD & Powershell. I think they could fix that by putting in all the Linux commands people care about and make it easier to return the object as text without writing a novel. The aliases are only helpful if they can still pipe like Linux.

[ZenoArrow]

> "Did PowerShell really catch on?"

Yes, it's very popular with Windows sysadmins, which is more or less who it was designed for.

[k__]

I see, guess I simply didn't meet much windows admins :)

[MandieD]

Windows admins and web/mobile developers move in different tech circles. I didn't know very many web/mobile developers before switching to a team of Java, Node and front-end developers. I'm amazed at what they don't know about working in an old-school, Microsoft-heavy corporation.

This included the object-oriented nature of PowerShell. The ones who have fully accepted that it is a command line wrapper for .Net like it way better than they did when they were trying to use it as a crappy version of bash.

I, on the other hand, routinely astound them with my ignorance about the brave new world of build tools that assume that you have constant access to the internet (among many other points of my ignorance).

I'm now trying to get re-accustomed to Unix-style command line tools, and it's irritating as anything not to be able to ().somepropertyname to get exactly what I want :)

[nunez]

Yeah it really did! Most of their server offerings are PowerShell first. Server Nano and Core are managed with PowerShell over WinRM. PowerShell Desired State Configuration has been growing in popularity over the last few years.

It hasn't really taken off outside of Windows. Unless you're in a mostly Windows environment, PowerShell on the Mac or on Linux doesn't make a lot of sense.