by Doctor Evil (5 Submissions)
Category: Coding Standards
Compatability: Visual Basic 3.0
Difficulty: Beginner
Date Added: Wed 3rd February 2021
Rating: 
(10 Votes)
Windows XP is coming. With that, everyone will be moving to the NT platform. This article goes through some tips to prepare your programs for compatibility with the NT platform.
VBcoders
Windows NT Compatibilty
With the release of Windows XP, everyone will be moving to the NT platform. This means that you have to prepare your apps to
run on the NT platform today! You can no longer just blow off NT compatibility. Did you know that Microsoft is dropping
support for Windows 95 at the end of this year, and will drop Support for Windows 98 in 2 years? Windows 9x is a thing of
the past.
New Visual Themes
Microsoft has totally redesigned the User Interface (UI) in this version of Windows. The new Visual Themes are a
semi-problem. All of your VB apps will have the new titlebar, close/min/max buttons, and border, but the standard VB
controls (like the button) will not. Realize, however, that simply replacing your buttons with the XP look-alike ones is
NOT a solution. For one reason, it is not just the buttons that have been redesigned. Every control has been. Even
the frame. Also, if the user decides not to use the default theme, then your buttons will look strange because they use the
style of the Windows default theme, not the one the user is using. Be aware that this does not affect menus. The VB menus
have been drawing in the new XP style menu. (including the alpha-blended shadows)
UPDATE: I have created a button control that actually calls the Theme APIs to draw the button. You can get it here.
Application Compatibility
Chances are, your app will probabally run on XP. If you have access to a Windows 2000 machine, test your app on it.
If it runs, chances are that it will run on XP.
Since XP is WinNT, if you have used any code in your projects that is
labeled "does not work in NT", it won't run in XP. Usually, 9x-only code doesn't work in NT due to the security
restrictions.
Some examples of what WON'T work:
Anything that has to do with hiding your app from the CTRL-ALT-DEL list. The NT Task Manager shows ALL processes, no
matter what. Even system services show up. In fact, the RegisterServiceProcess API that many of you use to hide your apps
from the list doesn't exsist under NT.
Most code to shut down your computer. The app must get more token privliges before it calls the shutdown API. (assuming
the user has enough rights to shut down anyways) If you would like some good code to shut down a NT system, see
Code that writes to the Registry. Specifically, to anything besides HKEY_CURRENT_USER. HKLM writes fail if the current
user is not an Administrator.
If you try to write to different areas of the hard drive. Many users can't write to many locations due to NTFS
restrictions.
Basically, if the user has Admin rights, chances are that your app will run. But if they are not, you might have
problems.
Detecting The Operating System
At a minimum, you should detect the OS that your program is running under. This way, if you are sure that your app won't run
under NT, you can simply display a message box informing the user that their OS is not supported and that they should go to
your website to download a new version of your software that does support NT, then exit your program. This prevents nasty VB
error message boxes that will only confuse the user. (or even GPFs) Here is some code that will detect if your app is
running under NT or not: (You can put this into a .MOD)
Public Const VER_PLATFORM_WIN32_WINDOWS = 1
Public Const VER_PLATFORM_WIN32_NT = 2
Public Type OSVERSIONINFO
OSVSize As Long
dwVerMajor As Long
dwVerMinor As Long
dwBuildNumber As Long
PlatformID As Long
szCSDVersion As String * 128
End Type
Public Declare Function GetVersionEx Lib "kernel32" Alias "GetVersionExA" _
(lpVersionInformation As OSVERSIONINFO) As Long
Public Function RunningUnderNT() As Boolean
Dim OSV As OSVERSIONINFO
OSV.OSVSize = Len(OSV)
If GetVersionEx(OSV) = 1 Then
If OSV.PlatformID = VER_PLATFORM_WIN32_NT And Then
RunningUnderNT = True
End If
End If
End Function
Then you can call the function during the startup of your app.
Private Sub Form_Load()
If RunningUnderNT Then
MsgBox "Sorry. This program does not support your operating system." & vbCrLf & vbCrLf & "Please go to my website at
[address] to download the latest version of this program, which may support this version of Windows.", vbCritical, "Windows
Version Not Supported"
End
End If
...
End Sub
While your program is running, you can check the version of Windows before making any API calls that won't work in NT. You
can either state that the requested function is not available, or substitute NT-compatible calls in place of the 9x ones.
The NTFS File System
For those of you who have used a NT OS before, you know what NTFS is and what it does. To the rest of you, NTFS will be a
new suprise. While upgrading from Windows 9x/ME to XP, Setup will convert drives from FAT16/32 to NTFS. (You can choose not
to, but you really should anyways.) NTFS allows Administrators to set access privlages to certain folders and even certain
files. You can be granted anywhere from no access at all to full read/write access to a file/folder, and everything in
between. So, it is possible that a user can read a file (even your application and it's folder) but not write to it. The
probelm comes in when your program tries to write to the disk, or even if it tries to read a file. What if your program
writes a configuration file, but the current user is not allowed to write to the folder? Not only will your program error
out if you didn't put error handlers in, but the settings will never be saved. This is obviously not good. You should try
to save settings to the HKEY_CURRENT_USER section of the Registry, or allow the user to pick where they want to save
your configuration file to. Then save the the path to the config file in the Registry. This way, you can be sure that
everything works out OK. Also, be sure to ALWAYS put in error handlers in any sub/function that writes to the
Registry or the hard drive. Of course, it is a good idea to put error handlers in any sub or function to handle anything
that you didn't anticipate. I as a user can't stand when a VB app (or any other app for that matter) didn't use error
handlers, then comes up with that nasty little VB error message box, causing the program I'm using to close.
Remeber, NT cannot just be blown off anymore. You have to make your programs compatible with NT now. Good
luck, and happy coding!
