Class cRegCheck

Source

RegCheck.PKG (Uses: RegCheck.inc and Language.pkg)
The required file Language.pkg is ON PURPOSE not part of the download as it is part of VdfQuery.
You can obtain vdfquery from the Data Access Ftp site here

What's New

In short: support for the latest version of DataFlex and Windows
- This release of Regcheck only supports Visual DataFlex 7 and Visual DataFlex 8.
- As of now, Windows XP is supported as well, it has not been tested with Novell, but we do hope that one of you guys will do that for us.
- A new feature has been added that allows you to determine if the platform running your application meets all requirement. For example in the default setup, we prohibit running VDF applications on a home edition of windows, such as Windows ME and XP Home.

Purpose

To check for correct registry settings when running a Visual DataFlex application with the DataFlex database. If you will use a driver to connect all your files to a Client/Server DBMS (e.g. Pervasive, IBM DB2, MS SQL, Oracle. ) you don't need to read any further. This package only deals with registry settings for the DataFlex DBMS running on peer-to-peer networks or stand-alone machines or when DataFlex and Client/Server databases are used together in an application.

Even if you're careful to implement the correct registry settings when deploying a VDF application with the DataFlex DBMS, some weirdo e.g. a system administrator or other installed software will apply changes that potentially will be very dangerous to your application's database. RegCheck.pkg will simply detect the client software and check the machine registry settings and will perform any changes if necessary, though it will by default ask for user confirmation first. It will also by default log changes to a text file.

The checking/changes performed by the package is described below. The package will perform different depending on the client software installed i.e. Windows95/98 or Windows NT Client or Windows NT Server. It will also check for the correct settings for Novell Client32 software, if installed and if user is logged on to a Novell Netware server and that at least version 2.2 of Client32 is installed.
The package has been updated to also support Windows 2000 and Windows XP.

Installation notes

It is advised that you create a .\VDF8\Common folder and place the files RegCheck.pkg, RegCheck.inc and Language.pkg in that folder. You should only have DAC packages in the PKG folder. If you do, you should also change the VDF System Path - MakePath used in by the compiler. In the IDE select File - Configure and click the Workspaces tabpage. Insert the line C:\VDF8\COMMON before the line C:\VDF8\PKG

Usage

Add the following line:

Use RegCheck.pkg

to the top part section of your VDF .src file and below the Workspace or Application object.
That's all there is to it!
The file RegCheck.inc contains all text strings for multiple languages.
Check that your language have been translated and set Language.pkg to the proper language.
By default English is used. (Note: If you need to make a translation for your language, please e-mail it to mailto:contribute@vdf-guidance.com so it can be included in the next revision.)

At the end of the package is an oRegCheck object that is based on the class cRegCheck. In that object you can set properties to change the working behavior of the package.

Limitations

If a VDF application is installed at a customer site on an NT-server, you should run your VDF application once at the server. This will ensure the correct settings on the NT-server. You could also start your application from an install script (e.g. Wise), after a successful installation. Yes, this is a limitation but I haven't come up with a better way of implementing it yet.

It's much more difficult to ensure correct settings for each workstation and it is also more probable that some workstation get its registry screwed up. Therefor each time a VDF app is started, its registry will be checked. If the customer still runs into DBMS trouble and you suspect it might be the registry on the NT-server that is incorrect, you could ask the customer to start the VDF application from the NT-server again (the registry might have been changed by some other software).

Debug Mode

You can set the package in debug mode to make it display more info about all the information it gathers. Note: This is only to be used in your development environment to check that the package works correct.

Here's how you do it. At the near top of RegCheck.pkg is the line:

 //#REPLACE DEBUG$$MODE ON

Just uncomment the line, re-compile and you will run in debug mode. Don't forget to comment the line before you deploy your application.

Deployment

When you deploy your VDF application also deploy the file Vrdr2Upd.exe and put it into the Programs directory of the workspace. If necessary it will be started automatically. Hint: It can be found on your machine in the Vdf5\Msredir directory.

What it does

The main procedure DoCheckCurrentClient, will automatically be executed when your program is started. It will determine what client software is run, Windows 95/98/Me, NT Client, NT Server, Windows 2000, Windows XP and Novell Client32.
Note: Novell Client32 has not been tested with Windows XP

