This article provides information and tips for converting Microsoft VisualBasic version 1.0 for MS-DOS programs to Microsoft Visual Basic forWindows.To convert Visual Basic for MS-DOS programs, you must have bothVisual Basic version 1.0 for MS-DOS and Visual Basic version 2.0 orhigher for Windows.
: One or more of the following functions are discussed in this article; VarPtr, VarPtrArray, VarPtrStringArray, StrPtr, ObjPtr. These functions are not supported by Microsoft Technical Support. They are not documented in the Visual Basic documentation and are provided in this Knowledge Base article "as is." Microsoft does not guarantee that they will be available in future releases of Visual Basic.
Converting Visual Basic for MS-DOS Applications
If you have Visual Basic for MS-DOS, you can create applications thatrun under both MS-DOS and Windows. Such applications exist as separate.EXE files for each target environment. There is no way to create asingle file that will run in both environments. When you convert aVisual Basic application from MS-DOS to Windows, you are faced with thefollowing problems:
- The binary file formats of the modules are different for the two products.
- The appearance of some forms and controls is different.
- There are language differences between Visual Basic for MS-DOS and Visual Basic for Windows.
Some of these language differences result because Windows and MS-DOScontrol their respective environments in very different ways. Otherdifferences occur because some language components of Visual Basic forMS-DOS are simply not supported by Visual Basic for Windows.
You can resolve these problems using the following general procedure. Therest of this article includes specific information on these general steps.
To convert an application from MS-DOS to Windows:
- Start Visual Basic for MS-DOS and open the project to convert.
- Move all procedure declarations into an include file (.BI) and add a $INCLUDE metacommand at the module level of each file.
- Save each form and code module in text format.
- Copy the project's .MAK, .FRM, and .BAS files to a new directory.
- Edit the project file (.MAK) to change explicit path names--if used.
- Open the project in Visual Basic for Windows and view each form. If an error occurs reading the MS-DOS form definition, Visual Basic for Windows creates a .LOG file and displays a warning.
- Review the .LOG files (if any) to see a listing of incompatibilities. Fix these errors using Visual Basic for Windows or a text editor.
- Adjust the visual interface of the application to best match the capabilities of Windows.
- Resolve any conflicts between Visual Basic for Windows keywords and existing symbol names. (Symbols are the names of variables, constants, objects, procedures, parameters, or labels used in code.)
- Convert platform-specific code to work with the target environment.
- Run your application in the target environment to verify its behavior and to test your changes.
: Visual Basic capitalizes keywords automatically based on an internalconvention. In MS-DOS, the convention is all uppercase. In Windows, theconvention is to capitalize the first letter of each keyword. Although theappearance of your code may change, the content remains the same.
Moving Procedure Declarations to an Include File
Visual Basic for MS-DOS uses DECLARE statements to declare Basic andQuick library procedures (.QLB). Visual Basic for Windows usesDeclare only for DLLs. To avoid syntax errors when you move yourMS-DOS application to Windows, move DECLARE statements to a VisualBasic for MS-DOS include file (.BI) and add a $INCLUDE metacommand atthe module level of each file. For example:
Visual Basic for Windows does not recognize the $INCLUDE metacommand, sothis statement is treated as a comment. The code will continue to runcorrectly in Visual Basic for MS-DOS, however.
Saving Form and Code Modules in Text Format
By default, all forms and code modules (.FRM and .BAS) are saved in abinary format. As mentioned previously, however, the binary format isnot compatible between versions of Visual Basic. To load an MS-DOSproject in Windows, you must first save all of the files in text format.Once a file is saved in text format, it will continue to be saved inthat format by default.
To save a form or code module in text format:
- Start Visual Basic for MS-DOS and open the project to convert.
- From the File menu, choose Save File As. Visual Basic displays the Save File As dialog box.
- Select the Save as Text check box.
- Choose OK.
Copying Project Files
After you save the forms and code modules in text format, copy the entireproject to a new location so you do not overwrite your source application.Copy only the .MAK file and the files listed in the .MAK file. BecauseWindows and MS-DOS custom controls are not compatible, there is no need tocopy files with .QLB extensions. Portions of applications that depend oncustom controls or Quick library procedures (.QLB files) must be rewritten.
Editing the Project File
If you saved your modules to a directory other than the current one,Visual Basic for MS-DOS includes the paths in your project file (.MAK).Load this file in a text editor, and change the paths to reflect thedirectory of the new project.
Opening the Project and Viewing Forms
After copying and editing the project files, start Visual Basic forWindows and open the project. View each form in the project by selectingthe file in the Project window and choosing the View Form button.
If errors occur, Visual Basic for Windows displays a warning, "Errorsduring load." Refer to 'filename.LOG' for details. Make a note of thefile name and choose the OK button to close the dialog box.
Reviewing the .LOG Files
Two types of errors (invalid form names and invalid properties) occur whenloading an MS-DOS form in Visual Basic for Windows.
Forms in Visual Basic for Windows cannot be named MDIForm. If you have aform with this name in your MS-DOS project, it will generate the followingerror in Visual Basic for Windows and the form will not load:
MDIForm is a class name
You must change the form name in the .FRM file using a text editor. Forexample:
Version 1.00 BEGIN Form tMDIForm ' Added "t."
After making this change, reload the project.
When you view an MS-DOS form that has a property or property setting notsupported by Visual Basic for Windows, Visual Basic for Windows createsa .LOG file similar to this one:
Line 120 :Property BorderStyle in control picJAW could not be set. Line 141 :Property Attached in control HScroll1 could not be loaded. Line 254 :Property Attached in control VScroll1 could not be loaded.
It is important to review the .LOG files to check for properties thatmay be used in code or that critically affect the appearance or behaviorof your application.
When you save a form file in ASCII format, Visual Basic for Windowsomits default property settings, invalid property settings, and invalidproperties. Because Visual Basic for Windows treats omitted propertysettings as default values, invalid property settings revert to theirdefault. For more information, see Appendix A, "ASCII File Formats" ofthe Visual Basic for Windows "Programmer's Guide."
Adjusting the Visual Interface
When Visual Basic for Windows loads a project created in Visual Basicfor MS-DOS, it changes the appearance of forms as they are loaded.These changes are due to the differences between Visual Basic for MS-DOS and Visual Basic for Windows:
- The position and size of controls may change because the Visual Basic for MS-DOS character coordinates are converted to twips in Visual Basic for Windows.
- Colors may change because the Visual Basic for MS-DOS colors are converted to RGB values.
- Custom controls are mapped to picture controls.
Use the Visual Basic for Windows design tools to adjust the appearance andplacement of controls as appropriate.
You may be able to define global changes to the appearance of yourapplication by editing the ASCII form description for each form modulebefore you load the form in Visual Basic. For information about the formatof the ASCII form description, see Appendix A, "ASCII File Formats" of theVisual Basic for Windows "Programmer's Guide."
Converting Platform-Specific Code
Some applications, such as the sample application CALC.FRM, will runfine on either MS-DOS or Windows without changing much code. However,more complex applications can require significant recoding. There areseveral categories of platform-specific code that you must change tomove an application from MS-DOS to Windows:
- System calls. Code that relies on MS-DOS interrupts must be rewritten.
- Data type and scoping differences. Visual Basic for Windows and Visual Basic for MS-DOS have different default data types. The scoping rules for arrays are also different.
- Unsupported keywords. Most of the Visual Basic for MS-DOS keywords that are not supported in Windows have functionality that is replaced by forms and event-driven programming style.
- Different coding mechanisms. Some features, such as declaring global variables and displaying run-time graphics, require different coding mechanisms because of language differences between Visual Basic for Windows and MS-DOS.
The following four sections provide details on these differences:
Many MS-DOS system calls have some equivalent under Windows. However, themechanism for calling Windows functions is very different from using MS-DOSinterrupts. For information on calling Windows functions, see "CallingProcedures in DLLs" in the Visual Basic for Windows "Programmer's Guide."
Data Type and Scoping Differences
In Visual Basic for MS-DOS, the default data type is SINGLE. In VisualBasic for Windows, the default data type is Variant. This difference cancause serious errors using Get and Put on existing data files, because thetwo data types are different sizes. To avoid this, add a DefSng statementto each module that doesn't already include a Deftype statement.
To remain consistent with earlier versions of Basic, Visual Basic forMS-DOS does not allow shared array variables to be shadowed at theprocedure level. For example, the following code behaves differently inMS-DOS and Windows:
' Module level DIM SHARED Array() AS INTEGER SUB ChangeArray () ' In MS-DOS, dimensions shared array. In Windows, creates ' a new copy of the array (shadows shared array). DIM Array(10) END SUB
To avoid this unexpected behavior, rename the procedure-level array.
Visual Basic for Windows omits about 100 keywords that are supported byVisual Basic for MS-DOS. Using any of these keywords in the MS-DOSapplication that you convert to Windows results in omittedfunctionality. You must rewrite any code that relies on these keywords:
ALL INKEY$ SEEKEQBLOAD INP SEEKGEBOF INSERT SEEKGTBSAVE IOCTL SEGCALLS IOCTL$ SETINDEXCDECL ISAM SETMEMCHAIN KEY SETUEVENTCHECKPOINT LIST SIGNALCOLOR LOCATE SLEEPCOM LPOS SOUNDCOMMON LPRINT SSEGCREATEINDEX MKC$ SSEGADDCSRLIN MKDMBF$ STACKCVI MKI$ STICKCVC MKL$ STRIGCVD MKS$ SWAPCVDMBF MKSMBF$ SYSTEMCVL OUT TEXTCOMPCVS PAINT TRONCVSMBF PALETTE TROFFDELETEINDEX PCOPY UEVENTDELETETABLE PEEK UPDATEDRAW PEN VARPTRERDEV PLAY VARPTR$ERDEV$ PMAP VARSEGEVENT POS VIEWFIELD PRESET WAITFILES RUN WINDOWFN SADDFRE SAVEPOINTGETINDEX$ SCREEN NOTE:
Visual Basic for Windows does not support DEF FN functions.
Different Coding Mechanisms
The scoping mechanisms in Visual Basic for MS-DOS are different from thosein Visual Basic for Windows, as shown by this table:
|Visual Basic MS-DOS construction|| Visual Basic for Windows equivalent|
|DIM SHARED (at module level)||Dim (at module level)|
|SHARED attribute (procedure level)||None. Use module-level variable, which is visible to all procedures|
|COMMON||None. Module-level [ASCII 150] only variables are not useful in Visual Basic for Windows|
Visual Basic for MS-DOS applications cannot display forms and graphics atthe same time. This limitation does not exist in Visual Basic for Windows.Code that displays graphics must be completely rewritten for use inWindows.
Similarly, custom controls are very different in Visual Basic for MS-DOSand Windows. Custom controls and Basic code that rely on custom controlsmust be rewritten for Windows.
Running Your Converted Application
To complete the conversion, run your application in Visual Basic forWindows and test for errors. The following is a list of problems you mayencounter. Only the most likely problems are listed here, along with theerror message you may see.
- Visual Basic for Windows reserves True and False as instrinsic constants.
Possible error message - Expected: identifier Remove or comment out the constant declarations for TRUE and FALSE.
- Visual Basic for Windows allows executable code only inside a procedure; there can be no executable code or labels at the module level of a Visual Basic application.
Possible error message - Invalid outside procedure Move module-level executable code into a Sub Main ( ) procedure and set it to be the startup procedure. Convert module-level error- handling code to local error handlers.
- Visual Basic for Windows does not recognize the DATA statement.
Possible error message - Expected: statement Convert the values in the DATA statement(s) to a sequential file; replace the DATA statement(s) with a block of code that opens, reads, and closes the file.
- Visual Basic for Windows does not recognize the COMMON keyword.
Possible error message - Expected: end-of-statement Replace the COMMON SHARED keywords with the keyword PUBLIC. Move module-level code into procedures.
- Visual Basic for Windows puts invalid procedure definitions at the Declarations level of a module.
Possible error message - Expected: parameter or ) Cut the procedure code from the Declarations level and paste it into a valid procedure definition. Delete the invalid procedure definition.
Techniques for Platform-Independent Applications
Writing an application that will convert easily from MS-DOS to Windowsrequires some planning. Here are some suggestions that make the processeasier.
- Start with MS-DOS. The appearance of MS-DOS forms requires less adjustment when converted to Windows. Also, because the forms-related features of Visual Basic for MS-DOS are a subset of those available in Windows, you are less likely to inadvertently use a feature for which there is no solution.
- Use the portable subset of the language. The lists of unsupported keywords provided earlier in this chapter will give you an idea of features to avoid when planning a portable application.
- Debug your MS-DOS application before you convert it to Windows. If you start with an application that runs without errors, you can assume that errors you encounter when converting are related to differences between the two platforms. This will save you a lot of time trouble-shooting.
- Create parallel Include files. In Visual Basic for MS-DOS, place COMMON SHARED and constant declarations in an Include file (.BI). For the Visual Basic application, add a Basic module (.BAS) with parallel Global declarations and appropriate constants.
- Package portable procedures in code modules. Procedures that will run in MS-DOS or Windows without modification should be placed in code modules (.BAS) that you can share between the two platforms.
- Modularize run-time graphics. Place all run-time graphics procedures in a separate module. Visual Basic for MS-DOS does not support graphics while forms are showing, and code for MS-DOS graphics is more hardware- dependent than similar code for Windows.
- Test portability. When developing a large application, periodically test its portability during development. This will help you develop a portable coding style.
Detecting the Platform at Startup
Applications created with Visual Basic for Windows include code that willautomatically start Windows if it is not running on your system. Thisfeature can be used to create an application that will run in eitherWindows or MS-DOS.
The following batch file starts CALCWIN.EXE. If Windows is not available orcannot start, the batch file runs CALCDOS.EXE instead:
IF ERRORLEVEL 1 CALCDOS.EXE
The application sets an MS-DOS error code of 1 if it can't start Windows.Otherwise, the error code is 0 when the application ends.
NOTE: This feature also applies to MS-DOS sessions. If Windows can't startbecause it is already running, the preceding batch file will startCALCDOS.EXE.