Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Microsoft Programming Windows

VBScript's 'Deprecation' Confirmed by Microsoft - and Eventual Removal from Windows (microsoft.com) 88

"Microsoft has confirmed plans to pull the plug on VBScript in the second half of 2024 in a move that signals the end of an era for programmers," writes Tech Radar.

Though the language was first introduced in 1996, Microsoft's latest announcement says the move was made "considering the decline in VBScript usage": Beginning with the new OS release slated for later this year [Windows 11, version 24H2], VBScript will be available as features on demand. The feature will be completely retired from future Windows OS releases, as we transition to the more efficient PowerShell experiences.
Around 2027 it will become "disabled by default," with the date of its final removal "to be determined."

But the announcement confirms VBScript will eventually be "retired and eliminated from future versions of Windows." This means all the dynamic link libraries (.dll files) of VBScript will be removed. As a result, projects that rely on VBScript will stop functioning. By then, we expect that you'll have switched to suggested alternatives.
The post recommends migirating applications to PowerShell or JavaScript.

This year's annual "feature update" for Windows will also include Sudo for Windows, Rust in the Windows kernel, "and a number of user interface tweaks, such as the ability to create 7-zip and TAR archives in File Explorer," reports the Register. "It will also include the next evolution of Copilot into an app pinned to the taskbar."

But the downgrading of VBScript "is part of a broader strategy to remove Windows and Office features threat actors use as attack vectors to infect users with malware," reports BleepingComputer: Attackers have also used VBScript in malware campaigns, delivering strains like Lokibot, Emotet, Qbot, and, more recently, DarkGate malware.
This discussion has been archived. No new comments can be posted.

VBScript's 'Deprecation' Confirmed by Microsoft - and Eventual Removal from Windows