It checks that all registry settings and/or settings in System.ini and Config.sys are set to the correct values according to Data Access's Corp. recommendations for Visual DataFlex and Lotus Corp. recommendations for non Client/Server databases, running under Win95/98 or Windows NT Client/NT Server and some other settings the authors have found useful.

If changes are made to the registry or to system.ini the program will be aborted and user asked to re-start the application.

By default the user will be asked if it's OK to perform a change. You can change the property pbSilentMode to True in the oRegCheck object if you don't want this user prompting.

For NT machines there's a setting to conditionally perform changes to the registry. The property pbDoNTRegistryChanges is used for this purpose. By default it has been set to True, 'Do perform registry changes'. If set to True the package will try to make the necessary changes and if they cannot be performed the user will be informed about it. This has been implemented since it's often not possible to make registry changes without being logged on as an Administrator. As explained above if necessary changes are not performed, the VDF application will be aborted.

You can also have automatic logging made to a text file when changes needs to take place. The standard DAC log package is used for this purpose. If you don't want logging just remark that line

Set phoLogObject to (oLogRegCheck(Self)) 

or set the property to 0 in the oRegCheck object. By default logging is done to an ASCII file in the Data directory of the current WorkSpace. If you rather want to log changes to a data file, comment the oLogRegCheck object that is based on the StatusAsciiLog class and uncomment the other oLogRegCheck object. If you do this you need to provide a StatLog.dat file. Hint: There's one in the Big WorkSpace's Data directory, to get you started. Note: You need to extend the field length because the messages logged are rather long (up to about 200 chars is used).

Checking Performed by RegCheck.pkg

Novell Client32 (Intranetware Client)

This can be used by Win95/98 machines as well as by NT Clients. The checking will only be done if the user is currently logged on to a Novell Netware Server when the VDF application is started.

1. The version needs to be at least 2.2
2. In addition to VDF installation requirements, there are changes that should be made for a Windows 95 WorkStation using Novell Client32 registry setting in order to ensure the robustness of the DataFlex database. HKEY_LOCAL_MACHINE\Network\Novell\System Config\Netware Dos Requester\Cache Writes\0 =off. This recommendation is made by Lotus Corp. Note: The registry setting 'Opportunistic Locking' does no longer exist from version 2.2
3. HKEY_LOCAL_MACHINE\Network\Novell\System Config\Netware Dos Requester\Close Behind Ticks\0 =0
4. HKEY_LOCAL_MACHINE\Network\Novell\System Config\Netware Dos Requester\Delay Writes\0 =OFF
5. HKEY_LOCAL_MACHINE\Network\Novell\System Config\Netware Dos Requester\File Cache Level \0 =0

Windows 95/98

1. If a Microsoft's network client is used for a Novell Netware server (not recommended), System.ini needs to contain:

[NWREDIR]
READCACHING = 0

2. FILES in Config.sys is by default in Win95/98 = 60. It will be set to the number of file handles specified by the property piFiles. If set to 0 no checking will be performed.
3. A Virtual Network Redirector VREDIR.VXD, ver. 4.00.955 or higher must be present. Due to the nature of local caching, the Redirector will NOT support ANY DataFlex based application running on a Microsoft Network. If you place the file VrdrUpd2.exe in either the Bin or the Programs folder of your WorkSpace, it will be started.
4. Although an acceptable Virtual Network Redirector (VREDIR.VXD) is available, (ver. 4.00.955 or higher) local read caching may still occur. It is corrected by setting: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ VxD\VREDIR\DiscardCacheOnOpen =1
5. There is one more setting that is needed for a Windows 95 WorkStation, in order to ensure the robustness of the DataFlex database. HKEY_LOCAL_MACHINE\System\CurrentControSet\ Control\FileSystem\DriveWriteBehind =00 00 00 00

Lotus Corp has made this recommendation.

Windows NT Client

1. Service Pack 2 or higher needs to be installed.
2. In addition to VDF installation requirements, there are several other changes need to be made for each NT workstation in order to ensure the robustness of the DataFlex database. The following registry changes are made:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ LanmanWorkstation\Parameters\UseOpportunisticLocking =0

