I thought I would add a blog to the ayrware site to highlight the trials and tribulations of a C++ developer and also as a place to post comments on IT related issues in general. My intention is to update this blog on a monthly basis, or more often, as time and work commitments permit.
6th February 2008, 11.15am
I came across a message forum post the other day in which a member asked what scheme he should employ when adding version information to his newly created application. As I suspected, the replies indicated there was no 'one size fits all' answer to his question. The reason for this is that most companies have their own versioning schemes in place; they range from the simple to the overly complex and convoluted.
I employ a very simple scheme which uses four 16-bit numbers to denote
MAJOR.MINOR.PATCH.BUILD. This scheme works well with Visual Studio since you can
insert your version numbers directly into the FILEVERSION and
PRODUCTVERSION entries, in the application resource file. I usually add the same
version numbers to both of these entries just to keep things simple.
So, under what circumstances are these numbers incremented? The BUILD number should
technically be increased each time you build your application. I only find this useful where an
application is being released for testing and perhaps anticipate several build/test cycles may
be required. Incidentally, I have always thought it odd that Visual Studio has never had the
facility to automatically increment build numbers.
I increment the PATCH number when there is a requirement to re-release software,
usually as a result of serious defects being found in the application or associated components.
The sort of defects I am thinking of here usually prevent application features working as
advertised or adversely affect the overall performance and stability of the end product.
The MINOR version number is increased when, say, features are added or improved and
very minor bugs are fixed. The application should remain fully compatible with any associated API,
component or resource. Some companies refer to software issued under a minor version number as
a maintenance release.
The last version number, denoted by MAJOR, is increased when a radically new version
of an application is released. In this case, the appearance, functionality and operating procedures
of the application will almost certainly bear no resemblance to the previous version. The usual
casualty of a major version release is the format of any data file used by the application
- think here how many times the native file format of Microsoft Word has changed and the efforts
the company has made to retain backwards compatibility.
Using the above scheme, confusion and errors are eliminated, with respect to a particular version number change, when it is time to make a new software release. In fact, it is probably better to change the relevant version number prior to starting work. Ask yourself is this a quick bug fix for a recent product release? If it is, simply increment patch and perhaps build numbers. Optimizing the application or adding 'nice to have' features? Increase the minor version number. You get the idea ...
28th December 2007, 7.25pm
Wow, has it really been eight months since my last entry? So much for posting an update every month or so! My only excuse is that I have been working pretty hard on Aurora, my presentation design tool and, like the ubiquitous car mechanic who can't face working on his own car, I have stayed away from keyboards and computers in the evenings, preferring to sample the delights of the real world instead.
Anyway, just in case you are interested in the progress I have made with Aurora, I have posted a screen shot of the main application window below - click the image for an enlarged view.
I have based the GUI design on that of Visual Studio 2005, employing its tabbed document view, docking panes and an output message window. This design is not 'set in stone' however and I may alter it if there are aspects that don't fit or are not intuitive.
What have I still to do yet? Well, for the first version of Aurora there are only two components of the application still outstanding. The first component is the page designer, which allows users of the application to lay out each page visually; shapes and images can be positioned and resized just like a modern paint package. The properties associated with each page object will be written to the current xml presentation file.
The second component is the flow control designer. This will be a bit like the page designer except that the shapes will be derived from those in a typical flow chart. Linking the shapes together, using various gui tools, will determine the order pages are presented to the user when the experiment is run. There will be provision for simple loops, conditional branching and timed events. Again, flow control properties will be written to the associated presentation file.
16th April 2007, 4.39pm
I came across an interesting news item which I thought I would draw to your attention, just in case you missed it the first time around. Anyway, it seems that Microsoft Research are about to test a new programming tool called Boku. This new tool, or programming environment, is aimed at kids and has been designed to allow the creation of programs via a simple graphical interface.
Matt MacLaurin, project manager for the group that created Boku, said that he wanted to encourage children to be more creative, to get them to exercise their brains and to get them away from passively watching TV. He said he wants kids to approach Boku like a puzzle game and hopes that they soon realize that it can be changed in a multitude of fun ways.
I believe it is the absence of fun, while being taught with intractable text based programming languages, that deters children from attempting any form of computer programming. This subject, at least here in the UK, is introduced to kids at school via some flavour of Basic or perhaps Java. These languages, although widely used, are hardly appropriate for very young children and perhaps only a small minority of older kids will be drawn into doing anything remotely creative outside the classroom.
Boku, which runs on XBox 360 and PC platforms, addresses these issues via a simplified programming model, based on behavior cards. Every program created, irrespective of its complexity, is guaranteed to be syntactically correct, free of bugs and can be run quickly when completed. MacLaurin also hopes to build an online community around Boku, where kids can discuss and share their latest creations.
2nd March 2007, 3.32pm
This week I have been converting a Visual C++ 2003 project to the new Visual Studio 2005 format. The project was originally created using VC++ version 6.0 and has been through quite a few development iterations. I am hoping that this will be the last, due to the shortcomings of the design, which are now all too apparent.
Anyway, the conversion process itself went quite smoothly but, after running the application in debug mode, the output window of the Visual Studio environment presented me with a whole raft of memory leaks. Why did the earlier versions of Visual Studio not highlight these leaks? More puzzlingly, why did my memory analysis tool, DevPartner, not pick them up?
I decided to concentrate on fixing the memory leaks, postponing investigation of the two questions above until a later date. After a lot of head scratching, it turned out that the leaks were due to the (questionable) design of the application - I had been allocating memory in one thread and, without realizing it, deallocating the memory in another.
The application in question is controlled by a small state machine and transitions between some of the states are triggered by a timeout event from the ATL Timer component. The timeout event triggers a state change which, in turn, deallocates all currently allocated memory. This code sequence was running in the timer timeout notification thread; the deallocated memory having originally been allocated in the main application thread!
Without altering the application radically, the most straight forward fix for the above state of affairs was to send a Windows user defined 'state change' message, to the the main application window, from the timer timeout handler. The state change would now be triggered from the main application thread and the memory would be deallocated correctly.