So I already mentioned the bug with VBscript reading the "ProgramFiles" environment variable from Windows Vista and Windows 7 (and corresponding server platforms as well). Well, I've done some more tinkering and found that it is due to WSH reading environment properties from a different place than CMD, PowerShell and KiXtart read from. This is still pertaining to 64-bit operating system versions, not 32-bit. This is very odd and very concerning for anyone still working with VBscript. After all: If this is looking in the wrong place, what else is?
Examples?
In PowerShell, try both of the following and observe the output…
> dir env:"ProgramFiles"
> dir env:"ProgramFiles(x86)"
In a CMD console, try both and observe the output…
> echo %programfiles%
> echo %programfiles(x86)%
Then create a .VBS script file and drop the following code in and run it…
Set objShell = CreateObject("Wscript.Shell")
wscript.echo objShell.ExpandEnvironmentStrings("%programfiles(x86)%")
wscript.echo objShell.ExpandEnvironmentStrings("%programfiles%")
Yep - this is f***ed up. Microsoft should release a patch to correct this, but I doubt they will. Asking everyone to stop what they're doing and convert all of their legacy scripts to PowerShell is not only a bong-smoking delusion, it's also like drinking the bong water and then eating the bong! I can see this causing a silent havoc on lots of systems around the world that use that environent variable in path resolution and path concatenation operations. As I said earlier: something this esoteric and fundamental belies a worrisome distrust for VBscript in general. How could you trust flying in an aircraft if you learn one of the key instruments has a known malfunction but is never going to be fixed?
Given that PowerShell is still not suitable for login scripting, and is still TOO DAMN SLOW to initialize, I will probably start shifting back towards KiXtart for the time being until this is either resolved (not likely) or until Microsoft beats PowerShell into a leaner, meaner execution machine. (as an aside: my guess is that due to the significant .NET stack that has to be awoken each time the shell is initialized, their "solution" will be to autorun it in the background like so many bloatware vendors do already).
The results of this unchecked bug could be very bad.
0 comments:
Post a Comment