VBScript deprecation: Timelines and next steps

https://techcommunity.microsoft.com/t5/windows-it-pro-blog/vbscript-deprecation-timelines-and-next-steps/ba-p/4148301

by bubblehack3r • 2 years ago

66 69 2 years ago

techcommunity.microsoft.com

pteraspidomorph• 2 years ago

Notably, these browsers have never implemented support for VBScript.

This reads mildly accusatory and got a chuckle out of me.

I'm surprised it took them this long!

yen223• 2 years ago

Folks who complain about Javascript don't realise how close we were to having vbscript as the dominant web language

lionkor• 2 years ago

yeah we should have a language that was built in a day instead of a week. move fast.

ksherlock• 2 years ago

In a slightly different universe, CERN gave Tim Berners-Lee a windows workstation instead of a NeXT Cube and www was built on top of Microsoft Word and VBScript.

draw_down• 2 years ago

Probably one of the most maddening things I have ever worked with, and that is saying something. Though a huge part of the blame for that goes to COM and registration, interop stuff, which is more Windows than VBScript and also probably never truly going away.

gregoryl• 2 years ago

FYI, it looks like you're hellbanned - I vouched this comment back from [dead]. Might be worth sending an email to the mods.

Edit: It's been since at least 2018?

sancarn4• 2 years ago

COM is still actively being used. Not sure why you think it's a problem with windows too. COM is and always has been quite revolutionary imo.

chem833• 2 years ago

I find PowerShell, the language, verbose and not very ergonomic. This ship has sailed, but I wish Microsoft had done something to make Windows automation a little closer to other platforms, so that it could benefit from the good software that exists on other platforms.

It seems that VBA will continue to exist as the programming front end for MS Office, which is unfortunate. They had announced Python support for Excel a while back and I wish it was better promoted as a viable VBA replacement.

bossyTeacher2• 2 years ago

PowerShell is terrible. The idea is good, the implementation bad

Someone12343• 2 years ago

Care to go into any detail at all..?

levidos• 2 years ago

PowerShell is amazing

ravenstine2• 2 years ago

I always wondered why Microsoft didn't just clone something like Bash as close as possible. Powershell was different enough from UNIX that I couldn't get myself interested in it during my phase when I was using both Windows and Linux.

lasermatts• 2 years ago

A deep chill ran down my spine as I remember all of those VBA tools I updated/generated during my first internship... some of those are still being used in some semi-industrial applications.....

kijin• 2 years ago

No worries, they probably haven't updated Excel since you left.

NoahKAndrews2• 2 years ago

