Title: Understanding Windows (8)

One of the fundamentals of software engineering is that user interface (UI) code should be separated from that which does the real work of the application. It is generally easiest to port code that isn't directly involved with the UI from one platform to another (including non Windows), as well as from one application to another. It is even easier if that code makes no direct API calls at all, for example substituting 'new' and 'delete' for global heap allocation functions.

As much code as possible should be written as 'library' code (at least conceptually) with well thought out interfaces that can be used in any environment. If this is done with care the resultant body of code can simply be re-compiled under any environment. It is a matter of choice whether this is a set of C functions or a true class library - I'd go for the class library every time.

In order to build a finished application it is then necessary to bolt on the platform specific components. These components can be thought of as coming in two flavours, first those for which the library code is a 'client' and secondly those which are clients of the library. The heap management routines (mentioned above), which are linked in behind the scenes, fall into the first category, as do any other substitutable drivers, hardware interfaces or whatever. The user interface code will largely be in the second category, i.e. a client of the library code.

This is best understood with a diagram, so I suggest that the interested reader goes away and draws one.

Hint: Try to make the library domain as large as possible and its interface as simple as possible. Make platform specific components as minimal as possible - that's it, you're getting the idea!

The inevitable thrust of the preceding articles is concerned with using the Windows API to provide the user interface to your program. Indeed example programs have been almost all UI and little real substance. This API when used with care can be reasonably portable across Windows platforms. The C++ equivalent is to use MFC. as a cleaner interface to the API. This used sensibly gives better portability to other Windows platforms, including simulating some features that aren't fully supported between '95 and NT.

Other class libraries that provide a more abstract view of the UI are available. These promise to enable source code portability across a wider range of platforms, at the cost of only supporting a common subset of features and involving some extra complexity.

In general, class libraries should support the 'document - view' architecture. I recommend that you should make the interface between your own platform independent code and the UI concentrate in one or more specialisations of the document class. As with the discussion above I feel that it is a mistake to allow references to the UI class library to creep into your own library code. Unless you are totally enamoured of the third party library you will probably want to separate them at some point in the future.

One of the above alternatives will suit many developers, depending on their particular needs.

On the other hand, if you are concentrating on Windows targets and wish to integrate your code with applications written in other languages (or macro languages in third party applications) then other possibilities arise.

The simplest is to make your code into one or more DLLs, these export a simple functional interface and being language independent can be used almost anywhere.

Other alternatives include the venerable 'VBX control', the exciting new 16 and 32 bit OLE custom controls and full OLE 2 server applications, all of which require significant extra work to produce.

All of these separate compiled components can be shared across multiple application instances, so they should be considered for use with purely C/C++ applications.

I find it difficult to raise any real enthusiasm for this language but with many companies using VB 3.0 and its close relatives - VBA (Visual Basic for Applications) in other Microsoft products, we have to take it seriously.

The main reason for its popularity is that it is very easy to produce a running application without needing either skill or patience. For this reason it is often put forward as an ideal proto-typing tool, frankly I believe this not to be the case, it isn't really difficult to produce an equivalent UI framework in C/C++.

VB applications have a certain indefinable 'look and feel' which I think comes from the 'form' concept, combined with the general availability of icons as a UI element.

Where VB is useful is in providing a 'quick and dirty' test bed for DLLs as well as producing finished applications for vertical markets or bespoke applications where there may be no justification for producing optimal solutions and where maintenance by less skilled programmers is considered desirable.

For all its ease of use, VB is a positive minefield when applied to large projects. It is not an OOP language and gets out of control if you aren't careful for anything over - say - 10,000 lines of code. Having said all of that, it handles databases (Access 1.1) very well and has a quite reasonable exception handling mechanism.

As with all languages it is desirable to separate UI from the rest and VB does this by allowing you to attach code to 'events' within each form module but also allows you to write code in modules which are not associated with forms. Some abstraction is possible in terms of references to VB objects (forms and controls) but sadly less in terms of programmer defined types.

For each class that you wish to work with, declare a VB type that contains a handle and any other members that may be useful for information purposes. The handle is used by the DLL to store the address of its actual class instance. Each function takes a reference to this object as its first parameter, possibly writing to the members.

The VB code may read the information members that will be updated by the DLL functions. So long as the VB code doesn't actually modify the handle member, the functions can only be called with valid references and the handle only has to be checked for zero by the functions. This relies on the fact that VB initialises all data instances (including automatic ones) to zero before they are used.

Passing a reference to a type understood by VB enforces a lot more type safety than the direct handle mechanism but with the real object being in the hands of the DLL allows for the full C++ class semantics to be applied.

Having additional attributes in the interface structure is optional but useful. I would advocate that these are only written to by the DLL functions, and where the VB code needs to supply new values that these are passed as separate arguments.

As an example, imagine an interface to a lift class, the interface structure can be declared in 'C':

struct LiftData { int num_floors; int max_people; int cur_floor; LiftBase *pLift; };

Assuming that we have a class 'LiftBase' define some exportable functions:

#ifdef __cplusplus extern "C" { #endif void __export CALLBACK lift_create(LiftData& ld, int num_floors, int max_people ){ ld.pLift = new LiftBase( num_floors, max_people ); ld.num_floors = num_floors; ld.max_people = max_people; ld.cur_floor = ld.pLift->get_cur_floor(); } void __export CALLBACK lift_destroy(LiftData& ld) { delete ld.pLift; ld.pLift = 0; } void __export CALLBACK lift_request( const LiftData& ld, int floor_num, BOOL in_lift) { if( ld.pLift ) ld.pLift->request( floor_num, in_lift ); } // ... and more 'lift_' procedures #ifdef __cplusplus } // End extern "C" #endif

The above fragments illustrate the technique. The functions correspond with the public interface to the LiftBase class (more or less). If other classes are derived from LiftBase, there would need to be extra creation functions for these types. Assuming that virtual functions (and destructors) are used throughout, the existing 'member' functions remain equally valid. LiftData represents an abstract type - this gives you an OOP interface to the DLL!

This DLL interface is aimed at VB but would be perfectly good for any client language.

Sadly, VB doesn't understand C header files, nor will it read import libraries. We have to declare the functions in a '.bas' module:

Type LiftData num_floors As Integer max_people As Integer cur_floor As Integer pLift As Long End Type Declare Sub lift_create Lib "lift.dll" (ld As LiftData, ByVal n_f As Integer, ByVal max_p As Integer) Declare Sub lift_destroy Lib "lift.dll" (ld As LiftData) Declare Sub lift_request Lib "lift.dll" (ld As LiftData, ByVal f_num As Integer, ByVal in_lift as integer)

These 'Declare Sub' lines declare the signature of the procedure as well as its DLL name in one go. Notice that all parameters that are passed by value are explicitly declared as such. It's important to get these declarations correct; failure to do so will lead to garbage being passed to the DLL functions!

This article has rambled over a wider area than purely Windows programming. It's good to keep in mind the fact that most Windows applications do have a wider context. Putting it another way, don't get too wrapped up in the Windows specifics and leave your UI options as open as you can.

The VB - DLL interface ideas are presented as a result of my own experiences, so if you have any further thoughts on them please write in with your own contribution/criticism!