We have just released new versions of our software tools that are code signed.

This change will please those of you that are using more recent operating systems that will ask your permission to start an executable that is not signed by a company that you trust. No more warnings for Vista and Windows 7 users!

We have also introduced a new user hinting feature that provides some general guidance on what to do next using unused space on the user interface. This user hinting came about as a result of some usability testing we did during November. We hope you find this useful, if not for yourself, but your colleagues when introduced to the software.

Everyone uses Visual Studio to write C and C++ software don’t they? Yes! you all chorus. Apart from some guys at the back who like to use gcc and g++. They use MinGW when working on Windows. And they may even use Emacs, or perish the thought, vi!

Up until now we haven’t been able to cater to the needs of gcc and g++ users. We’d get email every month asking when we were going to support MinGW or if we supported QtCreator. It was frustrating admitting we couldn’t support that environment. Even more so as the founders of Software Verification wrote large GIS applications using gcc and g++ back in the early 1990s.

During October we integrated support for MinGW and QtCreator into Coverage Validator, Memory Validator, Performance Validator and Thread Validator. Both COFF and STABS debug formats are supported, which provides some flexibility in how you choose to handle your symbols.

We’ll continue to add support for additional compilers to our tools as long as there is interest from you, the kind people that use our software tools.

Ever had a crash with a pointer value of 0xcdcdcdcd or 0xdddddddd or 0xfeeefeee?

You have? Sooner or later when you work with C or C++ you’ll bump into one of these crashes. You will no doubt try to reproduce the crash and thats when you’ll probably notice this unusual value has repeated itself. Perhaps the value is significant, perhaps it is telling you something?

Stephen has just written an article about the unusual bit patterns you can find in variables on the stack or in the various Win32 heaps or in the CRT heap. The article closes with some suggestions on how to prevent these errors from occurring.

A few minutes spent reading about the bit patterns may help you see these bit patterns less frequently and dig you out of any 0xfeeefeee hole you may have fallen into.

T-shirts appears to be the answer. Even better if they come with a natty logo or slogan.

Andy Brice has come up with a wonderful idea of creating some interesting T shirt designs with programming related in-jokes. The profits from the sale of these T-shirts goes to two worthy charities: SightSavers and JairpurFoot. SightSavers is a charity helping to prevent blindness and eyesight problems and Jaipurfoot is a charity helping to provide low cost prosthetics to people in 22 countries.

Head on over to T-Shirts for Programmers to read about Andy’s motivations for the T-shirts. His blog also has lots of interesting articles about the independent software business.

Full disclosure: Andy Brice is a customer of ours. Andy uses Coverage Validator to improve the testing of his popular Table Planning software. Andy has recently written a review of Coverage Validator V3.

We provided Performance Validator to them to see what they could do. Today we found out.

The Darmstadt Dribblers have just taken their robot Isra to RoboCup 2008, held in Suzhou, China. They came 4th in the championship (24 teams competing), losing to the championship winners (also from Germany). The other two quarter finalists were both from Japan. Thats a good result, against some good competition.

Isra running to the ball.

Isra tackles an opponent.

Isra scores a goal.

This YouTube video shows Isra in action at Suzhou:
http://www.youtube.com/watch?v=QTbGXqQNkqQ&feature=PlayList&p=28F7B3DCA3198715&index=7

The Dramstadt Dribblers have uploaded various videos here:
http://www.youtube.com/profile_videos?user=DarmstadtDribblers

Still think software engineering can’t be fun?

We’ll be reporting on the Dribblers’ performance as they enter more competitions.

About a month ago we hadn’t heard of XULRunner. Then the folks at Songbird emailed us asking if our JavaScript tools supported XULRunner.

Its easy to miss a new tool or technology what with all the various development directions people are taking. XULRunner is a platform independent way to write applications using the same technology used to create Firefox and Thunderbird. You use the XPCOM, XUL and JavaScript technologies to create your application. With a bit of magic it then runs on your platform of choice. Songbird are using XULRunner to create a platform independent media player. I guess they know their target market, they are founded by the same people that did Winamp and Yahoo! Music Engine.

Given that we already supported JavaScript for Firefox and Flock support for XULRunner seemed like a natural fit. Ideally it would have worked out of the box, just change a few settings on the UI of our tools and off you go. It didn’t turn out that way, although now we’ve made the appropriate changes, its as trivial as selecting xulrunner.exe instead of firefox.exe when you are choosing the JavaScript runtime.

