Windows Script Host:
The Microsoft Windows Script Host (WSH) (formerly named Windows Scripting Host) is an automation technology for Microsoft Windows operating systems that provides scripting abilities comparable to batch files, but with a wider range of supported features. This tool was first provided on Windows 95 after Build 950a on the installation discs as an optional installation configurable and installable by means of the Control Panel, and then a standard component of Windows 98 (Build 1111) and subsequent and Windows NT 4.0 Build 1381 and by means of Service Pack 4. The WSH is also a means of automation for Internet Explorer via the installed WSH engines from IE Version 3.0 onwards; at this time VBScript became means of automation for Microsoft Outlook 97.[1] The WSH is also an optional install provided with a VBScript and JScript engine for Windows CE 3.0 and following and some third-party engines including Rexx and other forms of Basic are also available.[2] [3] [4]
It is language-independent in that it can make use of different Active Scripting language engines. By default, it interprets and runs plain-text JScript (.JS and .JSE files) and VBScript (.VBS and .VBE files).
Users can install different scripting engines to enable them to script in other languages, for instance PerlScript. The language independent filename extension WSF can also be used. The advantage of the Windows Script File (.WSF) is that it allows the user to use a combination of scripting languages within a single file.
WSH engines include various implementations for the Rexx, BASIC, Perl, Ruby, Tcl, PHP, JavaScript, Delphi, Python, XSLT, and other languages.
Windows Script Host is distributed and installed by default on Windows 98 and later versions of Windows. It is also installed if Internet Explorer 5 (or a later version) is installed. Beginning with Windows 2000, the Windows Script Host became available for use with user login scripts.
Usage[edit]
Windows Script Host may be used for a variety of purposes, including logon scripts, administration and general automation. Microsoft describes it as an administration tool.[5] WSH provides an environment for scripts to run – it invokes the appropriate script engine and provides a set of services and objects for the script to work with.[5] These scripts may be run in either GUI mode (WScript.exe) or command line mode (CScript.exe) offering flexibility to the user for interactive or non-interactive scripts.[6] Windows Management Instrumentation is also scriptable by this means.
The WSH, the engines, and related functionality are also listed as objects which can be accessed and scripted and queried by means of the VBA and Visual Studio object explorers and those for similar tools like the various Script Debuggers and Editors. Conversely, VBA is a third WSH engine installed by default.
WSH implements an object model which exposes a set of Component Object Model (COM) interfaces.[7] So in addition to ASP, IIS, Internet Explorer, CScript and WScript, the WSH can be used to automate and communicate with any Windows application with COM and other exposed objects, such as using PerlScript to query Microsoft Access by various means including various ODBCengines and SQL, ooRexxScript to create what are in effect Rexx macros in Excel, Quattro Pro, Microsoft Word, Lotus Notes and any of the like, the XLNT script to get environment variables and print them in a new TextPad document, The VBA functionality of Microsoft Office, Open Office(as well as Python and other installable macro languages) and Corel WordPerfect Office is separate from WSH engines although Outlook 97 uses VBScript rather than VBA as its macro language.[8]
Python in the form of ActiveState PythonScript can be used to automate and query the data in SecureCRT, as with other languages with installed engines, e.g. PerlScript, ooRexxScript, PHPScript, RubyScript, LuaScript, XLNT and so on. One notable exception is Paint Shop Pro, which can be automated in Python by means of a macro interpreter within the PSP programme itself rather than using the PythonScript WSH engine or an external Python implementation such as Python interpreters supplied with Unix emulation and integration software suites or other standalone Python implementations et al.[9][10] as an intermediate and indeed can be programmed like this even in the absence of any third-party Python installation; the same goes for the Rexx-programmable terminal emulator Passport.[11] The SecureCRT terminal emulator, SecureFX FTP client, and related client and server programmes from Van Dyke are as of the current versions automated by means of the WSH so any language with an installed engine may be used; the software comes with VBScript, JScript, and PerlScript examples.
As of the most recent releases and going back a number of versions now, the programmability of Take Command and 4NT in the latest implementations (by means of “@REXX” and similar for Perl, Python, Tcl, Ruby, Lua, VBScript, JScript and the like and so on) generally uses the WSH engine.[12] The ZOC terminal emulator gets its ability to be programmed in Rexx by means of an external interpreter, one of which is supplied with the programme, and alternate Rexx interpreters can be specified in the configuration of the programme.[13][14] The MKS Toolkit provides PScript, a WSH engine in addition to the standard Perl intepreter perl.exe which comes with the package.
VBScript, JScript, and some third-party engines have the ability to create and execute scripts in an encoded format which prevents editing with a text editor; the file extensions for these encoded scripts is .vbe and .jse and others of that type.
Unless otherwise specified, any WSH scripting engine can be used with the various Windows server software packages to provide CGI scripting. The current versions of the default WSH engines and all or most of the third party engines have socket abilities as well; as a CGI script or otherwise, PerlScript is the choice of many programmers for this purpose and the VBScript and various Rexx-based engines are also rated as sufficiently powerful in connectivity and text-processing abilities to also be useful. This also goes for file access and processing—the earliest WSH engines for VBScript and JScript do not since the base language did not,[15] whilst PerlScript, ooRexxScript, and the others have this from the beginning.
WinWrap Basic, SaxBasic and others are similar to Visual Basic for Applications, These tools are used to add scripting and macro abilities to software being developed and can be found in earlier versions of Host Explorer for example. Many other languages can also be used in this fashion. Other languages used for scripting of programmes include Rexx, Tcl, Perl, Python, Ruby, and others which come with methods to control objects in the operating system and the spreadsheet and database programmes.[16] One exception is that the Zoc terminal emulator is controlled by a Rexx interpreter supplied with the package or another interpreter specified by the user; this is also the case with the Passport emulator.
VBScript is the macro language in Microsoft Outlook 97, whilst WordBasic is used for Word up to 6, Powerpoint and other tools. Excel to 5.0 uses Visual Basic 5.0. In Office 2000 forward, true Visual Basic for Applications 6.0 is used for all components. Other components use Visual Basic for Applications. OpenOffice uses Visual Basic, Python, and several others as macro languages and others can be added. LotusScript is very closely related to VBA and used for Lotus Notes and Lotus SmartSuite, which includes Lotus Word Pro (the current descendent of Ami Pro), Lotus Approach, Lotus FastSite, Lotus 1·2·3, &c and pure VBA licensed from Microsoft is used Corel products such as WordPerfect, Paradox, Quattro Pro &c.
Any scripting language installed under Windows can be accessed by external means of PerlScript, PythonScript, VBScript and the other engines available can be used to access databases (Lotus Notes, Microsoft Access, Oracle, Paradox) and spreadsheets (Microsoft Excel, Lotus 1·2·3, Quattro Pro) and other tools like word processors, terminal emulators, command shells and so on. This can be accomplished by means of the WSH, so any language can be used if there is an installed engine.
In recent versions of the Take Command enhanced command prompt and tools, the “script” command typed at the shell prompt will produce a list of the currently installed engines, one to a line and therefore CR-LF delimited.[17][18][19]
Examples[edit]
The first example is very simple; it shows some VBScript which uses the root WSH COM object “WScript” to display a message with an ‘OK’ button. Upon launching this script the CScript or WScript engine would be called and the runtime environment provided.
Content of a file hello0.vbs
WScript.Echo "Hello world" WScript.Quit
WSH programming can also use the JScript language.
Content of a file hello1.js
WSH.Echo("Hello world");
WSH.Quit();
Or, code can be mixed in one WSF file, such as VBScript and JScript, or any other:
Content of a file hello2.wsf
<job>
MsgBox "hello world (from vb)"
WSH.echo("hello world (from js)");
</job>
Security concerns[edit]
Windows applications and processes may be automated using a script in Windows Script Host. Viruses and malware could be written to exploit this ability. Thus, some suggest disabling it for security reasons.[20] Alternatively, antivirus programs may offer features to control .vbs and other scripts which run in the WSH environment.
Since version 5.6 of WSH, scripts can be digitally signed programmatically using the Scripting.Signer object in a script itself, provided a valid certificate is present on the system. Alternatively, the signcode tool from the Platform SDK, which has been extended to support WSH filetypes, may be used at the command line.[21]
By using Software Restriction Policies introduced with Windows XP, a system may be configured to execute only those scripts which are stored in trusted locations, have a known MD5 hash, or have been digitally signed by a trusted publisher, thus preventing the execution of untrusted scripts.[22]
Available scripting engines[edit]
Note: By definition, all of these scripting engines can be utilised in CGI programming under Windows with any number of programmes and set up, meaning that the source code files for a scipt used on a server for CGI purposes could bear other file extensions such as .cgi and so on. The aforementioned ability of the Windows Script Host to run a script with multiple languages in it in files with a .wsh extension. Extended Html and XML also add to the additional possibilities when working with scripts for network use, as do Active Server Pages and so forth. Moreover, Windows shell scripts and scripts written in shells with enhanced capabilities like TCC, 4NT etc. and Unix shells under interoperability software like the MKS Toolkit can have scripts embedded in them as well.
| Engine Name | Scripting Language Implemented | Base Language | File extensions | Availability | Produced By | Status | Initial Release Date | Encoded Scripts | Notes |
|---|---|---|---|---|---|---|---|---|---|
| VBScript | Microsoft VBScript | Microsoft Visual Basic 6.0 | .vbs | Installed by default | Microsoft | default install | 1999 | Yes, .vbe | |
| JScript | Microsoft JScript | Microsoft Visual J++ 6.0 | .js | Installed by default | Microsoft | default install | 1999 | Yes, .jse | |
| VBA | Microsoft Visual Basic for Applications | Microsoft Visual Basic 6.0 | .mod, .bas, .frm, other | VBA is a standard feature of Microsoft Office products[23] | Microsoft | VBA is a standard feature of Microsoft Office products | 1999 | Unknown | |
| JScript .NET WSH Engine | Microsoft JScript | Microsoft J++.NET | .js* | .NET Framework Component | Microsoft | With various tools, .NET Framework | 2003 | Yes | May require manual install/config |
| VB.NET WSH Engine | Microsoft VB.NET | Microsoft Visual Basic.NET | .vb* | .NET Framework Component | Microsoft | With various tools, .NET Framework | 2003 | Yes | May require manual install/config |
| WinWrap Basic | WinWrap Basic | Basic | .wwb | In the main WWB installation | Polar Engineering | Standard functionality of WWB; Utilises both .NET and COM | 2004 | Yes | |
| PerlScript | Perl | Perl 5 | .pls | with ActiveState Perl | ActiveState | Open source | 1999 | Reportedly yes | |
| PScript | Perl | Perl 5, CGI functionality | .p, .ps | with MKS Toolkit | MKS | Commercial | 2001 | ||
| XBScript | xBase Scripting Engine | xBase (Clipper) | .xbs, .prg | Clipper | with XBScript sofrware | Commercial | |||
| LotusScriptWSH | LotusScript | Microsoft Visual Basic (q.v.) | .nsf | Third party download | Service Desk Plus | Freeware | 2001 | ||
| RexxScript | Rexx | Rexx | .rxs, .rx, .rex | With some Rexx implementations | Various | Freeware | 1998 | ||
| ooRexxScript | Open Object REXX | REXX | .rxs | with Open Object Rexx or free from some third parties | Open Object Rexx team | Open source | |||
| PythonScript | Python | Python | .pys | SourceForge & with ActivePython | The Pywin32 project | Open source | |||
| TclScript | Tcl/Tk | Tcl/Tk | .tcls | SourceForge | ActiveState or third party | Open source | |||
| ActivePHPScript | PHP | PHP | .phps | with PHP | PHP team | Open source | |||
| PHPScript | PHP | PHP | .phps | with PHP | PHP team | Open source | Earlier version of ActivePHPScript | ||
| RubyScript | Ruby | Ruby | .rbs | with Ruby distribution | Ruby team | Open source | Yes | ||
| XLNTScript | XLNT | DCL | .xcs | with XLNT | Advanced Systems Concepts, Inc. | Commercial | 1997 | An OpenVMSDCL-based multi-purpose scripting application for Windows | |
| LuaScript | Lua | Lua | .lua | with Lua | Lua organisation | Open Source | |||
| Object REXXengine | Object REXX | Rexx | .rex, .rxs | with IBM Object REXX | IBM | Commercial | 2002 | ||
| XML Engine | XML parsing | Extended HTML, XML | .xml | with many XML implementations | Elf Data | de facto Default install | 2000 | Macintosh too | |
| Kixtart WSH Engine | Kixtart | KixTart, MS-DOS, Windows 95. Windows NT shells | .kix | with KixStart | MicrosoftNetherlands | Windows Resource Kits and other resources | 1996 | Download from Microsoft or elsewhere, aka KixStart32 | |
| NullScript | NullScript | Null language | .ns | with NullScript | NullScript Organisation | Windows Resource Kits and other resources | 1999 | ||
| ForthScript | Forth | Forth | .fth, others | Forth | DMOZ | Open Source | |||
| Haskell Script | Haskell | Haskell | *.hsk (provisional), others | free download | Open Source | ||||
| XSLT WSH Engine | XSLT | XSLT | .xslt | free download | Open Source | ||||
| CobolScript WSH Engine | Cobol | Cobol | .cbl. .cob, .cb | Fujitsu Cobol 3 — free for educational use | Commercialware from Fujitsu free with free compiler for educators &c | Proprietary | |||
| Delphi scripting engine | Delphi | Delphi, a Pascal variant | .dlp, .del, . | In some Delphi distributions or resource kits | Commercial | 2003 | |||
| DMDScript | DMDScript | D, a major incrementation of C | .dmd | DMD Distributions, download | Freeware | Available on Web | 2014 | DMD | |
| C# Script | C# | Microsoft C#.NET | .cs. .c#, others | Source code available | Open Source, active development underway | unclear | 2013 | ||
| Small C Scripting Engine | C | C (K&R, Ansi) | .c, others | Various locations, check Web | Freeware | 2009 | |||
| JavaScript WSH Engine | JavaScript/Java | Java & variants | .java, .j, jva, others | With many JavaScript implementations | Sun/Other Java Organisations | Freeware | |||
| Take Command WSH Engine | 4NT/Take Command | TCC, the current version of 4NT p | .btm, .cmd, bat, others | Check JP Software | JP Software | Proprietary | 2015 | Early development | |
| 92Script WSH Engine | TI-89/92+/Voyager 200 TI-Basic | Calculator TI-Basic | .92bs | Project Web/FTP site | Various independent programmers | Experimental, Open Source | 2014 | “possible” | Beta Q4 2015 for main engine; graphing functionality (92Script/Tk) then or later |
| 48Script WSH Engine | HP-48 Calculator family on-board programming language | HP 48 Programming Language, distant relative of Forth, Basic, Lisp | .48s | Project Web/FTP site | Various independent programmers | Experimental | 2015 | Planned | Status as of 2015-09-30. Language has Lisp, Basic, Forth, and other influences. |
| Fortran Script | Fortran | Fortran 77 | .for, .ftn. f77, f90, f95 | Various | Various | Experimental proof-of-concept, academic exercise, shareware, commercial, open source. | 2000 | ||
| PascalScript | Object Pascal | Pascal 7 | .pas, .ops, other | Object Pascal | RemObjects | Freeware | 2001 | Can also be used with Delphi directly | |
| Lisp WSH Engine | Lisp | Lisp | .lisp, .lsp | Various Lisp tools | AutoLisp and others | Freeware or Shareware | |||
| BESEN | ECMA-JavaScript | Java and Variants | .bes, .bsn, others | SourceForge | BESEN Organisation | Open Source | 2011 | ||
| ECMAScript WSH engines | Java and Variants | Various | Various | Various | Various | Experimental, Freeware, Open Source, Shareware, Proprietary, Commercialware | 2005 | There are numerous ECMAScript implementations but not all have WSH engines | |
| CFXScript WSH Engine | Casio CFX-9850 and fx Calculator series on-board programming language | Casio Calculator Programming Language, as ported to various operating systems as CFW | .cfxb | Project Web/FTP Sites | independent programmers | Experimental | 2015 | Planned[24] | Status as of 2015-09-30. Language has elements of Basic, Forth, Fortran, and others. |
| SharpCalcScript WSH Engine | Sharp graphing calculators on-board programming language | Sharp S-Basic as ported to windows as NeusSFortran | .scsb | Project Web/FTP Sites | independent programmers | Experimental | 2015 | Planned | Status as of 2015-09-30. Also subsumes the S-Basic language of Sharp’s Pocket Computers. |
There have been suggestions of creating engines for other languages, such as LotusScript, SaxBasic, BasicScript, KiXtart, awk, bash, csh and other Unix shells, 4NT, cmd.exe (the Windows NT shell), Windows PowerShell, DCL, C, C++, Fortran and others.[25] The XLNT language[26] is based on DCL and provides a very large subset of the language along with additional commands and statements and the software can be used in three ways: the WSH engine (*.xcs), the console interpreter (*.xlnt) and as a server and client side CGI engine (*.xgi).[27]
When a server implementing CGI such as the Windows Internet Information Server, ports of Apache and others, all or most of the engines can be used; the most commonly used are VBScript, JScript, PythonScript, PerlScript, ActivePHPScript, and ooRexxScript. The MKS Toolkit PScript programme also runs Perl. Command shells like cmd.exe, 4NT, ksh, and scripting languages with string processing and preferably socket functionality are also able to be used for CGI scripting; compiled languages like C++, Visual Basic, and Java can also be used like this. All Perl interpreters, ooRexx, PHP, and more recent versions of VBScript and JScript can use sockets for TCP/IP and usually UDP and other protocols for this.
Version history[edit]
| Windows version | Shipped with WSH version | Last redistributable version |
|---|---|---|
| Windows 95 | None (separate redistributable) | 5.6 |
| Windows NT 4.0 | None (separate redistributable) | 5.6 |
| Windows NT Server 4.0 | None (separate redistributable) | 5.6 |
| Windows CE 3.0 | 1.0 (optional install on installer disc) | 2.0 |
| Windows 98 | 1.0 | 5.6 |
| Windows 98 Second Edition | 1.0 | 5.6 |
| Windows 2000 | 2.0 (also termed WSH 5.1) | 5.7 |
| Windows 2000 Server | 2.0 (also termed WSH 5.1) | 5.7 |
| Windows 2000 SP3, SP4 and SP5 | 5.6 | 5.7 |
| Windows Me | 2.0 (also termed WSH 5.1) | 5.6 |
| Windows XP | 5.6 | 5.7 |
| Windows XP SP3 | 5.7 | Not applicable |
| Windows Server 2003 | 5.6 | 5.7 |
| Windows Vista | 5.7 | Not applicable |
| Windows Server 2008 | 5.7 | Not applicable |
| Windows 7 | 5.8 | Not applicable |
| Windows Server 2008 R2 | 5.8 | Not applicable |
| Windows 8 | 5.8 | Not applicable |
| Windows Server 2012 | 5.8 | Not applicable |
| Windows 10 | 5.812 | Not applicable |
| Windows Server 2016 | 5.812 | Not applicable |
The redistributable version of WSH version 5.6 can be installed on Windows 95/98/Me and Windows NT 4.0/2000. WSH 5.7 is downloadable for Windows 2000, Windows XP and Windows Server 2003. Recently[when?], redistributable versions for older operating systems (Windows 9x and Windows NT 4.0) are no longer available from the Microsoft Download Center.
Since Windows XP Service Pack 3, release 5.7 is not needed as it is included, with newer revisions being included in newer versions of Windows since.
What is the difference between CMD and Powershell?
On the first look PowerShell is pretty similar to cmd. They are both used to run external programs like ping or copy, and give you way to automate tasks by writing a script/batch file.
But PowerShell is a lot more than that.
First of all it provides a very rich set of commands (calleds cmdlets) that integrate deeply with windows and most of Microsoft products. Cmdlets like Get-Process which lists active processes.
Another big difference is that the output of this command is not just text, it’s collection of objects. This is way superior to outputting just text, because you can easily query any property of the object, like its name or memory consumption. In cmd you’d have to parse the output.
Another great thing about PowerShell is its integration with .NET. You can easily use all the classes defined in .NET to program any functionality cmdlets are missing.
You can also integrate the powershell runtime into .NET applications with ease and consume Output PowerShell obkects directly.
All in all, PowerShell is cmd on steroids that let’a you automate and manage Windows more easily.
Answer:
The simple answer is that PowerShell is object-oriented, and cmd.exe is string-based. But that’s glossing over the “why is this not just different, but BETTER?”, which is the underlying question.
PSH can create .NET objects on the shell and allow the user to interact with them.
I can, interactively, open an XML file, browse into it using DOM (ParentNode.ChildNode.ChildNode.Attribute), using XPath (SelectSingleNode(“//host”), or [XML] class methods (GetParentNode()), edit it with $xml.CreateElement()/$node.AppendChild(), save it, and fire up in Visual Studio. Interactively.
Normally, I would have to write a program to do it, compile it, run it, (wait for it to bomb out), and then manually open the file in VS.
I can write a script to fire up a new Internet Explorer, have it navigate to a URL, then start filling out fields in forms and expand dynamic content (with great difficulty) using COM automation. Or do the same thing in Excel – take a CSV file, dump it into Excel, reformat it (this table style, add these formulas, that column width) and save it.
I can resize the console window. Or change the title. Or increase the buffer (really? Only 300 lines by default?) Or copy the contents of the buffer, complete with colors.
Answer:
CMD is the older “shell” or “batch” language going back in some form (command.com) to the original DOS operating system.
PowerShell is the new and vastly improved shell and programming language first made available as an add-on and now included (and now enabled) in the Windows operating systems.
While CMD is technically a “programming language” it is a very poor one where it is difficult to define general purpose variables, assign those values, and to use modern control structures.
For example CMD includes “if/then/else”, call (subrouting label or batch file), and an odd form of “for” (really a “foreach”) loop but other than that is largely dependent on “goto” while PowerShell has a excellent flow of control structures.
PowerShell was designed to off an EFFECTIVE superset of CMD functionality which it come close to doing directly AND it can call CMD for anything that isn’t available directly.
PowerShell supports not only calling CMD as an “external program” but calling any other pre-existing or new program as an external extension to its own functionality.
PowerShell has direct access to almost all of DOTNET, and easy access to COM and even C#, F# and other DOTNET languages.
PowerShell passes and returns OBJECTS (structured data with methods, events, and properties) to other commands and returns these objects from most commands as well while CMD produces only text.
This idea of ‘objects’ is extremely important as is removes the need to “parse” results based on line position or characters on the lines – -instead one merely queries the objects for the properties available.
PowerShell also now includes LITERALLY THOUSANDS of functions, cmdlets, and other funtionality and is extemely extensible.
PowerShells regular expressions are comparable to those in Perl, or perhaps arguably more powerful can capable. One of the main things about regular expresions in Perl is that besides being very extensive they are a NATURAL part of the language — PowerShell comes close to this ideal of integration established by Perl for regular expressions.
PowerShell includes extensive and excellent error handling.
PowerShell includes extensive, extensible, and excellent Help.
PowerShell’s main deficiencies are these:
- Not available by default on every version of WIndows still commonly in use (Win2003/XP
- Not enabled even when present until the latest versions of Windows — Win2012 and Windows 8.
Answer:
Cmd is an antiquated CLI that mainly executes console programs that live on your file system, and processes the output they provide as text. Powershell is an object oriented shell/programming language that processes objects. It uses a ‘pipeline’ approach, much like bash, except instead of processing text in the pipeline, it processes objects. This allows you to call upon that object’s properties and methods, making it a very powerful tool to have in the toolset. It’s a .NET language, so you can actually build full featured apps with it, like Windows Forms apps, WPF apps etc, as well as more traditional scripts.
Powershell can also invoke the same command line utilities that CMD does, such as ping or netstat, but it also has Cmdlets. Cmdlets are not console programs, but actually functions that either live inside compiled DLLs on your system, typically written in C#, or Powershell based functions that live inside Powershell modules.
Powershell can do everything CMD does and much, much more. In fact one of its primary purposes was to replace both CMD, batch files and vbScripts.
Answer:
CMD is basically an updated version of DOS prompt. It’s very simple, and its only commands are related to file management (which is not needed anymore as we have Windows Explorer), everything else is done by executing .exe files or other batch files which are made of the same commands. Powershell, on the other hand, is designed for automation. It has much more advanced commands which can often do what you can’t do with CMD, or which is incredibly hard to do with it. For example, the command Add-AppxPackage installs a Windows Store application from an .appx file – that’s called sideloading. This action is very complicated because of the nature of Windows Store apps, which are deeply itegrated with Windows Store and the shell itself. It can’t be done with CMD at all.
Powershell also has a more advanced support for variables, objects, making it as powerful as other scripting languages. Batch is also technically a scripting language, but it only has very simple functionality: even loops need to be implemented using the “goto” command, which is one of the many things that make the code hard to read.
Answer:
You can run CMD commands in Powershell, but not the opposite.
POwershell is much more powerful and allows a much more modern and sound scripting.
Then Powershell uses object, not strings.
In other words, you can take the output of a command and reuse it in other commands much more easily than how you’d do with a traditional CMD.
Then Powershell comes from C#, so it’s much more powerful as a programming tool.
Answer:
Just some additional information, since powershell is integrated with .net so you can do some inline c# with powershell to make it even more powerful which you can never have a chance with cmd prompt. Also it can start jobs to make parallel processing of different {script block}.
Answer:
There’s a fairly large difference between these two. At the end of the day, they both execute sequences of actions; PowerShell is an extreme evolution past CMD, much more in line with what a ‘proper’ shell should be.
PS is great for its integration with .NET.
Answer:
roughly 30 years of progress in scripting languages.
Really, cmd has not any significant progress since the DOS era. It was replaced, first by Windows Scripting Host and now by powershell.
I seem to vaguely recall QBasic and earlier dialects.. not sure where those fit in. At least you could rename files across directories.
Answer:
PowerShell has a pipeline based on typed .NET objects, while cmd (and most other command line processors, like Unix based shells, usually) have a pipeline based on strings of characters.
Command Prompt vs. PowerShell: What Are the Differences?
Being a Windows user, you don’t have to deal with the command line interface for daily activities. That being said, for any advanced tasks the command line provides greater flexibility and control over the task. In fact, that’s the sole reason why Windows has both the Command Prompt and PowerShell. Since both are command line interfaces, the PowerShell and Command Prompt may look similar at first glance. But there are significant differences between both of them. Let us get to know what PowerShell and Command Prompt actually mean and how PowerShell differs from Command Prompt.
What is Command Prompt
Command Prompt is the default command line interface provided by Microsoft starting from Windows NT (Windows NT 3.x and above). It is a simple win32 application that can interact and talk with any win32 objects in the Windows operating system. It has a user-friendly command structure and is widely used to execute batch files, troubleshoot Windows problems, perform advanced actions, get information, etc. Due to its user interface and command line structure, many call it “the DOS prompt,” though it doesn’t have anything to do with MS-DOS.
What Is PowerShell
The first version of PowerShell, which is based on the .NET framework, was released way back in 2006 and is much more advanced than the Command Prompt. PowerShell has many different advanced features like command piping, task automation, remote execution, etc.
On the other hand, PowerShell deeply integrates with the Windows operating system while still providing interactive command line interface and scripting language. Considering the deep integration and support for the scripting language, it is often used by system administrators and IT professionals to perform task automation and configuration management.
How PowerShell Differs from Command Prompt
The PowerShell is much more advanced in terms of features, capabilities and inner workings when compared to the legacy Command Prompt. In fact, almost every under-the-hood module of Windows can be exposed by PowerShell, thus making it a useful tool for IT professionals, system administrators, and power users.
When I say PowerShell, most of you may think of the standard command-line interface, but Windows also comes with PowerShell ISE (Integrated Scripting Environment) which helps you create custom and complex PowerShell scripts for all kinds of works.
Moreover, PowerShell uses what are known as cmdlets. These cmdlets can be invoked either in the runtime environment or in the automation scripts. Unlike the Command Prompt or even the *nix shell, the output generated from a cmdlet is not just a stream of text (strings) but a collection of objects.
Since PowerShell treats them as objects, the output can be passed as an input to other cmdlets through the pipeline. This allows you to manipulate the data as much as you want without seeking the help of complex Reg expressions. This is just not possible in the Command Prompt.
When you compare all this to the legacy Command Prompt, you will find it painfully inferior to the PowerShell in terms of both functionality and how much you can do with it.
But all this power of PowerShell comes at a cost; that is the learning curve. If you don’t mind the steep learning curve, then do give PowerShell a try. Of course, if you are entering into the realm of system administration, then you definitely need to learn PowerShell to make your life easier.
If you are an average Windows user who hardly uses the Command Prompt, then you might not get much out of the PowerShell.
What problem did MS solve by creating PowerShell? [closed]
8
I’m asking because PowerShell confuses me.
I’ve been trying to write some deployment scripts using PowerShell and I’ve been less than enthused by the result. I have a co-worker who loves PowerShell and defends it at every turn. Said co-worker claims PowerShell was never written to be a strong shell, but instead was written to:
a) Allow you to peek and poke at .NET assemblies on the command-line (why is this a reason for PowerShell to exist?)
b) To be hosted in .NET applications for automation, similar to DCOP in KDE and how Gnome is using CORBA.
c) to be treated as “.NET script” rather than as an actual shell (related to b).
I’ve always felt like Windows was missing a decent way to bang out automation scripts. cmd is too simplistic in many cases, and WSH is too obtuse (although the combination can be used successfully, I’m not a fan). When I first heard about PowerShell I felt like Windows was finally getting a decent shell that would be able to help with automation of many tasks, but recent experiences, and my co-worker, tell me otherwise.
To be clear, I don’t take issue with the fact that it’s built on .NET, or that it passes objects around rather than text (despite my Unix background :]), and I’m not arguing that PowerShell is useless, but from what I can see, it doesn’t solve the problem I was hoping it would solve very well. As soon as you step outside of the .NET/Powershell world, things quit being nice and cozy for you.
So with all that out of the way, what problem did MS solve by creating PowerShell, or is it some political bastard child as I suspect? I’ve googled and haven’t hit upon anything that sufficiently answered that for me, but the more citations the better.
Answer:
PowerShell was actually built as several things: A mature and extensible automation platform and a modern administration shell.
The former is primarily used for the administration GUIs for Exchange and other server products of recent times. The GUI is just a wrapper around PowerShell which does the heavy lifting behind (kind of like UNIX GUI programs come to be, as a wrapper for a commandline program).
Jeffrey Snover (PowerShell inventor) elaborates a little on how PowerShell was created with which goals and problems it should solve.
In my opinion, PowerShell as a shell is clearly intended as a replacement for cmd (easy to see) and Windows Script Host (Windows Script Host didn’t get much attention in recent years, even though it had similar concepts as .NET back in its day [one platform, multiple languages with ActiveScripting], but with .NET Microsoft basically put that to rest and resurrection probably wasn’t an option for them).
It unifies most aspects of Windows administration in common concepts and methods you only have to learn once. Also, the power in PowerShell for me stems greatly from it passing around objects which might explain why you get into problems when you step out of the .NET/PowerShell world where you only get a String[] from a command. But for many things you would call an external program for in cmd, there is a cmdlet which will do it for you.
Answer:
As a developer, I can tell you I no longer have a bunch of ConsoleApplication42 projects laying around in a folder.
As a developer at a small company where I pretty much do all things IT (DBA, manipulate routers, pull call detail records from the switch, monitor and graph bandwidth for customers, etc…) I can tell you that PowerShell fills a sorely needed gap in Windows and the fact that it’s built on .NET provides a seamless upgrade path when the PowerShell pipeline is too slow to handle millions of iterations or a more permanent, strongly typed implementation is needed.
Anyway, I guess the question is why are you switching to PowerShell if you don’t have a pressing need? I mean it’s good to learn it now since it’s basically the new management interface for all things Microsoft. But if that doesn’t affect you then don’t bother if you don’t think you’re gaining anything.
EDIT (In response to comments below)
It sounds like you’re trying to use the .NET Process class to launch an exe and redirect it’s stdout so it can be read by the caller. I agree that is a pain in .NET but fortunately PowerShell does all this for you pretty simply. As for capturing the result and still writing it to the display, that’s pretty simple too though the command isn’t a very well-known one because it isn’t used that often. Here’s an example:
# I always find it easier to use aliases for external commands
Set-Alias csc C:\Windows\Microsoft.NET\Framework64\v3.5\csc.exe
# Create some source file
Set-Content test.cs @"
class Program {
static void Main() {
System.Console.WriteLine("Hello World");
}
}
"@
# Call CSC.EXE
# the output of csc.exe is written to results.txt and piped
# to the host (or select-string if you prefer)
csc test.cs | Tee-Object -file results.txt
# Check for errors
if ($LASTEXITCODE) {
# this is where community extensions would come in
# handy. powershell 2.0 also has a command to send
# mail but in 1.0 you can grab one from poshcode.org
}
Disadvantages of Windows PowerShell
Windows PowerShell is a task-based command-line shell and scripting language designed especially for system administration that is used by information technology professionals on a regular basis. Although it is developed by Microsoft and is widely available, it does have some potential drawbacks that IT professionals may not appreciate. If you are learning how to use the language, issues could arise at some point.
Object-Based
One of the potential disadvantages of using Windows PowerShell is that it is object-based. With most shells, you rely on text-based commands to get the job done when writing scripts. If you switch to Windows PowerShell from some other type of shell, you’ll have to get used to a different way of thinking about things. This can be a problem that takes some time to get past for some users.
Security Risks
Another potential drawback of using Windows PowerShell is that it can create some potential security risks. Many IT professionals use it as a way to connect remotely to other computers and servers. When engaging in this process, PowerShell can leave some holes open for security breaches. This creates a potential for viruses, malware or other harmful programs to be installed in the server. If someone else who knows Windows PowerShell gets involved, it could cause problems.
Web Server
Another issue with Windows PowerShell is that it requires you to run a Web server on your server when utilizing remote functionality. This takes up additional space on a server. In many cases, companies will not want to take up more room and designate more resources to this on their own servers. If you are an IT professional working for a company, you may have to get approval from a higher-up before this is allowed.
Considerations
Although Windows PowerShell does have some potential drawbacks, it also has a few advantages. For example, since it is developed by Microsoft, it is being integrated more and more into Microsoft products and services. Windows PowerShell is also versatile and easy to administrate once you learn the basics of the scripting language. It also gives you the ability to run specific commands that are designed to run only on local networks if you are using the remote connection function.
How PowerShell Differs From the Windows Command Prompt
Windows 7 added PowerShell, a more powerful command-line shell and scripting language than the Command Prompt. Since Windows 7, PowerShell has become more prominent, with it even becoming the default choice in Windows 10.
PowerShell is more complicated than the traditional Command Prompt, but it’s also much more powerful. The Command Prompt is dramatically inferior to shells available for Linux and other Unix-like systems, but PowerShell competes favorably. In addition, most Command Prompt commands are usable in PowerShell, whether natively or through aliases.
How PowerShell Differs From the Command Prompt
RELATED: 5 Cmdlets to Get You Started with PowerShell
PowerShell is actually very different from the Command Prompt. It uses different commands, known as cmdlets in PowerShell. Many system administration tasks — from managing the registry to WMI (Windows Management Instrumentation) — are exposed via PowerShell cmdlets, while they aren’t accessible from the Command Prompt.
RELATED: Geek School: Learning How to Use Objects in PowerShell
PowerShell makes use of pipes—just as Linux does—that allow you to pass the output of one cmdlet to the input of another cmdlet. Thus, you can use multiple cmdlets in sequence to manipulate the same data. Unlike Unix-like systems—which can only pipe streams of characters (text)—PowerShell pipes objects between cmdlets. And pretty much everything in PowerShell is an object, including every response you get from a cmdlet. This allows PowerShell to share more complex data between cmdlets, operating more like a programming language.
PowerShell isn’t just a shell. It’s a powerful scripting environment you can use to create complex scripts for managing Windows systems much more easily than you could with the Command Prompt.
The Command Prompt is essentially just a legacy environment carried forward in Windows—an environment that copies all of the various DOS commands you would find on a DOS system. It is painfully limited, can’t access many Windows system administration features, is more difficult to compose complex scripts with, and so on. PowerShell is a new environment for Windows system administrators that allows them to use a more modern command-line environment to manage Windows.
When You Would Want to Use PowerShell
So, when would an average Windows user want to use PowerShell?
RELATED: How To Troubleshoot Internet Connection Problems
If you only rarely fire up the Command Prompt to run the occasional ping or ipconfig command, you really don’t need to touch PowerShell. If you’re more comfortable sticking with Command Prompt, it’s not going anywhere. That said, most of those commands work just fine in PowerShell, too, if you want to try it out.
RELATED: How to Batch Rename Multiple Files in Windows
However, PowerShell can be a much more powerful command-line environment than the Command Prompt. For example, we’ve shown you how to use the PowerShell environment built into Windows to perform a search-and-replace operation to batch rename multiple files in a folder—something that would normally require installing a third-party program. This is the sort of thing that Linux users have always been able to do with their command-line environment, while Windows users were left out.
However, PowerShell isn’t like the Linux terminal. It’s a bit more complicated, and the average Windows user might not see many benefits from playing with it.
System administrators will want to learn PowerShell so they can manage their systems more efficiently. And if you ever need to write a script to automate various system administration tasks, you should do it with PowerShell.
PowerShell Equivalents of Common Commands
Many common Command Prompt commands—from ipconfig to cd —work in the PowerShell environment. This is because PowerShell contains “aliases” that point these old commands at the appropriate new cmdlets, running the new cmdlets when you type the old commands.
We’ll go over a few common Command Prompt commands and their equivalents in PowerShell anyway—just to give you an idea of how PowerShell’s syntax is different.
Change a Directory
- DOS:
cd - PowerShell:
Set-Location
List Files in a Directory
- DOS:
dir - PowerShell:
Get-ChildItem
Rename a File
- DOS:
rename - PowerShell:
Rename-Item
To see if a DOS command has an alias, you can use the Get-Alias cmdlet. For example, typing Get-Alias cd shows you that cd is actually running the Set-Location cmdlet.
SomaBright 