UserBank
UserBank 1.1, the MFC software registration system
Note: UserBank 1.1 is discontinued. This information is provided as is.
UserBank overview
UserBank 1.1 by Cruquius Soft is a software registration system for distributors of Visual C++/MFC applications.
It consists of two parts: the UserBank application itself, which is a database of registered users, and a software library, called AppLock, to be employed in building your application.
With UserBank, an application has a unique Application Lock embedded in its executable, only known by the distributor. When a user applies for registration, the distributor entitles him or her a personal Registration Code, based on the user’s name and the embedded Application Lock. Of course, the user has to pay a registration fee first. The user enters his or her name together with the Registration Code and the app becomes registered.
As long as the application is unregistered, a blinking message “Unregistered copy” appears on the status bar most of the time. Hopefully this in itself is sufficiently annoying to motivate user registration. If you feel that it convinces the user even more, you can ‘cripple’ your app in the unregistered state.
An unregistered app also has an extra item “Registering <<your app>>…” in the Help menu.
If the user registers, he or she is rewarded by seeing his or her name in the app’s “About Box” and of course by the relief of never seeing the blinking message and the extra Help item again.
Of course, this well-known registration system is far from bomb proof. Users simply have to enter a proven combination of a User Name (not necessarily their own) and a Registration Code to get their copy registered. You can only hope that the combination of sheer quality and a decent pricing policy lets your users register the app in a proper way.
The algorithm used for generating the Registration Code is sufficiently contrived to make it unlikely that the Application Lock is distilled from even a large number of valid combinations of user names and registration codes. Of course no encryption scheme is safe for a skilled and really motivated hacker, and UserBank’s one is no exception. So please don’t expect UserBank to protect really valuable assets.
System requirements
UserBank 1.1 itself is a Visual C++/MFC application using DAO-objects. It uses a considerable number of supporting DLL’s, that are all part of Microsoft Visual C++ 6.0. Because UserBank is geared towards Visual C++ users, these DLL’s are not included in the package, as they will be installed on the user’s system already. UserBank runs with Visual C++ 5.0 DLL’s too. It may run with Visual C++ 4.2 DLL’s as well, but it is not tested.
It may be possible that you have an installation of Visual C++ without the DAO-files. If this is the case, install them now from the Visual C++ CD (check “Microsoft Data Access Objects” under “Database Options” in Visual C++ Setup).
UserBank is 32-bit software, running under Windows 95/98 or under Windows NT 3.51 or later. It will not run under Windows 3.1 or WfW 3.11.
UserBank keeps its data in file “UserBank.mdb”. This is a simple, Access compatible database file containing just two tables. If you dare, you may build a more advanced database system based on these tables, but be sure not to change the tables’ design or else UserBank won’t function properly.
Uninstall
UserBank can be uninstalled using the standard procedure in Windows 95/98 or Windows NT.
How the distributor generates registration data
The application distributor enters the User Name in UserBank’s database. UserBank calculates the personalized Registration Code on the fly. The program even prepares an E-mail message to the user, containing the registration data. For more information: see UserBank Help. UserBank can handle an unlimited numbers (well, over 4 billion) of apps and users.
How the user enters registration data
Apart from the usual ‘OK’ button, the “About Box” of a UserBank enhanced app has a ‘Register…’ button. This opens a small dialog in which the user can enter his or her name and personal Registration Code. Three attempts are allowed: another try is possible only after restarting the application.
The User Name and the Registration Code are kept in the Windows registry.
Note: the ‘Register…’ button only appears if the application is in its unregistered state. In registered state, the button is hidden. When the application is linked in debug mode however, it is changed to an ‘Unregister’ button.
Choosing an Application Lock
Each application has it’s own, ‘unique’ (well, sort of) and secret (that’s up to you) Application Lock. This number is used, together with the user’s name, to calculate the user’s individual Registration Code.
The Application Lock can be any number comprising three to nine digits, not starting with a zero. The user’s individual Registration Code will have the same number of digits. A small number offers less protection than a nine-digit number of course, but it may be less error prone in entering. Apart from that there are no special considerations in selecting the number.
The Application Lock should be entered in UserBank’s User View (refer to Help) and exactly the same lock should be embedded in your application.
Embedding an Application Lock in your application
To enhance your Visual C++/MFC application with UserBank’s user registration is a relatively easy task. A special MFC-class should be used as the base class for your frame window and one function call is needed.
Using the library
UserBank’s application software is provided as a small static library. All relevant files are in UserBank’s AppLock subdirectory.
The library comes in two versions. ‘AppLock.lib’ is compiled without debugging code and should be used in the final release. ‘AppLockD.lib’ is compiled with debugging code for Visual C++ 6.0 (the system may work with earlier versions of Visual C++, but it’s not tested). Both versions assume that the application uses MFC in a shared DLL.
The header file is called ‘AppLock.h’. You may move the .lib files to MFC’s lib directory and the header file to MFC’s include directory, so the IDE can easily find them, but you can also leave them in UserBank’s AppLock directory.
- To make your project link with the libraries, you have to add them explicitly to your project. To do this, open Visual Studio’s Project Settings, choose the Link tab and then Category: General. In the settings for target ‘Win 32 Release’, add ‘AppLock.lib’ to the “Object/library modules”. Do the same with ‘AppLockD.lib’ in the ‘Win 32 Debug’ settings. Include (preferably relative) directories as appropriate. (You can also add the AppLock subdirectory as an “Additional include directory” under Project Settings, C++ tab, Category: Preprocessor).
Deriving CMainFrame from CAppLockFrameWnd
The first thing you have to do is change your MainFrame files.
Normally class CMainFrame in your application is derived from a standard class like CFrameWnd. Now CMainFrame has to be derived from UserBank’s class CAppLockFrameWnd, which in turn is derived from CFrameWnd.
- To achieve this, simply replace all text occurrences of ‘CFrameWnd’ by ‘CAppLockFrameWnd’ in the app’s source files ‘MainFrame.h’ and ‘MainFrame.cpp’.
In ‘MainFrame.h’ include UserBank’s header file ‘AppLock.h’ (possibly preceded by its directory).
MDI and Ole IP applications
In multiple document applications (MDI) CMainFrame normally is derived from CMDIFrameWnd. Just like deriving from CAppLockFrameWnd enhances a single document mainframe, in an MDI application CMainFrame should be derived from CAppLockMDIFrameWnd. Bundled with UserBank is a rudimentary sample application (in subdirectory ‘Sample’) that uses CAppLockMDIFrameWnd. You may consult the commented source files.
An application with a COleIPFrameWnd as CMainFrame’s base class (to implement in-place editing) can use CAppLockOleIPFrameWnd likewise.
Note that for the time being there is no (easy) way to use UserBank’s registration scheme in dialog-based apps (mainly because these are not based on a CFrameWnd).
Calling SetApplicationLock
In CMainFrame’s OnCreate handler the all important member function SetApplicationLock should be called with the unique, secret Application Lock as the first parameter.
SetApplicationLock has a second parameter, comprising a combination of the following flags. Note that the flags are all one word, although your browser may break them across two lines.
| APPLOCK_SHOWONSTATUSBAR | In unregistered state, the application shows the message “*** Unregistered copy ***” on the status bar. |
| APPLOCK_BLINK | The message blinks every two seconds (only in combination with APPLOCK_SHOWONSTATUSBAR). |
| APPLOCK_HELP | In unregistered state, the application has the item “Registering <<your app>>…” on its Help menu. In registered state, there is no such menu item. |
If the second parameter is not specified, a default value of all three flags is used.
Adding resources
To operate, CAppLockFrameWnd and its cousins CAppLockMDIFrameWnd and CAppLockOleIPFrameWnd expect some dialog templates and strings in the application’s resources.
These resources are defined in the file ‘AppLock.rc’.
- The easiest way to embed these resources in your application is to add an include clause to your .rc2 file, the file that contains the non-editable resources.
You can also use Visual Studio’s “Resource Includes” command in the View menu, or you may copy and paste the resources to your main resource file. Note that in this case, ‘AppLock.h’ should be included in the main resource file.
Adding a Help topic
If you call SetApplicationLock with the APPLOCK_HELP flag set, an extra item “Registering <<your app>>…” will be added to the Help menu (at least when your application is in the unregistered state). Because the help information will vary wildly from one application to the other, only a skeleton topic text is provided. It is in the file ‘AppLock.rtf’. You should edit this text (using Word or another text processor capable of handling .rtf files) to something that makes more sense.
- Use Microsoft Help Workshop (bundled with Visual Studio) to add the help topic. Load your applications help project file (.hpj). Under “Files…” add ‘AppLock.rtf’. Under “Map…” include the file ‘AppLock.hm’.
Removing the old “About Box”
Though not strictly necessary, you may prefer to remove the original “About Box” from the MFC-code, as it is now non-functional. The AppLock classes now implement the “About Box”.
Knowing the state of your application
After creation of the frame window, your application can monitor at any point during execution whether it is registered or not. Simply call the frame’s member function IsRegistered(). If it returns TRUE (non-zero) the application is registered; otherwise it is unregistered. You may use this information to ‘cripple’ your unregistered application in one way or the other. Refer to the Sample app to see an example.
Testing your application
When your app is built in debug mode, the “About Box” has an ‘Unregister’ button in registered state. Also in debug mode only, a message appears in the debug window stating the User Name, the Registration Code and the correct registration code. Both facilities allow for easy testing of the app. Make sure to never distribute a debug build – but of course you shouldn’t do that in any case.
Customizing the AppLock classes
There is plenty of room to enhance on the AppLock classes. AppLock’s resources can be edited, for instance to localize them. Commented source code of the classes is provided in the ‘AppLock.cpp’ file (not of the core registration algorithm, of course).
Note that most work is done in the class CAppLock. The three frame classes all have a CAppLock as member variable and delegate most tasks to it.
One of the things that come into mind is providing a slicker “About Box”. You can edit the dialog template, but you might also derive a class from CAppLockAboutBox with more functionality.
it’also fairly easy to override AppLock’s default Help handling. Normally, when the “Registering <<your app>>…” command is invoked, the frame simply calls WinHelp with a topic-id of CRUQ_IDS_REGISTERHELP. You may override OnRegisterHelp in your CMainFrame to do something completely different, for instance opening a text file or even trying to access a web page (tip: use the Win32 function ShellExecute to achieve this).
License
UserBank by Cruquius Soft and its associated software library AppLock are shareware. You are hereby licensed to use this software for evaluation purposes without charge for a period of 60 days. If you use this software after the 60-day evaluation period a registration fee of $19 is required.
Registering UserBank gives you the right to create an unlimited number of freely distributable royalty-free application executables with the embedded Application Lock.
UserBank, © 1999 by Cruquius Soft, Amsterdam, the Netherlands.