| VB 6 and DOS | ||
| Using VB 6 with DOS requires some new thinking | ||
![]() A recent programming job required a DOS solution to be programmed using VB 6. You remember DOS? ... The operating system responsible for the PC revolution? A DOS environment is still the best way to interface some systems. (The contract specifications required an interface to an all-Java environment.) But VB 6 assumes that it is in a Windows environment. In fact, it's actually easier to create 'DOS' based systems in VB.NET than using VB 6. But VB 6 is capable of creating DOS systems. Here's how it's done! |
||
|
When you start a new project using VB.NET, one of the choices presented to you is Console Application. In fact, many of the best books about VB.NET and .NET foundation make the console interface to VB.NET their main focus because Windows isn't really assumed anymore in the object oriented .NET world. Windows is treated as just one of the supported .NET environments. (This is a significant break with the past for Microsoft! Look for more and more software from Microsoft that, well, "runs in Windows" but isn't necessarily "Windows" anymore.) A good example is Jesse Liberty's groundbreaking introduction to VB.NET, Learning Visual Basic .NET. When you start a new project using VB 6, however, the template for a console app is missing! The "Standard EXE" starts with a Windows form, the "ActiveX EXE" and "ActiveX DLL" are classes. So you try the Help system. Microsoft continually updates Help so your version might be different than mine (I have October 2001, the last one provided by Microsoft for Visual Studio 6), but the Visual Basic Documentation in my version has no entries for DOS or Console. In fact, I couldn't find anything in Help spelling out the steps. So how do you just create a plain old app that runs in DOS? Creating something that 'looks like' DOS is pretty simple. One way to define a DOS app is just to assume that it's a VB 6 Windows App that lacks a form. To create this type of DOS app, follow these steps: Ordinarily, your project will automatically start by displaying Form1. (VB 6 coders know that the initial Form Load event is a good place to put some types of startup code.) But when you delete Form1 from the project, Visual Studio defaults to Sub Main() instead. So you should also start the module that was added with a Sub Main() subroutine. You create an EXE the same way using the File menu. Many DOS programs require parameter input on the command line when they run. But how do you emulate that when you're testing? To solve this problem, simply right click the Project and select Properties. Then select the Make tab and enter whatever you want the program to be able to read input a command line parameter. The illustration shows both running as an EXE and the dialog to input the parameter for testing. But now things get a bit more fun! Keep in mind that what you have so far is really a Windows program, not actually DOS as we once knew it. 'Real' DOS was 16 bit software. The new Windows console is a 32 bit Windows session. It's mainly just a different design for a standard window. So popping open a MsgBox or another form from your code isn't a problem. But if you expect this app to do what 'real' DOS would do, you're in for a surprise. For example, how do you send things to the DOS StdOut or read things from DOS StdIn (this is what you do if you "redirect" something from one DOS command to another as in the command DIR > DirList.txt to create a directory list in the file DirList.txt.) Since the command window in 32-bit Windows application is not actually DOS, the traditional DOS interfaces aren't available. A VB 6 console application "detaches" from the VB 6 session that launched it, and without some extra coding, you can't write to the DOS window or accept input from the DOS window in your VB 6 program. In fact, just defining what "DOS" really is in an XP world can become really confusing. In Windows 98 and earlier, DOS was started using the executable file COMMAND.COM. In Windows NT and later, it was changed to CMD.EXE. You can read a great page discussing this issue at What Do You Mean, "DOS"?. If you search the web for information about this, you will find lots of pages that talk about "DOS Mode". (Hint: There isn't one for Windows 2000, NT and XP.) You can also find lots of advice about how "Windows" programs "won't run in DOS" because they have to be "converted" using the VB Link command or some other Microsoft utility. (Hint: They run just fine in a Win32 "command prompt" window.) So there is a lot of, well ... not wrong but misleading information out there waiting to trip you up. Before you decide to code up a routine in DOS and VB 6, thinking it will be easier than a Windows app, think again. Many DOS "command" functions require calls to Win32 API interfaces to make them work at all. The example used earlier, using StdIn and StdOut, requires both a knowledge of how VB 6 creates a new Windows session for the DOS window and the use of Win32 API's. Because it's quite long, the complete text of the example program that accepts a selection from a Win32 console window and displays the name of the computer is at the end of this article. If you "don't do" Win32 API programming, you may have difficulty with this example. Try this article to learn about Win32 API programming. The program starts by creating a Win32 console window to work in and ends by destroying it again. These are the functions that do the trick. Check the program source at the end of the article to see how they're used. To write to StdOut, just use the WriteConsole function and to read from StdIn, use the ReadConsole function. Another way to simply execute programs as you might in DOS is to use the Shell function. An example of something you might want to do would be to call the console command ping.exe to see if a web URL is active. In this case, another Win32 API call, WaitForSingleObject is used because Ping operates asynchronously. We don't want to close the session until Ping completes. Here's how that might be done. To get the most recent version of the Shell and common controls DLLs, download and install Internet Explorer. The FileSystemObject object is another tool that is very useful in scripts. The FSO object model is contained in a type library called Scripting, which is located in the file Scrrun.Dll. Check Microsoft Scripting Runtime in the References dialog to add it to your program. You can then use the Object Browser to view its objects, collections, properties, methods, and events, as well as its constants. The bottom line is that DOS and VB 6 is a "mixed bag" at best. The way to survive is to hunt around in a whole variety of tools and objects until you (finally!!!) find the one that will work for you. |
||


