[xl]

[Disclaimer: I work for Microsoft.]

As far as I recall, the original impetus behind what became PowerShell (as handed down to us in a conference room by Ballmer himself, sometime around 2001) was to fill the gap between ops people who did enterprise administration manually with tools like MMC and engineers who automated enterprise administration with tools like C++/DCOM. The latter were necessary in a lot of cases, but they were expensive, and we needed to give the industry a way to do powerful automation without hiring a bunch of PhDs. So, yes, someone did ask for it - the IT industry.

[scurvy]

I was part of the Hotmail team which consisted mainly of Solaris admins trying to mass administer a giant number of Windows servers. We kept pleading with the Windows team and upper management (forgot who it was at the time, Raikes?) to give us a powerful shell and ssh on Windows. We ended up licensing FSecure's ssh daemon for windows. We also used cygwin, too.

[thoth]

>forgot who it was at the time, Raikes?

It was Allchin when I was there... about that era.

[robotresearcher]

> So, yes, someone did ask for it - the IT industry.

... who couldn't use the well-known mature shell tools since they were locked into a closed platform, and Windows' cmd.exe was comparatively very weak.

[Someone1234]

It wasn't cmd that was the problem (although, it is weak); it was how Windows exposed APIs to allow automated solutions.

You had two options: VBScript (which is a glorified COM+ agent) or a "real" programming language like VB6/C# which mixed COM+ with Win32 API calls (which are too hard to use for most non-programmers).

Powershell within itself does improve CMD. But that isn't primarily how PS pushed Windows automation forward, Microsoft said that every major server feature and server function should work in Powershell, so engineers at Microsoft had to look at it (be it their lacking COM+ interface, provide a new PS interface, or something else).

The net result isn't that CMD got replaced by something better. It is that we have a lot more APIs and ways of interacting with Windows features and services than we ever used to.

The ironic thing is that today you could write MS Dos-style console applications that work in CMD which provide all of this new automation functionality because of the Powershell push. Back before Powershell you'd have to hack it using unsupported APIs, registry entries and similar.

[flukus]

> Powershell within itself does improve CMD.

Kind of depends on how you define improved. I find powershell slow enough that I usually still use cmd unless I'm dealing with a powershell script.

[toyg]

If all this API effort had gone into a real cross-platform language (Python, Ruby, or even Perl which was king in 2001), Windows would have flourished. They went for their traditional lock-in approach instead, so now they have to catch up.

[jjnoakes]

Windows did flourish...

And are you suggesting that Perl would have been a better solution for a Windows interactive shell and automation tool?

Are you going for the more readable argument? Or the more strongly typed argument?

[toyg]

> Windows did flourish

Late reply, sorry. I don't think we're on the same page: Windows sold relatively ok, basically doing tying the battle for the Enterprise sector, but in the meantime it lost the cloud war and was literally wiped out of several other segments (mobile, web etc). But don't take it from me: if everything were hunky-dory, they wouldn't be busy steering like crazy towards opensource, something that was unthinkable 15 years ago.

> are you suggesting that Perl would have been a better solution for a Windows interactive shell and automation tool?

From a mindshare/commercial perspective, yes it would have been (and I say this as a complete Perl-hater). By starting from scratch, MS then had to spend a decade evangelising their new solution, with mixed results. It would have been tremendously easier to just offer first-rate support for established sysadmin tools (ssh, perl/python etc) from day 1; but again, don't take it from me: the big new Windows Server features are Ubuntu-bundling and native ssh support. This would not be necessary, were Powershell and Windows dominant from a commercial perspective.

[rbanffy]

> Windows did flourish...

Sure. Just see all those buildings full of Windows servers running Facebook, Google, Twitter, Amazon...

[jjnoakes]

It's moving the goal posts a bit to suddenly restrict this discussion to only servers, no?

There are plenty of Windows servers running plenty of businesses. They may not outnumber non-Windows servers, but I don't think "majority" has to be a prerequisite for "flourish".

There are also buildings full of Windows clients...

[nurettin]

I was administering windows computers at a university at the time of windows 98and most of my automation came from ActiveX where I could register external libraries and script most OS interfaces with vb or js. Powershell is just that plus lots of objects and types

[vertex-four]

No. The well-known mature shell tools manage files and processes - neither of which are a focus of managing a Windows system. Windows revolves around services which you RPC to, which internally store their state - attempting to faff with their state from outside the service is almost always both undocumented and likely to cause failure.

Powershell allowed those services to standardise their RPCs in such a way that sysadmins could call them easily. Alternatively, you'd have COM or a variety of other RPC mechanisms, depending on the service, often undocumented themselves as they were only ever intended to be used by a GUI packaged with the service.

[lobster_johnson]

It's been years since I used Windows APIs -- back then there was OLE Automation, which allowed dynamically, late-bound (call by name, really) RPC calls into COM from scripting languages. Has this been superceded by something else? Using IDL-defined COM interfaces from scripts sounds like something nobody would want to do.

