Application Security Testing: An Integral Part of DevOps
How do you run processes under Windows?
To many, this might seem like a bit of a strange question, because you're used to starting Explorer, finding the application or process you want to run, and then clicking it to start it. You might also be used to using the command line and typing in the name of something to run, or you might never venture outside the Start menu. Whichever way you do it, you're starting a process, and that process will run and perform some desired function.
Under Linux and most Linux-like operating systems, there's a strong philosophy of using many small processes or tools to perform everything needed for one larger process. For example, if you were searching for a file on Windows, you might start a copy of Explorer, and type the name of a file in the Windows Search field. On a Linux-based machine, you would be more likely to run a process that gets a list of files. Then, you'd pass that list of files to a process that filters out only the names you're interested in, and then that filtering process would pass the final list to a display process in order to show you the results.
This way of doing things leads to a lot of re-use, not just of code but of individual processes and small-scale tools. If you already have a tool that can process zip files, why do you need another? In many cases, desktop applications are nothing more than graphical wrappers around command line tools that perform the actual underlying task.
As you might imagine, this also means that, in general, you don't use as much disk space because of the re-usable nature of things.
That's All Well and Good but Why Are You Going on about Linux in a .NET Article?
Well, many people may not realize this, but you can do the same thing with .NET.
Take your copy of Visual Studio, for example. What do you see? An editor, build tool, and language compiler all rolled into one, right?
Well, it might come as a surprise that the actual compiler is installed when you install the .NET framework & Runtime; it's called 'csc.exe'. Likewise, the build tool is also installed with the .NET framework and that's called 'msbuild.exe'. The only part of the three parts mentioned that's actually built into Visual Studio is the Integrated Editing Environment; for the other two functions, it calls out to csc.exe and msbuild.exe as needed, and then acts on the output those two programs produce.
It's very easy to do this kind of thing in your own applications by using the .NET process class. The process class lives in the 'System.Diagnostics' namespace and, as well as being used to start and run other processes, it also can be used to collect information about processes that are currently already running in the system.
The following C# code shows how you might use the process class to start running a copy of Notepad.
Process myProcess = new Process(); myProcess.StartInfo.UseShellExecute = false; myProcess.StartInfo.FileName = "c:\\windows\\notepad.exe" myProcess.Start()
If you add this into a console mode, WinForms, or WPF application, when the code executes you should find that "Notepad.exe" springs to life on your PC. Running Notepad, however, is perhaps not the best example, so let's have a look at something else we might want to do.
If you notice in the previous code sample, Line 2 sets a property called 'ShellExecute' to false. If you set this to true and set the file name to a normally non-runnable file, for example:
And then run the code again, you should find that this time, your default browser starts up, and loads the named page.
When you choose to use "Shell Execute", you're asking the Windows Operating System to activate the default handler for a given file. If that file is an EXE, the process is run just as normal. If the file is a non-EXE file, Windows looks for the default program (which, in the previous example, was a web browser) to run it.
You can use this, for example, to launch an applications web page, or load up a PDF manual into a default PDF viewer. More than that, you can use it in the same manner as Linux programs might, by running command line programs behind the scenes, capturing the programs output then acting on it in some way. Who knows? Uou might even write the next Visual Studio.
Passionate about .NET and want to share a tip/trick? Or, is there something you'd like to see covered that you want to know more about? Come and find me on Twitter as @shawty_ds or leave me a comment in the box below and, if I can, I'll do a future post on the subject.