a p p e n d i x A

Meeting Windows Logo

Requirements
EPS: Please Change the title to just
Appendix rather than Appendix A.
There is only one.
The Windows Logo Program
Windows Fundamentals
Windows Installer Service
Component Sharing
Data and Settings Management
User Interface Fundamentals
OnNow/ACPI Support
Application Migration
Appendix A Meeting Windows Logo Requirements 416
For several years, Microsoft has sponsored a variety of Designed for Win-
dows and Certified for Windows logo programs. Applications that met a set of
requirements and passed independent verification of their compliance were
allowed to display the Windows logo on their packaging and advertising. In this
appendix, Ill show you how you can use Visual Basic along with the Windows
Installer to meet the most recent version of these requirements.
The Windows Logo Program
The requirements for the current logo program are contained in a document titled
Application Specification for Microsoft Windows 2000. (Actually, there are both
desktop and distributed versions of this document; Ill concentrate on the desktop
specifications). You can download a copy of this document yourself from
Microsofts Web site at msdn.microsoft.com/winlogo. Version 1.0a of this
specification was released in January 2000, just before the release of Windows
2000 itself.
Applications which comply with this specification are eligible to display the
Certified for Windows logo, along with a list of the Windows platforms that the
product is certified on. However, before an application can display the logo, its
compliance must be verified. Verification is performed by an independent com-
pany named VeriTest. The VeriTest Web site is at www.veritest.com/msl-
ogos/windows2000/.
The basic fee for logo compliance testing starts at $5,200 and goes up from there,
though both Microsoft and VeriTest have offered discount coupons from time to
time. This is obviously more than youll want to spend for many internal applica-
tions. But you should consider the logo guidelines even if youre not interested in
applying for the actual logo. Thats because, as youll see in this appendix, these
guidelines are not simply arbitrary hoops to jump through. Rather, they represent
the state of the art in designing applications that run well and interact smoothly
with the Windows operating system.
In an appendix this size, I can only summarize the guidelines. If youre inter-
ested in seeing how Microsoft says you should write Windows applications, I
encourage you to download the full application specification for yourself.
The application specification is broken up into seven major areas, which in turn
contain 40 separate requirements:
Windows Fundamentals
Windows Installer Service
Windows Fundamentals 417
Component Sharing
Data and Settings Management
User Interface Fundamentals
OnNow/ACPI Support
Application Migration
Ill consider each of these areas in turn in the rest of the appendix. As youll see,
you can meet most of the logo requirements for free simply by using Visual
Basic 6.0 as your development platform and the Windows Installer as your setup
platform.
Windows Fundamentals
The Windows fundamentals group of requirements includes 10 areas that your
application should pass to be certified. These areas represent basic functionality:
Provide primary functionality and maintain stability
Provide 32-bit components
Support long file names and UNC paths
Support printers with long names and UNC paths
Do not read or write certain files
Associate types with your data files
Perform Windows version checking correctly
Support AutoPlay of compact disks
Install only verified Kernel Mode drivers
Install only (Windows Hardware Quality Labs) WHQL-tested hardware
drivers
Provide Primary Functionality and Maintain Stability
What this requirement really says is that your application should not crash Win-
dows and that Windows should not crash your application. For the most part,
Appendix A Meeting Windows Logo Requirements 418
Visual Basic applications should be safe here because the Visual Basic runtime
protects you from most unusual techniques that could get you in trouble. Errors
such as trying to write to a nonexistent drive letter, or trying to create a file larger
than a drive, will be caught by the runtime library and be returned to your pro-
gram as an error.
This requirement does emphasize the need for your application to contain thor-
ough and consistent error trapping. Even if something goes wrong, your applica-
tion must not collapse entirely. This means that every procedure except the most
trivial (one-line calls to another procedure, for example) must contain an error
handler, and that error handler must contain a Case Else to manage the
response to unexpected errors.
You can also use the resiliency functions of the Windows Installer to help make
your application more robust. For example, you can use the Installer automation
model or API to check the path to a component that the user might have installed
anywhere, or to request that a copy of a missing component be reinstalled from
the source media.
Provide 32-Bit Components
Certified applications must use 32-bit executables. If youre using Visual Basic 6.0
as your development environment, you get this automatically. All executables
compiled by Visual Basic 6.0 are 32-bit.
Support Long File Names and UNC Paths
Logo-compliant applications that allow users to enter file names (for example,
when they choose a file to open) must support both long file names (LFNs) and
Universal Naming Convention (UNC) paths. This should not be a problem for
applications written in Visual Basic, because Visual Basic itself understands LFNs
and UNCs consistently.
One minor area that may cause a problem in Visual Basic applications is the
Common Dialog Control. If you allow the user to multiselect files, and specify that
you want long file names, it uses a null-separated format to return file names:
Path<null>Filename1<null>Filename2<null>
You can use the InStr() function to break this string apart at the nulls and
reassemble it.
Windows Fundamentals 419
The Windows Installer Service supports both LFNs and UNC paths as installa-
tion locations. For full support of LFNs, you should specify long names for all of
your files in the File table inside of your Installer database.
Support Printers with Long Names and UNC Paths
Logo-compliant applications must be able to use printers with long names or
located at UNC paths. Again, if you use Visual Basic and the Common Dialog con-
trol to handle your printing, you get this functionality automatically.
Do Not Read or Write Certain Files
There are four files that you should not read or write to on Windows NT or Win-
dows 2000 systems:
autoexec.bat
config.sys
win.ini
system.ini
This requirement comes about because those files may not exist on all operating
systems and users may not have the necessary permissions to write to their
default locations. Fortunately, youve got several easy alternatives for storing
information: the Registry or private .ini files.
To use the Registry from Visual Basic, you can use the SaveSetting, GetSetting,
and GetAllSettings functions. To use a private .ini file, you can use the WritePri-
vateProfileString and GetPrivateProfileString API calls.
Of course, the Windows Installer also supports writing information to the Reg-
istry via the Registry table (and associated special tables for COM information). It
also supports the use of private .ini files through the IniFile table and associated
tables.
So, using the combination of Visual Basic and the Windows Installer, you can
set up your application with its configuration information in approved locations,
and then read and write that data as necessary from those same locations.
Appendix A Meeting Windows Logo Requirements 420
Associate Types with Your Data Files
To be more precise, if your application creates non-hidden files outside of its own
directory, these files must be associated with icons, file type descriptions, and
default actions.
The simplest way to conform to this requirement, of course, is to just not create
files outside of your applications own directory. This may not be feasible, of
course, especially if your application needs to save files for later use and prompts
the user for their location.
An alternative strategy is to use a file extension thats already sure to be regis-
tered on the target system by Windows itself. For example, if you save your appli-
cations files with the extension .txt, theyll appear as normal text files in the
operating system. However, with this approach youll have to figure out what to
do if the user attempts to open a text file that doesnt contain data usable by your
application or wasnt created with your application.
Probably the better approach is to actually register a distinct file type with your
application for its data files. The Windows Installer can help you do this when you
install your application. All the information to handle the needs of data files is
contained in the Registry table group in the Installer database.
Perform Windows Version Checking Correctly
This is a relatively simple requirement, but it causes problems for many applica-
tions. If your application is meant to run on Windows NT 4.0 or higher, you
should check that the Windows version number is greater than or equal to 4.0 (not
that its exactly equal to 4.0). Checking for exact equality has broken hundreds of
applications in the past, despite the fact that this should be obvious.
Listing 2.1 in Chapter 2, Running the Installer, shows how you can use the
GetVersionInfoEx() API call from Visual Basic to determine the Windows version.
If you need to know the Windows version while installing, the Windows
Installer Service provides the VersionNT and Version9x properties.
Support AutoPlay of Compact Disks
Logo-compliant applications distributed on CD-ROM or DVD-ROM must use the
Windows AutoPlay feature to launch the application setup when theyre inserted
into the CD-ROM drive for the first time. If youre using a professional Installer
Windows Installer Service 421
editing package, your package may create an AutoPlay program for you. Other-
wise, you can create your own autorun.inf file on the CD to take care of this detail.
The simplest possible autorun.inf file looks like this:
[autorun]
open=setup.exe
That tells Windows to run the setup.exe program in the root directory of the CD
when that CD is inserted into the drive.
For more information on the possible options you can specify in an
autorun.inf file, refer to the MSDN Web site article Creating an Autoplay-
enabled CD-ROM Application at msdn.microsoft.com/library/psdk/
shellcc/shell/Shell_basics/Autoplay_intro.htm.
Install Only Verified Kernel Mode Drivers
If your product installs kernel mode drivers, those drivers must pass the tests
administered by the Windows 2000 Driver Verifier Manager tool. If youre writing
your product in Visual Basic, youre not going to be writing kernel mode drivers,
so you dont need to worry about this requirement.
Install Only WHQL-Tested Hardware Drivers
If your product installs hardware drivers, those drivers must pass the tests admin-
istered by the Windows Hardware Quality Labs. This requirement is also unlikely
in the extreme to apply to Visual Basic products, because its pretty much impossi-
ble to write a hardware driver in Visual Basic.
Windows Installer Service
The second set of requirements refer to proper use of the Windows Installer Ser-
vice itself. Naturally, using the Installer to install your software is the first step
towards meeting these seven requirements:
Install using a validated Installer package
Observe the componentization rules
Appendix A Meeting Windows Logo Requirements 422
Identify shared components
Install to Program Files by default
Support Add/Remove Programs
Support advertising
Ensure correct uninstalls
Install Using a Validated Installer Package
Thats right, to gain the Windows Certification logo an application must use the
Windows Installer Service for its setup. Thats one reason why all of the major
setup tools vendors are now supporting the Windows Installer (and perhaps one
of the main reasons that you bought this book).
Note that the Installer package must pass validation. At a minimum, this means
that you must run msival2 on the package using the standard set of ICE tests
that ship with the Installer SDK and not get back any errors. Refer back to Chapter
13, Validating Installer Databases, for more details on package validation.
Observe the Componentization Rules
I covered the rules for determining what should be in a component in Chapter 3,
Basic Installer Concepts. Those rules must be followed for a logo-compliant
product. Additionally, it just plain makes good sense to follow those rules because
theyll help the Windows Installer correctly install and uninstall your application
without breaking other applications.
Identify Shared Components
Properly identifying shared components is a matter of properly using the Win-
dows Installer service. There are two cases to be aware of:
If a component is composed entirely of files that are only installed by the
Windows Installer, your job is done. You dont have to do anything special
to have the Windows Installer handle the shared components in this case.
If a component includes files that are shared with older applications (ones
that do not use the Windows Installer Service), you need to set the Shared-
Windows Installer Service 423
DllRefCount bit in the Attributes column of the Component table for that
component.
Install to Program Files by Default
Logo-compliant applications must be installed to a subdirectory under the users
Program Files directory by default. You can accomplish this easily with the Win-
dows Installer. Just use the property ProgramFilesFolder as the DirectoryParent
value for the directory thats the root of your applications installation. The
Installer will determine at runtime how to resolve this to the users actual pro-
gram files directory.
Support Add/Remove Programs
To properly support the Add/Remove Programs applet, an application needs to
write certain values to the Windows Registry. The Installer will automatically
write these values if you set the necessary properties in the Property table in your
Installer database:
ProductName
ARPINSTALLLOCATION
Manufacturer
ProductVersion
In addition, you may want to set the rest of the properties whose names begin
with ARP (see Chapter 7, Putting the Pieces Together) in order to provide addi-
tional information to the user when they use the Add/Remove Programs applet
to modify your applications installation.
Support Advertising
If your application installs its own file types, it must support advertising for those
file types. This requires filling in the Shortcut, Icon, Extension, and Verb tables
within the Installer database.
Of course, the Installer makes it easily possible to go beyond this minimal stan-
dard. You may wish to consider whether it makes sense to break your application
up into components that are installed on demand, and to make use of the Installer
Appendix A Meeting Windows Logo Requirements 424
API or automation model to call chunks of your application in when theyre
needed. But thats optional as far as the logo requirements are concerned.
Ensure Correct Uninstalls
Logo-compliant applications can be installed cleanly and correctly. If you use the
Windows Installer to install your application, and do not include any custom
actions, you get this behavior for free. This is one of the chief benefits of the
Windows Installer.
If your Installer package does include custom actions, youll need to consider
their effects. The uninstallation process must remove any files that these custom
actions installed. This may require you to write a second custom action with con-
ditional execution in the appropriate sequence table to make sure that it only runs
when the application is being uninstalled.
Component Sharing
The third group of requirements have to do with Windows own requirements for
component sharing. There are four requirements in this group:
Do not attempt to defeat Windows File Protection
Build side-by-side components
Install side-by-side components
Install shared files to the correct locations
Do Not Attempt to Defeat Windows File Protection
Windows File Protection is a new feature of Windows 2000 that prevents attempts
to overwrite most files that Windows 2000 itself installs. This feature is designed
to increase the stability of Windows by preventing other applications from over-
writing necessary system files with newer but potentially conflicting versions.
If you properly follow the Installer rules for componentization you wont run
afoul of system file protection. Thats because youre only allowed to create com-
ponents from files that you produce, and all of the files protected by system file
Data and Settings Management 425
protection are produced by Microsoft. When those files need replacing, Microsoft
will do so via a service pack for Windows 2000 only.
Build Side-by-Side Components
Side-by-side components are a new attempt on the part of Microsoft to avoid the
DLL Hell syndrome in which upgrading a shared library would break older
applications that depended on the old version of the library. Windows 2000 and
Windows 98SE support side-by-side components. Basically, this means that you
can install .dlls in the same folder as their parent application, and the operating
system will allow multiple versions of the .dll to be loaded at one time.
If youre using the Windows Installer to install your application, and you install
a .dll to the same folder as your application, it will automatically do the right
thing.
Install Side-by-Side Components
This is the flip side of the previous requirement. If you build side-by-side compo-
nents, you must use them. The Windows Installer will make the correct Registry
entries for side-by-side .dlls to ensure this.
Install Shared Files to the Correct Locations
If your application installs shared files for older operating systems, you must put
them in one of two places:
Common Files\<company name>
Program Files\<company name>\Shared Files
The Windows Installer provides built-in properties to locate the Common Files
and Program Files directories, so installing files to these locations is just a matter
of making the right entries to the File and Directory tables.
Data and Settings Management
The next group of requirements contains six requirements that relate to properly
handling your applications data and persistent settings:
Appendix A Meeting Windows Logo Requirements 426
Store data in My Documents
Classify and store application data correctly
Degrade gracefully on Access Denied
Run in a secure Windows environment
Respect Group Policy
Properly store .adm file settings
Store Data in My Documents
The first time that a logo-compliant application displays the Common File open or
save dialogs, it must default to the users My Documents folder. You can accom-
plish this by using the Windows Installer automation model directly from Visual
Basic. For example, using a Common Dialog named dlgCommon, you could exe-
cute this code to open a file:
Dim objInstaller As WindowsInstaller.Installer
Dim objSession As WindowsInstaller.Session
Dim strGUID As String

