Those that have been focused on Windows for any decent amount of time will recognize that Windows has built-in support for multiple scripting languages (not including batch files, which I don’t consider to be a language — that goes for Unix/Linux shell scripts too). The three main contenders:
- VBScript. Initially created in 1996 (so almost 25 years ago), it was released as part of the Windows Script Host. It included basic language functionality, but most of the benefit came from its ability to use COM objects to interact with Windows (files, registry, processes, etc.).
- PowerShell. Built on top of the .NET Framework, this came out in 2006 and offers a tremendous amount of functionality and extensibility with lots of cmdlets, access to the full .NET Framework, and even access to COM objects.
If you look at the history and functionality of these, VBScript and JScript peaked with the release of Windows Script Host 5.1, which came out with Windows 2000 in 2001. New versions released with WSH 5.6, 5.7, and 5.8 brought only minor enhancements. You can find a description of WSH 5.6 (a.k.a. 2.0) added features such as support for parameters being passed to scripts, as well as the .WSF file format that supported including scripts into other scripts. (Needless to say, this quickly became a pre-requisite for the Microsoft Deployment Toolkit, BDD at that point, which leverages both of these features.) But good luck finding anything that describes new features in 5.7 and 5.8. So effectively, VBScript, JScript, and Windows Script Host have been unchanged since 2002. That’s a long time to be “functionally stabilized.” So if you haven’t considered moving away from these, you probably should. (There’s no immediate risk in these being eliminated, since it would likely have an app compatibility impact.)
PowerShell, on the other hand, is being updated regularly and has even expanded to other platforms. It is the de facto choice for scripting on Windows today, so it’s something definitely worth knowing. (Check out PSD if you are interested in a version of the MDT scripts transformed into PowerShell. It’s still a work-in-progress.)
Going back in time, there were some other scripting solutions that were widely used on Windows. (If you are still using any of these, it’s time to move on…)
- Kixtart. It hasn’t shown any activity for a number of years, but it is still kicking. (Did you know that initial versions of BDD used Kixstart? We decided to move to VBScript with a Hypertext Application [HTA] to phase this out.)
- WinBatch. This one is still being updated. Like Kixtart, it was used for a lot of logon scripts.
- AutoIt. While probably best known for UI automation (e.g. clicking on wizard buttons to automate software installs), it also has general-purpose scripting capabilities.
In the future, I’ll comment more on “other” scripting languages that exist more outside of the Microsoft “bubble.”
Categories: Windows 10
What’s a good alternative for AutoIT? I still use it occasionally to make executables.
LikeLiked by 1 person
Executables that do what? It would be a last resort for “button-pushing” app installers. Beyond that, it’s just another scripting tool…
LikeLiked by 1 person
Mostly because the only thing remotely resembling a Task Sequence in Intune is Win32 app dependencies. Nothing else provides any sort of sequential functionality. I cannot make a Configuration Profile or a Script dependent on a Win32 app.
For example, we just blew up Autopilot testing by adding a Device Restriction configuration profile for system proxy settings and assigning it to our regional group tags. But during ESP, the configuration profile is installing before the proxy agent Win32 app that manages Internet connectivity. Without this proxy agent app, the proxy settings sever the connection to the Internet and Autopilot dies. I now feel my only option is to delete the configuration profile, make a Win32 app that does the same thing, and make it dependent upon the proxy agent app in order to ensure these things happen in the correct order.
I’ll reply to myself 🙂 I can make a Win32 app that contains a PowerShell script and run that instead of an AutoIT executable. I’m sure I’ll find a better example at some crazy situation in the future! Have a good weekend.
Nice trip through memory lane! I used all of these at one point or another, sticking mostly to PowerShell currently.
LikeLiked by 1 person