3. Registry has also been set to the recommended settings by LOTUS Corp.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ LanmanWorkstation\Parameters\UtilizeNtCaching =0

1. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ LanmanWorkstation\Parameters\UseUnlockBehind =1
2. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ LanmanWorkstation\Parameters\UseLockReadUnlock =0x0
3. RDISK /S will be run automatically to make a backup copy of the changed registry database if pbNTRegistryBackup is true.

Windows NT Server

1. Service Pack 2 or higher needs to be installed.
2. VDF requires Opportunistic file locking be disabled at an NT server.HKEY_LOCAL_MACHINE\system\CurrentControlSet\services\ LanmanServer\EnableOplockForceClose =1
3. HKEY_LOCAL_MACHINE\system\CurrentControlSet\services\ LanmanServer\EnableOpLocks=0
4. RDISK /S will be run automatically to make a backup copy of the changed registry database if pbNTRegistryBackup is true.

Public Properties

Properties to set:

PhoLogObject Integer
Object id to be used for logging changes made. Set to 0 will disable logging.

piFiles Integer Default = 200
Number of Files in Config.sys for client not running Novell Client32. If set to 0 no checking will be performed.

pbSilentMode Boolean True| FALSE
Ask user before making a change to the registry or System.ini

pbDoNTRegistryChanges Boolean. TRUE|False
Try to make changes to the registry on NT machines.

pbNTRegistryBackup Boolean True|FALSE
Make a backup of the NT registry after a change?
We don't recommend to set this on a deployed application as it is very security sensitive. Once this property has been set to True, it will use the RDisk command to create a backup of your registry.
As a result this command will create %WINDOWS%/Repair folder that contains all security info. If a malicious user can get access to these files, he or she will be able to gain full control over the machine.

pbDriverBruteForce Boolean TRUE|False
To force the possible change of settings even if there are other database drivers than DataFlex loaded. It is possible that a (for example accounting) Btrieve database get consulted for info while the rest of the data is in DataFlex. There could be other situations were you don't want any checking to be done for your application because all files are in e.g. Btrieve.

pbTestServicePack Boolean TRUE|False
The default setting (True) will check for the service pack and if it is to low deny the running of the application

piRunOnWindows95 Default = cx_Run_Do_Not_Run
Default Settings for on which version a vdf program is allowed to run.

piRunOnWindows9X Default = cx_Run_Normal
Default Settings for on which version a vdf program is allowed to run.

piRunOnWindowsNT40 Default = cx_Run_Normal
Default Settings for on which version a vdf program is allowed to run.

piRunOnWindowsNT2k Default = cx_Run_Normal
Default Settings for on which version a vdf program is allowed to run.

piRunOnWindowsNTXP Default = cx_Run_Normal
Default Settings for on which version a vdf program is allowed to run.

piRunOnWindowsNET Default = cx_Run_With_Warning
Default Settings for on which version a vdf program is allowed to run.

piRunOnHomeVersion Default = cx_Run_Do_Not_Run
Default Settings for on which version a vdf program is allowed to run.

piRunOnServerVersion Default = cx_Run_Normal
Default Settings for on which version a vdf program is allowed to run.

piRunOnUnknownVersion Default = cx_Run_Do_Not_Run
We do not allow a VDF application to run under an OS which is unknown.

piMinNT40_ServicePack Default = 6
Minimal required service pack for Windows NT.

piMinNT2K_ServicePack Default = 1
Minimal required service pack for windows 2000.

piMinXP_ServicePack Default = 0
Minimal required service pack for windows XP.

piMinNET_ServicePack Default = 0
Minimal required service pack for windows .NET.
Added .NET service pack because it will come.

Properties to query:

psComputerName String
The name of the current machine.

psUserLoginName String
The name of the current logged in user.

piMajorVersion Integer
Identifies the major version number of the operating system. For example, for Windows NT version 3.51, the major version number is 3; and for Windows NT version 4.0, the major version number is 4.

piMinorVersion Integer
Identifies the minor version number of the operating system. For example, for Windows NT version 3.51, the minor version number is 51; and for Windows NT version 4.0, the minor version number is 0. For Windows 95, dwMinorVersion is zero. For Windows 98, dwMinorVersion is greater than zero.