Comments Filter:
  • by Gavino ( 560149 ) on Sunday May 26, 2024 @06:54AM (#64500019)
    yet PowerShell and JavaScript aren't? Won't attackers just switch to alternatives also? Make it make sense.
    • by cascadingstylesheet ( 140919 ) on Sunday May 26, 2024 @07:15AM (#64500053) Journal

      yet PowerShell and JavaScript aren't? Won't attackers just switch to alternatives also? Make it make sense.

      But, but, VBScript is only used by old guys, and is uncool! Oh wait, I mean some valid technical reasons, mumble mumble ...

      Yeah, never really understood the VB hate. "You can write malicious code with it, and then trick people into running it!" Um, yeah ... okay.

      • I loved VBScript, I remember when you could script Corel Draw with it.
        Great fun. But I was just learning, tinkering.
        Had a job once programming PowerPoint with VB.

        For example, now, I have absolutely no idea how to automate Inkscape.
        It's possible with Python.
        Even Blender can be fully scripted in Python.
        GIMP I think it's done with Lisp? Not sure.

        But just can't be bothered learning these things anymore.

        • by jhoegl ( 638955 )
          Id say the point here is that VBS is easily transferable and ubiquitous. Anyone can learn it, and do it for free....

          Powershell is owned and controlled by Microsoft, allowing them to control many aspects of the script base.

          This isnt about retiring a script base, its about making money off the new thing.
          • You may not remember those days, but the VB5 (6?) doc actually had to be bought (MSDN I think it was called). I fondly remember taking two weeks to download it at 28kbaud.

            I know VBS is not VB. but in those years, free information was sparse once the bbs had died.

            • Reasons:
              - Cannot cloud monetize VBScript
              - Cannot sell subscription based products for VBScript
              - Cannot blame others, *cough*, Angular, React, Jquery, Bootstrap, ECMA Script spec team, ...
              - Cannot hire developers to maintain it

              Microsoft has already shown that it intends to remove C++ from its Win32 API, OS binaries, command line tools, etc.

              Consider rumor level headlines: "Microsoft is hiring for a new team, responsible for migrating C# code to Rust on Microsoft 365."

              https://www.reddit.com/r/rust/... [reddit.com]

      • by AmiMoJo ( 196126 )

        The mistake was basically the same as a bunch of other extremely unwise 90s Microsoft technologies, like ActiveX.

        VBScript could be embedded in documents. As well as making them non-portable, it meant that a simple spreadsheet or memo could exploit any weakness in the VBScript engine. Naturally, it was initially enabled by default for all documents.

        They made it so that the user needs to click to enable it, but users are idiots and will click anything to get to the next screen. Like WOPR said, the only winnin

        • VBScript could be embedded in documents.

          VB Script is only being removed from Windows. There's no announcement that it will be removed from Office.

          They made it so that the user needs to click to enable it, but users are idiots and will click anything to get to the next screen.

          Actually this only works for trusted documents. If you download some random document online it won't let you execute VBscript without jumping through some hoops to make the document trusted first. But you don't give Microsoft enough credit here. Users are typically idiots, but largely they only mash the "enable" button when something doesn't work. Largely users aren't blindly enabling macros in document

          • by Briareos ( 21163 )

            Actually this only works for trusted documents. If you download some random document online it won't let you execute VBscript without jumping through some hoops to make the document trusted first. But you don't give Microsoft enough credit here. Users are typically idiots, but largely they only mash the "enable" button when something doesn't work. Largely users aren't blindly enabling macros in documents when they expect to see a document. Not only that but this change effectively eliminated the automatic exploits that ran scripts on "AutoOpen".

            This is all fine and dandy for Word, but since they had the great idea to make changing the auto-filter and -sort only work when you enable editing this falls flat on it's face with Excel...

          • I hope so, theres a *lot* of crusty old applications that still require VB6. Ancient things customized back in the 90s when we still hadn't quite figured out that it was a bad idea, ticking away in the back of some old workshop never being replaced because the need never came up. While its undoutably great for our profession (lots of work replacing that gunk), this profession isn't whats good for us, but whats good for our clients.

            VB6 was a terrible idea from the outset, or rather a decent idea implemented

            • by vbdasc ( 146051 )

              I hope so, theres a *lot* of crusty old applications that still require VB6. Ancient things customized back in the 90s when we still hadn't quite figured out that it was a bad idea, ticking away in the back of some old workshop never being replaced because the need never came up. While its undoutably great for our profession (lots of work replacing that gunk), this profession isn't whats good for us, but whats good for our clients.

              Only applications written in VB6 require VB6, or, rather, the VB6 runtime library/libraries (possibly with minor exceptions), which is not a bad thing or a security risk per se. It's not a bad idea at all, it's just old and unsupported, abandoned by Microsoft with no reasonable migration path (VB .NET doesn't count).

              VB6 was a terrible idea from the outset, or rather a decent idea implemented terribly

              Nonsense. It was implemented extremely well, for Microsoft standards. It had almost a cult following.

              , but a lot of nonsense depends on it.

              As does a lot of still useful stuff. Unfortunately, exposing VB6-written stuff to the open In

        • by vbdasc ( 146051 )

          The mistake was basically the same as a bunch of other extremely unwise 90s Microsoft technologies, like ActiveX.

          ActiveX wasn't an "extremely unwise technology" at all. It was a huge object-oriented framework for interoperability, inter-process and inter-machine communication, packaging APIs, automation and other things. Old-timers may have heard of its original name, OLE2. Enabling Internet Explorer to process web pages with embedded ActiveX objects, now that was unwise.

          VBScript could be embedded in documents. As well as making them non-portable, it meant that a simple spreadsheet or memo could exploit any weakness in the VBScript engine. Naturally, it was initially enabled by default for all documents.

          VBScript isn't, and never was meant to be embedded in documents. You might be confusing VBScript (Visual Basic Scripting) with VBA (Visual Basic for

        • The mistake was basically the same as a bunch of other extremely unwise 90s Microsoft technologies, like ActiveX.

          VBScript could be embedded in documents. As well as making them non-portable, it meant that a simple spreadsheet or memo could exploit any weakness in the VBScript engine.

          Sure, that was a big attack vector. But it wasn't inherent to VB, it was an MS design decision. (And, let's face it, it was super useful. And It's not as though attack vectors went away when they started clamping down on that, lol. All computing is a compromise between functionality and security.)

          Anyway, I meant that I don't get the reflexive hate of the VB language and environment in itself. Okay, it has a different syntax. So what?

          My cynical nature says that the hate mostly comes from it being more huma

      • It just means that the old guy who maintained VBscript retired or died.
    • by Tony Isaac ( 1301187 ) on Sunday May 26, 2024 @08:03AM (#64500169) Homepage

      Yes, any scripting language, or any language, is an attack vector. Other languages like JavaScript and PowerShell are actively maintained by Microsoft and others, in part with constant security updates. VBScript doesn't get nearly as much attention and maintenance, making it a worse security threat than languages that *are* maintained.

      Also, unlike modern languages, VBScript never really had any security considerations built into its design.

      • unlike modern languages, VBScript never really had any security considerations built into its design.

        Why doesn't Microsoft just write a new VBscript interpreter which cares about security? Don't they have like a jillion programmers working for them? Doesn't their system have fine-grained access control on everything? Why is it yet so spectacularly insecure?

        • Re: (Score:3, Insightful)

          by BadDreamer ( 196188 )

          Because the issue is the design. Not the interpreter.

          Reworking the design would break so much old software anyway, requiring massive redesign and rewrites, that there's no win in doing so.

          And the jillion programmers have their hands full dealing with current products. Throwing money on this is pointless, and will require resources better used for something useful.

        • Adding security to the interpreter would break scripts that need insecurity to function.

          • Re: (Score:2, Insightful)

            by drinkypoo ( 153816 )

            Some things should be denied because only malware uses them, where for other things you should ask the user what they want to do. Sandbox the applications, make a fake registry and make changes there, do something clever... don't just throw up your hands and say "I can't fix this mess I've made". Microsoft has become the company of "I just can't".

            • The features that people use it for are also the features that malware use. Such as talking directly to various subsystems running as SYSTEM that manage the computer. I have VBscripts active today that do things like set volume and display resolution, changing Windows license keys is a VBscript from Microsoft. Many installers do stuff in VBscript, obviously Excel reaching out to the web and other things that it is not supposed to do because VBscript can hook into DLLs.

              • VBA and VBScript are not the same. VBScript only has Variant for a datatype and cannot call DLL functions directly, you'd need to go through some kind of separate COM tool written in a language that can. VBA is a full programming language essentially identical to VB6 minus the compiler, plus 64bit extensions and Office references already added. Removing VBS will not impact VBA, so Excel will still be able to connect to the internet and do basically anything (there's VBA code that executes inline assembly).
                • by flink ( 18449 )

                  It's been a while, so I might get the name wrong, but you can load and access any ActiveX COM object by loading it's DLL or EXE when running in Windows scripting host using GetObject:

                  Set obj = GetObject("path/to/library.dll", "namespace.objectName")
                  obj.someCall)

              • by vbdasc ( 146051 )

                The features that people use it for are also the features that malware use. Such as talking directly to various subsystems running as SYSTEM that manage the computer. I have VBscripts active today that do things like set volume and display resolution, changing Windows license keys is a VBscript from Microsoft

                That's what the account permissions and UAC prompts are for. By the way, is JScript not able to do all this?

                VBscript can hook into DLLs.

                Again, JScript can't?

                By this logic, we should remove bash from Linux distros, because users can do bad things with it.

              • Such as talking directly to various subsystems running as SYSTEM that manage the computer

                Any other program can as well. Talking to a SYSTEM process isn't inherently a security risk.

                The only way a program can't is if the target process / thread has a higher integrity level [microsoft.com] than the caller. Which is just a fancier DACL that Microsoft doesn't want the local admin to modify, don't let the marketing fool you. (Worse it's dual use. Processes / Objects created with a higher integrity level are also trusted more by the kernel, which can lead to a developer being more careless due to the mindset of t

            • Microsoft has become the company of "I just can't".

              This, of course, is after decades of lots of people telling them "You really shouldn't." You can't beat inevitability.

          • I suppose the counter argument would be that such changes would break some scripts, require rework of some, and have some work fine.

            Removing it breaks all of them, so it's not like removal is better for the users.

            Of course the answer is really that is a waste of money since they've already started a whole separate ecosystem that VBS isn't a part of.

        • Re: (Score:2, Insightful)

          by thegarbz ( 1787294 )

          Why doesn't Microsoft just write a new VBscript interpreter which cares about security?

          Better question: Why bother? Not everything ever created deserves to live in perpetuity. There are many alternate languages. Much of what used VBScript legitimately in windows can be done with a PowerShell script. There's no need to keep old shit running when better alternatives exist.

          • by Anonymous Coward

            Isnt that the crux of the problem? The current trend of replacing old with new, but without achieving feature parity or ensuring that the current known edge cases are being handled is problem for many. Yeah sure, we are grumby old people and we are resistant to change. But are you really "resisting to change" when the new version does not work for you and the old one gets decommissioned ?

            • You're begging the question. What are missing with tools currently available to you that exists in VBScript. Other than general handwaving make your case for why this well and truly depreciated language should remain. What isn't working for you?

        • Because they're cornered.

          If they do as you suggest, they probably break all compatibility with existing scripts, requiring customers to rewrite untold amounts of macros to fix stuff that "we broke" with a new Office version. And since customers are going to have to go fix thousands upon thousands of documents with hidden VBScript garbage hiding in them regardless of "new VBS" or "VBS deprecated use JS / Python / Etc." may as well get rid of the snowflake proprietary bullshit - it's gonna be the same level

      • None of the other languages offered by Windows Scripting are any more secure than another. This is just like them realizing that creating ActiveX/COM objects "is a security risk" because anyone can load a library and use its code... it's a bullshit excuse for simply not wanting to maintain it. The next bit of news will be the deprecation of the VB runtimes, which this is much more likely about

        • by Tony Isaac ( 1301187 ) on Sunday May 26, 2024 @10:52AM (#64500503) Homepage

          You must be young.

          VBScript is indeed less secure than modern scripting languages. This is because once enabled, VBScript can do *anything* it wants to. There is no fine-grained control to say "You can display an alert using VBScript, but you can't update the Registry or replace an executable." It can either do everything, or nothing.

          Newer languages are built with an understanding that certain parts of the language are riskier than others.

          • You aren't even in the conversation here. My statements were about hosted langages in the Windows Scripting API/Window Scripting Host. Running say, a python script outside of that platform has nothing to do with this conversation. What you can do with VBScript, you can do with JScript, and any other ActiveX host such as ActivePython/Perl/Tcl on and on and on

            • You are correct that VBScript's insecurity comes from its reliance on ActiveX. PowerShell, which has the capability of doing literally _anything_ that VBScript could do (because it's really .NET under the hood) is still more secure, because there are many granular security controls in place that protect sensitive areas of the operating system. VBScript has no such security protection. Further, security vulnerabilities are regularly patched in PowerShell / .NET, in a way that is not true of VBScript / Active

    • Was less about the language and more with how the ecosystem treated them.

      VBS would in various contexts, just run with unfettered access to everything. JavaScript only executes in specific sandboxed cases or if you explicitly set up node.

      Poweshell scripts aren't runnable by default unless you opt in.

      Of course, I think cmd is as trusted as VBS and I think it can throw the "run ps scrpts" switch and launch a ps scrpts.

      This may be a bit out of date, it's been a while since I messed with Windows.

      • VBS would in various contexts, just run with unfettered access to everything. JavaScript only executes in specific sandboxed cases or if you explicitly set up node
         
        You are just guessing. Wrongly, I will add. Javascript doesn't run in any more of a secure context than VBScript or any other hosted activescripting languages

    • by gweihir ( 88907 ) on Sunday May 26, 2024 @09:43AM (#64500367)

      My guess is this is a fake explanation. I think MS just wants to reduce the pathetic effort they still spend on Windows even more.

    • Itâ(TM)s probably less about what are potential attack vectors and more about what is actively maintained? This means for a matching attack vector JS would have more devs on hand to address the issue.

    • yet PowerShell and JavaScript aren't? Won't attackers just switch to alternatives also? Make it make sense.

      Simple answer to your second question: YES

      And asking M$ to 'make sense' is like asking for a glass of ice water in h3ll. Good luck with that.

    • VBScript is 32-bit, and Microsoft doesn't want to spend millions of dollars worth of developer salary to change that.

      Thus, VBScript is shoved out to sea.

  • by Anne Thwacks ( 531696 ) on Sunday May 26, 2024 @06:56AM (#64500023)
    "the downgrading of VBScript "is part of a broader strategy to remove Windows and Office features threat actors use as attack vectors to infect users with malware"

    Is not a very broad strategy ... its really only half-baked

    Why not go the whole hog, and remove Windows and MS Office - eliminating all of the malware and attack vectors?

  • I learned VBScript over JavaScript because it seemed like a good idea at the time. I found the code looked cleaner to me.

    Then it started getting dropped everywhere and I had this major project requiring an update. Ugh. It all got converted by someone else and it feels like someone stole my baby. All the logic is mine, but all my code is forgotten.

    Mind you, that was probably a decade ago. The entire thing could have been replaced again twice over by now.

    • I learned VBScript over JavaScript

      JavaScript or MS JScript?

      • I'm not sure... I've edited a few pre-existing scripts but never really learned it. Certainly not well enough to know which variant was being used.

        My career went elsewhere and I ended up as a DBA using T-SQL scripting, and when I need other scripting these days and I can't fall back to my old DOS shell scripting knowledge, I tend to use PowerShell.

        At home it's mostly Linux and while I 'get it', I'm stuck at the 'copy scripts off the Internet' stage because I don't do enough of it to bother with anything fu

        • At home it's mostly Linux and while I 'get it', I'm stuck at the 'copy scripts off the Internet' stage because I don't do enough of it to bother with anything further.

          No shame in that. There's even something to learn from the copy and paste sites - the multitude of ways to do certain tasks.

    • I used VBscript because I was doing database reporting, and the only options for Crystal Reports were VBscript or their screwed over version of VBscript which was just different enough to be even worse. I like to imagine that they've improved this since (but won't go look for fear they haven't) but at the time you couldn't even calculate a median without sorting the set yourself — they didn't offer an array sort function, so I also learned how to write a sort for that.

      Taking away VBscript instead of s

  • ...migrate applications to PowerShell or JavaScript

    That's a weird statement. PowerShell is not a programming language. Sure, you can script in it, like you can write bash-scripts, but I wouldn't list bash as a programming language either.

    I suppose I haven't written any sort of Office applications for a long time (15 years or so). I wasn't aware that JS had displaced VBA for things like Excel. Old Visual Basic (through version 6, pre .NET) and VBA were (are) nice languages for their purposes. I'm not sure that JS is any sort of improvement. I suppose the

    • by jrnvk ( 4197967 )

      ...migrate applications to PowerShell or JavaScript

      That's a weird statement. PowerShell is not a programming language. Sure, you can script in it, like you can write bash-scripts, but I wouldn't list bash as a programming language either.

      Most VBScripts I've worked with in industry are things that shouldn't have been in a scripting language to start with. So this really is just a spiritual continuation for those type of developers.

      That being said, porting to Powershell is really just a syntax change for most cases. Anything client-side should have died years ago with IE.

  • by xack ( 5304745 ) on Sunday May 26, 2024 @07:22AM (#64500069)
    Microsoft put VBScript in Internet Explorer to make IE only web pages such as Windows update. Luckily for us Techies liked Mozilla (the original browser that's now Seamonkey) so much that the trick failed and paved the way for Webkit at as well.
  • It seems like just yesterday that I was cobbling something together in GWBasic because VBScript didn't come with OSes as old as I was trying to minimize dependencies installed on lab boxes.
  • Reminds me of when I was asked to convert all the Excel spreadsheets an insurance company had into something open.
    Yeah, I am glad I ended up running away from that.
    But no worries! Because this time, Ai Copilot will convert it all to Javascript for you! And then execute it in Office 365 / Azure / some unholy insecure mess where your code is used for training that of other companies! But it is safe! Yeah.. I mean one character wrong and it will totally barf.
    I hope they practice on COBOL first and see how far

  • by zephvark ( 1812804 ) on Sunday May 26, 2024 @08:39AM (#64500233)

    With modern computer speeds and capacity, there's no reason Windows can't be backwards-compatible all the way back to MS-DOS 1.0 but, then you might find that you can keep using your existing software. What a $hame that would be. What a convenience for customers! Why, you could easily run TRS-80 and Apple II programs, and why not CP/M?

    In The Olden Days, you'd have to get software designed specifically for your machine. Now, there's no reason your machine can't run all the software. Atari, Amiga, Commodore PET, VAX VMS, whatever amuses you.

    Of course, those are nasty retro programs that are INHERENTLY DEFORMED! You need our new 128-bit computer with OOPsy AI programming! You do. More importantly, Microsoft needs more money.

    • What a one-dimensional view. Nothing good comes from maintaining endless backwards compatibility to long depreciated and non-maintained software. The security implications of that are staggering. If a few people need to spend some money pulling themselves out of the dark ages, so fucking be it.

    • With modern computer speeds and capacity, there's no reason Windows can't be backwards-compatible all the way back to MS-DOS 1.0 but, then you might find that you can keep using your existing software. What a $hame that would be. What a convenience for customers! Why, you could easily run TRS-80 and Apple II programs, and why not CP/M?

      In The Olden Days, you'd have to get software designed specifically for your machine. Now, there's no reason your machine can't run all the software. Atari, Amiga, Commodore PET, VAX VMS, whatever amuses you.

      Of course, those are nasty retro programs that are INHERENTLY DEFORMED! You need our new 128-bit computer with OOPsy AI programming! You do. More importantly, Microsoft needs more money.

      What the hell are you talking about?

      What Microsoft software to you think deprecating vbScript will drive? What's the application you're imagining that's built on vbScript that you won't be able to run the old version of anymore? Where's the "I was going to stick with my old version of X but I really, really want Windows 2027 so I'll have to upgrade X and give a fortune in upgrade licensing to Microsoft"?

      If you're going to rant, cool, but maybe rant coherently in a plausible fashion.

    • Apple once sold hardware versions [wikipedia.org] of what you're suggesting. Nobody bought them, and thus they became a forgotten curiosity from The Olden Days.

      I once used one to forward-migrate spreadsheets originally written in VisiCalc to Excel, by way of (iirc):

      1. Apple IIe Card in a 68k Mac to emulate a ProDOS hard disk so we could read the file from the 5.25" floppy, and save to the "hard disk" with a file manager app - the IIe card had drive connectors on it so you could plug in the 5.25" floppies from an Apple II.

    • Old software comes with old vulnerabilities. You want to decrease the attack vector by having less code.
  • There will be a reckoning with legacy industrial controls controls using vbscript..
  • MS will be adding the new "ability to create 7-zip and TAR archives in File Explorer". Wow, only 30+ years since anybody could do it for free on unix.
    • only 30+ years since anybody who can read could do it for free on unix. PHBs permitting!

      PHB- him say "MS product very plenty better!"

      Perhaps someone needs to explain "circle the wagons, cowboy" in words of one syllable.

  • VBscript should be opened up for a third party to maintain it. I am sure many people and companies still need it. Like everything else, it will be removed and people needing it will need to spend a lot to convert to something else.

    • Maybe somewhere along the way they'll figure out why using proprietary garbage only ends up costing them more money in the end when you want to sunset that shit.

      Next time, use something open from the beginning, instead of starting with proprietary garbage and hoping that the proprietor will be nice enough to give away their product when they've lost interest. Good luck with that.

    • Might be a solution on the horizon... it's taken 25 years but there's finally a 3rd party solution that's fully backcompatible with VB6 being developed called twinBASIC, and VBA is essentially a subset of VB6. Not complete but it's far enough along it handles large, complex programs and minus bugs can already execute all the VBS files I tried by putting in a sub main and running from the IDE. Does all the COM/ActiveX stuff, and beyond basic VBS and VB6 compat adds tons of modern language features like 64bit
  • MS is cutting off its most valued clients who refuse to change. 1) Lawyers and Judges. They have scripts to do name changes on templates and court forms developed over 30 years. 2) PR drones: Have scripts to intert voters names and tell them they care, using AI inputs. 3) Change Control Excel Queens. One IT change needed 1000+ approvers, and 19 groups. Fake unread approvals are needed to stop time wasting telephone calls. Never mind cut'n'paste using details for the past change is soooo common. See DB2 -805

Is knowledge knowable? If not, how do we know that?

Working...