Microsoft reminds developers VBScript really is going away

With the end of Windows 10 looming, Microsoft has reminded hard-pressed admins that other critical technologies are on the endangered list, notably VBScript. While VBScript appears multiple times throughout Microsoft's technology stack, Microsoft's latest warning specifically concerns Visual Basic for Applications (VBA) …

[martinusher]

How to Future Proof? Simple....

Don't use any Microsoft technology. In the case of scripting there's no real reason for using something like VBA except that "We've always used it". There are several standardized scripting languages out there that run on multiple platforms so always use these and always stick to the standards. Avoid proprietary extensions but if you're really forced to use them isolate them in modules with well defined high level functions.

These are the rules I've lived by. Its difficult in a team environment to convince people of the dangers of pinning your work to one platform, especially one as ubiquitous as Windows, but if nothing else the lessons of recent W10/W11 transitions and changes to licensing models should have emphasized the need to avoid single source lock in at all costs.

[Ken Hagan]

Re: How to Future Proof? Simple....

Perhaps VBScript predates all those standardised languages. It certainly goes back to the 1990s and I'm fairly sure that "JScript" was a latecomer to the party.

I'm not disputing that anyone writing new code in VBScript in the last 15 (probably 20) years has made a bad decision, but maintaining old code is legitimate, and small improvements to old code are also legitimate, so when do you turn round and tell your paymaster that it is time to take a lot of still-working code and rewrite it in a new language just in case MS move the goalposts?

[Dan 55]

Re: How to Future Proof? Simple....

Aren't MS in the process of moving the goalposts now?

[that one in the corner]

Re: How to Future Proof? Simple....

True - which means that it is *way* past time to have had The Talk with management. If you started right now, you *might* find all the places that VBScript has crept, unnoticed, into all the company workflows*, but will you replace every single one before the Final Update** that stops them all working?***

* and don't forget that "workflow" not only covers that document automation system you got 17 contractors in for, back in 1998, and still boast about, but also means the 114 "just a quickie" scripts that were done as favours to PAs, as trivial fixes for the Sales team, as just something HR needed "only for one week as we get used to things", ...

** and company policy is tight, all the machines get all the updates, except for those two that are kept off the network and run the no-longer updated UI for the machine tools (see, we *have* thought it through and allow for special-case exemptions, we won't be caught out)

*** bugger, it was 116 quickies and nobody got paid: all the bank transfers went through without a hitch, but because those dozen lines of code failed to copy the exchange rates over, the multiplier was left at zero...

[katrinab]

Re: How to Future Proof? Simple....

But if you are in the UK, the exchange rate will likely be a divider rather than a multiplier, because £1 is worth more than 1 unit of most other currencies, so it would fail with a division by zero error.

[martinusher]

Re: How to Future Proof? Simple....

You can't do anything about legacy code, you have just do your best and suck up any fall out. But this is an argument to avoid making the same mistake in the future, no matter how attractive the language offering seems to be. A typical example is that where I was working started recruiting a new test software team to take over all the ad-hoc firmware testing and New Broom style decided to write (rewrite) everything in Python. Fair enough. Except that they insisted on using a "Windows" version of Python. Not a version of Python that runs on Windows -- they all do that -- but one designed specifically for the platform that included some tweaks that would have made moving to a different platform difficult, if not impossible. That's what I regard as self-immolation -- its the sort of thing that gives you exactly zero benefits but ties you to that platform.

BTW -- Most people don't realize that Visual Basic wasn't originally a Microsoft product, it was developed independently and then sold to MSFT to add to their portfolio.

[thames]

Re: How to Future Proof? Simple....

I'm not aware of a Windows specific Python, but there is Ironpython, which is a Dot Net version of Python - that is Python written in C# and part of the whole Dot Net system. It supposedly also ran on Mono, and so would apparently run on Linux. I don't know where that stands now that Mono is no more.

I think that Microsoft eventually gave up on Ironpython as pointless as it couldn't run the many, many, Python libraries that were written in C, which is what customers actually wanted to be able to do rather than use Dot Net libraries.

The project is still semi-alive on Github, but it is way, way, behind the current version of standard Python.

The main issue with trying to port an Ironpython program to standard Python would be if it used Dot Net libraries. You would need to replace those with something else.

[Anonymous Coward]

Amazed

I was amazed about a decade ago of finding a Chinese e-commerce website that still ran on Classic ASP (i.e. VBScript). It was archaic even then.

The last time I used Classic ASP must've been almost 3 decades ago.

[David-M]

This is a really wrong move. Maintaining VBS should be part of maintaining legacy situations.

If people are using it rather than say powershell, there's probably a reason for it, like when people build a nice path and people cut across the grass and don't use the path.

From a cursory test I suspect the reason is that -

1. VBS runs without opening a large black console window (powershell seems to open an unsightly large black window with scrawl, very unhelpful for the end user experience)

2. VBS has a tiny footprint (powershell is huge just to popup hello world)

3. VBS runs instantly (powershell is sluggish)

[thames]

VBScript long predates Powershell, so people were using it because that's what they had. The standard command interpreter was a very weak and limited language, so it was very hard (or impossible) to do the sorts of things with it that people with unix/Linux systems were using bash for. VBScript filled some of the gaps on Windows.

People used VBScript because that's what they had. I used it for something once a few decades ago, and it was just awful. It's not something I would have used if I had anything better.

That doesn't mean I'm a fan of Powershell either, I'm not. The standard scripting language situation on Windows has never been very good.

[Anonymous Coward]

An anecdote

I work for a large organisation - over 300k employees worldwide. On one of the Yammer groups someone asked whether it was permitted to use Copilot to write Python code to manipulate Word documents as it would save him a lot of manual effort.

Firstly, kudos for even asking - it shows that the security reminders are sinking in. :-)

