OLE container application often have special requirements not normally handled by installation programs, such as those generated by the Setup Wizard. This chapter explains those special requirements.
In this chapter, you learn how to do the following:
Ordinarily, you can use the Setup Wizard shipped with Visual Basic to create distribution disks for your application. The Setup Wizard takes care of these installation tasks:
OLE container applications have additional requirements, however. To correctly install an OLE container application, you may add the following tasks to the installation process:
The .LST file generated by the Setup Wizard contains information about how to register each file it installed. A typical entry in the .LST file looks like this:
The sixth argument, $(DLLSelfRegister), indicates what action the Setup program takes when registering the file. Possible values for the sixth argument are as follows:
Value | Meaning |
None. | File is not registered. |
$(DLLSelfRegister) | Use the DllSelfRegister function to register the file. |
$(EXESelfRegister) | Use the ExeSelfRegister function to register the file. |
filename | Use the Registration Info Editor (REGEDIT.EXE) to merge the file with the system registration database. |
If your application uses a .REG file, be sure to edit the .LST file to register the application at setup. For example, the following lines copy the .REG file and registers the OLESTORE application:
Visual Basic applications that expose OLE Automation objects are automatically flagged as $(EXESelfRegister). If these applications provide a .REG file as well, save the registration information that Visual Basic creates into the application’s .REG file, then use that file to register the application at setup.
Applications that rely on other applications for objects can be a nightmare to maintain. You should never assume that users have all the object applications required by your application. To check for installed OLE object applications, query the system registration database before you install your application.
The GetRegisteredList procedure (listing 16.1) returns an array containing the names of all the installed OLE applications from the target system’s system registration database:
Listing 16.1 Checking for Installed OLE Objects
To verify that the OLE object applications you need are installed, search for the name of the required application in the array returned by GetRegisteredList. The CheckInstalled procedure (listing 16.2) checks a list of required applications against the list of installed applications.
Listing 16.2 The CheckInstalled Procedure
The following Main procedure shows how to use the GetRegisteredList and CheckInstalled procedures together:
Depending on the size and complexity of your application, it is quite possible that the Visual Basic support files you must distribute are several times the size of your actual .EXE on disk. Usually, these files are already found on the user’s system. However, you must always distribute these files along with your .EXE in case your user’s files are out of date or not already installed.
OLE container applications require the following files:
Required by | File Name | Description |
---|---|---|
Visual Basic | VB40016.DLL VB40032.DLL |
Visual Basic run-time library. |
VB4EN16.DLL VB4EN32.DLL |
Visual Basic English-language object library. This file name will be different for other national languages. | |
SCP.DLL SCP32.DLL |
Code page translation library. | |
OLE | DDEML.DLL | Dynamic data exchange manager. |
COMPOBJ.DLL | OLE support for component objects. | |
OLE2.DLL | General OLE functions. | |
OLE2.REG | Registration file for OLE. | |
OLE2CONV.DLL | Supports converting OLE data types. | |
OLE2DISP.DLL | Supports OLE Automation. | |
OLE2NLS.DLL | Supports OLE national language support and localization features. | |
OLE2PROX.DLL | Supports cross-process invocations. | |
STDOLE.TLB | The OLE object library. | |
STORAGE.DLL | Supports creating OLE compound documents. | |
TYPELIB.DLL | Supports access and creation of object libraries. | |
Setup Toolkit | SETUP.EXE | Bootstrap setup program. Decompresses the Visual Basic run-time and support files, and launches the Setup1 or Setup32 program. |
SETUP.LST | Listing of files to install. | |
SETUP1.EXE | Setup program that installs files. | |
SETUPKIT.DLL | Support functions for Setup Wizard and Setup Toolkit. | |
VER.DLL | Checks file versions during installation. | |
VSHARE.386 | Permits file sharing under Windows. | |
Custom controls | ??????16.OCX ??????32.OCX |
As used by your application. |
OC25.DLL | Run-time DLL for OLE custom controls (.OCX). |
Because of the difficulties customizing the disk layout or installation procedure generated by the Setup Wizard, you may choose to use other installation tools, such as PKZIP—a popular shareware program from PKWARE, Inc. in Brown Deer, WI. If you are using these other setup tools, or creating your own, be sure to perform the following tasks before copying any of the Visual Basic run-time or OLE support files to users’ systems:
The VER.DLL (16-bit) and VERSION.DLL (32-bit) support files included in the Setup Toolkit provide functions for comparing file version information. The file COMMON.BAS in the Setup Toolkit provides declarations for the functions in these two .DLLs and demonstrates how to use those functions to compare file versions. Table 16.1 lists the functions you use when comparing file versions.
Table 16.1 Version-Comparison Functions in VER.DLL and VERSION.DLL
Procedure | Found in | Use to |
---|---|---|
GetFileVersionInfo | VER.DLL (16-bit) VERSION.DLL (32-bit) COMMON.BAS (declared) |
Retrieve version information from a file. |
GetFileVersionInfoSize | VER.DLL (16-bit) VERSION.DLL (32-bit) COMMON.BAS (declared) |
Get the size of the version information to retrieve (required to allocate a string to receive the version information). |
lmemcpy | SETUP.DLL (16-bit) STPKIT32.DLL (32-bit) COMMON.BAS (declared) |
Copy information retrieved by VerQueryValue into a Visual Basic variable. |
VerQueryValue | VER.DLL (16-bit) VERSION.DLL (32-bit) COMMON.BAS (declared) |
Extract an item of information out of the version information retrieved by GetFileVersionInfo. |
VerFindFile | VER.DLL (16-bit) VERSION.DLL (32-bit) |
Locate a file on the user's system before installing. |
VerInstallFile | VER.DLL (16-bit) VERSION.DLL (32-bit) COMMON.BAS (declared) | Attempt to install a file based on provided file version information. |
The VerFindFile and VerInstallFile are the two main functions you use to install files from distribution disks to a target system. Listing 16.3 show the declarations and constant values used for VerFindFile and VerInstallFile.
Listing 16.3 Declarations for VerFindFile and VerInstallFile
The InstallFile procedure in listing 16.3 demonstrates how to use VerFindFile and VerInstallFile during setup. First, VerFindFile checks the user’s system for the file to install. If the file is not found, InstallFile copies the file to the destination directory using VerInstallFile. If the file is found, then VerInstallFile compares the file’s version numbers, preserving the more up-to-date file.
Listing 16.4 Using VerFindFile and VerInstallFile
To use InstallFile to copy a file from your distribution disks to the user’s system, call the procedure with source and destination arguments, as follows:
The VerInstallFile function automatically expands the file if it was compressed on the distribution disk.
The preceding procedure uses the GetWinDir utility function (listing 16.5). GetWinDir is a general-purpose function that simply returns the directory where Windows is installed.
Listing 16.5 The GetWinDir Utility Function
The SETUPKIT.DLL (16-bit) and STPKIT32.DLL (32-bit) support files included in the Setup Toolkit provide functions for registering files with the system registration database. Files may register themselves or provide a .REG file which should be merged with the system registration database.
Table 16.2 Registration Functions in SETUP.DLL and STPKIT32.DLL
Procedure | Found in | Use to |
---|---|---|
FSyncShell | COMMON.BAS | Start an application and wait for it to finish running. |
DLLSelfRegister | SETUP.DLL (16-bit) STPKIT32.DLL (32-bit) COMMON.BAS (declared) | Merge registration information stored in a DLL into the system registration database. |
ExeSelfRegister | SETUP.DLL (16-bit) STPKIT32.DLL (32-bit) COMMON.BAS (declared) | Merge registration information stored in an .EXE into the system registration database. |
RegEdit | SETUP1.BAS | Merge registration information stored in an .REG file into the system registration database. |
When distributing applications on 16- and 32-bit platforms you have three choices:
The support files for each target system consume about 2M of disk space compressed. Dual-platform installation disks will use at least three disks for support files alone.
The Setup Wizard comes in 16- and 32-bit versions. Use the 16-bit version to create distribution disks for 16-bit target platforms; and use the 32-bit version to create disks for 32-bit platforms.
The Setup Wizard does not directly support creating dual-platform installation disks. In order to create an installation system that automatically switches between 16- and 32-bit file lists, depending on the user’s operating system, you need to perform these tasks.
The problem with distributing 16- and 32-bit applications on the same disks is that the Setup Toolkit is written in Visual Basic and, therefore, requires the Visual Basic run-times and support .DLLs to be installed by SETUP.EXE before you can use Visual Basic code to determine which operating system is running.
You must install the 16-bit run-time and support files on 32-bit systems if you use the Setup Toolkit to create distribution disks that support both platforms. This cost—several megabytes of disk space—may be enough to convince you to use two sets of installation disks. On the other hand, most of your 32-bit target systems may already have the 16-bit Visual Basic run-time and support files installed, so this issue may be moot.
In the SETUP1.VBP project, make these modifications:
The CheckOperatingSystem procedure sets the setup file list to use, based on which operating system the target system is running:
The CheckOperatingSystem procedure uses four utility functions to parse version information from the long integer returned by the GetVersion API function. These utility functions are also useful for parsing flags—in fact, the Windows header file (WINDOWS.H) defines C macros with equivalent names.
To create the distribution disks for both 16- and 32-bit platforms, follow these steps:
Visual Basic can create applications that run under the Windows 3.1 (16-bit) operating system, Windows NT 3.5 (32-bit) operating system, or Windows 95 (32-bit) operating system. Visual Basic itself comes in two versions: 16-bit and 32-bit.
For the most part, the same Visual Basic code will compile and run in either version of Visual Basic. However, you must use the appropriate version of Visual Basic for the operating system you are using (16- or 32-bit). You can’t run Visual Basic 16-bit under Windows 95, or Visual Basic 32-bit under Windows 3.1. Table 16.3 shows the compatibility between Visual Basic and widely installed Windows operating systems.
Table 16.3 Visual Basic Windows Operating System Compatability
Item | Runs Under This Operating System | |||
---|---|---|---|---|
Windows 3.1 | Windows NT 3.1/3.5 | Windows NT 3.51 | Windows 95 | |
Visual Basic 16-bit development environment | Y | N | Y | Y |
Visual Basic 32-bit development environment | N | N | Y | Y |
Visual Basic 16-bit applications | Y | Y | Y | Y |
Visual Basic 32-bit applications | N | N | Y | Y |
As table 16.3 shows, you can run 16-bit applications created with Visual Basic on some 32-bit platforms. However, you can’t run 32-bit applications on any 16-bit platform.
To create a 16-bit application in Visual Basic, you must use the 16-bit version of the Visual Basic development environment. Similarly, you must use the 32-bit development environment to create 32-bit .EXEs. You can use the same project (.VPJ) and source files on both platforms, with the exceptions shown in table 16.4.
Table 16.4 Compatibility Problems and Solutions When Sharing Visual Basic Code between 16- and 32-Bit Platforms
Problem | Solution |
---|---|
Old-style custom controls (.VBX) are not supported in Visual Basic 32-bit. Resource files (.RES) are 16-bit and 32-bit specific. | Use OLE custom controls (.OCX). Create duplicate 16- and 32-bit resource files and separate project files for 16- and 32-bit. |
Windows API library names and functions names may be different between operating systems. | Use the Alias keyword and/or conditional compilation when declaring Windows API functions. |
The API function names are case-sensitive on 32-bit systems; they are case-insensitive on 16-bit systems. | Use the Alias keyword when declaring Windows API functions. |
Window handles (hWnd) are the Integer data type in 16-bit operating systems and the Long data type in 32-bit systems. | Use conditional compilation statements for all API functions that take hWnd arguments or return hWnd values. |
Compiled support file names (.OCX, .DLL, .EXE) are usually different between 16-bit and 32-bit systems. Support files usually embed "16" or "32" in their names to identify their target operating system. | Create separate .VPJ files for 16- and 32-bit and use conditional compilation statements when declaring API functions in DLLs. Create separate 16- and 32-bit Setup disks when distributing applications. |
You cannot use the Visual Basic StrConv function in 32-bit Visual Basic. Therefore, you can't access Unicode text strings in data files. | Use only ANSI data files when doing file I/O in code. |
When using OLE objects in Visual Basic, you may not know whether the application providing the object is a 16- or 32-bit executable. The OLE DLLs support calling between 16- and 32-bit executables any which-way. However, you need to be aware of conversions that may occur as a result.
Container (.EXE) | Object (.EXE) | Automatic OLE Conversion |
16-bit | 16-bit | None. All strings are ANSI. |
16-bit | 32-bit | Call: ANSI strings converted to Unicode. Return: Unicode strings converted to ANSI |
32-bit | 16-bit | Call: Unicode strings converted to ANSI. Return: ANSI strings converted to Unicode. |
32-bit | 32-bit | None. All strings are Unicode. |
When using OLE objects that are contained in DLLs, a Visual Basic application uses the DLL that matches the mode that the application was compiled in. 16-bit applications use only 16-bit OLE object DLLs; and 32-bit applications use only 32-bit OLE object DLLs.
All Windows DLLs (16- or 32-bit) use ANSI character strings. Visual Basic 32-bit uses Unicode strings internally, but uses ANSI characters when passing or receiving strings from API functions declared in code. If you are using the 32-bit version of Visual Basic, Visual Basic automatically converts arguments to ANSI from Unicode and return values to Unicode from ANSI.
Container (.EXE) | DLL | Automatic Conversion |
16-bit | API 16-bit | None. All strings are ANSI. |
16-bit | OLE 16-bit | None. All strings are ANSI. |
32-bit | API 32-bit | Call: Aguments converted from Unicode to ANSI. Return: Arguments converted from ANSI to Unicode. |
32-bit | OLE 32-bit | None. All strings are Unicode. |
For more information on related topics, see Chapter 23, “Building and Distributing OLE Objects,” explains how to install OLE server applications.
© 1996, QUE Corporation, an imprint of Macmillan Publishing USA, a Simon and Schuster Company.