General
Installation
Although this product comes on CD-ROM it still needs a significant amount of disk space, particularly in your windows\system directory. The install program doesn’t give you any options for these files (system files mainly *.d11) so make sure you have plenty of room. It gobbled up about 6 Mb on my C drive and another 40 Mb on my E drive where I had expected most of it to go. You can certainly get away with less space than that but a installation is well over 110 Mb.
Documentation
I felt lucky to have the MSVC 1.0 hard copy documentation as this is now only provided on-line. Considering the price of books in general the £72 additional cost is probably very reasonable. I try to do as little as possible in front of a VDU so when it comes to V2.0 I expect I’ll have to buy the full set! Microsoft make a big play about their ’books on-line’ system but I find it somewhat cumbersome and less easy to navigate than the standard help files. The ’search plus’ option is quite effective though.
System requirements
I found that V1.0 would just run on a 4 Mb machine when a SIMM went down but only just. You really want a local bus 486 with at least 8 Mb ram and 1 Mb video card on a good monitor, running Windows 3.1 or later.
Visual Workbench
Editor
As this is What you use for 90% of machine time it needs to be good and it is. The application is a bog standard MDI, quite recognisably Microsoft, has no frills except context colouring and is simple to use.
The only drawback is that scrolling with the cursor keys is slow and you have to wait for each single line to scroll in turn. I had hoped that this would be fixed in this release but perhaps next time?
Workspaces
You can save the editor configurations under different ’workspaces’, this is only really useful for having a different layout for debugging sessions without throwing away your editing configuration. Useful if you remember to use it!
Project system
Creating and modifying projects is well handled by nice simple dialogs. The creation of static libraries from within the environment is now supported. The project options dialog has a ’debug’ or ’release’ radio button, this is a real boon!
The system reminds you if you have changed any options that could affect the build and gives you the opportunity to re-build the affected files, why it says ’affected’ no-one knows as it always goes ahead and re-compiles everything!
It isn’t possible to change options for individual files.
There seems to be no support for using an external assembler on .asm files or for using the help compiler from within a project.
Browser
The browsing system is based on separate files created during the build process, once this database is in place you can navigate through your class hierarchy, go to definitions or references and so on. It all works.
Debugging
Although external tools such as CodeView are provided, the integrated debugging is excellent. Push it too far and it may get into trouble with screen updating.
App Studio
The resource editor is really rather good, it can be invoked from Visual Workbench and comes up with the current project’s resource script. It automatically creates a header file but beware trying to change which file after you’ve started - it’s easy to lose all your ID’s and just end up with numbers! Read the manual first, I didn’t.
The bitmap editor can operate in ’tiled’ mode, this simplifies the creation of strips of toolbar button images particularly.
The ability to invoke Class Wizard by ’Ctrl double clicking’ a control is very productive.
Wizards
APP Wizard
This is the thing that you can use to create the skeleton of a Windows application using MFC. This is a one off process, if you change your mind about a feature you will have to go back to square one.
The only real reason for using it is that this is the only way to get to use the Class Wizard.
Class Wizard
Because this only Works on projects using MFC this is of less use than I think it could be.
When used in conjunction with classes derived from MFC bases it automates the process of adding message handlers particularly well. It can be used for creating classes and binding controls to data members. It is database aware and can be used to bind controls on forms to CRec0rdSet members.
This is the preferred method for doing this work as the MFC macros are pretty opaque to ordinary mortals.
Class Wizard can be invoked both from the text editor and the resource editor.
Compiler (and Linker)
Targets
Will create 16 bit DOS (including overlaid) and 16bit Windows applications.
Performance
The compiler is noticeably slow, I have had build times of up to 30 minutes for a medium sized project.
On the other hand it will happily work in the background and seems to plod on regardless of what you do with the system in the meantime.
In contrast the compiled code is both quick and small, executables can be as small as 20% of the size of an equivalent Borland compilation. However this is mainly due to the very efficient linker and this has less effect for large projects.
The optimiser has an effect on code size, unfortunately we have found some complex code that appears to optimise incorrectly.
The work around when this problem comes up is to control optimisation with #pragmas around the offending code. This is always a worry of course.
C++ language implementation
You won’t find any of these new-fangled templates, exceptions or run time type identification here. I’m kind of assuming that these features are being left till version 2.0 so we’ve all got something to upgrade to.
Generally errors and warnings are pretty strict (but fair of course) although I have occasionally had some pretty perplexing ones. Warning level four tends to fill the output window with ’unreferenced local function has been removed’ warnings for all your access functions in file after file.
The in-line assembler is limited to 286/7 code - this is a serious limitation in my view, you might as well just use an external assembler and done with it.
Microsoft Foundation Classes
This is a large and complex class library intended largely for use as a C++ -API to Windows. It is quite efficient both in speed and size. Really much of the kit is built around MFC, so you have to use it to take advantage of the Wizards for example.
The source code is provided but not recommended reading.
Call me old fashioned but I don’t see why the base window class has to contain a public data member m_hWnd unless it’s for the sake of efficiency.
The lack of templates, exceptions and run time type identification in the language is got around by means of some horrendous macros. Although these work very well, they are a good reason to make use of the wizards for building your code skeletons.
The concept of polymorphism that would normally be implemented using virtual functions is instead implemented with ordinary member functions in conjunction with ’message maps’. These are dictionaries of messages and functions created with macros which are looked up at run time as messages come through. This lookup is done using hashing and is reasonably quick. The reason that virtual functions aren’t used is that to crack messages down to individual functions for each message would otherwise create - very large virtual method tables for each window class. Furthermore you still need a big switch table to crack the incoming message so the message maps are only doing the same job explicitly.
The window handles and instance addresses are associated again using a hashing algorithm so that messages can be directed to the object associated with the target window.
All classes are ultimately derived from a CObject class using single inheritance. Object persistence is supported through a virtual serialize() member and a set of macros used to declare and define a derived class. Serialisation is done with a binary stream called CArchive and Works well.
If there is a problem with the library it is that you tend to get code for things you didn’t ask for such as shell registration in the CWinApp class, not a bad problem to have if you were going to implement it anyway.
Most applications will have an SDI or MDI frame window to carry the user interface controls such as the menu and tool bar and zero or more ’documents’ each with one or more ’view’ windows. You can use the classes to deviate from this model if you wish but you will find yourself doing more of the work.
Some of the specialist classes are quite usable and some are pretty necessary. This version has gained OLE 2 and database classes. These provide the only usable interface to these features!
The library is provided in .dll form as well as static which is particularly useful for the developer.
The Windows API parts of the library give you source code compatibility across any platform so long as it’s MS Windows, so this still leaves the field open to other multi-platform libraries.
ODBC
The database connectivity is through ODBC drivers, these are very good so long as there is a suitable driver available, the following are currently supplied as redistributables:
Notes from supplied help files.
FoxPr0 uses V2.0 or V2.5 data.
dBase uses V3.5 data only
Excel uses V3.0 or V4.0 data
Btrieve needs a separate wbtrcall.dll (stand-alone Windows Btrieve)
SQL need access to MS SQL server V1.11 or greater, or Sysbase SQL server V4.0 or greater
Oracle needs Oracle server V6.0.34 or later, but V7 gives minor inconsistencies
Given the attractions of writing commercial database applications in a Windows environment and an efficient language, this provides an attractive alternative to either specific libraries or conventional 4GLs.
Database portability is only limited by the differences in capability between data formats.
A useful little mini database program called Microsoft Query can be used to create database tables as well as query tables interactively.
Other Tools
There are a number of other applications for debugging and examining the Windows system, they all seem to work quite well.
Adrian Fagg