I replied saying it would be provided he checked the modules the generated code tried to import (as well as the usual other caveats). As this point he said he was in a Commercial role and had no coding background at all: the term "modules" meant nothing to him. So I sent him some links that explained the basics of modules and supply chain poisoning.

But that isn't the answer: he'll never learn enough, quickly enough to avoid malware. It did, however, occur to me that he said he only wanted to manipulate Word files so, in this case, asking Copilot to generate VBScript is the perfect answer - all the features he needs are built in and no need for numerous modules.

So just as VBscript find a new lease of life, MS wants to kill it. Great.

[Cliffwilliams44]

#1: Wrong! You can run PowerShell scripts without showing that console! You can run PowerShell and use forms! You can even create a web application in PowerShell (Pode).

#2: Wrong again! PowerShell core 7+ is under 2 MB without any module loaded.

#3: Strike 3! If you need to do anything the least bit extensive in VBScript it's a snail! I know, I've written many, many VBScript scripts over my 30-year career! Poor performance in PowerShell is 100% the fault of the author! There are many techniques that work well from the command line for convenience's sake that will drag your script down. Overuse of piping, using += to add items to a large array, using extensive string concatenation using + or +=. The list goes on! There are better, faster ways to handle all these situations. Don't blame the hammer because you are using it backwards!

[David-M]

For reference my test was on this 2-line .ps1 file -

Add-Type -AssemblyName System.Windows.Forms

[System.Windows.Forms.MessageBox]::Show('Hello, World!')

#3 obviously I'm referring to basic to moderate tasks - VBScript is instant, powershell isn't on my test.

#1 this would be news to people on the web where I found people unable to find ways to run powerscript without the console, I checked to see if AI could find a way and it couldn't. Perhaps you can suggest how (or a reference)

#2 a launched .ps1 'hello world' popup (above) has a sluggist start with a large footprint; VBS is minimal. Maybe powershell is small without any module loaded but then maybe that is not an ordinary scenario where it needs user interaction, like saying a car is perfectly light without any engine.

However I will look into whether there's anything invisible in the launch that could reduce the considerations I mention...

[MyffyW]

Goodbye, old friend

As just about the only thing I ever coded in (I am not and never have been a developer), I will admit this nearly 30-year-old pussy cat probably needs putting to sleep. But it won't stop me from shedding a tear and remembering happier times even though my most recent experience has seen it shit all over the lounge carpet.

[Darkhand]

Licensing

How does MS plan to handle device registration, if it's primary method to register a device is a VBScript (namely slmgr.vbs)?

[Always Right Mostly]

Pointless deprecation

Probably an outlier here but I see zero reason to banish VBScript. Security-wise there ara a ton of ways you can inflict serious harm with PowerShell and other alternatives, in fact in ways VBScript can't even do.

Also it's vastly easier to read through VBScript code than PS and most alternatives, so vetting code gets harder.

Go on, jump in pro or con. Want to hear why I am a fool for this view.

[DarkwavePunk]

Re: Pointless deprecation

They're probably doing it because they couldn't figure out how to shove "AI" into it. Half joking...

[Cliffwilliams44]

Re: Pointless deprecation

What they are killing is VBA in the Office apps. No mention int e article what they are replacing it with.

The VBScript interpreter (cscript.exe) hasn't been "officially" supported for years. Unless they are going to declare cscript.exe a virus and have all AV software delete it, It will still function. So, if you have old VBScript script files out there, they will continue to work.

[Anonymous Coward]

Re: Pointless deprecation

I'm not clear enough on this issue to understand why you're being downvoted- it could be that you're wrong, but if so, it would be helpful if those people could explain how and why more clearly.

That said, the article does claim that "Microsoft says .vbs files will no longer be supported", so surely this refers to standalone .vbs files...?

And how would all this relate to VBScript being used as a scripting language on a Classic ASP-based system? (Yes, this is still in use, and yes it's antique and should have been retired years ago, but that's another whole kettle of fish).

[NetMage]

Re: Pointless deprecation

It appears that Classic ASP using VBScript is also deprecated but it will be available for a very long time.

VBScript in the client side browser had been deprecated and unlikely to work for quite some time without special user configuration so that should have already been move to Javascript.

Classic ASP can be moved to Javascript or re-written in something more modern such ad ASP.Net.

[NetMage]

Re: Pointless deprecation

Incorrect (though admittedly the article is very poorly written).

VBA is not being deprecated or affected.

For VBA, use of VBScript in these two scenarios will eventually be unavailable:

Scenario 1: Call a .vbs script directly from VBA.

Scenario 2: Use VBScript as typelib reference (such as VBScript regular expression)

[david 12]

End of Personal Computers

And just another nail in a coffin with the lid already well nailed down.

MS target markets are enterprise and entertainment. Neither market has any use for vbscript, and for enterprise anything that expands the attack surface is a clear negative.

I've worked with too many developers who were convinced that their own familiar scripting system (shell, python, PHP, Perl, JS, etc) was the only "right' way to do scripting, and should be smuggled into production, to have any sympathy with people who think that VBS is "inferior'. But that's what "Personal" computers were for: you could put your own stuff on it and do your own stuff.