piPlatFormId Integer
Identifies the operating system platform. This member can be one of the following values:

    VER_PLATFORM_WIN32_WINDOWS Win32 on Windows 95 or Windows 98. 		    
    VER_PLATFORM_WIN32_NT Win32 on Windows NT.

piServicePackMajor Integer
Identifies the major version number of the latest Service Pack installed on the system. For example, for Service Pack 3, the major version number is 3. If no Service Pack has been installed, the value is zero.

piServicePackMinor Integer
Identifies the minor version number of the latest Service Pack installed on the system. For example, for Service Pack 3, the minor version number is 0.

pbNTServer
Is set to True if the running windows version is a server version

pbWindowsHome
Running on a Windows HOME version. That is Windows ME and Windows XP Home
Both are not recommended platforms for business (networking is limited).
So not for vdf.

psCSDVersion String
Windows NT: Contains a string, such as "Service Pack 2", that indicates the latest Service Pack installed on the system. If no Service Pack has been installed, the string is empty. Windows 95: Contains a null-terminated string that provides arbitrary additional information about the operating system.

psOSVersion String
Keeps a text which version of windows is running. If it can not sort it out it will have "Windows Version UNKNOWN". Other possible values are:

• Windows 95
• Windows 98
• Windows ME
• Windows NT40 Professional
• Windows NT40 Server
• Windows NT40
• Windows NT2K Professional
• Windows NT2k Server
• Windows XP Home
• Windows XP Professional
• Windows 2003 Server

Protocol Information

This is information from - DAC Technical Knowledge Base 631: Losing connection on Windows Network

We have found IPX/SPX with NetBIOS enabled to be the most reliable network protocol with Windows networks, whether they are Windows workstations accessing Windows NT Server, or simply Windows peer-to-peer networks.

On all machines involved, whether workstation or server, you need to do the following:

1. Install the IPX/SPX protocol.
2. Make sure that NetBIOS is used in this (IPX/SPX) protocol.
3. Make sure that IPX/SPX is flagged as the default protocol.
4. Make sure that Microsoft Print and File Services are bound to IPX/SPX protocol.
5. Make sure that Microsoft Print and File Services are NOT bound to other protocols (i.e. TCP/IP or NetBEUI).
6. If on Windows NT Server, reapply SP3 after all the above is completed.

Note: There is no checking done by RegCheck for these protocol settings.

Other recommended reading

" Integrating DataFlex with Netware" (White paper) by Jim Albright

Some explanation concerning opportunistic locking

The Windows NT Workstation and Windows NT Server services were designed with many optimizations to minimize network traffic and maximize throughput. The network redirector works closely with the Windows NT Cache Manager to provide read-ahead caching, write-behind caching, and search caching. Various file locking schemes, such as opportunistic locking and local file lock optimization, help to reduce network traffic. The SMB protocol that is used supports compound commands and responses, such as LockAndRead and WriteAndUnlock

With Exclusive Oplock, if a file is opened in a non-exclusive (deny none) mode, the redirector requests an opportunistic lock of the entire file. As long as no other process has the file open, the server will grant this Oplock, giving the redirector exclusive access to the specified file. This will allow the redirector to perform read-ahead, write-behind, and lock caching, as long as no other process tries to open the file.

When a second process attempts to open the file, the original owner will be asked to Break Oplock or Break to Level II Oplock. At that point, the redirector must invalidate cached data, flush writes and locks, and release the Oplock, or close the file.

Opportunistic Locking level II, provides a method for granting read access to a file by more than one workstation, and these workstations can cache read data locally (read-ahead). As long as no station writes to the file, multiple stations can have the file open with level II Oplock

An illustration of how level II Oplock work:

1. Station 1 opens the file, requesting Oplock.
2. Since no other station has the file open, the server grants station 1 exclusive Oplock.
3. Station 2 opens the file, requesting Oplock.
4. Since station 1 has not yet written to the file, the server asks station 1 to Break to Level II Oplock.
5. Station 1 complies by flushing locally buffered lock information to the server.
6. Station 1 informs the server that it has Broken to Level II Oplock(alternatively, station 1 could have closed the file).
7. The server responds to station 2's open request, granting it level II Oplock. Other stations can likewise open the file and obtain level II Oplock.
8. Station 2 (or any station that has the file open) sends a write request SMB. The server returns the write response.
9. The server asks all stations that have the file open to Break to None, meaning no station holds any Oplock on the file. Because the workstations can have no cached writes or locks at this point, they need not respond to the break-to-none advisory; all they need do is invalidate locally cashed read-ahead data.

