Article ID: 120075 - View products that this article applies to.
This article was previously published under Q120075
This article provides information and tips for converting Microsoft Visual Basic version 1.0 for MS-DOS programs to Microsoft Visual Basic for Windows. To convert Visual Basic for MS-DOS programs, you must have both Visual Basic version 1.0 for MS-DOS and Visual Basic version 2.0 or higher for Windows.
WARNING: 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 ApplicationsIf you have Visual Basic for MS-DOS, you can create applications that run under both MS-DOS and Windows. Such applications exist as separate .EXE files for each target environment. There is no way to create a single file that will run in both environments. When you convert a Visual Basic application from MS-DOS to Windows, you are faced with the following problems:
You can resolve these problems using the following general procedure. The rest of this article includes specific information on these general steps.
To convert an application from MS-DOS to Windows:
Moving Procedure Declarations to an Include FileVisual Basic for MS-DOS uses DECLARE statements to declare Basic and Quick library procedures (.QLB). Visual Basic for Windows uses Declare only for DLLs. To avoid syntax errors when you move your MS-DOS application to Windows, move DECLARE statements to a Visual Basic for MS-DOS include file (.BI) and add a $INCLUDE metacommand at the module level of each file. For example:
'$INCLUDE: 'DOSINC.BI'Visual Basic for Windows does not recognize the $INCLUDE metacommand, so this statement is treated as a comment. The code will continue to run correctly in Visual Basic for MS-DOS, however.
Saving Form and Code Modules in Text FormatBy default, all forms and code modules (.FRM and .BAS) are saved in a binary format. As mentioned previously, however, the binary format is not compatible between versions of Visual Basic. To load an MS-DOS project 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 in that format by default.
To save a form or code module in text format:
Copying Project FilesAfter you save the forms and code modules in text format, copy the entire project 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. Because Windows and MS-DOS custom controls are not compatible, there is no need to copy files with .QLB extensions. Portions of applications that depend on custom controls or Quick library procedures (.QLB files) must be rewritten.
Editing the Project FileIf 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 the directory of the new project.
Opening the Project and Viewing FormsAfter copying and editing the project files, start Visual Basic for Windows and open the project. View each form in the project by selecting the file in the Project window and choosing the View Form button.
If errors occur, Visual Basic for Windows displays a warning, "Errors during load." Refer to 'filename.LOG' for details. Make a note of the file name and choose the OK button to close the dialog box.
Reviewing the .LOG FilesTwo types of errors (invalid form names and invalid properties) occur when loading an MS-DOS form in Visual Basic for Windows.
Forms in Visual Basic for Windows cannot be named MDIForm. If you have a form with this name in your MS-DOS project, it will generate the following error in Visual Basic for Windows and the form will not load:
You must change the form name in the .FRM file using a text editor. For example:
MDIForm is a class name
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 not supported by Visual Basic for Windows, Visual Basic for Windows creates a .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 that may be used in code or that critically affect the appearance or behavior of your application.
When you save a form file in ASCII format, Visual Basic for Windows omits default property settings, invalid property settings, and invalid properties. Because Visual Basic for Windows treats omitted property settings as default values, invalid property settings revert to their default. For more information, see Appendix A, "ASCII File Formats" of the Visual Basic for Windows "Programmer's Guide."
Adjusting the Visual InterfaceWhen Visual Basic for Windows loads a project created in Visual Basic for 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:
You may be able to define global changes to the appearance of your application by editing the ASCII form description for each form module before you load the form in Visual Basic. For information about the format of the ASCII form description, see Appendix A, "ASCII File Formats" of the Visual Basic for Windows "Programmer's Guide."
Converting Platform-Specific CodeSome applications, such as the sample application CALC.FRM, will run fine on either MS-DOS or Windows without changing much code. However, more complex applications can require significant recoding. There are several categories of platform-specific code that you must change to move an application from MS-DOS to Windows:
System CallsMany MS-DOS system calls have some equivalent under Windows. However, the mechanism for calling Windows functions is very different from using MS-DOS interrupts. For information on calling Windows functions, see "Calling Procedures in DLLs" in the Visual Basic for Windows "Programmer's Guide."
Data Type and Scoping DifferencesIn Visual Basic for MS-DOS, the default data type is SINGLE. In Visual Basic for Windows, the default data type is Variant. This difference can cause serious errors using Get and Put on existing data files, because the two data types are different sizes. To avoid this, add a DefSng statement to each module that doesn't already include a Deftype statement.
To remain consistent with earlier versions of Basic, Visual Basic for MS-DOS does not allow shared array variables to be shadowed at the procedure level. For example, the following code behaves differently in MS-DOS and Windows:
To avoid this unexpected behavior, rename the procedure-level array.
Unsupported KeywordsVisual Basic for Windows omits about 100 keywords that are supported by Visual Basic for MS-DOS. Using any of these keywords in the MS-DOS application that you convert to Windows results in omitted functionality. You must rewrite any code that relies on these keywords:
NOTE: Visual Basic for Windows does not support DEF FN functions.
ALL INKEY$ SEEKEQ BLOAD INP SEEKGE BOF INSERT SEEKGT BSAVE IOCTL SEG CALLS IOCTL$ SETINDEX CDECL ISAM SETMEM CHAIN KEY SETUEVENT CHECKPOINT LIST SIGNAL COLOR LOCATE SLEEP COM LPOS SOUND COMMON LPRINT SSEG CREATEINDEX MKC$ SSEGADD CSRLIN MKDMBF$ STACK CVI MKI$ STICK CVC MKL$ STRIG CVD MKS$ SWAP CVDMBF MKSMBF$ SYSTEM CVL OUT TEXTCOMP CVS PAINT TRON CVSMBF PALETTE TROFF DELETEINDEX PCOPY UEVENT DELETETABLE PEEK UPDATE DRAW PEN VARPTR ERDEV PLAY VARPTR$ ERDEV$ PMAP VARSEG EVENT POS VIEW FIELD PRESET WAIT FILES RUN WINDOW FN SADD FRE SAVEPOINT GETINDEX$ SCREEN
Different Coding MechanismsThe scoping mechanisms in Visual Basic for MS-DOS are different from those in Visual Basic for Windows, as shown by this table:
Collapse this tableExpand this table
Visual Basic for MS-DOS applications cannot display forms and graphics at the same time. This limitation does not exist in Visual Basic for Windows. Code that displays graphics must be completely rewritten for use in Windows.
Similarly, custom controls are very different in Visual Basic for MS-DOS and Windows. Custom controls and Basic code that rely on custom controls must be rewritten for Windows.
Running Your Converted ApplicationTo complete the conversion, run your application in Visual Basic for Windows and test for errors. The following is a list of problems you may encounter. Only the most likely problems are listed here, along with the error message you may see.
Techniques for Platform-Independent ApplicationsWriting an application that will convert easily from MS-DOS to Windows requires some planning. Here are some suggestions that make the process easier.
Detecting the Platform at StartupApplications created with Visual Basic for Windows include code that will automatically start Windows if it is not running on your system. This feature can be used to create an application that will run in either Windows or MS-DOS.
The following batch file starts CALCWIN.EXE. If Windows is not available or cannot 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 start because it is already running, the preceding batch file will start CALCDOS.EXE.
Article ID: 120075 - Last Review: August 16, 2005 - Revision: 2.3
Retired KB Content Disclaimer
This article was written about products for which Microsoft no longer offers support. Therefore, this article is offered "as is" and will no longer be updated.