Rumours of VBScript's Death Have Been Greatly Exaggerated

Rumours of VBScript's Death Have Been Greatly Exaggerated

  • Comments 29

A reader recently left the following comment today which deserves a full and detailed response.  (Yep, I'm going to get prolix again.) 

I teach a Windows network administration scripting course to about 1500 admins and auditors each year.  I've been using VBScript all along mainly because it's a good transition language to VBA/VB.NET ... but I will likely switch the courseware to ActiveState's Win32 Perl instead. 

It seems like MS is going to let VBScript die a slow death and I'm doing a disservice to my students by making them invest their time in it.  I think MS should definitively state its intentions for the future of VBScript on the Script Center website and perhaps start doing all of its example administration and ResKit scripts in JScript (or Perl) instead so as not to trick new scripters into wasting their time. 

It's too bad, I still think VBScript is easy to teach and a gentle intro to VBA/VB.NET, but if the language isn't going anywhere, then I have to look out for my students' long-term interests.  Perl looks like it will become the de facto cross-platform administration language (if it isn't already) and there's a gigantic and solid community of support behind it (whereaas MS seems to just abandon its user base sometimes). 

If I'm wrong here about VBScript's future, then please tell me otherwise.  Thanks for being straightforward and honest in this blog. 

[emphasis added]

There's a lot to respond to in there. 

Let me first of all state categorically Microsoft's position on the COM Scripting technologies.  It's not often that I get to be The Voice Of Microsoft, but here we go:

We will continue to support VBScript and JScript for the foreseeable future.  Obviously VBScript, JScript, WSH, etc, must continue to be shipped with the operating system forever, as huge amounts of existing business-critical code depends upon them. To characterize that as "dying a slow death" is excessively melodramatic.  We expect that the unmanaged COM scripting languages will continue to be useful for many, many years.  The Visual Studio Sustaining Engineering Team presently is responsible for VBScript, JScript, Windows Script Components, Windows Script Host, etc. 

I'm looking at the logs right now, and there have been 702 file changes in the last three years, almost all bug fixes and security improvements. As we find bugs, security issues, etc, the Sustaining Engineering Team will investigate them and issue new releases with operating system service packs as necessary, as we have always done.  (And I will code-review their changes!) 

However, there will be no new features added to the languages -- indeed, there have been no new features in a long time.  The last person to actually add a new feature to any script team technology was me, on November 1st 2000!  (The feature was adding code signing support to WSF files.)

An analogy might be helpful.  I have plenty of old hammers in my toolbox, and they do their intended job today just as well as they always have.  To criticize a hammer for not being a cool new hydrogen-powered nailgun (yes, they do exist -- my kitchen contractors had one), or for being a bad tool to build skyscrapers, is to miss the rather important point that a hammer is still a useful tool for a broad variety of tasks!  There have been very few massive improvements in hammer technology in recent years, but it would be a serious mistake to say that hammers are dying a slow death.  It would also be a mistake to not teach people how to use hammers because hydrogen powered nailguns exist.  VBScript is a hammer, not a stone axe.  It'll be around for a long time.

I've been meaning to blog more about script languages as pedagogic tools, and now seems like as good a time as any.

First off, let's think about theory.  As I've blogged before, the important thing when you're learning how to program is to understand the semantics of the language, to understand what abstractions the language provides and use them appropriately to manipulate data correctly.  Therefore, the question "what is the future of VBScript?" is somewhat irrelevant.  If you're teaching people to program, pick a language that teaches people to program.  Once they know how to program, they'll be able to move from language to language with relative ease.  A loop is a loop is a loop, whether it is for(;;) or While Blah or some other goofy syntax.

From that approach, the sensible question to ask is "what language most easily teaches the concepts that I want the students to learn?"  and not "what language is going to have new features next year?"  When I was learning how to program over the years I used Commodore Pet BASIC, Waterloo Structured BASIC, Pascal, Lisp, Scheme, New Jersey Standard ML, Java, C, C++, Ada and Turing.  (The latter was a language specifically designed at the University of Toronto for teaching programming concepts.)  Aside from C++, I use none of those languages for anything practical, but I use the concepts that I picked up in each every day.  I often use functional programming techniques, for example.  If you want to teach someone functional techniques then it makes sense to pick a functional language. Teach the concept and then show how to do the same thing (much less elegantly, though it is improving!) in C# or whatever their language of choice is.

Clearly you understand the value of this approach, as you stated twice in your comment that VBScript is great because it is a good introduction to more complex languages such as VBA and VB.NET, which are useful for more heavy-duty application programming tasks.  But listen -- do you smell something?