The following registry entries are used to enable or disable Oplock for Windows NT Workstation or Server. These registry keys may not exist by default. To access the registry run REGEDT32.EXE from the File menu, choose Run in Program Manager or File Manager.

WARNING: Using Registry Editor incorrectly can cause serious, system-wide problems that may require you to reinstall Windows NT to correct them. Microsoft cannot guarantee that any problems resulting from the use of Registry Editor can be solved. Use this tool at your own risk.

Some parameters that can interest you when manipulating the network cache behavior:
Server Service Entries

\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters

EnableOplocks   REG_DWORD   0 or 1
Default: 1 (true)

Specifies whether the server allows clients to use Oplock on files. Oplocks are a significant performance enhancement, but have the potential to cause lost cached data on some networks, particularly wide-area networks.

MinLinkThroughput   REG_DWORD   0 to infinite bytes per second
Default: 0

Specifies the minimum link throughput allowed by the server before it disables raw and opportunistic locks for this connection.

MaxLinkDelay   REG_DWORD   0 to 100,000 seconds
Default: 60

Specifies the maximum time allowed for a link delay. If delays exceed this number, the server disables raw I/O and opportunistic locking for this connection.

OplockBreakWait   REG_DWORD   10 to 180 seconds
Default: 35

Specifies the time that the server waits for a client to respond to an Oplock break request. Smaller values can allow detection of crashed clients more quickly but can potentially cause loss of cached data.

Note: Nils nor Frank takes any responsibility on the influence that these settings can have on your environment, direct or indirect. This information can be checked at http://www.microsoft.com

Acknowledgements

I would also like to thank for the invaluable input and feedback received
during the beta test phase from Frank G. Vandervelpen (who gave me the idea in the first place to write the package), Peter H. van Wijk, Vincent Oorsprong, Ulbe Stellema, Sture Anderson, Magnus Bergh, Wil van Antwerpen, José A.F. Guimaraes e Costa and everyone else that helped but is not directly mentioned here.

Thanks to you all !

To-Do and known bugs

Although the package is full functional and up-to-date with the latest there's always a list of things on the wishlist. Below is our list, please do contact us before you start working on one of the requests.
This will help in avoiding people working on the same thing.

Id	What	Assigned to
1.	Detection of the Internet Explorer version	not assigned
2.	Detection of the version of the used Common Control	not assigned
3.	Detection of the name of "the program", to be displayed in the translated strings	not assigned
4.	The text makes several references to "software vendor". It would be cool if this was replaced with the actual name of the supplier of the software (defined by yet another define)	not assigned

known bugs

Id	What	Assigned to
1.	On Win9x if VREDIR is loaded but the registry key 'DiscardCacheOnOpen' is not available on the machine then RegCheck incorrectly reports that the VREDIR is not installed. After that the required registry value is created and the program halted. Status: non critical	not assigned
2.	The logfiles are all saved in the .\Data folder with the same name regcheck.log, because of this machine A can (and will) overwrite a regcheck.log created by machine B	Peter Tawse

Dependencies

Right now, the only dependency which we are aware of seems to be the Language.pkg file from VDFQuery.
It retrieves the setting made in this file to retrieve the language to use for the user-interface.

Download

regcheck.zip ~ 27kb zipfile date Sept 25, 2007
regcheck.zip ~ 27kb zipfile date June 9th 2003
regcheck.zip ~ 27kb zipfile date May 22th
regcheck.zip ~ 27kb zipfile date May 5th

Subversion

http://svn.vdf-guidance.com/Regcheck/trunk/

List of Changes

June 9 2003: Fixed a problem where the DriveWriteBehind registry setting was written out as a string instead of as a binair value. This has now been changed into writing a DWord value instead.
Renamed function ComputerName into NetbiosComputerName in order to avoid a naming clash with Tufware's report classes.

May 22 2003: Fixed a problem with translations when the english language was chosen