I've just spent one of the most frustrating weeks of my life working on an AREV 2.12 to AREV 3.12 conversion prior to an OI Upgrade. The upgrade itself was relatively painless but the application itself then began to fail in mysterious ways - the worst of which was in a custom program designed to display grids of information. This program - checking in at nearly three thousand lines of code - just wouldn't display the current line in the grid correctly - everything was off by 4 bytes.
Well as the object code hadn't changed it had to be something that had changed between AREV 2.12 and 3.12 right?
So I started comparing @Variables between the two systems and found a few likely contenders - @CRTHIGH for example. But try as I might nothing worked. Finally as Friday evening approached a small light went off in my head. The program referenced @ATRBT and this doesn't actually compile in AREV 3.12...
So all we had to do was load a non-existent variable with its old value and then everything would work... suffice to say this proved challenging to say the least but eventually I had a routine that loaded what @ATRBT used to be and lo and behold the recalcitrant program now worked.
It's not very often that you have to know about the absolutely obscure aspects of system internals but when you do you're grateful for the knowledge.
Well as the object code hadn't changed it had to be something that had changed between AREV 2.12 and 3.12 right?
So I started comparing @Variables between the two systems and found a few likely contenders - @CRTHIGH for example. But try as I might nothing worked. Finally as Friday evening approached a small light went off in my head. The program referenced @ATRBT and this doesn't actually compile in AREV 3.12...
So all we had to do was load a non-existent variable with its old value and then everything would work... suffice to say this proved challenging to say the least but eventually I had a routine that loaded what @ATRBT used to be and lo and behold the recalcitrant program now worked.
It's not very often that you have to know about the absolutely obscure aspects of system internals but when you do you're grateful for the knowledge.
Labels: Atrbt 3.12 2.12
From the Sprezz archives we dig out this venerable document as it still seems to have relevance to our customers in the marketplace today!
The new Universal Driver 3.0 from Revelation Software gives customers new methods of formatting and structuring the location of data files.
One of these methods is the ability to run OpenInsight applications in a thin client model. For the purposes of this document, “thin client” means storing the repository files (or REVBOOT) on a local workstation while storing the datafiles on a remote server. This relies on the hiding files concept of the Universal Driver, and requires some initial configuration of the local system and the registry on the server the UD is installed on.
This document will describe how to move a system from your local development system to a client’s site. During development, we will have everything stored in one path. For example, OpenInsight sits in the following directory path:
S:\APPS\TABLET\OINSIGHT\RELEASE
This is the directory that contains the OINSIGHT.EXE, which we’ll refer
to as REVBOOT. Underneath, we have all of our data volumes, stored in
the DATA volume.
S:\APPS\TABLET\OINSIGHT\RELEASE\DATA\CUSTS
S:\APPS\TABLET\OINSIGHT\RELEASE\DATA\PRODS
S:\APPS\TABLET\OINSIGHT\RELEASE\DATA\INVS
When the application gets installed at the client site, the client will install
this in two sections, on the client’s server, which we’ll call SVR1PHL, the entire application will be installed on the D:\WINAPPS\3RDPTY directory. (Installing the entire application allows for server side maintenance of the data, but is
optional.) This means that we’ll have paths like
D:\WINAPPS\3RDPTY
D:\WINAPPS\3RDPTY\DATA\CUSTS
D:\WINAPPS\3RDPTY\DATA\PRODS
D:\WINAPPS\3RDPTY\DATA\INVS
On each workstation, the user only needs a REVBOOT directory and single directory called DATA. Following standard Windows™ conventions for program installation, our client workstation would probably have installed this section as C:\Program Files\My Company\TabletApp
Everything up to this point gets installed and placed as would be expected. The data is on the server, the programs and windows are stored on the local workstation. What we need to do now is tell the workstation how to find the files.
There’s a new attribute of the REVPARAM file which allows the definition of a share name to store data. This attribute is called ShareName. This is used in conjunction with the ServerName attribute. What we need to do is create a DATA subdirectory underneath the REVBOOT of our workstation copy. This gives us
C:\Program Files\My Company\TabletApp\Data
In that subdirectory, we put in a single file, REVPARAM, with the following entries:
TcpIpPort = 777
ServerOnly = 1
ServerName = SVR1PHL
ShareName = DATA
Because of the path tree method of the UD driver, when we go to access any LH volume in this directory (or lower), the driver will find the REVPARAM and use that for instructions.
The UD driver finds the paired attributes ServerName and ShareName and determines that whenever the user wants anything from the DATA volume, it needs to go to the SVR1PHL server to get the files. This means if the user looks for DATA\PRODS, the UD driver will query the SVR1PHL server for the DATA\PRODS directory and use that as it’s file store.
We also need to tell the server how to find this data, and for this, we need to make some additional modifications on the server. The first step is to go into the server’s registry and create some additional keys. Go to the registry location for the Universal Driver settings, which is
HKEY_LOCAL_MACHINE\SOFTWARE\RevSoft\Revelation Universal Driver\3.0.
Underneath this location, we need to create a new subkey called “shares”. This gives us
HKEY_LOCAL_MACHINE\SOFTWARE\RevSoft\Revelation Universal Driver\3.0\Shares.
Inside this section, we need to create a new string value called DATA, with
a value of D:\WINAPPS\3RDPTY\DATA.
This tells the LH Service that when it gets a request for the volume named DATA to start at this location. Because this also cascades down the directory tree, if the LH service gets a request for the DATA\CUSTS directory, it will look for the files in D:\WINAPPS\3RDPTY\DATA\CUSTS.
There’s one more step, and that’s the creation of an additional REVPARAM file, this time in the D:\WINAPPS\3RDPTY\DATA directory. This REVPARAM file contains the following:
TcpIpPort = 777
ServerOnly = 1
No other REVPARAM file is needed on the server.
That’s all that’s needed to find and run OpenInsight in a thin client mode.
How did this all work? This is possible through the initial REVPARAM created on the workstation. As far as the local workstation is concerned, all the data files are stored in directories below REVBOOT. As this tree is traversed, the UD Driver comes upon a REVPARAM file. In this REVPARAM file, there are the ServerName and ShareName attributes. This tells the UD driver that there’s no point in trying to find the files at this location, but to send a message to ServerName and ask for the data in ShareName. When ServerName receives the request, it queries its registry for a ShareName matching ShareName, and finishes the directory traversal from that point.
By extension, using the volumes we defined above, we could have on the workstation, the following:
C:\Program Files\My Company\TabletApp\Data\CUSTS
C:\Program Files\My Company\TabletApp\Data\PRODS
C:\Program Files\My Company\TabletApp\Data\INVS
Each of these folders could have a revparam pointing to a share on different servers. This would allow the CUSTS volume to exist on SVR1PHL, the PRODS volume to exist on SVR2PHL and the INVS volume to exist on SVR1NHMP.
The new Universal Driver 3.0 from Revelation Software gives customers new methods of formatting and structuring the location of data files.
One of these methods is the ability to run OpenInsight applications in a thin client model. For the purposes of this document, “thin client” means storing the repository files (or REVBOOT) on a local workstation while storing the datafiles on a remote server. This relies on the hiding files concept of the Universal Driver, and requires some initial configuration of the local system and the registry on the server the UD is installed on.
This document will describe how to move a system from your local development system to a client’s site. During development, we will have everything stored in one path. For example, OpenInsight sits in the following directory path:
S:\APPS\TABLET\OINSIGHT\RELEASE
This is the directory that contains the OINSIGHT.EXE, which we’ll refer
to as REVBOOT. Underneath, we have all of our data volumes, stored in
the DATA volume.
S:\APPS\TABLET\OINSIGHT\RELEASE\DATA\CUSTS
S:\APPS\TABLET\OINSIGHT\RELEASE\DATA\PRODS
S:\APPS\TABLET\OINSIGHT\RELEASE\DATA\INVS
When the application gets installed at the client site, the client will install
this in two sections, on the client’s server, which we’ll call SVR1PHL, the entire application will be installed on the D:\WINAPPS\3RDPTY directory. (Installing the entire application allows for server side maintenance of the data, but is
optional.) This means that we’ll have paths like
D:\WINAPPS\3RDPTY
D:\WINAPPS\3RDPTY\DATA\CUSTS
D:\WINAPPS\3RDPTY\DATA\PRODS
D:\WINAPPS\3RDPTY\DATA\INVS
On each workstation, the user only needs a REVBOOT directory and single directory called DATA. Following standard Windows™ conventions for program installation, our client workstation would probably have installed this section as C:\Program Files\My Company\TabletApp
Everything up to this point gets installed and placed as would be expected. The data is on the server, the programs and windows are stored on the local workstation. What we need to do now is tell the workstation how to find the files.
There’s a new attribute of the REVPARAM file which allows the definition of a share name to store data. This attribute is called ShareName. This is used in conjunction with the ServerName attribute. What we need to do is create a DATA subdirectory underneath the REVBOOT of our workstation copy. This gives us
C:\Program Files\My Company\TabletApp\Data
In that subdirectory, we put in a single file, REVPARAM, with the following entries:
TcpIpPort = 777
ServerOnly = 1
ServerName = SVR1PHL
ShareName = DATA
Because of the path tree method of the UD driver, when we go to access any LH volume in this directory (or lower), the driver will find the REVPARAM and use that for instructions.
The UD driver finds the paired attributes ServerName and ShareName and determines that whenever the user wants anything from the DATA volume, it needs to go to the SVR1PHL server to get the files. This means if the user looks for DATA\PRODS, the UD driver will query the SVR1PHL server for the DATA\PRODS directory and use that as it’s file store.
We also need to tell the server how to find this data, and for this, we need to make some additional modifications on the server. The first step is to go into the server’s registry and create some additional keys. Go to the registry location for the Universal Driver settings, which is
HKEY_LOCAL_MACHINE\SOFTWARE\RevSoft\Revelation Universal Driver\3.0.
Underneath this location, we need to create a new subkey called “shares”. This gives us
HKEY_LOCAL_MACHINE\SOFTWARE\RevSoft\Revelation Universal Driver\3.0\Shares.
Inside this section, we need to create a new string value called DATA, with
a value of D:\WINAPPS\3RDPTY\DATA.
This tells the LH Service that when it gets a request for the volume named DATA to start at this location. Because this also cascades down the directory tree, if the LH service gets a request for the DATA\CUSTS directory, it will look for the files in D:\WINAPPS\3RDPTY\DATA\CUSTS.
There’s one more step, and that’s the creation of an additional REVPARAM file, this time in the D:\WINAPPS\3RDPTY\DATA directory. This REVPARAM file contains the following:
TcpIpPort = 777
ServerOnly = 1
No other REVPARAM file is needed on the server.
That’s all that’s needed to find and run OpenInsight in a thin client mode.
How did this all work? This is possible through the initial REVPARAM created on the workstation. As far as the local workstation is concerned, all the data files are stored in directories below REVBOOT. As this tree is traversed, the UD Driver comes upon a REVPARAM file. In this REVPARAM file, there are the ServerName and ShareName attributes. This tells the UD driver that there’s no point in trying to find the files at this location, but to send a message to ServerName and ask for the data in ShareName. When ServerName receives the request, it queries its registry for a ShareName matching ShareName, and finishes the directory traversal from that point.
By extension, using the volumes we defined above, we could have on the workstation, the following:
C:\Program Files\My Company\TabletApp\Data\CUSTS
C:\Program Files\My Company\TabletApp\Data\PRODS
C:\Program Files\My Company\TabletApp\Data\INVS
Each of these folders could have a revparam pointing to a share on different servers. This would allow the CUSTS volume to exist on SVR1PHL, the PRODS volume to exist on SVR2PHL and the INVS volume to exist on SVR1NHMP.
of just how productive you can be using Revelation's tool set.
Last week I spent a day on client's site as he had some issues of stability that he wished to resolve. We spent the morning going through these then, as afternoon approached, he asked "OK can you knock me up a copy protected installation routine for me to ship my product with?".
Here's where a Revelation/Open Source Community mashup really comes into its own.
Firstly download NSIS - we have the engine to create a full SETUP.EXE.
Next take the excellent NSIS installation script provided at one of the conferences by our friends at SRP and spend 5 minutes customising it - we have the working OI Installation routine.
Next install Sprezzatura's registry method handling routines registry_methods.zip - we have the wherewithal to copy protect the application by embedding encrypted registry keys.
Finally write a new front end screen for the application that compares the Windows computer name (using the GetComputerName declaration in DLL_KERNEL32) to an encrypted version thereof in the registry and if found launches the app, if not launches a newly written registration screen. Have the registration screen display an encrypted string to read to the client's tech support line to receive back an unlock code which permits the stamping of the registry. We have the solution.
Now we're not claiming this is bullet proof (bullet proof we can do but it'd take longer) but it's one heck of a lot of return for 4 hours of invested time!
Last week I spent a day on client's site as he had some issues of stability that he wished to resolve. We spent the morning going through these then, as afternoon approached, he asked "OK can you knock me up a copy protected installation routine for me to ship my product with?".
Here's where a Revelation/Open Source Community mashup really comes into its own.
Firstly download NSIS - we have the engine to create a full SETUP.EXE.
Next take the excellent NSIS installation script provided at one of the conferences by our friends at SRP and spend 5 minutes customising it - we have the working OI Installation routine.
Next install Sprezzatura's registry method handling routines registry_methods.zip - we have the wherewithal to copy protect the application by embedding encrypted registry keys.
Finally write a new front end screen for the application that compares the Windows computer name (using the GetComputerName declaration in DLL_KERNEL32) to an encrypted version thereof in the registry and if found launches the app, if not launches a newly written registration screen. Have the registration screen display an encrypted string to read to the client's tech support line to receive back an unlock code which permits the stamping of the registry. We have the solution.
Now we're not claiming this is bullet proof (bullet proof we can do but it'd take longer) but it's one heck of a lot of return for 4 hours of invested time!
| Making Databases Happen |
USA +1 267 238 3814
|