For those of you old enough, who have been using computers since MS-DOS days, through the 9x generation and later into the NT generation, you will quite likely be familiar with the various means Microsoft provided the User to perform basic command-line tasks to manipulate the installed Operating System.
It all started with COMMAND.COM, which continued through the 9x generation of Windows, then with the introduction of Windows NT Microsoft introduced us to the new and slightly improved CMD.exe which you'll still find even in the latest Windows 10 installations.
Both the COMMAND.COM and CMD.exe were Shell based utilities which could be used to perform basic command-line operations to manipulate the Operating System. Many of you will be very familiar with a command-line operation for performing a System File check: SFC /SCANNOW which is a way to check the System for corruption, and occasionally even manages to fix issues.
The Shell also included Scripts but owing to the limitations of command-line interaction, the User was somewhat limited in what they could do to access and make use of these scripts. A common script used though, even to this day, is the Batch file which has the file extension .bat, and these were used a lot in the 80s and 90s by Windows users who wanted to tweak their Dial-up modems, Printer settings, Registry settings, etcetera,.
The scripting languages were to be fair somewhat modest during this time, but when Microsoft introduced Windows Server 2003, this sparked the beginning of improved Scripting options, and also improved functionality between the Shell and Graphical User Interface (GUI). These modest improvements at the time saw a lot of interest, and events of the future saw some massive improvements, in part oddly, thanks to the persistent pests who were creating and distributing virus infections - taking advantage of security vulnerabilities in the Windows Shell.
Prior to the release of the Windows Server 2003, there was a reaction from Microsoft to address the limitations of Scripting capabilities, and in 1998 Microsoft introduced an additional command-line executable tool named cscript.exe and also a new Host named Windows Script Host, which users of Windows 98 were able to make use of. Users could now make use of Visual Basic Scripts (VBScript) and JavaScripts (JScript or JS) which could manipulate the Application Program Interface (APIs) via Microsoft's Active Script. Unfortunately, while the User could do greater things with the COM now, this was not fully integrated into the Shell, and to top it off, there were multiple security issues which the aforementioned pests took great delight in exposing with their virus and trojan infections.
Microsoft introduced the additional command-line tools in later editions of Windows. First we saw the new Net Shell (netsh.exe), then also, Windows Management Instrumentation Command-line (WMIC) which was an interface for the User to interact with the Windows Management Interface (WMI). Both are still present today in the Windows 10 Operating System. While very useful tools, again, neither were integrated with the Command Shell, and if working within the Shell the command-line utilities were not inter-operable, so again not terribly useful for the Scripting community.
About a year before Microsoft introduced the Windows Server 2003, Microsoft started experimenting with the use of Scripts in a new tool they were developing, which they named MONAD. This in conjunction with a new approach to using Command-line utilities, was in essence the infancy of Windows PowerShell. You can read about Microsoft's intentions with MONAD in a paper they released in August, 2002 here: https://blogs.msdn.microsoft.com/po...d-manifesto-the-origin-of-windows-powershell/
It's actually pretty interesting to read, but if reading is not your thing, do not despair, my next posting to this Section will help you avoid the task, yet still learn about the history
By the way, MONAD is also known as Microsoft Shell (MSH) if you want to search for more details about it.
It was not until June 2005 though that the General Public were introduced to MONAD, when Microsoft released their BETA edition of this new tool. Interest in this new approach quickly took hold, which saw further BETA releases, in September 2005, then January 2006.
Continued interest saw Microsoft further develop the tool and during April 2006 they officially renamed MONAD to Windows PowerShell. With this announcement, Microsoft released Candiate 1 Windows PowerShell to be tested in a closed community (Similar to today's Insider program for Windows 10). The interesting thing though was that while private members were testing this, it was now included in the Windows Operating System, and Users did not need to download it separately or purchase it separately; this was a clear indication that Microsoft were all ready committed to a new approach to management of the Operating System using Scripts, the Shell etcetera,.
Release Candidate 2 of Windows PowerShell was released later the same year, in September 2006, and later in January 2007 Users still running earlier editions of Windows that pre-dated the Windows PowerShell creation, could now officially download Windows PowerShell v. 1.0 and install it into their own Windows editions.
Users had to wait then until late 2008 to get a chance to review the three test versions of Windows PowerShell v. 2.0, but it was certainly worth the wait. In 2009 Windows PowerShell v. 2.0 was offically ready for public release. Windows 7 was one of the first editions to include v. 2.0, however, Users still running older editions of Windows could download it from the internet by October of the same year, in both 32-bit and 64-bit architecture.
We are now here with Windows 10 and at the release of Windows 10, Microsoft included a testing framework for the Windows PowerShell. As you can imagine a lot of testing has been done by those eager to improve it. In 2016 Microsoft officially declared they were making Windows PowerShell an open source project, and the full source code was published on Github's website.
On top of this, Microsoft also announced they intended that this new tool would be fully supporting Ubuntu, CentOS and OS X as well as Windows OS of course. They wanted this to be a cross-platform tool and that is all ready taking place.
Windows PowerShell v. 1.0 and 2.0 both rely on the .Net Framework but now thanks to the efforts of the open source community we not only have Windows PowerShell but now a new improved Windows PowerShell Core v. 5.1 which runs off the .Net Core. This will bring some exciting additions to the end-user's ability to control settings, APIs, Executables, Scheduled Tasks, COMS, and so forth.
Well that's the brief History over and done with. Now it's time to get down to the Scripting and Functions that make Windows PowerShell a mighty tool. That is why I asked Ian to add this section to our Forum. A place where you can share your experiences with Windows PowerShell or Windows PowerShell ISE, and share your Scripts and/or functions you have coded to take advantage of this tool to control your Operating System, or just to have some fun.
If you are new to Scripting, that is fine, join in, share your efforts, and ask your questions if you need some help to get it working as you want it to.
Why not team up with some Forum members and work on a co-project.
This is your place to have some fun and help others learn the wonders of Windows PowerShell.
Regards,
Regedit32
It all started with COMMAND.COM, which continued through the 9x generation of Windows, then with the introduction of Windows NT Microsoft introduced us to the new and slightly improved CMD.exe which you'll still find even in the latest Windows 10 installations.
Both the COMMAND.COM and CMD.exe were Shell based utilities which could be used to perform basic command-line operations to manipulate the Operating System. Many of you will be very familiar with a command-line operation for performing a System File check: SFC /SCANNOW which is a way to check the System for corruption, and occasionally even manages to fix issues.
The Shell also included Scripts but owing to the limitations of command-line interaction, the User was somewhat limited in what they could do to access and make use of these scripts. A common script used though, even to this day, is the Batch file which has the file extension .bat, and these were used a lot in the 80s and 90s by Windows users who wanted to tweak their Dial-up modems, Printer settings, Registry settings, etcetera,.
The scripting languages were to be fair somewhat modest during this time, but when Microsoft introduced Windows Server 2003, this sparked the beginning of improved Scripting options, and also improved functionality between the Shell and Graphical User Interface (GUI). These modest improvements at the time saw a lot of interest, and events of the future saw some massive improvements, in part oddly, thanks to the persistent pests who were creating and distributing virus infections - taking advantage of security vulnerabilities in the Windows Shell.
Prior to the release of the Windows Server 2003, there was a reaction from Microsoft to address the limitations of Scripting capabilities, and in 1998 Microsoft introduced an additional command-line executable tool named cscript.exe and also a new Host named Windows Script Host, which users of Windows 98 were able to make use of. Users could now make use of Visual Basic Scripts (VBScript) and JavaScripts (JScript or JS) which could manipulate the Application Program Interface (APIs) via Microsoft's Active Script. Unfortunately, while the User could do greater things with the COM now, this was not fully integrated into the Shell, and to top it off, there were multiple security issues which the aforementioned pests took great delight in exposing with their virus and trojan infections.
Microsoft introduced the additional command-line tools in later editions of Windows. First we saw the new Net Shell (netsh.exe), then also, Windows Management Instrumentation Command-line (WMIC) which was an interface for the User to interact with the Windows Management Interface (WMI). Both are still present today in the Windows 10 Operating System. While very useful tools, again, neither were integrated with the Command Shell, and if working within the Shell the command-line utilities were not inter-operable, so again not terribly useful for the Scripting community.
About a year before Microsoft introduced the Windows Server 2003, Microsoft started experimenting with the use of Scripts in a new tool they were developing, which they named MONAD. This in conjunction with a new approach to using Command-line utilities, was in essence the infancy of Windows PowerShell. You can read about Microsoft's intentions with MONAD in a paper they released in August, 2002 here: https://blogs.msdn.microsoft.com/po...d-manifesto-the-origin-of-windows-powershell/
It's actually pretty interesting to read, but if reading is not your thing, do not despair, my next posting to this Section will help you avoid the task, yet still learn about the history
By the way, MONAD is also known as Microsoft Shell (MSH) if you want to search for more details about it.
It was not until June 2005 though that the General Public were introduced to MONAD, when Microsoft released their BETA edition of this new tool. Interest in this new approach quickly took hold, which saw further BETA releases, in September 2005, then January 2006.
Continued interest saw Microsoft further develop the tool and during April 2006 they officially renamed MONAD to Windows PowerShell. With this announcement, Microsoft released Candiate 1 Windows PowerShell to be tested in a closed community (Similar to today's Insider program for Windows 10). The interesting thing though was that while private members were testing this, it was now included in the Windows Operating System, and Users did not need to download it separately or purchase it separately; this was a clear indication that Microsoft were all ready committed to a new approach to management of the Operating System using Scripts, the Shell etcetera,.
Release Candidate 2 of Windows PowerShell was released later the same year, in September 2006, and later in January 2007 Users still running earlier editions of Windows that pre-dated the Windows PowerShell creation, could now officially download Windows PowerShell v. 1.0 and install it into their own Windows editions.
Users had to wait then until late 2008 to get a chance to review the three test versions of Windows PowerShell v. 2.0, but it was certainly worth the wait. In 2009 Windows PowerShell v. 2.0 was offically ready for public release. Windows 7 was one of the first editions to include v. 2.0, however, Users still running older editions of Windows could download it from the internet by October of the same year, in both 32-bit and 64-bit architecture.
We are now here with Windows 10 and at the release of Windows 10, Microsoft included a testing framework for the Windows PowerShell. As you can imagine a lot of testing has been done by those eager to improve it. In 2016 Microsoft officially declared they were making Windows PowerShell an open source project, and the full source code was published on Github's website.
On top of this, Microsoft also announced they intended that this new tool would be fully supporting Ubuntu, CentOS and OS X as well as Windows OS of course. They wanted this to be a cross-platform tool and that is all ready taking place.
Windows PowerShell v. 1.0 and 2.0 both rely on the .Net Framework but now thanks to the efforts of the open source community we not only have Windows PowerShell but now a new improved Windows PowerShell Core v. 5.1 which runs off the .Net Core. This will bring some exciting additions to the end-user's ability to control settings, APIs, Executables, Scheduled Tasks, COMS, and so forth.
Well that's the brief History over and done with. Now it's time to get down to the Scripting and Functions that make Windows PowerShell a mighty tool. That is why I asked Ian to add this section to our Forum. A place where you can share your experiences with Windows PowerShell or Windows PowerShell ISE, and share your Scripts and/or functions you have coded to take advantage of this tool to control your Operating System, or just to have some fun.
If you are new to Scripting, that is fine, join in, share your efforts, and ask your questions if you need some help to get it working as you want it to.
Why not team up with some Forum members and work on a co-project.
This is your place to have some fun and help others learn the wonders of Windows PowerShell.
Regards,
Regedit32
