{"id":3723,"date":"2008-10-31T17:22:00","date_gmt":"2008-10-31T17:22:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/vbteam\/2008\/10\/31\/shell-games-matt-gertz\/"},"modified":"2024-07-05T14:05:32","modified_gmt":"2024-07-05T21:05:32","slug":"shell-games-matt-gertz","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/vbteam\/shell-games-matt-gertz\/","title":{"rendered":"Shell Games (Matt Gertz)"},"content":{"rendered":"

I was once temporarily taken off the VB team to get an unrelated project back on track, just a mere handful of weeks before it was due to ship.  <\/span>I won’t go into the gory details; suffice it to say that we had reason to believe that the product would have<\/i><\/b> to ship without delay, and that any major failure in the deliverable could create some seriously undesirable problems for both us and our customers.  <\/span><\/font><\/font><\/p>\n

In the interest of expediting the development of the product, a external team knowledgeable in the underlying issue had been hired to do the actual work.  <\/span>When our testers were analyzing the results of their labors, they found wildly unacceptable performance in what had been produced.  <\/span>So, besides shepherding the work on the forty or so functional issues remaining in the product, I had to address the performance issues as well.  <\/span>This was bread and butter to me at the time; I’d recently come off a stint as the VB Performance Lead, and had a good grasp of the tools of the trade.  <\/span>So, I set about to investigate the cause of the problems.<\/font><\/p>\n

Without getting too deeply into the details of the project, the upshot was that each file on the operating system having a certain extension would be opened and analyzed so see if it contained any of a particular set of keywords.  <\/span>The extension was not an uncommon one; thus, a *lot* of files would have to be opened from the file system and examined.  <\/span>This, of course, was where I suspected the problems would be, but what I discovered in the code left me absolutely astonished.<\/font><\/p>\n

The natural thing to do for this sort of program was to recursively iterate the directory, find the relevant files, open them , search for the data, and then add the file to a list if the data was found.  <\/span>What they did instead was this:  <\/span>once the relevant file was found, they had created a thread whose sole purpose was to launch an application that they had on hand which generated a log report on the file.  <\/span>The thread would listen for that application to terminate, and then open the log report and scan *it* for yes\/no results.  <\/span>Yes, that’s right – imagine dozens of threads being opened at one, each of them launching a copy of this app, with four disk hits (find file, find & launch app, open file, create log file) for each.  <\/span>Yeah, that might just cause a little slowness on a Pentium II Win98 machine!<\/font><\/p>\n

After I calmed down (about an hour later), I asked them why they were doing it this way.  <\/span>“Well, we don’t actually know the criteria that would cause a ‘yes’ answer for a given file, since we don’t actually have the source code for the app that does<\/b> know it,” they replied.  <\/span><\/font><\/font><\/p>\n

Well, good grief!  <\/span><\/font><\/font><\/p>\n

Five minutes’ search on MSDN gave me the format of the file being scanned, and in another thirty minutes I’d ripped out all of the threading, shell code, and log-parsing code, replacing it with ten lines of code designed to open the file and scan for the appropriate data.  <\/span>The ultimate savings?  <\/span>A total scan of a typical machine shrunk from two hours<\/b> to ten minutes<\/b>.  <\/span>All in all, a most satisfactory day’s work.<\/font><\/p>\n

Yeah, yeah, yeah… what’s your point, Matt?<\/font><\/h2>\n

My point in bringing up that story is to note the incredible damage that can be done by misusing shell calls.  <\/span>Shell calls are expensive and, worse, they create results that may not easily understandable by the calling program (beyond a simple succeed\/fail).  <\/span>If you think that you need to “shell out” to another program, remember this simple word :  <\/span>don’t<\/b>.<\/font><\/p>\n

Of course, it’s very tempting to shell out when an existing application already exists.  <\/span>For example, if you want to get a listing of all subdirectories in a parent directory, and you want if formatted in a manner similar to that to which you are accustomed, then it’s very tempting to make a call to <\/font>dir \/a:d > out.txt<\/span><\/b> and to parse the results.  <\/span>The alternative, after all, is to overcome inertia and learn how to navigate the file system from code, right?   <\/span>Sounds great, but the best advice here is don’t do that<\/b>.  <\/span>That’s what snippets are for, after all.<\/font><\/p>\n

“There is still some goodness in him – I can feel it.”<\/font><\/h2>\n

Still here?  <\/span>OK, shell commands aren’t actually evil – they’re just misunderstood.  <\/span>They can be powerful tools if used right.  <\/span>And the best usage of a shell command is a “fire and forget” situation, where you really want the user to be interacting with a bona fide<\/i> version of the application.  <\/span>In most cases, if the executable is producing output AND you care about it, it’s best to in-line the functionality if at all possible.<\/font><\/p>\n

In Visual Basic, you can “shell out” to an application in two easy ways, both of which either leverage or wrap the System.Diagnostics.Process class.  <\/span>These are detailed below.<\/font><\/p>\n

When you don’t care when the shelled application ends:  <\/span><\/font><\/font><\/font><\/h3>\n

This is rather easy to do, and there’s actually a snippet that helps you when you forget the actual code.  <\/span>To find it, put your cursor in a method, launch the snippet picker by typing “?” and pressing “Tab,” then choose “Windows System – Logging, Process, Registry, Services,” “Windows – Processes,” and “Start an Application” in that order.  <\/span>(That’s for VS2008 – it’s slightly different in VS2005.)  <\/span>You’ll get the following line:<\/font><\/p>\n

        <\/span>Process.Start(“notepad.exe”<\/span>)<\/p>\n

<\/span><\/p>\n

<\/p>\n

 <\/p>\n

<\/span><\/p>\n

And you can replace “notepad.exe” with the name of whatever executable that you want to run.  <\/span>There are several overloads of this function, but you need to be careful with them, since a few of them allow you to specify a username and password to do a “Run As,” and that’s information that you definitely don’t want to hardcode or persist in human-readable form.  <\/span>There’s a simple overload that allows you to pass command-line arguments in a string, which can be very useful for certain apps, and you’d use it like this (for example):<\/font><\/p>\n

        <\/span>Dim<\/span> proc As<\/span> Process =  <\/span>_<\/p>\n

<\/span><\/p>\n

          <\/span><\/span>Process.Start(“notepad.exe”,”c:UsersMattDocumentshello.txt”<\/span>)<\/p>\n

<\/span><\/p>\n

<\/p>\n

 <\/p>\n

<\/span><\/p>\n

The first argument to Process.Start can also be a document which will be launched with the application that’s registered to it, and <\/font>this link<\/font><\/a> shows an example of that usage.  <\/span><\/font><\/font><\/p>\n

As I imply in the second example above, Process.Start returns an instance of the Process class which points to the process of the application you just created, and you can call all sorts of neat methods using that return value, including one that kills the process.  <\/span>I mention this because you might otherwise be tempted to kill the process you just created using “Stop an Application” snippet:<\/font><\/p>\n

        <\/span>Dim<\/span> processList() As<\/span> Process<\/p>\n

<\/span><\/p>\n

        <\/span>processList = Process.GetProcessesByName(“notepad”<\/span>)<\/p>\n

<\/span><\/p>\n

        <\/span>For<\/span> Each<\/span> proc As<\/span> Process In<\/span> processList<\/p>\n

<\/span><\/p>\n

            <\/span>If<\/span> MsgBox(“Terminate “<\/span> & proc.ProcessName & “?”<\/span>, _<\/p>\n

<\/span><\/p>\n

MsgBoxStyle.YesNo, “Terminate?”<\/span>) = MsgBoxResult.Yes Then<\/p>\n

<\/span><\/span><\/p>\n

                <\/span>proc.Kill()<\/p>\n

<\/span><\/p>\n

            <\/span>End<\/span> If<\/p>\n

<\/span><\/span><\/p>\n

        <\/span>Next<\/p>\n

<\/span><\/span><\/p>\n

<\/p>\n

 <\/p>\n

<\/span><\/p>\n

This snippet iterates over all processes having the name “notepad” and asks you for each one if you want to terminate it.  <\/span>But since you already have a valid Process object, you don’t need to use this snippet  <\/span>– just call Kill() on the return value of Start() directly.<\/font><\/p>\n

When you want to wait for the new application to end before proceeding:  <\/span><\/font><\/font><\/font><\/h3>\n

This involves using the Microsoft.VisualBasic.Interaction.Shell command, which gives you a few “frequently used” options for controlling applications that you launch.  <\/span>Here’s a contrived example :<\/font><\/p>\n

        <\/span>Dim<\/span> retval As<\/span> Integer<\/p>\n

<\/span><\/span><\/p>\n

        <\/span>retval = Shell(“C:windowssystem32notepad.exe”<\/span>, AppWinStyle.NormalFocus, True<\/span>, 20000)<\/p>\n

<\/span><\/p>\n

<\/p>\n

 <\/p>\n

<\/span><\/p>\n

I’ve specified the path to the application in the first second.  <\/span>The second argument allows me to control whether the new application is minimized, maximized, etc – in the above example, I’ve chosen for notepad to come up “normal.”  <\/span>The third argument specifies if I want to wait for the new application to complete and, given that I’ve chosen “True” for that above, the fourth and final argument specifies how many milliseconds I want to wait for that to happen, with -1 indicating an infinite wait.  <\/span>(I’ve coded for 20 seconds above.)  <\/span><\/font><\/font><\/p>\n

If the application shuts down before the time limit is reached, a zero will be returned from the Shell command.  <\/span>If, on the other hand, the time limit is reached and the application is still running, the program will stop blocking and return the process ID of the application – note that this will not affect the instance of the application that I launched, though.  <\/span>You can then use the process ID to take whatever action you need to do – for example:<\/font><\/p>\n

        <\/span>If<\/span> retval <> 0 Then<\/p>\n

<\/span><\/span><\/p>\n

         <\/span>   <\/span>Dim<\/span> proc As<\/span> Process = Process.GetProcessById(retval)<\/p>\n

<\/span><\/p>\n

            <\/span>‘ <\/span><\/span>(Call interesting methods on proc here.)<\/span><\/p>\n

<\/span><\/p>\n

<\/p>\n

 <\/p>\n

<\/span><\/p>\n

        <\/span>End<\/span> If<\/p>\n

<\/span><\/span><\/p>\n

<\/p>\n

 <\/p>\n

<\/span><\/p>\n

creates a Process object based on the process ID returned from the above code, and you can act on it in the same way that you used the return value from Start() in the first example.<\/font><\/p>\n

The bottom line<\/font><\/h2>\n

If you can, I’d try to avoid shelling out to other applications.  <\/span>It’s much more performant to implement the functionality in-line or, better yet, leverage an assembly that’s common to all of the applications in question.  <\/span>Still, you will occasionally come across situations where you want to launch the “one true” application programmatically.  <\/span>The methods I’ve listed above are easiest and will get you going quickly.<\/font><\/p>\n

‘Til next time…<\/font><\/p>\n

  <\/span>–Matt–*<\/font><\/font><\/p><\/p>\n","protected":false},"excerpt":{"rendered":"

I was once temporarily taken off the VB team to get an unrelated project back on track, just a mere handful of weeks before it was due to ship.  I won’t go into the gory details; suffice it to say that we had reason to believe that the product would have to ship without delay, […]<\/p>\n","protected":false},"author":258,"featured_media":8818,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[22,195],"tags":[101,165,166],"class_list":["post-3723","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-matt-gertz","category-visual-basic","tag-matt-gertz","tag-vb2005","tag-vb2008"],"acf":[],"blog_post_summary":"

I was once temporarily taken off the VB team to get an unrelated project back on track, just a mere handful of weeks before it was due to ship.  I won’t go into the gory details; suffice it to say that we had reason to believe that the product would have to ship without delay, […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/vbteam\/wp-json\/wp\/v2\/posts\/3723","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/vbteam\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/vbteam\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/vbteam\/wp-json\/wp\/v2\/users\/258"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/vbteam\/wp-json\/wp\/v2\/comments?post=3723"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/vbteam\/wp-json\/wp\/v2\/posts\/3723\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/vbteam\/wp-json\/wp\/v2\/media\/8818"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/vbteam\/wp-json\/wp\/v2\/media?parent=3723"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/vbteam\/wp-json\/wp\/v2\/categories?post=3723"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/vbteam\/wp-json\/wp\/v2\/tags?post=3723"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}