I can smell the skepticism from here.  Why the heck would you or your students care about this kind of theory?  They're not writing dissertations on the theory of computing machinery, they're writing logon scripts.  They're not going to have to design massive applications, they're going to change directory permissions.

Why do you mention -- twice! -- that you use VBScript because it affords a smooth ramp up to VBA and VB.NET?  They are totally useless to you if your goal is to train administrators how to do administration tasks.  You are training possibly the most pragmatic set of IT professionals on the planet.  Administrators do not care about highfalutin' programming concepts like functional programming or object oriented programming.  Administrators do not need the language features afforded by VB.NET.  Administrators write thousand line scripts that look like this:

Directory.Create("CORPSERVER/BobSmith")
Directory("CORPSERVER/BobSmith").Permissions.Add("BobSmith", "ReadWriteDelete")
Directory("CORPSERVER/BobSmith").CreateFile("Logon.BAT")
Directory.Create("CORPSERVER/BillJones")
Directory("CORPSERVER/BillJones").Permissions.Add("BillJones", "ReadWriteDelete")
Directory("CORPSERVER/BillJones").CreateFile("Logon.BAT")
... a thousand more lines of this stuff

Now, perhaps our administrator could generate a more elegant and maintainable program by, say, abstracting away those operations into a function, putting the user names into a file, and writing a processing program that sucks the names out of the file one at a time and calls the function.  That would be great, but since this is a single-use script, any time spent making it elegant and maintainable before it is deleted this afternoon is rather wasted time. 

Administrators like to learn how to use one language well enough to get by, and then do everything in that language.