Yeah, I like the ideas behind PS, but Nushell implements them so much better (it's yet to be stabilized though)

Someone12343• 2 years ago

"Nushell" has a "TODO" for half the basic features, like flow-control. Can you go into specifics about exactly what Nushell is implementing "so much better?"

Powershell is a mature offering that uses standardized (albeit verbose) naming to allow you to infer what a command should be called Verb-Noun (Get/Set/Start/Stop/etc)-(Process/Service/File/etc).

People are welcome to critique Powershell but more often than not they don't state what the problem actually is.

zamadatix2• 2 years ago

It may have a separate timeline but it does seem to hint at going out the door in similar order on Office as well. I think the Python in Excel stuff is still in beta but things like lambdas, regex or Office Scripts all actually work (even on the web versions) and start taking big bites out of why you'd want to look at VB. New Outlook dropped VB support even on the desktop and I don't think they plan on maintaining separate development platforms for the other apps forever.

Someone12343• 2 years ago

Python in Excel could have been amazing, except Microsoft executes it in a cloud environment and require a Cloud Service account to even open spreadsheets with it in.

I'd strongly recommend people avoid Python in Excel, it is a Trojan Horse into forcing you to subscribe to access your own spreadsheets.

albertopv• 2 years ago

New Outlook is just an embedded web app. I tried it for weeks, old one is still better, and least rooms calendar is updated properly.

pitaj• 2 years ago

It seems that VBA will continue to exist as the programming front end for MS Office

They already recommend that new projects use their JS-based Office Scripts instead.

sancarn4• 2 years ago

Not sure about other people but most of my apps I've made actually can't be made in Office Scripts... They are useless for my needs.

avidphantasm• 2 years ago

I don’t like the verbosity either, but have come to appreciate it as a cross-platform scripting tool for technical people who aren’t programmers. Again, it’s verbose, but more approachable for these new users than unix scripting languages. Being able to run scripts on macOS and Linux is a bonus. Given all this, I’ve come to peace with PowerShell.

ravenstine2• 2 years ago

With WSL2, is there any objective reason to write new Powershell scripts in 2024? I am genuinely curious because I barely have used Windows these days and had some brief experience with WSL2.

orthoxerox2• 2 years ago

Bash has no access to Windows internals. Some parts of Hyper-V you can configure only through pwsh, there's simply no GUI there to do it.

sterlind• 2 years ago

PowerShell lets you script Windows itself. You can configure network interfaces, set group policy settings, change registry keys, install programs, gather diagnostics, etc. etc. Linux has systemctl, Windows has Start-Service. Linux has kill, Windows has Stop-Process. Linux has ip, Windows has Set-NetworkInterface. WSL2 is just a VM - one with a ton of slick host integrations, but a VM nonetheless. Its power to do anything to Windows itself is very limited. It's also not installed by default.

Disclaimer: work for MS, not on PowerShell or WSL.

7bit7• 2 years ago

If you love awk and sed, no. If you rather work with objects, yes, absolutely.

chem833• 2 years ago

Yes, there is.

If you write bash to execute on WSL2, you’re just orchestrating the Linux VM (that runs on Hyper-V and is cleverly integrated into Windows and makes you feel like you have a native bash shell). If you want to automate Windows using bash, you need some runtime that translate all Linux-like calls to the Windows COM interface.

jasomill3• 2 years ago

In addition to the reasons already stated, WSL2 is a heavy dependency. Compared to PowerShell:

1. Typical WSL2 distros require far more disk space.

2. RAM used by WSL2 may not be immediately freed when your script exits.

3. WSL2 distros don't auto-update, so telling someone to install, e.g., Ubuntu via the Microsoft Store is insufficient to ensure a well-maintained WSL2 instance.

4. WSL2 requires enabling Windows hypervisor support, which can be difficult (KVM) or impossible (non-bare metal EC2 instances) in virtualized Windows instances.

While (1) is probably not a big deal and (2) and (3) have reasonable workarounds, (4), where relevant, tends to be a showstopper.

13of402• 2 years ago

IMO, the problem isn't that you can't use it in a terse way, it's that even though it gives you lots of options for terseness (type, cat, and gc are all aliases for get-content, for example) people naturally try to code in the canonical way and they assume that's the long-form cmdlet names. In Unix, "ls" is what you get so it has to be canonical. In PowerShell you can use ls or dir or get-childitem but there's nothing to hint which is correct to use in a proper script, so when you see example code it looks like "get-childitem | foreach-object {...}" instead of "dir | %{...}"

ygra4• 2 years ago

Scripts should not use the aliases because they can differ across machines or users. The cmdlet names are stable. That being said, for quick one-off scripts my code looks very much like my command-line usage, which is somewhere between terse and golfed.

Idiomatic PowerShell embraces the pipeline, though. The number of scripts I've seen in the wood which were haphazardly ported from VBScript or C# showed, however, that people don't care about idiomatic.

7bit7• 2 years ago

No hints?? They are by definition aliases. That ist hint enough. If in doubt, dont use the aliases.

7bit7• 2 years ago

I wish Microsoft had done something to make Windows automation a little closer to other platforms, so that it could benefit from the good software that exists on other platforms.

PowerShell is cross-platform and works und Ljnux and MacOS as well.

And it's extremely good on itself already, because everything are objects, instead of just strings (bash, etc.). And because it's .NET you can seamlessly write anything you like including kernel calls, etc. without ever needing something like a 3rd party package like you would with e.g., Python.

nozzlegear• 2 years ago

Isn’t PowerShell itself the third party package? At least on Linux and MacOS, I mean.

sancarn4• 2 years ago

They had announced Python support for Excel a while back and I wish it was better promoted as a viable VBA replacement

But the existing implementation of Python means that it's not even close to a viable replacement lmao

sancarn4• 2 years ago

good software that exists on other platforms

You mean like AppleScript?

eterm• 2 years ago

I'm glad that Microsoft takes a really long time to deprecate these things.

It's "This gets extra awkward in 3 years, and dissappears some time after that", not "This disappears in 3 months".

unnah• 2 years ago

So far I have avoided Powershell in anything distributed to end users, because execution of unsigned scripts is disabled by default in Windows. It has been easier to use VBScript or BAT files to automate basic tasks, since those scripts can be run unsigned... I suppose it is too much to hope for that Microsoft would now reconsider enabling Powershell script execution by default.

workingdog• 2 years ago

Whatever you have that's calling the Powershell script just has to tell the Powershell system that it's ok to run the unsigned script. The default is just to keep people from double-clicking rando Powershell script files and all hell breaking loose.

lowleveldesign• 2 years ago

I haven't considered the execution policy such a blocker since you may change it on the powershell.exe command line (for example, run "powershell.exe -ExecutionPolicy RemoteSigned -File script.ps1" from a bat file). Also, the default execution policies changed between PowerShell 5.x, shipped with Windows, and modern PowerShell 7.x, which you need to install separately. In 7.x RemoteSigned is the default in the server environment.

croes2• 2 years ago

I know lots of software products which use VBScript to realize application scripting

endorphine• 2 years ago

Can you share some?

croes2• 2 years ago

Seems to be favorite choice for software from german speaking countries.

The first two that came in my mind are

Enaio, a DMS and Serviceware Processes, a Helpdesk solution.

LkpPo2• 2 years ago

SyncBack

jsd1982• 2 years ago

Just ran into a Y2038 bug in some classic ASP+VBScript code in production the other day. Someone long ago wrote `Date() + 5000` to set an expiry date far in the future (5000 days). As it turns out, 5000 days from now puts us past 1970-01-01 + 2**31 seconds (2038-01-19ish) and that causes VBScript to raise an error and abort the ASP page request with a 500 error.

I raised the issue that we have about 14 years left of ASP+VBScript literally being able to execute properly and calculate dates (sans any large date additions remaining). Guess it'll be sooner than that based on this post but 14 years is definitely the upper bound if your VBScript code even touches dates.

ygra4• 2 years ago

Interesting that VBScript uses Unix time for timestamps. I would have expected something like FILETIME (NT's 1601 epoch) or OLE DateTime, which uses floating point with the integral part referring to days since 1899 and the fractional part is divided into the 24 hours of the day). Windows in general seems to have so many different date/time formats that using Unix time is quite surprising.

jmull2• 2 years ago

I wonder if I’m the one who will get stuck porting the large number of 20+ year-old asp pages we have at my day job to something else?

(Which have been working fine all this time, BTW.)

These pages are actually jscript (a variant of javascript), but we probably need to understand this to mean that’s going away as well.

xerox13ster• 2 years ago

Is Microsoft killing the script host or the script itself?

If they're only killing VBscript and not the wscript.exe/cscript.exe scripting host, then Windows probably will still run the jscript variation of a script.

wscript and cscript since XP days and especially 7 have pretty much always been capable of running either pure ES3 or ES5. I think now we're just going to lose the VB style com objects.

jmull2• 2 years ago

Sure, I get the argument.

But I really don't think we can count on all the related .dlls/COM objects to keep getting support after what is probably their main interface is killed off.

It just doesn't make sense to kill off just vbscript and not most/all of the other stuff that went along with it. I really doubt it's mainly about the language... I think it's about all that script-host/classic asp/COM stuff.

VBScript deprecation: Timelines and next steps

Related Stories