Set objInstaller = _
CreateObject("WindowsInstaller.Installer")
objInstaller.UILevel = msiUILevelNone
strGUID = objInstaller.Products(0)
Set objSession = objInstaller.OpenProduct(strGUID)
dlgCommon.InitDir = _
objSession.Property("PersonalFolder")
dlgCommon.ShowOpen
Note that the My Documents folder may have different names depending on
the operating system. Its not safe to make any assumptions about its location.
Classify and Store Application Data Correctly
Application data (files created by your application, as differentiated from files that
the user saves) should also be saved in the proper places. There are three separate
places to do this, depending on the type of data. Fortunately, the Windows
Data and Settings Management 427
Installer provides properties for all three of these special folders, so you can use
the same code as shown in the previous section (but with different folder names)
to retrieve the required locations:
AppDataFolder for per-user data that should roam with the user
LocalAppDataFolder for per-user data that should not roam with the user
CommonAppDataFolder for per-machine data
Degrade Gracefully on Access Denied
Despite your best efforts, users will attempt to do things that Windows doesnt
allow. For example, you cant prevent a non-administrative user from browsing to
the Windows System directory and trying to save their files in that location. When
they try, though, Windows will raise an error since regular users arent allowed to
write to that folder.
Degrading gracefully in this situation means that your application should con-
tinue to run and should inform the user that something went wrong. With Visual
Basic, you can accomplish this by making sure that theres an error handler in any
procedure that writes data and pass the error message received from Windows
back to the user.
Run in a Secure Windows Environment
This requirement is really a special case of the need to degrade gracefully when
access is denied. Your application should be functional for a regular user under
Windows NT. This means that the application must work if the user is only
allowed to write to three specific locations:
The HKEY_CURRENT_USER Registry hive
Their own My Documents directory
The Common Documents directory
Ensuring this is usually just a matter of ensuring proper defaults for file save
dialogs and not hard-coding any paths for saving information. Note also that the
user can work with sub-keys and sub-folders of these three locations.
Appendix A Meeting Windows Logo Requirements 428
Respect Group Policy
Group Policy settings allow the system administrator to remove potentially dan-
gerous items from access by regular users. Most applications wont need to worry
about these settings at all. If your application contains any of these functions,
though, youll need to read a Registry key and disable them if the group policy
says they should be disabled:
Run arbitrary applications
List drives and files other than through the common dialog
List recently opened files
Shut down Windows
The Windows Installer automatically checks the appropriate group policies
when displaying file dialogs, as does the Common Dialog control in Visual Basic.
Refer to the Windows 2000 application specification for a full list of group poli-
cies and the Registry keys that you can check to determine their status.
Properly Store .adm File Settings
.adm files are administrative templates for manipulating group policy settings. If
your application creates such files, they must be stored under either
HKEY_CURRENT_USER\Software\Policies or
HKEY_LOCAL_MACHINE\Software\Policies. Youre extremely unlikely to
need to create such files in a Visual Basic application.
User Interface Fundamentals
When the Windows logo requirements were first issued for Windows 95, they
were largely concerned with the user interface. Now that most applications use
the new shell interface, there are only seven UI requirements to adhere to:
Support system size, color, font, and input settings
Support High Contrast
Provide keyboard access
Expose the focus
User Interface Fundamentals 429
Do not rely on sound
Do not clutter the Start Menu
Support multiple monitors
Support System Size, Color, Font, and Input Settings
Your applications forms and dialog boxes must respect the settings that the user
makes with the Control Panel Display applet. This automatically happens if you
restrict yourself to the controls that ship with Visual Basic. For third-party custom
controls, you can check by running a form with the control and then using the
Control Panel to change to a different color scheme and default font. The control
should automatically be updated when you save the settings.
One non-obvious consequence of this requirement is that you should make your
controls bigger than seems necessary when youre using default Windows set-
tings, so that theres still room for all the text if the user chooses one of the larger
font settings.
The controls used by the Windows Installer in making its dialog boxes also
automatically support system settings.
Support High Contrast
As an additional requirement, your application should remain usable if the user
selects one of the high contrast settings from the Control Panel Display applet.
Again, the standard controls shipped with Visual Basic support this setting auto-
matically. You should test-drive your application under this setting to be sure that
you can still find everything without undue difficulty.
Because the high contrast schemes are monochrome, this means that your appli-
cation cant depend exclusively on color to convey information. For example, if
you use red, yellow and green boxes to indicate the status of items, you should
also provide an alternative way (such as a tooltip or status bar message) for the
user to retrieve the status.
Provide Keyboard Access
Your application must provide keyboard shortcuts for all functionality. This is
easy to accomplish when you use Visual Basic for designing the application. Just
Appendix A Meeting Windows Logo Requirements 430
remember to include accelerator keys in the caption properties of labels and
menus. Youll also want to double-check that you dont accidentally use the same
accelerator key twice on the same form.
For the Installer interface, you can ensure keyboard accessibility by including
accelerator keys in the Text property of all the controls in the Control table.
Expose the Focus
For the benefit of those using screen-reader and magnifier software, your applica-
tion must clearly indicate the location of the input focus at all times. This is
another feature thats built into the controls that ship with Visual Basic, and to the
controls that are used by the Windows Installer.
Do Not Rely on Sound
Because some users do not hear well, or do not have sound cards, you should
never rely exclusively on sound for feedback. Always display a prompt or other
visual cue any time youre conveying information with sound.
The Windows Installer doesnt use sound at all (except for system sounds that
the user may have associated with messages), so its automatically compliant with
this requirement.
Do Not Clutter the Start Menu
Logo-compliant applications add as few items as possible to the Start Menu. In
particular, youre not allowed to add these things:
Help files (The user can get to Help from within the application.)
Document files (Readme documents should be displayed during installa-
tion. You can do this with an RTF control on an Installer dialog.)
Uninstall shortcuts (The Control Panel Add/Remove Programs applet will
take care of this.)
Youre also not allowed to add things to the top portion of the Start Menu
(above Program Files), as this is meant to be reserved for personal use.
You can follow this requirement by being careful with the entries you make into
the Shortcut table in the Installer database.
OnNow/ACPI Support 431
Support Multiple Monitors
Now that Windows supports multiple monitors, you should be able to run your
application on a multiple monitor system without problems. Both Visual Basic
and the Windows Installer support multiple monitors natively, so this should not
be a problem.
One thing to watch out for in this regard is a technique that was once popular
for hiding controls on Visual Basic forms: setting their Left property to a negative
number. With a multiple monitor system, its possible for negative Left coordi-
nates to still be displayed on a monitor. The correct way to hide controls is to set
their Visible property to False.
OnNow/ACPI Support
Five of the logo requirements relate to the new OnNow and Advanced Configura-
tion and Power Interface (ACPI) interfaces in Windows:
Indicate busy status
Allow sleep and resume
Handle sleep notifications when connected
Handle wake without losing data
Handle wake from critical sleep
Indicate Busy Status
Some applications may be busy but appear to Windows as being idle. These appli-
cations are required to call the SetThreadExecutionState API in a particular way to
tell Windows that theyre not really idle. Because Visual Basic isnt thread-aware,
this option isnt open to applications written in Visual Basic.
Fortunately, an active application in Visual Basic wont appear idle to Windows.
So you can generally ignore this requirement for Visual Basic applications.
Appendix A Meeting Windows Logo Requirements 432
Allow Sleep and Resume
The application must allow the user to suspend the computer and later resume
without losing data. This interaction with the operating system is handled by the
Visual Basic runtime library, so its not something that you need to worry about.
Handle Sleep Notifications When Connected
The application must respond to suspend notifications even when its connected
to the network. This interaction with the operating system is handled by the
Visual Basic runtime library, so its not something that you need to worry about.
Handle Wake without Losing Data
The application must wake up from a suspend state without losing data. This
interaction with the operating system is handled by the Visual Basic runtime
library, so its not something that you need to worry about.
Handle Wake from Critical Sleep
The application must wake up from emergency suspension (for example, a sud-
den loss of power) without crashing. This interaction with the operating system is
handled by the Visual Basic runtime library, so its not something that you need to
worry about.
Application Migration
The final Windows logo requirement concerns application migration. This
requirement states that if an application is installed on Windows 9x, or Windows
NT4, and the system is upgraded to Windows 2000, then the application will con-
tinue working. Put another way, applications should not have platform-specific
behavior. Because Visual Basic creates applications that use a single binary format
regardless of the operating system, youre covered in this regard.
The Windows Installer saves Control Panel Add/Remove Program information
in such a manner that its also available after an operating system upgrade.