[vertex-four]

Indeed, nobody would want to do that, which is why Powershell exists. Scripting VB or Javascript against COM or whatever else the software vendor decided to use was generally an awful experience, if the interface was even documented at all. Powershell replaces all of that for system administration purposes - you can even run Powershell commands easily from within any .Net application and get structured, object-oriented output, which is what at least all the Windows Server GUI stuff does now.

You're still stuck with OLE/COM for e.g. Excel automation, though, I think.

[innocentoldguy]

I'm having to do this on a project right now, and I wholeheartedly agree. Nobody would want to do this.

[mattzito]

Well, lots of windows admins used things like cygwin and the like to get a unix-y working environment, but PowerShell offers a much more robust set of mechanisms to manipulate the underlying Windows operating system.

[13of40]

> who couldn't use the well-known mature shell tools since they were locked into a closed platform

Yeah, I remember the bad old days, when I'd download that CygWin installer and Windows would just give me the old skull and crossbones and say "You're not allowed to install GNU tools, Sucka!" One time I jailbroke XP and got it installed, but then CMD was all "You can't run grep.exe and sed.exe under CMD, Sucka! Not allowed!" I was so sad that I couldn't use those tools on Windows, so sad.

[rbanffy]

> a way to do powerful automation without hiring a bunch of PhDs.

I remember writing Windows software with DCOM was difficult, but it was more on the painfulness side than a difficult intellectual endeavor. Sure you didn't need PhDs to automate things.

> So, yes, someone did ask for it - the IT industry.

The part of it stuck in Windows, that is. Vendor lock-in is a powerful thing.

[bluejekyll]

Yeah, DCOM was a task of fillout the correct fields with the correct values, and try again until you get it right. Anyone with passing C++ knowledge could do it through shear brute force.

It's one of the things which made me never want to program on Windows again.

[kazinator]

I ported a bunch of COM to Linux in the late 1990's. Not DCOM with the full RPC, but just in-process COM. I had .so shared libs with DllMain and DllCanUnload now in them, I had CoCreateClass, I had a significant part of the registry API implemented in terms of a text file store (HKEY_LOCAL_USER being in the home directory, HKEY_LOCAL_MACHINE somewhere in /etc, ...) and such. IUnknown, QueryInterface, AddRef, Release, ...

[MichaelMoser123]

Netscape did that with XPCOM [1] they once thought that this is a good idea - i guess for versioning of interfaces; nowadays firefox has moved on from this.

[1] https://en.wikipedia.org/wiki/XPCOM

[Quiark]

Haha, funny enough our company did this as well - we had lots of legacy C++ code using COM and wanted to port to Linux. It was not that hard after all.

[snaky]

That's nice, but having CORBA implementations - why?

[kazinator]

To port some code as-is.

[alistproducer2]

I read this a while back. It's an interview with the dude who wrote PS https://www.petri.com/jeffrey-snover-powershell

[aurhum]

His HN handle is JeffreySnover; He is commenting on this story at this moment.

[itomato]

Not "The IT Industry", surely only a subset of Windows systems managers.

[jaredhansen]

That's actually a pretty substantial chunk of "the IT Industry" though. And if you're the people who make Windows, it's not surprising that it's a big enough chunk to do something about.

[jl6]

I personally find that the term "IT" has become a bit of a code word for "Enterprise Wintel", and that anyone working outside of the gravitational pull of Microsoft prefers to describe themselves as working in "tech"

[toomanybeersies]

I think that IT has become a code word for being a tech worker in a company, rather than a worker in a tech company.

[chetanahuja]

All those sysadmins would have been perfectly happy with just a properly working unix like shell.

[coldtea]

Yes. Like all those early car buyers would be perfectly happy with faster horses.

[sigsergv]

Both PS and bash are horses actually.

[kriro]

Unix like shell + Python/Perl/Ruby = car

That being said I really don't mind that MS went the PowerShell route. It improved their ecosystem a lot and I belive was also one of the engines behind the more open minded move towards open source...maybe someone at MS can chime in but I feel like PS was always one of the strong projects pushing that forward from talking to some MS engineers.

[newacct23]

false equivalency

[coldtea]

No, actually it's quite apt.

PowerShell, or at least the concept behind PowerShel, is an improvement/superset over the Unix shells -- and can do whatever the shells can do, plus stuff they cannot do, because they don't support typed entities.

Its problems are not technical or conceptual -- they are ecosystem and historical: lack of compatible tools, windows-only, etc.

[matt_wulfeck]

Or to the point of the original parent: the industry considers powershell a solution in search of a problem.

[pjmlp]

Only those that disregard the inventions from Xerox and ETHZ.

Powershell ideas go back to how REPLs work in those environments.

[chetanahuja]

And everybody remembers how Ford was forced to reintroduce a carriage with a horse a couple of decades later because nobody was really using those horseless carriages. Right?

https://blogs.windows.com/buildingapps/2016/03/30/run-bash-o...