(Actually, it's even moreso than that.  When I write an administrative script that, say, copies a thousand files from one dev box to another, you know what I do?  I get a file list in my editor and then type a vi macro that turns the line of code into a legal statement in some script language, then I run that macro a thousand times, run the resulting script, and delete it.  My leet skillz in the admin space are a function of my mastery of my editor, not my deep knowledge of programming languages!)

The theoretical approach gets us nowhere.  The theoretical approach says "the semantics are the program; all languages are basically just variations on ways to abstractly express those semantics. Get the semantics right in your head and you'll be able to write the program in the language of your choice."  But for administrators, the semantics are NOT in the program nearly so much as the semantics are in the object models.  As I've said  before, for most administrative jobs, the programming language is the thing that mediates between you and the object model. 

Therefore, let me make the same argument from a completely opposite standpoint.  The language is unimportant because you're not going to be using nine tenths of the language features anyways.  Spend enough time to get the basics down on some language, any language, and then spend the whole time studying really kick-ass administrator object models like WMI.

The question is now neither "what's the best pedagogic language?" nor "what language will have new features?" The question to be answered now is "What language best mediates between administrators and today's object models?" 

And, if you're future-proofing, another good question is "what language best mediates between administrators and future object models?"

Clearly your choice depends on what object models you think that your students will be using to do their jobs.  Do you think that people will continue to use COM-based object models like WMI for a while?  Then a COM-based scripting language like VBScript or ActiveState's Perl might be a good idea.  Whether I'm going to add new features to VBScript is irrelevant to that decision -- VBScript exists now, Perl exists now, and if either of those are useful languages to call WMI, then by all means, teach whichever one you think your students will pick up on better.

But what about the future?  You wisely asked these questions in the first place with an eye to the future.  Let me again be the Voice of Microsoft here and say what the future is:

Managed programming, the .NET Framework and the Longhorn WinFX classes are the way of the future.  We are betting the entire company on it.  That's why I haven't been adding new features to VBScript for the last three years!  Yes, we will continue to support COM and VBScript forever, but if you want to enable people to take full advantage of all the incredible coolness that is coming in Longhorn, start thinking hard about managed code and the .NET Framework right now.  Learn as much as you possibly can about Monad and the Longhorm APIs, and start laying the groundwork for that curriculum.  Administrators in the future will use Monad and other managed languages to mediate between them and the WinFX framework, I guarantee it.

As I've blogged before, it is sometimes hard to know what tool to choose for a particular task.  Clarify your requirements.  Put these in priority order -- a good language for my curriculum

  1. works well with existing object models (VBScript)
  2. works well with future object models (any .NET language)
  3. affords a smooth ramp up to some other more complex language technology (VB.NET, C#...)
  4. is available on every platform (perl)
  5. makes it easy to learn basic general-purpose algorithmic programming techniques (your choice)
  6. makes it easy to learn specific advanced programming techniques (OOP, functional programming, etc.) (JScript)
  7. has a large installed base, lots of documentation, etc (any established language)
  8. has lots of new features planned (C#, VB.NET)
  9. is cool (C#, VB.NET…)

Once you've got those in priority order, it should become easier to pick the right tool.  If #4 is the most important to you, we shouldn't even be talking about this.  Use perl and be done with it if you want admins to be able to write programs for Solaris boxes! 

If you have multiple conflicting priorities, well, not much I can do to solve that problem except by providing as many facts and as much analysis here as I can. 

My aim is and has always been to make the Windows platform as attractive as possible to all programmers, from administrative scripters to game designers to developers of multi-tiered enterprise developers.  If perl on Windows is the best tool for your students, by all means, use it.  I'll be happy as long as that "on Windows" is in there!

  • Hi Eric, M. here again, thanks for your long and thoughtful reply. It's a real treat to be able to have access to the insiders at MS through these MSDN blogs, and yours is one of my favorites.


    > there will be no new features added

    This is what I meant by "die a slow death": death in the marketplace, not removal from the OS. Hammers originally had no claw on the backside of the head to pull out nails, but now you wouldn't even consider buying a hammer without that "new" feature. VBScript lacks a claw (.NET integration) and, like you say, will never get one. Your assumption is that VBScript will be able to get the job done TOMORROW just as it can today, I disagree. You even later say:

    > Administrators in the future will use
    > Monad and other managed languages
    > to mediate between them and the WinFX
    > framework, I guarantee it.

    Will VBScript be able to do this? If not, then VBScript will fade from use.



    > But for administrators, the semantics are
    > NOT in the program nearly so much as the
    > semantics are in the object models.

    Like the objects and classes in .NET/WinFX? I agree.



    > Why do you mention -- twice! -- that you use
    > VBScript because it affords a smooth ramp up
    > to VBA and VB.NET? They are totally useless
    > to you if your goal is to train
    > administrators how to do administration
    > tasks.

    Hmmmmm, maybe in bad taste to quote you back to yourself, but: "What I know about the practicalities of scripting the IE object model, or administering a network with WMI, or building a multi-tier ASP site, you could fit into a matchbox (http://weblogs.asp.net/ericlippert/archive/2004/02/11/71529.aspx)."

    It's not so easy to do network administration of hundreds of servers, thousands of workstations, and scores of custom-built LOB applications while auditing conformance to HIPAA, VISA or other mandated standards. Most of my attendees specialize in security and auditing, they're not just "copying files" and "changing directory permissions". Their coding is as important to their jobs as it is to the DBAs or the webmasters. But it seems that JScript(.NET) can do it all for them and provide a nice road to C# and C/C++ too, so JScript should be the admin language that MS champions, not VBScript. This is what should be stated on the Script Center website. Greg Stemp and the other scripting guys should be writing in JScript(.NET) and recommending that VBScript be gracefully given up -- otherwise, aren't they just stringing us along?



    > Administrators like to learn how to use one
    > language well enough to get by, and then do
    > everything in that language.

    I agree, but soon you won't be able to do everything you need to do as an administrator with VBScript. If I had known three years ago that VBScript would today be a dead end ("there will be no new features added"), then I would have been teaching JScript or Perl instead.

    Why am I leaning towards Perl? Because Perl seems to be backed by all the world, runs on every platform, and its eventual .NET integration seems a certainty, e.g., PerlASPX from activestate.com is a start.

    Microsoft JScript on the other hand...??? Will MS change its mind again and let that die off too? If Monad becomes as central as you say, what will be its preferred language? I want to be able to promote JScript.NET, but my clients trust me and I'm loyal to them. So when I search MS's site and Resource Kits for JScript.NET administration scripts (not ASP.NET scripts using JScript) as a sign of MS's committment to that language, how many scripts do I find? Almost none.

    There was nothing inherently wrong with VBScript, nothing that couldn't be upgraded or fixed, this dead-end is MS's choice. Perl is harder to learn at the beginning, but better to have a "hydrogen-powered nailgun" and know it will be upgraded and useful for many years to come than to have an obsolete clawless hammer collecting rust in the basement...

  • > thanks for your long and thoughtful reply

    You're welcome. I've been meaning to address your questions for YEARS and just didn't get around to it until you prompted me last night.

    > Will VBScript be able to do this?

    There are always COM Callable Wrappers. A bit kludgy, yes, but they get the job done.

    > they're not just "copying files" and "changing directory permissions".

    It wasn't my intention to trivialize what admins do -- and yes, I know next to nothing about administering machines except that its hard.

    Fortunately I live with people who have MS certs...

    My point was simply that admins don't want to waste time writing large, object-oriented, carefully factored, elegant programs -- they want tools that get the job done and when the job is done, the tool might never be used again.

    It's pretty rare that an admin needs to FROM SCRATCH, solve, say, the topological sort problem I talked about a while back. Admin problems are about calling into object models, not about constructing clever algorithms that take advantage of the unique semantics of particular languages. How many admins know or care what prototype inheritance is, for example?

    > Greg Stemp and the other scripting guys should be writing in JScript(.NET) and recommending that VBScript be gracefully given up -- otherwise, aren't they just stringing us along?

    I've invited the scripting guys to respond, so I'll let them take that one.

    I personally would love it if JScript .NET became more of a mainstream language. I think it's an excellent general-purpose and pedagogical language with a lot of scope for growth in many directions.

    > If Monad becomes as central as you say, what will be its preferred language?

    Monad will provide a new language specifically designed for administrative scripting.

    > There was nothing inherently wrong with VBScript, nothing that couldn't be upgraded or fixed, this dead-end is MS's choice.

    We considered writing VBScript for the .NET platform, but as I said, we realized that there would be so much overlap with VB.NET and so little value added, that it was pointless. VB.NET _is_ the upgrade for VBScript in .NET. Can it be made better for admins? Sure, there's plenty of room for improvement. Take your case to Paul Vick and let him know what you want.

    The "dead end choice" is not VBScript -- it's bigger than that. It's the whole idea of unmanaged COM programming. The dream of .NET is to replace ALL programming with managed programming -- from scripting to device drivers. It's going to be a long road to get there! It will take many, many years and there will be missteps and blind alleys along the way. But the overall direction is unmistakable.
  • >> But it seems that JScript(.NET) can do it all for them and provide a nice road to C# and C/C++ too, so JScript should be the admin language that MS champions, not VBScript. This is what should be stated on the Script Center website.

    Nooooo!!!! Please don't make a C-based language the tool of choice for occupational programmers. A VB-based language is so much better. Sorry Eric, but I'm going to dredge this post back up for M.: http://blogs.xtras.net/mikes/PermaLink,guid,728d9237-a54c-4d15-b544-d3f59ad5fdd9.aspx

    BTW, when I proposed VBScript.NET, I meant not "porting VBScript" to .NET, but instead a "new VB-based .NET language and IDE optimized for occupational programmers with features that would allow people to move up to VB.NET w/automatic code conversion to VB.NET." Hopefully the post describes it better.

    Also I completely agree with M. on all other points.
  • Not to sound like a complete fool, but what is stopping people from using VB.NET in a nearly identical manner that VBScript is used today? Sure, you have to do one little extra step and use the vbc.exe compiler against the "script", but you do get a language that is VB that can be modified from notepad.exe and is available on any machine that has the .NET Framework installed. Or am I missing something here?

    As for Perl being the language of choice... ummm... Who is to say that ActiveState ever completes the .NET version? What guarantees do you have of this? And again, VBScript/VB.NET let you do this today... there is no need to wait for some company to provide the .NET enabled version. It's here.

    As for JScript, having JScript.NET is a logical progression as Java is not the same thing as JScript/JavaScript so moving to .NET you have J# and JScript.NET. I agree with Eric that VB.NET already meets the necessary requirements to replace VBScript and is already included on every machine that has the Framework installed.

    Eric, I think you missed this fact in your response to this guy. I see that you mention it in one of your follow up responses, but you might consider going into more detail; maybe even showing a short script written in VBScript and it's conversion to VB.NET with a quick walkthough of how the script would be executed in both examples.

    BTW, keep up the great bloggin'!
  • " That's why I haven't been adding new features to VBScript for the last three years! Yes, we will continue to support COM and VBScript forever, "
    This is what I would have understood to be meant by the phrase dying a slow death.

    VBscript is dying a slow death because it is still useful, however everyone that uses it knows they have to switch from it at some point because their knowledge of it, while maybe useful in getting a particular 'job' done in the present is not at all useful in getting a particular 'job' in the marketplace.

    The stand that some people have taken towards Visual Basic and VB.Net being incompatible as showing that the time they spent learning VB was a waste is only more comprehensible if you take someone that invested a lot of time in vbscript. Thank god I always preferred Jscript or I would be a bitter anti-microsoft guy about now complaining about a sore rectum.

    Rectum!? Hell, it just about ruined their skillset.
  • Eric,

    After lookiong at scripting languages as administrative support tools for a few years, my informed non-Microsoft opinion is that... you're pretty darned correct.

    The one statement I disagree with to a certain extent is:

    [VBA and VB.NET]...are totally useless to you if your goal is to train administrators how to do administration tasks.

    Of course VB is not well-designed for use as an admin language; it is simply somewhat familiar/comfortable to many administrators, and if MSH lives up to its promise as being a full-fledged ".NET interpreter" with deep reach, it will go far towards eliminating a fundamental need by administrators for a compilable language.

    However, there is always some gap between what people implement for admins and what admins truly need. Apropos of that, I'm quoting a memorable paragraph from Richard Stallman's "TCL War" post (http://groups.google.com/groups?selm=9409232314.AA29957%40mole.gnu.ai.mit.edu):
    '...The principal lesson of Emacs is that a language for extensions should
    not be a mere "extension language". It should be a real programming
    language, designed for writing and maintaining substantial programs.
    Because people will want to do that!...'

    This won't directly matter to the majority of admins in the MSH era, but I would not be surprised to see the "cutting edge" few finding their share of frustrations with not having a compilable language.

    Since the VB.NET and C# compilers actually are part of the runtime distribution, I would not at all be surprised to see them being exploited by some admins as solutions to problems not addressed in MSH. In fact, they already are useful; I've written some tools to use them as on-demand API wrappers, for example.

    Overall, I'd say your point is correct for the vast majority of administrators; but a compiler is an incredibly useful and flexible tool. It will be interesting to see if having compilers universally available has an impact on administration in the next few years.
  • > The "dead end choice" is not VBScript --
    > it's bigger than that. It's the whole idea
    > of unmanaged COM programming. The dream
    > of .NET is to replace ALL programming with
    > managed programming

    I think *this* is the most important thing in your post, both for Windows and for the entire IT industry. VBScript in this case is just another roadkill on the way to .NET and the drive to abstract away from the OS (in the same way the OS now allows us to mostly forget about the details of the hardware)...

    > Monad will provide a new language
    > specifically designed for administrative
    > scripting.

    ...and so perhaps JScript will be another roadkill too. But until MSH.EXE and the .NET classes are fully fleshed out with complete support for ADSI, WMI, and other administrative objects (like in Longhorn), what should an administrator today learn? Even though Perl has ugly syntax, it seems it will be the most useful for the time being on both Windows and Linux/BSD, and, if not ActiveState, then someone will cover that market niche to allow Perl to interact with the Framework/CLR.

    I agree with Mike Schinkel that a C-ish language like Perl or JScript aren't as coder-friendly or pretty (or "agile"?) as VB, but the .NET Project is not even halfway done yet and we (out here in the industry) don't know whether this bet will work anyway, so better for us to hedge and go with Perl while we wait to see what happens. Besides, if Linux and Apple+BSD really gain ground in the next five years, then admins will have to know Perl anyway to stay competitive.

    I'd really like to see what are the best arguments in favor of JScript(.NET) over Perl, not in any religious or purely language-technical way, but from the standpoint of a new programmer who wants to leverage these skills for as long as possible and today has administrative duties to fulfill. Scripting Guys? Greg? Andrew? Where are you???


  • As a programmer who does *lots* of administrative "scripting", let me tell you
    that the .Net framework is not the be-all, end-all of an administrator's tool belt.

    As you've stated above:
    >As I've said before, for most administrative
    >jobs, the programming language is the thing
    >that mediates between you and the object
    >model.

    Well, let me tell you that doing some Administrative tasks in .Net is *much* more complicated then
    programming in VBScript, or even batch file programming, primarily because Microsoft hasn't gotten
    close to creating the .Net object model that Administrators need!

    I'll also say this: Microsoft hasn't even gotten it right for VBScript yet!


    Take, for example, some of the simple tasks that you show in your "Sample Administrator Script"

    Directory.Create("CORPSERVER/BobSmith")
    Directory("CORPSERVER/BobSmith").Permissions.Add("BobSmith", "ReadWriteDelete")
    Directory("CORPSERVER/BobSmith").CreateFile("Logon.BAT")
    Directory.Create("CORPSERVER/BillJones")
    Directory("CORPSERVER/BillJones").Permissions.Add("BillJones", "ReadWriteDelete")
    Directory("CORPSERVER/BillJones").CreateFile("Logon.BAT")

    Batch file:
    ------------------------
    md ../CORPSERVER/BobSmith
    CACLS "../CORPSERVER/BobSmith" /G BobSmith:RWC
    ECHO @Echo Off > ../CORPSERVER/BobSmith/Login.bat


    VBScript
    ------------------------
    Dim objFSO
    Dim WshShell
    Set objFSO = CreateObject("Scripting.FileSystemObject")
    Set WshShell = WScript.CreateObject("WScript.Shell")

    'Create the folder
    Dim strNewFolder
    strNewFolder = objFSO.BuildPath(WshShell.CurrentDirectory, "CORPSERVER/BobSmith")
    If Not objFSO.FolderExists(strNewFolder) Then
    objFSO.CreateFolder (strNewFolder)
    If Not objFSO.FolderExists(strNewFolder) Then
    WScript.Echo "*** Error creating folder"
    Wscript.Quit (1)
    End If
    End If

    'Set permissions, well VBSCript doesn't have this capability. Shell to CACLS, but
    'Cacls doesn't do all rights correctly. Fine, we could use XCacls, but geez,
    'neither are COM objects...
    WshShell.Run "CACLS " & Chr(34) & strNewFolder & chr(34) & " /G BobSmith:RWC", 1, True

    'OK, create Login.bat (w/ just @ECHO Off for now...)
    Dim strNewFile
    strNewFile = objFSO.BuildPath(strNewFolder, "Logon.bat")
    Dim objTS
    objTS = objFSO.CreateTextFile(strNewFile, true)
    objTS.WriteLine ("@ECHO OFF")
    '... other lines for Logon.bat
    objTS.Close

    'OK, now this permission stuff...
    WshShell.Run "CACLS " & Chr(34) & strNewFile & chr(34) & " /G BobSmith:RWC", 1, True
    'Rest of code...
    ------------------------

    OK, that wasn't too bad. Especially writing it in a modern IDE (PrimalScript, VS.Net) with
    code completion.

    However, nice hack to get the ACL's working. Permissions, while an "advanced" function of
    windows, are critical for administrators. I guess this is fallout from Microsoft's flawed
    security implementation practices. (Sure, it's easy to create a folder in a script, but who
    would *ever* want to secure it)

    VB.NET
    ------------------------
    Option Strict On
    Option Explicit On

    Imports System.IO
    Imports System.Diagnostics

    Module VBAdmin
    Sub Main()
    'Create the folder
    Dim strNewFolder As String = Path.Combine(Environment.CurrentDirectory, "CORPSERVER/BobSmith")
    If Not Directory.Exists(strNewFolder) Then
    Directory.CreateDirectory(strNewFolder)
    If Not Directory.Exists(strNewFolder) Then
    Console.WriteLine("*** Error creating folder")
    Environment.Exit(1)
    End If
    End If

    'Set permissions, well can't do this in VB.Net either. Since we want to shell & wait,
    'we need a ProcessStartInfo Object.
    Dim startInfo As New ProcessStartInfo("CACLS.exe")
    startInfo.Arguments = String.Format(" ""{0}"" /G BobSmith:RWC", strNewFolder)
    Dim objProcess As Process = Process.Start(startInfo)
    objProcess.WaitForExit()

    'OK, create Login.bat (w/ just @ECHO Off for now...)
    Dim strNewFile As String = Path.Combine(strNewFolder, "Logon.bat")
    Dim objTS As StreamWriter = File.CreateText(strNewFile)
    objTS.WriteLine("@ECHO OFF")
    '... other lines for Logon.bat
    objTS.Close()

    'OK, now this permission stuff...
    Dim startInfo2 As New ProcessStartInfo("CACLS.exe")
    startInfo2.Arguments = String.Format(" ""{0}"" /G BobSmith:RWC", strNewFile)
    Dim objProcess2 As Process = Process.Start(startInfo)
    objProcess2.WaitForExit()
    'Rest of code...
    End Sub
    End Module
    ------------------------
    OK, 40 vs 33 lines. Pretty much the same code, with the ability to use managed code,
    and the ability to declare and fill you variables on the same line.

    We've "progressed" 6 years (IE 3 was '96, .Net was right around '02). And I still can't ACL
    a folder in code. Yes, there's ADSSecurity.dll's IADsSecurity, but we're talking a *simple*
    way to acl here :-)

    OK, ACL'ing might be a little bit of a harsh example.

    What about WMI. It's the way Microsoft is pushing remote administration. Fine, I love it.
    How about using WMI to change a Service (say, MSSQLServer) from Manual to Automatic.

    Batch File:
    -----------
    SC <\\ServerName> config MSSQLServer start= auto


    VBSCript:
    ---------
    strComputer = "."
    Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2:Win32_Service.Name='MSSQLSERVER'")
    errReturn = objWMIService.ChangeStartMode("Automatic")
    If errReturn = 0 Then
    wscript.echo ("OK")
    Else
    wscript.echo ("*** Error")
    End If


    VB.Net
    ------
    Option Strict On
    Option Explicit On

    Imports System
    Imports System.Management

    Module VBAdmin2
    Sub Main()
    Dim strServer As String = "."
    Dim Service As New ManagementObject(String.Format("\\{0}\root\cimv2", strServer), "Win32_Service.Name='MSSQLSERVER'", Nothing)

    Dim inputArgs As ManagementBaseObject = Service.GetMethodParameters("ChangeStartMode")
    inputArgs("StartMode") = "Automatic"

    Dim result As ManagementBaseObject = Service.InvokeMethod("ChangeStartMode", inputArgs, Nothing)
    If Convert.ToInt32(result.Properties("ReturnValue").Value) = 0 Then
    Console.WriteLine("OK")
    Else
    Console.WriteLine("*** Error")
    End If
    End Sub
    End Module

    This has gotten simpler how?

    I do realize that there's a ton of added functionality in the WMI ManagementObject
    class, but geez, it's confusing.


    And I do realize that simple, single purpose command line tools are always going to
    be easier to use, but there should be a less generic object structure for WMI.

    And I still don't know how to set the minimum password length for a computer other then
    LSA api calls.


  • So far you have proven the original poster right. VBScript is a walking dead.

    Christopher Lewis demonstrated that Microsoft has no real understanding of the scripting needs of administrators.

    I still maintain that Microsoft is yet again unable to finish what it has started. You abandon VB Script long before it is obsolete. And I'm sure the next scripting language will be abandoned as soon as it is launched, because there is some new scripting technology 5 or 10 years in the future.

    #%¤&¤*§#$!
  • I've continued to research the "Perl vs. JScript(.NET) for Windows Admins" question and here are some things that should be considered (if anyone is following this thread):

    Perl 5.x is more difficult to learn than JScript/VBScript, and Perl 6.x will be even more difficult. Take a look at the previews for Perl6 (http://dev.perl.org/perl6/apocalypse/) especially the section on Subroutines. The learning curve for Perl6 puts it into the same difficulty-family as C# and VB.NET. Admins will have to be savvy on Perl 5-vs-6 issues for years to come to cope with versioning and backwards-compatibility problems (and for both Windows and Linux/BSD boxes, since we want cross-platform support here).

    Perl6 implements a new runtime (code-named "Parrot") which produces bytecode that will be .NET-compatible (http://dev.perl.org/perl6/architecture.html). But this .NET integration is still years away. Because the Perl community knows that version 6 is on the horizon, no one will seriously invest any .NET-integration efforts today. If there are Perl6/Parrot/.NET integration problems, then we could be waiting for many years...

    "Perl should stay Perl (http://dev.perl.org/perl6/apocalypse/A01.html)." Perl6 is looking less and less like a good "transition" language to anything other than Perl (or C) imo. VBScript leads to VBA to VB6 to VB.NET, and JScript leads to JScript.NET to C# to C/C++, so there are family resemblances that can leveraged in different domains for different skill levels. If Perl doesn't "transition" well, and Perl6 will be very tough for beginning scripters, then it's looking less appropriate for our needs.

    As Eric said above, the Monad shell (MSH.EXE) will have its own new language, which will therefore not be Perl (or JScript or VBScript). Monad is a big question mark... Will it be huge? Will it be left to flounder like so many other MS trail baloons? Will it be two years or more like FIVE years before it is 90% functional? This functionality is also a .NET issue, namely, when will the .NET Class Library include all the admin classes we want? Monad's usefulness depends not only on its own intrinsic capabilities as a shell (which is not exactly a MS forte) but also on what .NET classes it can find.

    So far, it seems the best investment a cross-platform admin can make today is to learn shell scripting for the Linux/BSD machines and JScript(.NET) for the Windows boxes, keep an eye open for Monad developments, then advance to C#/C/C++ as desired. This might seem to leave the Linux/BSD boxes under-represented, but vastly more can be done with bash on Linux than CMD.EXE on Windows. Perl seems not to be worth the effort, especially with Perl6 on the horizon. VBA doesn't concern admins much, and regular VB is going to VB.NET (and C# is just as powerful). For the advanced admins who do security, C/C++ is often required, and JScript(.NET) is a nice appetizer for that syntax...

    Where are the Scripting Guys in this discussion?! You'd think they'd be all over Monad and the advantages of JScript(.NET) over VBScript or whatever! Why isn't JScript pushed by MS more heavily? Eric, is JScript(.NET) not going to get any further development either? What's the future for JScript at MS? (Btw, thanks again for this blog! I hope I'm not abusing your time, but I bet others face these same decisions.)


  • Re: Perl: I know next to nothing about Perl, so I really can't comment on it one way or the other.

    Re: Transitions: I can see where you're coming from, but I (weakly) disagree. JScript, C# and C++ bear only the most superficial resemblances to each other. VB.NET is MUCH more like C# than JScript is like C# when you start thinking about language features and stop thinking about unimportant surface features like whether its "for i = 1 to 10" or "for(i=1; i <= 10 ; ++i)".

    Let me put it another way -- simple VB.NET, C#, JScript.NET, C++ programs are simple syntactic variations on each other, and some of those variations are simpler than others. But complex JScript programs -- with prototype inheritance, closures, run-time evaluation, etc -- are conceptually totally different from complex VB.NET/C# programs.

    Those complex VB.NET/C# programs by and large continue to be relatively simple syntactic variations.

    So I don't buy this argument that there's a natural progression from one "braces and semis" language to another. That's rather like saying that there's a natural progression from Chess to Go because they both have black and white pieces on a square grid.

    What I think is far more important is that the .NET languages are all ways to talk to the framework, which is where the real semantics are.

    Let me make an analogy for you. You're trying to figure out whether to teach people French, Spanish, Latin or Esperanto. OK, who finds it easier to communicate:

    * a Spanish-speaking organic chemist writing formulas being read by a French-speaking organic chemist, or

    * a Spanish-speaking organic chemist writing formulas being read by a Spanish-speaking civil engineer

    The important thing isn't what language you use, the important thing is the _domain_ that you're talking about. So what if you can use perl to administer Windows and Unix boxes? The object models you manipulate are the interesting part, and they're independent of the language.

    * Re: Monad

    I know next to nothing about Monad. Go find a Longhorn Evangelist and start bugging them to tell you more.

    * Re: Where are the scripting guys?

    Beats me. I have no ability to compel them to speak. And keep in mind, we blog in our less-than-copious spare time here.

    * What's the future of JScript?

    JScript .NET is owned by the C# team. They're continuing to fix bugs, add new features, and attend standardization meetings.

    JS.NET is not a huge priority right now because very few people are banging down our doors demanding new JScript .NET features compared to the number of VB and C# feature requests.

    We're a tool making species, but we don't very often make tools as solutions in search of problems. It's usually not the case that if you build it, they'll come.

    JScript development in the Before Time was always driven by forces external to the language team. JScript v 1, 3 and 5 were driven by feature requests from IE, v2 by ASP and v4 by Visual Interdev.

    No juggernaut is driving feature requests for JScript .NET now, so not a whole lot of stuff is being done on it.

    But we're keeping it under development and continuing to get through the standards process because looking forward, there are a few technologies now in the pipeline which may someday need to drive features on a managed version of the language. (Obviously I can't talk much about them.)
  • > I don't buy this argument that there's a natural progression
    > from one "braces and semis" language to another.

    I agree that surface syntax is far less important, but, crazy as it sounds, part-time/admin coders simply do get very discouraged when they contemplate going from one language to another and the new one "looks different"... I see it all the time.


    > But we're keeping [JScript.NET] under development ...
    > looking forward, there are a few technologies now in the
    > pipeline which may someday need...

    Great, exactly what I was looking for.


    > And keep in mind, we blog in our
    > less-than-copious spare time here.

    Gotcha. I'll sign off and say Thanks! one last time...

  • A blog? About VBScript? It's true that VBS isn't on anyone's list of up and coming technologies. Still, as Eric Lippert has written, it's not dead yet. OK, so I'd rather be programming Java or (if I got really lucky)...
  • Thanks for taking time to go thru this. I'm an Admin who is just starting to learn some scripting and was starting to have the sames concerns as M. "am i learning a dying language"?

    As for the admin side...you're right...i don't have a lot of time to learn languagues...i just need a way to make a few things happen a lot of times. i have enough studying for the other MS products that have to support.

    I'm not a programmer or developer. i'm a network admin, that's my job. primarily, i just need to be able to gain access to WMI & ADSI. is that so difficult?

    it woulda been nice to have heard from the scripting guys...maybe i'll hit their blog and try to get their input.

    again, Thank You.
  • monad links
    http://dotnetjunkies.com/weblog/stefandemetz/posts/11794.aspx
Page 1 of 2 (29 items) 12