Windows Command Line Start Primer Tutorial

Windows Command Line Start Primer Tutorial

Windows Command Line Start Primer Tutorial

A lot of Windows desktop processing tasks require you to do more than one thing at a time (calling all afficianados of multitasking). Windows (from Microsoft) caters well for people who multitask, and there is a cute keyboard shortcut for decluttering the desktop (available for Windows 7 and up) when it becomes too cluttered at your desktop (we talked a bit about this with Windows Multitasking Tip Primer Tutorial below) … today we show you a command line tool that may help you arrange your Windows procedure thoughts. We show some examples of the use of the command line command “start” which sets off Windows program and/or batch files (that may call a Windows program) and has some control of the Windows that those procedures run in, in regards to their size and priority and supervision arrangements, while preserving all the flexibility, such as command line arguments, straight “cmd” work allows.

You will see, should you peruse the tutorial:

  • Start supervising a batch file (downloadable as fgrep.bat) that can take (extra) command line arguments, or not, and, therefore, be asking for (extra) interactive input, or not
  • The significance of “exit” to Start usage scenarios (ie. useful for Start but can be annoying for Cmd (because windows sometimes close too soon)) … see link
  • Start process priority control
  • The wonderful Procexp – Process Explorer – Information/Download – Alternative to Task Manager … almost essential for analyzing what Start is doing, but of so much more use generally, for the detail, than Windows Task Manager, as far as process information goes
  • Extra functionality available to Command Prompt being kicked off “Run as administrator” (for example, ability to copy to system areas of hard disk)
  • The significance of adding a process onto the %PATH% of your Windows environment (though Linux and unix have a path too, and commands can work in this similar manner) … relooking at picture, probably need to say, here, that the significance is twofold, in that you no longer need to specify the .bat in fgrep.bat and you can be anywhere on the hard disk as your current directory, and have your “new” (Windows) command fgrep be understood (though, who’s to know your family will understand you trying this at 2:30am in the morning because you just wanted to pop out for a bit of an “fgrep” fix … don’t say I didn’t prepare you for your favourite commands to take over your life … “sit, Nala … sit … please, Nala, no lickie … just sit”)
  • Start /k switch takeovers, with respect to use of /b (or not), and the use of /wait switch
  • Taking something you like from one Operating System (in this case Linux/unix “fgrep” command) and creating a similar “pipe” type solution in another Operating System (ie. Windows) … for fgrep.bat … you normally only create “hybrid” versions, as is the case for our “fgrep.bat” example today, of things you like, and that are the words you are used to typing (as, after all, the Windows command line command “find” could just as easily serve your purposes here, and is used in our “fgrep.bat”, if you were used to typing that command, that is), because it is normally very difficult to recreate the scenarios of all the switches, and their combinations, that happened with the source Operating System, in regard to your destination Operating System
  • Start scenarios with batch files not asking for command line arguments, but stopping for interactive input from the user via the calling of Windows programs, calling on previous Basic Tutorial and Pascal Primer Tutorial tutorials

