5 ms·

> 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

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

mattzito 10y ago
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.
Someone1234 10y ago
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.
- toyg 10y ago
  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.
  - deleted 10y ago
    [deleted]
  - jjnoakes 10y ago
    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?
    - rbanffy 10y ago
      > Windows did flourish... Sure. Just see all those buildings full of Windows servers running Facebook, Google, Twitter, Amazon...
      - jjnoakes 10y ago
        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...
        rbanffy 10y ago
        This discussion is about PowerShell, which is primarily intended to automate server management and has been ported to Linux, presumably, for the same purpose.
        jjnoakes 10y ago
        > This discussion is about PowerShell, which is primarily intended to automate server management Many (me included) find PowerShell extremely useful for automating any sort of Windows management, client or server. So I disagree that the discussion should be implicitly assumed to be limited to Windows servers.
    - 10y ago
- flukus 10y ago
  > 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.
- deleted 10y ago
  [deleted]
- nurettin 10y ago
  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 10y ago
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 10y ago
  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.
  - innocentoldguy 10y ago
    I'm having to do this on a project right now, and I wholeheartedly agree. Nobody would want to do this.
  - vertex-four 10y ago
    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.
13of40 10y ago
> 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.

mattzito 10y ago

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.

Someone1234 10y ago

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.

toyg 10y ago
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.
- deleted 10y ago
  [deleted]
- jjnoakes 10y ago
  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?
  - rbanffy 10y ago
    > Windows did flourish... Sure. Just see all those buildings full of Windows servers running Facebook, Google, Twitter, Amazon...
    - jjnoakes 10y ago
      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...
      - rbanffy 10y ago
        This discussion is about PowerShell, which is primarily intended to automate server management and has been ported to Linux, presumably, for the same purpose.
        jjnoakes 10y ago
        > This discussion is about PowerShell, which is primarily intended to automate server management Many (me included) find PowerShell extremely useful for automating any sort of Windows management, client or server. So I disagree that the discussion should be implicitly assumed to be limited to Windows servers.
  - 10y ago
flukus 10y ago
> 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.
deleted 10y ago
[deleted]
nurettin 10y ago
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 10y ago

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 10y ago
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.
- innocentoldguy 10y ago
  I'm having to do this on a project right now, and I wholeheartedly agree. Nobody would want to do this.
- vertex-four 10y ago
  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.

13of40 10y ago

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