This means that now anyone can implement PowerShell on any platform they want to. We know some of our most passionate customers sometimes work on platforms that can’t run PowerShell today, so when writing this specification, we wrote it in a platform neutral manner.
We hope to see implementations on all of your favorite platforms. This would benefit the industry, our partners, and our customers. We told you that you should learn PowerShell and we would do everything we could to make it the best investment you ever made. Specifying the language and enabling the community to implement it is yet another step in that direction.
It's interesting how many open source projects are expected to, and do, port their projects to Windows, but Microsoft expects the community to do the work of porting their projects to other platforms. Now obviously, Microsoft isn't usually the one doing the expecting, but Microsoft has a lot more resources than any random person doing a port in their freetime.
I remember when Apache wasn't available for Windows; and I remember when Microsoft "let" the Mono team write their Silverlight port.
This is all just marketing. They can say they are open and working with the community, but they are offering something empty: anyone who wants to use Powershell, or has experienced its value, is already working on Windows and most likely isn't interested in working on any other platform. And thus there is no one (or close to no one) who is both interested in doing and qualified to do a port. And I think Microsoft has shown their track record of working with the community only to continuously leave community products at least one step behind the moving target that is their "standard", often defined as whatever the latest from Microsoft offers. Everyone else's ports are seen a lesser because they are behind the "official" release.
Now, obviously, different implementations are good for the standard and market overall, and only serve to strengthen it from a diversity standpoint. But it's interesting that Microsoft is actively encouraging forks of their projects when they've, in the past, cited forks as a deficiency of open source.
You're lucky it's not in the Microsoft PDF killer format: XPS!
Still, I always wondered why they keep publishing stuff like this in a "working" format (doc, odt...) instead of a "distribution" format (ps, pdf...) .
As someone who occasionally has to write PowerShell, I can say with confidence that is an abomination of a language with a horrible syntax. I hope this never gets implemented on any other platform when there are so many superior alternatives.
Note the lack of any regex-munging tools? That's because PS is sending a list of processes, not just lines of text. The constant Unix 'what's a good regex for this or that' problem is gone because content is separate from presentation - which as we all know is good engineering.
I'm a Unix guy. Window Server 2008R2 still requires reboots for trivial activity (eg, installing Office web), which I don't think is appropriate for servers. But PoSH is awesome.
I've heard a lot of good things about it, mainly from people used to CMD though. When I checked it out, I didn't find a lot to do with it. I didn't feel like learning a new shell language that only works on Windows. The lack of familiar helper tools such as diff, grep and sed didn't help, and I don't know whatever Windows equivalents may exist. I'm sure if I was using Windows PWSH would be great, but like many of us I don't have any interest in using Windows as a webserver platform.
Now that there may be a prospect of using PowerShell on other platforms, I wonder why I'd bother? Day to day tasks I'm perfectly happy doing in bash, and anything more complex, I'd just as soon use Python, Ruby, PHP or Perl.
There's been a (partial) port of PowerShell to Linux/Mono out there for a few years; maybe having the language spec will allow the project to go a bit further.
This isn't pointed at you, keyle, but here PowerShell seems to be one of those things that's universally panned by people who don't understand it, or who refuse to give a serious chance to anything that isn't a traditional Unix shell...
To answer your question, PowerShell's big win is that it's an object-oriented shell on top of .NET. Where the Unix shell pipes flat data, PowerShell pipes .NET (and COM) objects.
In practice this means things that may require complicated and often fragile text-wrangling in the Unix shell are straightforward and robust in PowerShell. For example, suppose you wanted to kill all processes with a private working set greater than 1 GB:
ps | ?{ $_.PM -gt 1GB } | %{ $_.Kill() }
Here ps returns a collection of all current processes, then pipes it to the where-object cmdlet (abbreviated "?") which filters the collection to those with a private working set greater than the given size. The filtered collection is then piped into the foreach-object cmdlet ("%") which invokes the Kill() method on each object passed in – these are real .NET objects being passed around, so you can invoke methods, set properties, etc.
You can get the same result with a Unix shell script, but you have to be careful to count the columns output by ps correctly, skip the output header, pass it through awk, save the corresponding PIDs and then invoke the kill command on them... and then it all breaks if you run it on a different Unix system where ps outputs a different formatting. In practice you usually leave the shell environment and write a Perl or Python script instead for this sort of thing.
In PowerShell you can directly instantiate .NET and COM objects, and you can implement your own cmdlets and modules either in the PowerShell scripting language or in any .NET language like C# or F#. So e.g. you can access the .NET class libraries to get the time as so:
[System.DateTime]::Now
And this makes PowerShell handy for interactively developing .NET class libraries (at least until C# gets a real REPL, and if you aren't using F# anyway). Of course this object-oriented approach is all the more necessary on Windows, which is inherently an object-oriented system (think OLE automation, WMI, etc., let alone .NET) than it is on Unix-based systems.
Some people will complain about the PowerShell scripting language... and sure, it's not perfect, but I think the team did about as good a job as possible satisfying the various requirements involved in building a new Windows shell language that could be used both interactively and as the basis for writing scripts. Superficially the language is heavily influenced by Perl, and while I'd still rather use Perl for "serious" automation tasks, PowerShell gets the job done... and it's nowhere near as ugly as scripting in the traditional Unix shell, nevermind the old Windows command shell.
For more on the design rationale, in the words of one of PowerShell's creators:
Yep, it has some interesting features/capabilities but the syntax is soooo baroque. All I want out of shell is a means to get boring shit done without having to think about it too much. At this point, Cygwin is STILL the way to go on windows and it would take A LOT of simplification to make powershell even competitive on windows, let alone competitive on *-nix platforms with a plain old shell like bash.
There are some very powerful commandlets (basically scripts) for control over various pieces of MicroSoft infrastructure components (Exchange, Active Directory and more). Having access to these commandlets on my favored environment would be useful. I wouldn't even need to be running a PowerShell session to run them, but that would occasionally be nice too (there is something to be said for object pipes).
Because they are not licensing a piece of software. They are promising not to sue if you implement your own compatible software. If it were software it would be licensed.
From what I've seen "covenant" is the most common term used for this kind of thing. For example, here's a page I put together once to help me understand the differences between the various patent promises that might affect ODF and OOXML, although half the links to the originals no longer work. It shows two Microsoft documents, a Sun documents, and the terms IBM uses for many standards side by side, with the text colored so that sections in the difference ones that correspond in function are colored the same. It makes it easy to look at one and see how the others word their similar section:
In essence, a "covenant" not to sue is a fancy way of saying "promise" not to sue.
As far as the difference between a covenant/promise and a license goes, the courts have been unclear in their guidance. Covenants/promises may not survive a sale of the patent--although the cases are mixed. Covenants/promises may not provide the person they are given to the right to sell things that use the patent to third parties (or rather, it may not apply to the third parties and so the patent owner might be able to sue them). The case law here is murky, too, with the latest tending to favor that the covenant/promise does apply downstream.
I've seen cites to at least one appeals court case where the court said all patent licenses are really just promises not to sue. That's because a patent does not give the patent owner permission to practice the patent. It just gives him the power to exclude others from doing so, and so he can't really license you the right to actually make something that is covered by that patent. All he can do is agree not to sue you if you do so.
Most of the cases, though, apply to covenants/promises to a specific party. E.g., company X and company Y are disagreeing over X's patent, and as part of some settlement X grants Y a promise not to sue.
Different considerations might apply when the covenant/promise/license is not to anyone specific but is rather a non-exclusive covenant/promise/license to everyone. When viewed as a license, this kind of license is something called a "bare license". Bare licenses are not good for the recipient, as they can be revoked at any time. What you really want is for the covenant/promise/grant to be viewed as a contract. Fortunately, there is a mechanism in contract law to allow this, called promissory estoppel. The basic idea is that if I make a promise to you (where you can be the whole world), reasonably knowing that you are going to rely on this promise, and you do rely on this promise and act accordingly, then the law will enforce the promise.
This is likely most useful for remote-controlling windows boxes from some non-windows endpoint. I can see that being handy for a unix-centric admin forced to admin exchange, for example.
FUD. A summary of their argument is (1) Microsoft has software not covered by the promise, and (2) the promise only covers the patents you need to implement the covered specification. Neither of these makes the promise worthless.
This is no more worthless than the similar promises from IBM, Sun, and many others that cover a huge number of specifications that are widely used in open source. It's the normal way patents are made available for free use in implementing specifications.
[+] [-] thwarted|15 years ago|reply
We hope to see implementations on all of your favorite platforms. This would benefit the industry, our partners, and our customers. We told you that you should learn PowerShell and we would do everything we could to make it the best investment you ever made. Specifying the language and enabling the community to implement it is yet another step in that direction.
It's interesting how many open source projects are expected to, and do, port their projects to Windows, but Microsoft expects the community to do the work of porting their projects to other platforms. Now obviously, Microsoft isn't usually the one doing the expecting, but Microsoft has a lot more resources than any random person doing a port in their freetime.
I remember when Apache wasn't available for Windows; and I remember when Microsoft "let" the Mono team write their Silverlight port.
This is all just marketing. They can say they are open and working with the community, but they are offering something empty: anyone who wants to use Powershell, or has experienced its value, is already working on Windows and most likely isn't interested in working on any other platform. And thus there is no one (or close to no one) who is both interested in doing and qualified to do a port. And I think Microsoft has shown their track record of working with the community only to continuously leave community products at least one step behind the moving target that is their "standard", often defined as whatever the latest from Microsoft offers. Everyone else's ports are seen a lesser because they are behind the "official" release.
Now, obviously, different implementations are good for the standard and market overall, and only serve to strengthen it from a diversity standpoint. But it's interesting that Microsoft is actively encouraging forks of their projects when they've, in the past, cited forks as a deficiency of open source.
[+] [-] y0ghur7_xxx|15 years ago|reply
Microsoft, just put an HTML page with the spec online. There is no need for a docx file for a language specification.
[1]http://www.microsoft.com/downloads/en/details.aspx?FamilyID=...
[+] [-] lloeki|15 years ago|reply
Still, I always wondered why they keep publishing stuff like this in a "working" format (doc, odt...) instead of a "distribution" format (ps, pdf...) .
[+] [-] jkahn|15 years ago|reply
[+] [-] mikemaccana|15 years ago|reply
I'm a Unix guy. Window Server 2008R2 still requires reboots for trivial activity (eg, installing Office web), which I don't think is appropriate for servers. But PoSH is awesome.
[+] [-] code_duck|15 years ago|reply
Now that there may be a prospect of using PowerShell on other platforms, I wonder why I'd bother? Day to day tasks I'm perfectly happy doing in bash, and anything more complex, I'd just as soon use Python, Ruby, PHP or Perl.
[+] [-] nahname|15 years ago|reply
[+] [-] norswap|15 years ago|reply
[+] [-] __david__|15 years ago|reply
[+] [-] profquail|15 years ago|reply
http://pash.sourceforge.net/
There's been a (partial) port of PowerShell to Linux/Mono out there for a few years; maybe having the language spec will allow the project to go a bit further.
[+] [-] keyle|15 years ago|reply
[+] [-] Niten|15 years ago|reply
To answer your question, PowerShell's big win is that it's an object-oriented shell on top of .NET. Where the Unix shell pipes flat data, PowerShell pipes .NET (and COM) objects.
In practice this means things that may require complicated and often fragile text-wrangling in the Unix shell are straightforward and robust in PowerShell. For example, suppose you wanted to kill all processes with a private working set greater than 1 GB:
Here ps returns a collection of all current processes, then pipes it to the where-object cmdlet (abbreviated "?") which filters the collection to those with a private working set greater than the given size. The filtered collection is then piped into the foreach-object cmdlet ("%") which invokes the Kill() method on each object passed in – these are real .NET objects being passed around, so you can invoke methods, set properties, etc.You can get the same result with a Unix shell script, but you have to be careful to count the columns output by ps correctly, skip the output header, pass it through awk, save the corresponding PIDs and then invoke the kill command on them... and then it all breaks if you run it on a different Unix system where ps outputs a different formatting. In practice you usually leave the shell environment and write a Perl or Python script instead for this sort of thing.
In PowerShell you can directly instantiate .NET and COM objects, and you can implement your own cmdlets and modules either in the PowerShell scripting language or in any .NET language like C# or F#. So e.g. you can access the .NET class libraries to get the time as so:
And this makes PowerShell handy for interactively developing .NET class libraries (at least until C# gets a real REPL, and if you aren't using F# anyway). Of course this object-oriented approach is all the more necessary on Windows, which is inherently an object-oriented system (think OLE automation, WMI, etc., let alone .NET) than it is on Unix-based systems.Some people will complain about the PowerShell scripting language... and sure, it's not perfect, but I think the team did about as good a job as possible satisfying the various requirements involved in building a new Windows shell language that could be used both interactively and as the basis for writing scripts. Superficially the language is heavily influenced by Perl, and while I'd still rather use Perl for "serious" automation tasks, PowerShell gets the job done... and it's nowhere near as ugly as scripting in the traditional Unix shell, nevermind the old Windows command shell.
For more on the design rationale, in the words of one of PowerShell's creators:
http://stackoverflow.com/questions/573623/powershell-vs-unix...
[+] [-] angdis|15 years ago|reply
[+] [-] brudgers|15 years ago|reply
http://stackoverflow.com/questions/573623/powershell-vs-unix...
[+] [-] andreaja|15 years ago|reply
[+] [-] protomyth|15 years ago|reply
[+] [-] Osiris|15 years ago|reply
It seems they think there is a benefit for themselves to see PowerShell implemented on other platforms.
[+] [-] moondowner|15 years ago|reply
[+] [-] hexis|15 years ago|reply
[+] [-] me_again|15 years ago|reply
[+] [-] tzs|15 years ago|reply
http://www.tzs.net/odfooxmlpatent.html
In essence, a "covenant" not to sue is a fancy way of saying "promise" not to sue.
As far as the difference between a covenant/promise and a license goes, the courts have been unclear in their guidance. Covenants/promises may not survive a sale of the patent--although the cases are mixed. Covenants/promises may not provide the person they are given to the right to sell things that use the patent to third parties (or rather, it may not apply to the third parties and so the patent owner might be able to sue them). The case law here is murky, too, with the latest tending to favor that the covenant/promise does apply downstream.
I've seen cites to at least one appeals court case where the court said all patent licenses are really just promises not to sue. That's because a patent does not give the patent owner permission to practice the patent. It just gives him the power to exclude others from doing so, and so he can't really license you the right to actually make something that is covered by that patent. All he can do is agree not to sue you if you do so.
Most of the cases, though, apply to covenants/promises to a specific party. E.g., company X and company Y are disagreeing over X's patent, and as part of some settlement X grants Y a promise not to sue.
Different considerations might apply when the covenant/promise/license is not to anyone specific but is rather a non-exclusive covenant/promise/license to everyone. When viewed as a license, this kind of license is something called a "bare license". Bare licenses are not good for the recipient, as they can be revoked at any time. What you really want is for the covenant/promise/grant to be viewed as a contract. Fortunately, there is a mechanism in contract law to allow this, called promissory estoppel. The basic idea is that if I make a promise to you (where you can be the whole world), reasonably knowing that you are going to rely on this promise, and you do rely on this promise and act accordingly, then the law will enforce the promise.
[+] [-] Niten|15 years ago|reply
[+] [-] me_again|15 years ago|reply
[+] [-] leif|15 years ago|reply
Extra lols from the "download spec page":
[+] [-] Pooter|15 years ago|reply
[deleted]
[+] [-] chrisjsmith|15 years ago|reply
http://www.fsf.org/news/2009-07-mscp-mono
[+] [-] tzs|15 years ago|reply
This is no more worthless than the similar promises from IBM, Sun, and many others that cover a huge number of specifications that are widely used in open source. It's the normal way patents are made available for free use in implementing specifications.