The idea of this tutorial started with thoughts about Windows processing with invisible windows, and if you want to read about this, you could do worse than start your search with the myriad ideas (some good, some out of date, some not so good, some dependent on what platform you use, some dependent on whether you gravitate towards third-party solutions (all the time)) at Running a completely hidden batch file tutorial (which came from the brilliant _Object Yahoo Answerer’s link from this Yahoo Answers Question. Please enjoy today’s offering.


Previous tutorial of interest called Windows Multitasking Tip Primer Tutorial is shown below.

Windows Multitasking Tip Primer Tutorial

Windows Multitasking Tip Primer Tutorial

A lot of Windows desktop processing tasks require you to do more than one thing at a time (calling all afficianados of multitasking). Windows (from Microsoft) caters well for people who multitask, and there is a cute keyboard shortcut for decluttering the desktop (available for Windows 7 and up) when it becomes too cluttered at your desktop …

TitleBarOfInterestHeldDown / Windows-Key / Home-Key

… all at once …

Take a look at the picture … it also works for TitleBarOfInterestHeldDown / Shake the Laptop (I kid you not … no points for doing this while hula-hooping!).

You would find that AutoHotKey could be used to achieve this also, as would the construction of your own HotKey (via a VB.Net program for instance … know this from doing it ages ago in SAP Business One).


Please see another relevant tutorial for those Windows multitaskers out there … VB.Net MultiThreading and Procexp Windows Primer Tutorial … is shown below.

VB.Net MultiThreading and Procexp Windows Primer Tutorial

VB.Net MultiThreading and Procexp Windows Primer Tutorial

A lot of desktop processing tasks require you to do more than one thing at a time (calling all afficianados of multitasking). You can decide to adopt a supervisory scripting approach, where some scripting language fires off other processes while hanging around “rock solid” itself, or you could be like a search engine that acts like a spider or tree with linked processes that start and end. Another approach is MultiThreading, where a process adopts its main thread of processing and creates and maintains other processing threads to achieve the work of the task, so that much work can be achieved by the one process (with its one pid) in Windows. In the tutorial here we concurrently play music while surfing the net in a VB.Net Windows Form desktop application. The threading “smarts” are simplified by the use of VB.Net’s BackgroundWorker ToolBox component and the “surfing the net” is achieved via a WebView ToolBox component fed with a URL to use as it loads up (in its properties section). The music arrangements are quite simplistic in that continuous music is via a Windows Media Player command line arrangement where the same MP3 file is played 10 (or is that 11?!) times in a row, and Windows Media Player is closed when the Windows Form closes (by using TASKKILL to close all Windows Media Player tasks … don’t you like how I have left you so much room for improvement?!), and the Windows Media Player has no taskbar icon while it plays. Windows Task Manager is not as good as Procexp (Process Explorer) for showing thread details with an application, so the last slide of the tutorial (which is also the picture above) shows its information and use in action regarding this VB.Net application, as it executes. Stay tuned for a tutorial of the future in “smellorama”.

Multi-threading is a widespread programming and execution model that allows multiple threads to exist within the context of a single process. These threads share the process’ resources, but are able to execute independently. The threaded programming model provides developers with a useful abstraction of concurrent execution. However, perhaps the most interesting application of the technology is when it is applied to a single process to enable parallel execution on a multiprocessing system.

This advantage of a multithreaded program allows it to operate faster on computer systems that have multiple CPUs, CPUs with multiple cores, or across a cluster of machines β€” because the threads of the program naturally lend themselves to truly concurrent execution. In such a case, the programmer needs to be careful to avoid race conditions, and other non-intuitive behaviors. In order for data to be correctly manipulated, threads will often need to rendezvous in time in order to process the data in the correct order. Threads may also require mutually exclusive operations (often implemented using semaphores) in order to prevent common data from being simultaneously modified, or read while in the process of being modified. Careless use of such primitives can lead to deadlocks.

Another use of multithreading, applicable even for single-CPU systems, is the ability for an application to remain responsive to input. In a single-threaded program, if the main execution thread blocks on a long-running task, the entire application can appear to freeze. By moving such long-running tasks to a worker thread that runs concurrently with the main execution thread, it is possible for the application to remain responsive to user input while executing tasks in the background. On the other hand, in most cases multithreading is not the only way to keep a program responsive, with non-blocking I/O and/or Unix signals being available for gaining similar results.[1]

Operating systems schedule threads in one of two ways:

Preemptive multitasking is generally considered the superior approach, as it allows the operating system to determine when a context switch should occur. The disadvantage to preemptive multithreading is that the system may make a context switch at an inappropriate time, causing lock convoy, priority inversion or other negative effects which may be avoided by cooperative multithreading.
Cooperative multithreading, on the other hand, relies on the threads themselves to relinquish control once they are at a stopping point. This can create problems if a thread is waiting for a resource to become available.

Until the late 1990s, CPUs in desktop computers did not have much support for multithreading, although threads were still used on such computers because switching between threads was generally still quicker than full process context switches. Processors in embedded systems, which have higher requirements for real-time behaviors, might support multithreading by decreasing the thread-switch time, perhaps by allocating a dedicated register file for each thread instead of saving/restoring a common register file. In the late 1990s, the idea of executing instructions from multiple threads simultaneously, known as simultaneous multithreading, had reached desktops with Intel’s Pentium 4 processor, under the name hyper threading. It has been dropped from Intel Core and Core 2 architectures, but later was re-instated in Core i3, Core i5 and Core i7 architectures.

Click on picture above to see the VB.Net MultiThreading and Procexp Windows Primer Tutorial where we concurrently play music while surfing the net in a VB.Net Windows Form desktop application. Please know that this is just a Primer Tutorial regarding MultiThreading, and that MultiThreading is a large (and often complex) subject area in programming, and, of course is not restricted to VB.Net … try C#, Java, C++ research too!

Below are some good background reading for the concepts of this tutorial (some ideas researched were not used):

Download programming source code and rename to Form1.vb.

Link to MultiThreading information … via Wikipedia from where quote above is derived.

If this was interesting you may be interested in this too.


If this was interesting you may be interested in this too.


If this was interesting you may be interested in this too.

This entry was posted in eLearning, Operating System, Tutorials and tagged , , , , , , , , , , , , , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>