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.
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.
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.]
> 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.
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. :\
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.
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.
> 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".
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.
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.
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.
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 :)
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.
You can do stuff like putting callbacks on a handle to do async-io when you have a pointer to work with.