The first problem we had was that xulrunner.exe doesn’t use the js3250.dll DLL directly, it does it via the xul.dll DLL. As a result the UI and the stub couldn’t find the js3250.dll and thus couldn’t determine the version information we use to choose how to interact with js3250.dll. So we needed to support that.

The second issue was that each js3250.dll we’ve encountered has some internal differences that make line numbers inconsistent unless you use a build against the same header files used for that build. Very annoying, but thats how it is. So we need to know if its Firefox 1.0, 1.5, 2.0, Flock 0.7, or xulrunner to choose the appropriate way to interact with the target. If our tools don’t know they assume you are using the latest and greatest and give you the firefox 2.0 treatment. XULRunner needs the 1.5 treatment not the 2.0 treatment so we had to put in a check for that. Also, the version ids on xulrunner.exe shipped with Songbird are "Personal" and not a version number. Excuse me? Whats up with that? Not very useful information. It should read "1.8" or something similar given that XULRunner is currently at 1.8.0.4. Hopefully someone will fix that.

A third issue was a killer. Songbird triggers a hook that causes a fatal crash. Whoops, how did that get past testing? Same way any other bug does I guess Thats life, we are not perfect, so chalk that one up to experience.

We also needed a few XULRunner specific tweaks. For example when you are launching a XULRunner application you are looking for .ini files not .html/.js files.

To sum up, all our JavaScript tools now support XULRunner. This should help all of you using XULRunner to create platform neutral apps using Mozilla technology. If you have any specific issues please let support know at the usual address.

We’ve spent the last few years creating our software tools for C++, Java and all the funky scripting languages that are now getting the recognition they deserve (Python, Ruby, JavaScript, etc).

During all this time we’ve have been asked if we have .Net versions of our tools, nearly always a question related to C#. We had to answer “No, but we will have .Net versions at some time in the future.”. That time has come. We now have .Net versions of Memory Validator and Performance Validator available as beta products.

Users of our popular Memory Validator software tool (for C++, Delphi…) will notice that the UI for .Net is quite different. This is because detecting memory leaks in garbage collected environments requires different approaches to collecting and analysing data. We have some innovative ideas in .Net Memory Validator, including the Allocations view, which provides a breakdown of objects allocated per function name; the Objects view, which provides a breakdown of objects allocated per object type; the Generations view, which provides an easy to read display of how many objects allocated per generation per object type. You can easily spot the trend graph of object usage and determine which objects are climbing or falling. A reference view allows you to view the object heap as a graph. The hotspots, memory, analysis, virtual and diagnostic tabs will be familiar to users of the original Memory Validator for C++.

.Net Memory Validator has the same user interface features you will find on our other Memory Validator products for other garbage collected languages (Java, JavaScript, Python, Ruby, etc) making ease of use when switching languages a doddle. As with all our products the .Net version, although different under the hood has the same team behind it. You are probably familiar with the case of a company creating a software tool for language X and then porting it support language Y, but the language Y version is lacking because it was a ground up rewrite, often by people unfamiliar with the language X version. This leads to incompatiblities, differnt UI behaviour, new bugs. That isn’t how we create our new language versions. Each version has its own code base, which allows for the radical under the hood changes to accomodate each language. But it has the same team and keeps the same user interface elements where applicable. So even if the code under the hood changes you get the same experience regardless of language.

This also allows our bug fixing to be improved. Many bugs from one version of a product apply to our other language versions. Thus if we find and fix a bug in say Java Memory Validator that bug fix can often be applied to JavaScript Memory Validator, Python Memory Validator, Ruby Memory Validator and .Net Memory Validator, etc. And our customers usually get the bug fix the very next day. This development method has been carried into the .Net line of software tools.

.Net Performance Validator continues this trend of the same user interface. If you know how to use any of our Performance Validator products (including the C++ version) you will know how to use .Net Performance Validator. Its that easy.

The callstack view provides a real time insight onto where a particular thread is running. Raw Statistics lets you inspect the raw data collected about performance and Statistics lets you inspect this data in a more orderly fashion. Relations provides the same information but allows you to view which function was called from which function. Call Tree provides the a call tree which you can expand and contract to view the performance data. Call Graph provides this information as a graph with each function listed as infrequently as possible. Call Graph is a very useful way to find an expensive function, then right click, choose goto Call Tree Node and the first node in the call tree that relates to the same node in the Call Graph expands with the node highlighted and source code displayed if available. Analysis allows complex queries onto the data and the diagnostic tab provides information about the instrumentation process.

Cheers for now, we have more .Net tools to work on.

Linux? MacOS X? Not right now, but some time in the future. Where have you read that before?