Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

VBScript deprecation: Timelines and next steps

techcommunity.microsoft.com

Post reply on HN
Print view View original

61–70 of 75 posts

Re: VBScript deprecation: Timelines and next steps

#61

Post by jasomill »

13of40 wrote: post #55
ygra wrote: post #46

Earlier quoted context omitted.

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, tha…

Built-in aliases are guarateed to be present, so you can depend on them. There are other features, like shortened parameter names that might become ambiguous when new parameters are added, that aren't guaranteed backwards compatible, but aliases are stable.

Not necessarily:

1. UNIX-compatibility aliases like "ls -> Get-ChildItem" and "cat -> Get-Content" are not defined in PowerShell on Linux or macOS. For a complete list of these, see the PowerShell source code[1] (look for "#if !UNIX").

2. A number of aliases from PowerShell ≤ 5.1 were removed in PowerShell Core (≥ 6.0), including the particularly annoying "curl -> Invoke-WebRequest" (conflicts with curl.exe) and "sc -> Set-Content" (conflicts with sc.exe).

[1] https://github.com/PowerShell/PowerShell/blob/8ea1598964590b...

Re: VBScript deprecation: Timelines and next steps

#62

Post by jasomill »

chem83 wrote: post #57
nozzlegear wrote: post #53

Earlier quoted context omitted.

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

Yeah, it is. S/he’s missing the point. Good luck finding PowerShell pre-installed on any server or workstation. Is there even a non-MS sponsored distribution that includes it by default?

Kali Linux:

  jtm@aristotle:kali ~ $ apt-rdepends -r powershell
  Reading package lists... Done
  Building dependency tree... Done
  Reading state information... Done
  powershell
    Reverse Depends: ibombshell (0~git20201107-0kali2)
    Reverse Depends: kali-linux-headless (2024.2.8)
    Reverse Depends: offsec-pen300 (2024.2.3)
    Reverse Depends: offsec-pwk (2024.2.3)
  ibombshell
    Reverse Depends: kali-linux-everything (2024.2.8)
  kali-linux-everything
  kali-linux-headless
    Reverse Depends: kali-linux-default (2024.2.8)
    Reverse Depends: kali-linux-everything (2024.2.8)
  kali-linux-default
    Reverse Depends: kali-linux-everything (2024.2.8)
    Reverse Depends: kali-linux-large (2024.2.8)
  kali-linux-large
    Reverse Depends: kali-linux-everything (2024.2.8)
  offsec-pen300
  offsec-pwk

Re: VBScript deprecation: Timelines and next steps

#63

Post by jasomill »

ravenstine wrote: post #30
chem83 wrote: post #7

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…

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.

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.

Re: VBScript deprecation: Timelines and next steps

#64

Post by xerox13ster »

jmull wrote: post #51

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.

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.

Re: VBScript deprecation: Timelines and next steps

#65

Post by ygra »

13of40 wrote: post #55
ygra wrote: post #46

Earlier quoted context omitted.

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, tha…

Built-in aliases are guarateed to be present, so you can depend on them. There are other features, like shortened parameter names that might become ambiguous when new parameters are added, that aren't guaranteed backwards compatible, but aliases are stable.

In addition to the other comment, PowerShell loads a profile script where a user may freely remove aliases or redefine them as they see fit. It's also a reason why my command line for executing PowerShell scripts includes -noprofile.

Re: VBScript deprecation: Timelines and next steps

#66

Post by jmull »

xerox13ster wrote: post #64
jmull wrote: post #51

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.

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.

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.

Re: VBScript deprecation: Timelines and next steps

#67

Post by LkpPo »

jmull wrote: post #66
xerox13ster wrote: post #64

Earlier quoted context omitted.

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.

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.

The page say dll will be removed.

Re: VBScript deprecation: Timelines and next steps

#69

Post by 7bit »

ravenstine wrote: post #31
bossyTeacher wrote: post #8

Earlier quoted context omitted.

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

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.

Because these people didn't want another relict that only does text manipulation. If you love awk and sed, you can use Bash.

If you like to work with real objects, use PowerShell...

Re: VBScript deprecation: Timelines and next steps

#70

Post by 7bit »

bossyTeacher wrote: post #48
Someone1234 wrote: post #17

Earlier quoted context omitted.

Care to go into any detail at all..?

In most normal languages, a non-void function returns either null or some data. Normally, the type of data is always the same. So your function returning a string will never return an int. Either it returns a string or an int. In PowerShell this is not guaranteed for all the functions in packages supported by Microsoft. A function returning a list of strings, can sometimes return a list of something that are not stri…

Skill issue, git gud
Post reply on HN