Microsoft Says VBScript Will Be Ripped From Windows In a Future Release (theregister.com) 79
Thomas Claburn reports via The Register: Microsoft has stopped developing VBScript after a 27-year relationship and plans to remove the scripting language entirely in a future Windows release. The Windows biz said on Monday that VBScript, short for Visual Basic Scripting Edition, has been deprecated in an update to its list of "Deprecated features for Windows client." "VBScript is being deprecated," Microsoft said. "In future releases of Windows, VBScript will be available as a feature on demand before its removal from the operating system."
VBScript debuted in 1996 and its most recent release, version 5.8, dates back to 2010. It is a scripting language, and was for a while widely used among system administrators to automate tasks until it was eclipsed by PowerShell, which debuted in 2006. "Microsoft Visual Basic Scripting Edition brings active scripting to a wide variety of environments, including Web client scripting in Microsoft Internet Explorer and Web server scripting in Microsoft Internet Information Service," Redmond explains in its help documentation. Unfortunately, Microsoft never managed to get other browser makers to support VBScript, so outside of Microsoft-exclusive environments, web developers tended to favor JavaScript for client-side tasks.
VBScript debuted in 1996 and its most recent release, version 5.8, dates back to 2010. It is a scripting language, and was for a while widely used among system administrators to automate tasks until it was eclipsed by PowerShell, which debuted in 2006. "Microsoft Visual Basic Scripting Edition brings active scripting to a wide variety of environments, including Web client scripting in Microsoft Internet Explorer and Web server scripting in Microsoft Internet Information Service," Redmond explains in its help documentation. Unfortunately, Microsoft never managed to get other browser makers to support VBScript, so outside of Microsoft-exclusive environments, web developers tended to favor JavaScript for client-side tasks.
wat (Score:4)
I thought the whole premise behind Windows was backwards compatibility. They screwed that up already with failing to run 16 bit windows applications, which they absolutely could have supported in any of several ways. If it's not going to run your antique software that I can run in an emulator or virtual machine on top of any OS that's a real failure that makes modern Windows on the bare metal less valuable.
Re: (Score:3)
16 bit software will run on Windows today, but only on 32-bit versions of Windows. My non-expert understanding is this is because of a silicon limitation in how thunking is handled, but I don't know enough to know if that's true or not.
Re:wat (Score:5, Interesting)
Re: (Score:3)
This is true. When I first heard that Windows no longer supported 16 bit applications it was several years after the fact. The unreasonable nerd in me wanted to be outraged but fact is I never even noticed so I guess it was pretty reasonable.
There are definitely people who need 16 bit applications but mostly because they’re running expensive industrial or laboratory hardware and most of those sorts of situations are worth someone’s while to try dosbox, virtualbox, or running old (hopefully) i
Re: (Score:2, Informative)
This is true. When I first heard that Windows no longer supported 16 bit applications it was several years after the fact. The unreasonable nerd in me wanted to be outraged but fact is I never even noticed so I guess it was pretty reasonable.
There are definitely people who need 16 bit applications but mostly because they’re running expensive industrial or laboratory hardware and most of those sorts of situations are worth someone’s while to try dosbox, virtualbox, or running old (hopefully) isolated hardware and really aren’t worth microsoft’s time.
It seems like that's a very bad business idea. 10 years ago I did a contract job for a company...it was ~2013 and they were *still* running Exchange 2000. They specially asked Microsoft to fix a daylight saving time "bug" because they intended to continue running Exchange 2000....because some shitty ancient reporting app that tied into their hundreds-of-millions-of-dollars industrial machine was no longer updated or supported. The guy who built it died.
I heard a few years ago that they got breached bec
Re: (Score:2)
Like I said...running ancient shit with no plan to update it seems like a really dumb business idea.
I worked at a place that was sort of cutting edge for their industry in the 1980s. Being sort of a hick industry they rode folksy wisdom like “If it aint broke then don’t fix it” into a whole lotta mess and are reportedly still stuck on a ton of 80s tech.
"Lost the source code" - BINGO Re:wat (Score:1)
Lost the source code and can't recompile?
Or, much more likely, didn't buy a source code license and the product is discontinued.
For many applications, the solution is simple: Run a 16-bit OS in a VM. But for some types of code or some use cases, that simply is not an option.
Re: (Score:1)
Re: (Score:2)
Decent job of backwards compatibility (Score:1)
I'm still running a game from 2000 on Windows 11, and that's without any "compatibility mode."
Only thing that doesn't work without a hack is the help system, since Windows 11 doesn't support 2000-era ".hlp" files "out of the box."
Re: (Score:2)
Civ 2 CTP Multi Gold and SMACX don't work right even on Win7 x64 without patches. Civ 2 doesn't even work without patches in XP Mode on Win7 x64 either, pretty hilarious. Does work in everything else (virtualbox, vmware, etc etc.) but Virtual PC couldn't do it. Much eyeroll.
I would like better support for accelerated graphics in QEMU/KVM though. I'd donate to that. I am using libvirt and I am very happy with the compatibility and reliability, I've found it to be better than vmware in those ways.
Re: (Score:3)
CIV1 works fine on dosbox, so all is good.
Re: (Score:2)
OTDVM works well as a solution for running 16-bit windows software. It's not quite as good as the real 16-bit WOW though.
Re: (Score:1)
Dude. 16 bit windows apps are 31 years old. Get the updated binary. The windows 95 version will work. Those are 28 years old.
Re: (Score:2)
The windows 95 version will work.
There is no guarantee at all that something written for Win95 will work on a modern Windows. And guess what, some Win95 things indeed can't work on a modern Windows, except under emulation.
Not to mention that VBScript itself is a thing from the Win95 era.
Re: (Score:2)
Thats not what I was replying to. I was replying to a guy complaining about Windows 16 (Windows 3.1, basically a wrapper over DOS) apps not working. Half the people working in IT where not even born when those where still a thing.
Re: wat (Score:2)
IBM is still selling a platform that can run binaries from the sixties.
The least Microsoft should be expected to do is run binaries from the eighties.
Microsoft deliberately and unnecessarily destroyed their software's ability to run. At this point the best hope for that compatibility to come back is wine on Windows. I've tried OTVDM and it is disappointing. Of the three things I tried to run on it, all three failed.
They had a WORKING solution for that software and removed it. And you're making excuses for t
Re:wat (Score:5, Informative)
Re: (Score:1)
The way how a tab key works has nothing to do with backward compatibility.
Re: (Score:2)
There's an obscure Windows setting called Mouse Keys that allows you to control the mouse pointer by using the numeric keypad's arrow keys to move the pointer and the middle "5" key to click on something. I have used it as a mouse back-up since Windows XP; it came in handy a few times when the mouse failed and I didn't have a spare one on hand. It's also on my Windows 10 Pro system, I've just configured it now and it's active after a reboot.
Re: (Score:2)
Re: (Score:2)
Actually, it was, for a while. Compatibility Mode was well supported and was pushed hard by Bill Gates while until he left and others slowly killed it. After its dominance was assured, forward lookers gained traction.
Re: wat (Score:2)
Utter rubbish.
They have spent enormous amounts of time and treasure through the years on backwards compatibility. Not exactly at the level of IBM mainframe stuff in terms of results. But MSFTâ(TM)s problem-space is so much bigger than IBMâ(TM)s.
Are they going to let things go after awhile? Sure. There always comes a time for a difficult decision for a particular thing. But, donâ(TM)t for a minute say they donâ(TM)t try.
Re: (Score:1)
But the new bunch in charge in MS seem to be a bunch of noobs like the commenter who claimed MS didn't do backward compatibility.
Anyway the fact that you could set shortcuts etc to run stuff in various compatibility modes showed that years ago MS did care about backward compatibility.
But Raymond Chen and people like him probably lost the war or have retired: https://devblogs.microsoft.com... [microsoft.com]
One of the tidbits of information they shared with us is some numbers about the programs they have to support. Their operations division is responsible for 9,000 different install scripts for their employees around the world. That was not a typo. Nine thousand. This highlighted for me the fact that backwards compatibility is crucial for adoption in the corporate world. Do the math. Suppose they could install, test and debug ten programs each business day, in my opinion, a very optimistic estimate. Even at that rate, it would take them three years to get through all their scripts. This isn't a company that bought some software ten years ago and don't have the source code. They have the source code for all of their scripts. They have people who understand how the scripts work. They are not just on the ball; they are all over the ball. And even then, it would take them three years to go through and check (and possibly fix) each one.
So these bunch have to change 9000 scripts to powershell? And then maybe a few years later have to change 9000 powers
Re:wat (Score:5, Interesting)
Our company has literally hundreds of .vbs scripts (written in VBScript, of course) which are used to automate various things. Thanks Microsoft, I guess. What is the excuse this time? Muh security again?
Re:wat (Score:4, Insightful)
What is the excuse this time? Muh security again?
It's the same excuse: because your company has accepted the ass-reaming with cries of "more please" every time Microsoft does stuff like this. They've been encouraged by their victims to behave like this for decades, so they do.
Re: (Score:2)
I worked for a company that had hundreds of DOS WordPerfect scripts that automated document creation based on various factors. They kept those DOS WordPerfect installations around at least into the mid-2000s until they were finally forced to upgrade because Corel eventually refused to provide any support, no matter how much they were willing to pay. It cost them a small fortune to move to the newer language version, partially because they had no one around from when the scripts were written.
For the next few
Re: (Score:2)
I thought the whole premise behind Windows was backwards compatibility.
This is what is called a faulty premise.
Re: (Score:2)
This is what is called a faulty premise.
A premise Microsoft is all to happy to encourage, but randomly fail to execute.
Re: wat (Score:2)
Microsoft has always marketed Windows on the premise that it will run your Windows software.
I'm sure the transition will go smoothly (Score:5, Funny)
I mean, there's barely any VBScript left in the System32 folder these days, right?
...right?
Re: (Score:1)
Re: (Score:2)
I wouldn't miss that either.
Clippy does not appove of this action (Score:2)
as there is still no decent alternative like the ability to use Fortran to automate Office tasks.
Re: (Score:2)
That's fine, Clippy has already been removed.
Details? (Score:4, Funny)
Re: (Score:2)
It would then just be command line Javascript, not the browser Javascript.
How many uses command line Javascript today? Now people uses Python or possibly Powershell.
There might be a few programs that uses Javascript through the Windows Scripting Host. But how many are there.
After all the Windows Scripting Host has been used for a number of malware attacks throughout history.
Re: (Score:2)
Re: (Score:2)
"How many uses command line Javascript today?"
NodeJS exists. People use it.
Re: (Score:2)
Re: Details? (Score:2)
Imho uninformed opinion if they are deprecating VBScript, jscript is likely next. It is VBScript smaller brother .
Re: (Score:2)
Re: (Score:3)
Lots of Windows Installer packages use VBScript to do various things. It was always easy to add WSH scripts to Windows Installer packages. If it's removed from Windows, a lot of software will fail to install properly (or even worse, fail to uninstall properly).
This is going to break things weirdly (Score:2)
Re: (Score:1)
> I can imagine that this is going to turn into a mini Y2K problem of sorts, where most people won't know this hits something until it does.
Indeed! Many established orgs have tons of legacy DOS and VBS to automate bunches of stuff that just worked for decades. Now the Help Desk will be inundated with "hey, somebody moved my cheese!"
Re: (Score:2)
In our company, the person who wrote most of the VBScript stuff decades ago is now retired. Oh joy...
Re: (Score:1)
We have a big pile of apps written in non-supported legacy tools and where the original dev is retired. There is plan to recode them, but shiny executive toys keep getting priority. Executive turn-over is too high such that perpetrators of short-sighted decisions are usually gone by the time fit hits the shan. Shop infected with Dilbertitis.
Re: (Score:2)
Indeed! Many established orgs have tons of legacy DOS and VBS to automate bunches of stuff that just worked for decades. Now the Help Desk will be inundated with "hey, somebody moved my cheese!"
Most of this stuff has broken over time with various windows updates anyway. Don't confuse DOS and VBS with those windows that popup. In many cases they look the same as they did in the early 00s but have been re-written in Powershell.
Now the Help Desk will be inundated with "hey, somebody moved my cheese!
If Help Desk gets any calls about this then IT didn't do their job properly, testing windows releases to see if they break something in the organisation.
Re: (Score:2)
Most of this stuff has broken over time with various windows updates anyway.
I guarantee you bigger companies than you care to imagine are still using vbscript
Re: This is going to break things weirdly (Score:2)
Most of AD and SCCM scripts are written with VBScript. The licensing management (slmgr) for Windows is written in VBScript. Most printer setup are written in VBScript.
Microsoft has a long tail of legacy it needs to get rid of. VBScript is horribly insecure, it has user-land ties into kernel space and could be executed by the browser.
It would be much better for Microsoft to pull an Apple and just make a clean break with Windows and give people a VM for legacy apps.
Re: (Score:2)
You could deprecate those insecure APIs and remove it from Edge while still leaving VbScript intact in WSH though.
Re: (Score:2)
Not really, because Edge has compatibility mode with the IE6 engine which in turn relies on a lot of the ancient integrations. I've gone through these issues with tons of clients. It would be a lot safer to run each 'old' Windows app in a separate VM and build a TCP link to the less-borked Windows subsystems that need to talk to ancient drivers/scripts/software (eg. a CUPS service that talks to the current Windows print subsystem so it can address some VBS in the DLL of a print driver's post-processor).
Idea
Re: (Score:2)
Powershell is much more powerful, but almost equally exploitable. You can just wrap .ps1 scripts inside a .cmd wrapper that sets the execution policy to whatever you want it to be.
How long before Microsoft decides to disable this too?
Re: (Score:2)
Hopefully soon, that's the primary way Windows servers get hacked. You have IIS executing DLL/EXE (ASP & .NET), which if exploited can be used to get some PowerScript that then self-elevates to execution privileges even if you had none before.
Basically in Linux land this would be equivalent to running an application in an LXC or Docker container, but then any trivial PHP script can break out of that, just because in the past we had poorly implemented security and we need to keep compatibility with non-c
Re: (Score:1)
Yeah and "malware" is a lame excuse to remove VB script support. After all exes have been used for lots of malware attacks too. Is powershell going to be much safer if it's used the same way VB script is used in large organizations? So far the backward compatibility track record for powershell is crap.
Many established orgs have tons of legacy DOS and VBS
Yeah in the old days Microsoft had people (like Raymond Chen) who cared about backward compatibility AND knew such things - guess they've retired/moved or lost power:
https://devblogs.microsoft.com... [microsoft.com]
One of the tidbits of information they shared with us is some numbers about the programs they have to support. Their operations division is responsible for 9,000 different install scripts for their employees around the world. That was not a typo. Nine thousand. This highlighted for me the fact that backwards compatibility is crucial for adoption in the corporate world. Do the math. Suppose they could install, test and debug ten programs each business day, in my opinion, a very optimistic estimate. Even at that rate, it would take them three years to get through all their scripts. This isn't a company that bought some software ten years ago and don't have the source code. They have the source code for all of their scripts. They have people who understand how the scripts work. They are not just on the ball; they are all over the ball. And even then, it would take them three years to go through and check (and possibly fix) each one.
Re: (Score:2)
It's not about malware. It's about not wanting to maintain old legacy code. Which I would almost understand, if it were not the case that many if not most organizations rely on it heavily, and, if it is going away, need some reasonable way to upgrade to whatever kludge of an abomination Microsoft is willing to allow this month.
(We'll go to Powershell of course, but, since it's more powerful but equally exploitable, how do we know Microsoft won't kill that too 5 or 10 years from now, which is well within t
Re: (Score:2)
For a really long time, VBScript was one of the few things one could count on being available (and not blocked by execution policies, etc.) on more or less any reasonable Windows installation.
Ergo, it is assumed by a lot of our software to be available, and its demise is likely to cause significant problems.
So now we have to replace our scripts with something just as exploitable, but much more powerful: Powershell scripts wrapped inside .cmd wrappers that set the execution policy to something sufficiently
Re: (Score:2)
Yep, and it's becoming abundantly clear that the problem is called "Microsoft", not "vbs files".
Re: (Score:2)
"I can imagine that this is going to turn into a mini Y2K problem of sorts, where most people won't know this hits something until it does. "
Whole shops are still run with Excel and VBScript, I still know a few, nobody will touch it with a 10 foot pole.
Re: (Score:2)
You might be thinking of VBA there - VBScript and VBA aren't the same thing. VBA is the embedded VB-like scripting language in Office. VBScript is a VB-like scripting language that lets you easily manipulate COM objects. Windows Installer let you easily include VBScript, so this is going to break a lot of installers and uninstallers.
Re: (Score:2)
It happened before when Microsoft EOLed ActiveX, when then dropped it from IE and now it is long gone with Edge. This is one of the challenges of basing yourself off propriety technologies, even if sometimes in the beginning it is the only viable option.
Re: (Score:2)
I've been trying to explain this to the management of multiple past and present employers and clients, for more than a quarter century now.
If you think you "own" a copy of a proprietary product, the reality is that it owns you.
To a lesser degree, this is true even of open-source products that that have dozens if not hundreds of recursive dependencies, that may change, become incompatible, develop security issues, or simply go away if the maintainer doesn't feel like maintaining it anymore.
Re: (Score:2)
I've been trying to explain this to the management of multiple past and present employers and clients, for more than a quarter century now.
If you think you "own" a copy of a proprietary product, the reality is that it owns you.
To a lesser degree, this is true even of open-source products that that have dozens if not hundreds of recursive dependencies, that may change, become incompatible, develop security issues, or simply go away if the maintainer doesn't feel like maintaining it anymore.
Of course with open source you can fork and take ownership, though many companies may not have the skillset to do so.
Re: (Score:2)
Very true, and one of its major advantages.
But there is still risk if you do not actually have that source.
I miss ARexx on Amiga (Score:2)
The Amiga OS had official support for inter-process communications using ARexx as the scripting language, and I've always missed that since those days. It was a very cool feature.
Of course, a lot of the cool things about that OS wouldn't be so cool with the security issues modern OSs need to deal with.
In another news (Score:5, Funny)
In another news, IBM decided to deprecate and retire COBOL from z/OS, the businesses' mainframe OS of choice. Thanks COBOL, for your many decades of service, and farewell.
Can you imagine that? Me neither, except on 1st of April.
Re: (Score:2)
Why is a programming language embedded in the OS a (Score:2)
Re: (Score:1)
These days, automation and systems management mostly.
Back in the day of the 8-bit-home-PC heyday, it was built in to sell computers.
For a bit of nostalgia, here's a Commodore 64 emulator in your browser [c64online.com], READY for you to type in your own BASIC-language code and RUN it. Don't forget the line numbers!
Re: (Score:2)
Re: (Score:2)
Every single major OS has one or more programming languages embedded.
Bash, DOS (command prompt), Windows PowerShell, to name a few. Decades ago, most OSes had Basic built in. Basic used to literally BE the command prompt, on the original IBM PC, on Commodore, Amiga, and Apple.
It doesn't seem odd at all to me that a programming language would be built in.
AppleScript (Score:2)
Looks like Apple still supports AppleScript, after 30 years. For a company notorious for abandoning support this seems to have had better staying power than VBScript despite being far more obscure of a language. Admittedly AppleScript has morphed into being an automation language rather than a general purpose scripting language. But that's same niche is one that VBScript filled on Windows, so I think it's still a fair comparison.
Personally I prefer the syntax of Rexx to either AppleScript or VBScript. (does