Riverblade

Blog


Welcome to our blog. We hope that these pages provide an insight into us, our products and how we develop them. Please feel free to write to us if you have anything to add to any of the posts here.

   Current Entries | Archives   RSS

 

Visual Lint 8.0.12.359 adds support for PC-lint Plus 2.0

Wednesday 22nd February, 2023


Visual Lint 8.0.12.359 has now been released. This is a maintenance update for Visual Lint 8.0, and includes the following changes:

Finally, if you are a C++ developer who has not yet tried PC-lint Plus, it is worth noting that Vector Informatik GmbH have a policy of transparent pricing, and that team licences for PC-lint Plus start from just €336 per developer per year, with no minimum team size.

Download Visual Lint 8.0.12.359

Posted by annajayne at 7:00am | Get Permalink

Visual Lint 8.0.11.357 has been released

Wednesday 18th January, 2023


Visual Lint 8.0.11.357 has now been released.

This is a maintenance update for Visual Lint 8.0, and includes the following changes:

Download Visual Lint 8.0.11.357

Posted by annajayne at 9:11pm | Get Permalink

Visual Lint 8.0.10.355 has been released

Friday 16th September, 2022


Visual Lint 8.0.10.355 has now been released.

This is a maintenance update for Visual Lint 8.0, and includes the following changes:

Download Visual Lint 8.0.10.355

Posted by annajayne at 7:58am | Get Permalink

Visual Lint 8.0.9.353 has been released

Wednesday 25th May, 2022


Visual Lint 8.0.9.353 has now been released.

This is a maintenance update for Visual Lint 8.0, and includes the following changes:

Download Visual Lint 8.0.9.353

Posted by annajayne at 7:00am | Get Permalink

EnvDTE::DocumentEvents crash in VS2022 v17.1 Preview 2

Monday 25th April, 2022


Heads-up for anyone writing Visual Studio extensions that it looks like EnvDTE::DocumentEvents::DocumentOpening() has a regression or change in behaviour that can cause a crash freeing a BSTR if you use it in VS2022 v17.1 Preview 2 onwards.

The interface in question is in the legacy automation interface once used by macros/addins and is now marked as "Microsoft internal use only" so I doubt this will affect anyone writing new code. Still, it's noteworthy - esp as the crash can manifest as a hang while opening a solution which makes it look like the IDE installation is corrupt.

Posted by annajayne at 7:45am | Get Permalink

Visual Lint 8.0.8.351 has been released

Monday 14th February, 2022


Visual Lint 8.0.8.351 has now been released.

This is a maintenance update for Visual Lint 8.0, and includes the following changes:

Download Visual Lint 8.0.8.351

Posted by annajayne at 8:00am | Get Permalink

Visual Lint 8.0.7.349 has been released

Monday 3rd January, 2022


Visual Lint 8.0.7.349 has now been released.

This is a maintenance update for Visual Lint 8.0, and includes the following changes:

Download Visual Lint 8.0.7.349

Posted by annajayne at 2:32pm | Get Permalink

Visual Lint and log4j (TL;DR: we don't use it)

Thursday 16th December, 2021


A good question from a customer given a bunch of headlines about security holes in the log4j logging library:

Triggered by the recent log4j vulnerability our organisation is asking all our software vendors if their software is affected by it - and if so by when a patch will be provided. May I ask for your confirmation that Visual Lint is not affected by this exploit?

I suppose that Visual Lint is Java free and thus has no problem with it. Thanks a lot for your answer!

Hopefully our answer will prove reassuring:

Visual Lint is written almost entirely in native C++ (more specifically, it's written in C++ 14). There is only one Java project in the entire codebase - the project which implements the Eclipse plugin (to our knowledge, Eclipse plugins can only be implemented in Java).

However, that project is just a thin Java wrapper around a native DLL - and it doesn't use log4j at all.

So, you're correct. Visual Lint (and indeed all our products and infrastructure) are 100% log4j free.

So your organisation can rest easy in this case.

Posted by annajayne at 8:40pm | Get Permalink

Visual Lint 8.0.6.347 - a Clang download here, a CppCheck download there....

Tuesday 16th November, 2021


Visual Lint 8.0.6.347 has now been released.

The most notable changes in this build relate to configuration - in particular, the user interface now embeds links to the installers for open source analysis tools, which should make configuring Visual Lint much easier:

Configuration Wizard page
The user interface now includes download links for selected open source analysis tools

This change was prompted by the fact that the Clang-Tidy installers are quite hard to find on the LLVM Download page, but is also applicable to (for example) CppCheck.

Visual Lint 8.0.6.347 is a recommended maintenance update for Visual Lint 8.0, and includes the following changes:

Download Visual Lint 8.0.6.347

Posted by annajayne at 11:15am | Get Permalink

Visual Lint 8.0.5.346 adds support for Visual Studio 2022

Thursday 21st October, 2021


Visual Lint 8.0.5.346 has now been released. This a recommended maintenance update for Visual Lint 8.0, and adds support for Visual Studio 2022 Preview:

Visual Lint 8.0.5.346 running within Visual Studio 2022 Preview 5.0
Visual Lint 8.0.5.346 running within Visual Studio 2022 Preview 5.0

The following changes are included:

Download Visual Lint 8.0.5.346

Posted by annajayne at 10:53am | Get Permalink

ResOrg 2.0.10.31 adds support for Visual Studio 2022

Thursday 7th October, 2021


ResOrg 2.0.10.31 has now been released. This a recommended maintenance update for ResOrg 2.0, and adds support for Visual Studio 2022 Preview:

ResOrg 2.0.10.31 running within Visual Studio 2022 Preview 4.1
ResOrg 2.0.10.31 running within Visual Studio 2022 Preview 4.1

The following changes are included in this build:

Download ResOrg 2.0.10.31

Posted by Anna at 11:02am | Get Permalink

The Woes of Windows Smartscreen

Monday 4th October, 2021


Windows Smartscreen is a great idea, but if you develop downloadable software for Windows it can sometimes be incredibly frustrating.

That has certainly been our experience this year, as Windows has displayed the following warning when running every build we have released since we renewed our code signing certificate:

Windows Smartscreen
Eek!

What this warning means is that Smartscreen does not recognise the executable (fair enough, as the chances are we had only just built it when it was downloaded), and does not yet trust the code signing certificate (we know that an EV certificate would help with this, but only at the cost of a loss of flexibility in the build process).

To the end-user (and yes, I include many developers in that) this warning must be offputting, to say the least. The lack of a "Run Anyway" button just compounds that. To see that, you have to click on the "More info" link to reveal it, as well as the name of the executable file and publisher:

Windows Smartscreen
If you click on the "More info" link you will see some useful information and a "Run anyway" button.

The warning usually disappears after a few days as customers download and install the update, but this time it has been different and we have been pulling our hair out over this for months.

More than one build has been submitted to Microsoft for analysis, but we never had any luck until last week, when we received this feedback:

Submission feedback
Success! (for this particular build, at least)

We do not know exactly how the internal logic Microsoft use to trigger Smartscreen warnings has changed in recent months, but we suspect it has in some way.

Coincidentally, at the same time as we submitted this file for analysis we also uploaded the same executable directly to the Visual Studio Marketplace, rather than (as previously) linking to the product page. Maybe that also helped - who knows?

Regardless, it's welcome as it means that Visual Lint 8.0.4.342 no longer triggers the Smartscreen warning, and hopefully as the code signing certificate builds reputation other builds will cease to do so too.

At least, we hope so.

Posted by annajayne at 4:28pm | Get Permalink

Visual Lint 8.0.4.342 has been released

Thursday 23rd September, 2021


Visual Lint 8.0.4.342 has now been released. This a recommended maintenance update for Visual Lint 8.0 and includes the following changes:

Download Visual Lint 8.0.4.342

Posted by Anna at 1:03pm | Get Permalink

Visual Lint 8.0.3.340 has been released

Tuesday 17th August, 2021


Visual Lint 8.0.3.340 has now been released. This a recommended maintenance update for Visual Lint 8.0, and includes the following changes:

Download Visual Lint 8.0.3.340

Posted by Anna at 10:42am | Get Permalink

Visual Studio 2022 Preview 2 and the v143 platform toolset

Wednesday 21st July, 2021


Visual Studio 2022 Preview 2 was released by Microsoft last week.

One of the changes included in Preview 2 is the addition of the Visual Studio 2022 specific v143 platform toolset (Preview 1 used the v142 platform toolset from Visual Studio 2019). Support for the v143 toolset has already been added to Visual Lint 8.0 and will soon become available within both VisualLintConsole and VisualLintGui in Visual Lint 8.0.3.

As part of that change, 8.0.3 will include a PC-lint Plus indirect file for Visual Studio 2022, and the Configuration Wizard and Options Dialog will both offer Visual Studio 2022 projects as an option:

Configuration Wizard with co-rb-vs2022.lnt
The PC-lint Plus indirect file co-rb-vs2022.lnt has been added to to support Visual Studio 2022.

Furthermore, since Preview 1 was released last month we have been gradually plugging away (no pun intended!) in the Visual Lint development branch, adding support for the VS2022 VSSDK COM interfaces along with new x64 build configurations where needed.

It's worth noting that although named identically, the Visual Studio 2022 interfaces differ somewhat from their 32 bit predecessors so a lot of boilerplate changes have been required. However as we (fortunately, it turns out) use an in-house Visual Studio interfacing library to wrap the Visual Studio COM interfaces we use those changes have been largely localised to the support library itself - and that's made things a lot easier than it might otherwise have been.

Once that was done we turned our attention to the Visual Studio plugin project itself, by adding x64 build configurations to it and then gradually working through the code fixing the inevitable compilation and linker errors (mostly by conditionally compiling out 32 bit specific code, such as that relying on the add-in interfaces used with Visual Studio versions prior to Visual Studio 2015).

We finally got a clean build on a dev machine this morning, and then turned our attention to adding a VS2022 VSIX package project, which is necessary to deploy a plugin (or "extension", in Microsoft terminology) to Visual Studio 2022.

A few tweaks, some headscratching and more tweaks later, and just after lunch today Visual Lint not only successfully loaded under debug in a Visual Studio 2022 experimental instance for the first time but also analysed its first project under that environment:

screenshot
A development build of Visual Lint running within Visual Studio 2022 Preview 2.
screenshot
A development build of Visual Lint running within Visual Studio 2022 Preview 2.

Of course getting the plugin running under debug is just the first step - there is still much to do before we can release a public build with a Visual Studio 2022 compatible version of the Visual Studio plugin.

That said, getting to this point is hugely encouraging, so today has definitely been a good day.

Posted by Anna at 4:19pm | Get Permalink

Visual Studio 2022 Preview 1 is now available

Monday 5th July, 2021


Ever since news broke in April of Microsoft's plans for Visual Studio 2022 we have been waiting to get our hands on a preview build of the new version.

The first public preview was finally released on 17th June, so naturally we have spent the past few days taking a look to see what we need to do - both to analyse codebases using it and to update our existing Visual Lint and ResOrg plugins to integrate within it.


From what I can see, Visual Studio 2022 Preview 1 seems to use Visual Studio 2019 project files (the platform toolset is still v142, and _MSC_VER is still 1929). I've no doubt that will change in subsequent preview versions.

However, unlike its predecessor Visual Studio 2019, Visual Studio 2022 is a fully 64 bit development environment (although VS2019 and its predecessors can compile and debug 64 bit projects, the IDEs themselves are firmly 32 bit).

As such it follows that plugins for Visual Studio 2022 must also be compiled as 64 bit. Although the plug-in architecture is not changing in VS2022 (see The Future of Visual Studio Extensions), the move to 64 bit is a very significant change in itself.

For our Visual Studio plugin to run within Visual Studio 2022, what we have to do is basically:

The full details of all of the changes involved are somewhat beyond the scope of this blogpost, but suffice it to say we have already started preparing to port the code to Visual Studio 2022 and expect that to keep us busy over the summer.

(well, it's not as if anyone can really go on holiday right now, is it?)

The screenshots below show Visual Studio 2022 Preview 1 with an AppWizard generated C++ VSIX extension project loaded and running. Note that I had to make a couple of minor corrections to the generated project and property files to get it to compile and link.

VS2022 IDE screenshot
An AppWizard generated VS2022 extension project loaded inside Visual Studio 2022 Preview 1.
VS2022 plug-in project running
An AppWizard generated VS2022 extension project running inside an experimental instance of Visual Studio 2022 Preview 1.

Posted by Anna at 12:49pm | Get Permalink

Visual Lint 8.0.2.338 has been released

Monday 28th June, 2021


Visual Lint 8.0.2.338 has now been released. This a recommended maintenance update for Visual Lint 8.0, and includes the following changes:

Download Visual Lint 8.0.2.338

Posted by Anna at 11:35am | Get Permalink

Visual Lint 8.0.1.337 has been released

Tuesday 20th April, 2021


Visual Lint 8.0.1.337 is a recommended maintenance update for Visual Lint 8.0. The following changes are included:

Download Visual Lint 8.0.1.337

Posted by Anna at 4:35pm | Get Permalink

Visual Lint 8.0 has been released

Saturday 27th March, 2021


The first public build of Visual Lint 8.0 has just been uploaded to our website. As of today, Visual Lint 8.0 replaces Visual Lint 7.0 as the current supported Visual Lint version.

As such Visual Lint 8.0 licences (as well as upgrades for Visual Lint 6.x and 7.x* per user licences) will shortly become are now available in our online store.

* Licences for Visual Lint 1.x through 5.x can be upgraded manually - please contact us for details.

Customers with active Visual Lint 7.x priority support subscriptions should already have received updated licence keys for the new version.

Visual Lint floating and site licence subscription customers have the option of continuing with Visual Lint 7.0 until their next renewal or updating to Visual Lint 8.0.

In addition, all customers who have purchased per-user or per-server Visual Lint licences since 1st January 2021 are also eligible to receive new Visual Lint 8.0 compatible licence keys.

If any of the above applies and you need a licence key compatible with Visual Lint 8.0 please contact us for details, quoting your order number and licence key.

Among the many changes included in Visual Lint 8.0 is the addition of support for Clang-Tidy - an open source C++ analysis tool from the LLVM Project which is notable for its ability to automatically correct many of the issues it finds.

The Clang-Tidy Analysis Configuration Dialog
The Clang-Tidy Analysis Configuration Dialog allows you to configure which Clang-Tidy checks are used.

You can read more about the integration of Clang-Tidy into Visual Lint in the blogpost Clang-Tidying up the house.

The following changes are included in Visual Lint 8.0:

Download Visual Lint 8.0

Posted by Anna at 12:45pm | Get Permalink

Visual Studio crashes when docking windows (TL;DR: it wasn't us)

Monday 22nd February, 2021


We've all done it. You prepare a new build, install it, start testing before releasing it and then...it crashes. The immediate thought is always "What have we done...?".

Exactly that happened to us recently when testing a Visual Lint build - all we did was dock a window and then Visual Studio crashed and restarted.

Oops.

So, what had we done? As it turns out, nothing - the crash was actually caused by a Windows 10 update - and happened irrespective of whether any third party extensions are installed. KB4598301 is reportedly the cause, though others (e.g. KB4598299) also seem to cause the same effects.

The following community post has more details of the bug and possible workarounds:

https://developercommunity.visualstudio.com/content/problem/1323017/unexpected-vs-crash-when-docking-or-splitting-wind.html

We have no doubt that Microsoft will fix this very soon (in Visual Studio 2017 and 2019, at least) so for now we're not too worried, but in the meantime - or if you're using an older version of Visual Studio - the workarounds are to uninstall the update, or edit devenv.exe.config.

If you decide to do the latter, check to see if the if the configuration/runtime/AppContextSwitchOverrides element exists. If it does append the following to its value:

;Switch.System.Windows.Interop.MouseInput.OptOutOfMoveToChromedWindowFix=true;Switch.System.Windows.Interop.MouseInput.DoNotOptOutOfMoveToChromedWindowFix=true

If however the element does not exist (it may not for older versions of Visual Studio), you can just add it:

<AppContextSwitchOverrides value="Switch.System.Windows.Interop.MouseInput.OptOutOfMoveToChromedWindowFix=true;Switch.System.Windows.Interop.MouseInput.DoNotOptOutOfMoveToChromedWindowFix=true" />

Once you restart Visual Studio you should then be good to go.

Posted by Anna at 12:07pm | Get Permalink

Clang-Tidying up the house

Tuesday 19th May, 2020


If there is any single consolation amidst the circumstances we are all having to cope with at the moment it is that many of us have lots of time to fill - not only with unproductive things like binging Netflix (I really should get around to watching Dirk Gently's Holistic Detective Agency...) but also with tasks which might have a more lasting long-term benefit.

A Clang-Tidy analysis of a Visual Studio 2019 skeleton MFC project within VisualLintGui.

Those could be tasks like learning a language (programming or human), joining online yoga classes, writing a book, designing a website, blogging, reading (I can recommend Francis Buontempo's Genetic Algorithms and Machine Learning for Programmers if you fancy learning a little about ML) or generally just getting on with stuff with perhaps fewer distractions than usual.

On the latter note, for the past few months we've been working on the codebase of the next version of Visual Lint in our development branch, and it is coming along quite nicely.

One of the things we have planned to do for some time is to add direct support for the Clang-Tidy analysis tool to Visual Lint. When the UK lockdown started, focusing on this task in particular proved to be a very useful distraction from all the fear and uncertainty we found around us.

Sometimes being in the zone helps in more ways than usual.

The screenshot above should give you an idea of where we are at the moment. Whilst there is still a great deal to do before we can consider this is production-ready the foundation is in place and it is definitely usable. For example, selected issues can already be suppressed from the Analysis Results Display by inserting inline suppression directives ("// NOLINT") using the same context menu command used to suppress (for example) PC-lint, PC-lint Plus and CppCheck analysis issues.

With Microsoft Visual Studio being one of the major development environments we support one of the most important things to address is configuring Clang-Tidy to be tolerant of non-standard Visual C++ projects. The errors shown for some files in the Analysis Status Display in the screenshot above are exactly because of this - a standards compliant C++ compiler is likely to generate at least some errors while compiling most Visual C++ projects.

The only error we saw in the Visual C++ project mentioned above was: clang-diagnostic-error: -- call to non-static member function without an object argument.

The StackOverflow topic Refactor MFC message maps to include fully qualified member function pointers discusses exactly the same issue.

This is mitigated by the fact that recent versions of Clang-Tidy do a pretty good job of handling nonstandard code, so the things that Clang-Tidy warns about seem to be exactly the sort of things you would expect it to and a fair degree of tuning is possible. For example, the clang-diagnostic-error issues in the case above could be disabled entirely if that was what you wanted (as it's a trivial fix you could alternatively choose to correct the code).

Furthermore, with the C++ Core Guidelines checks enabled (e.g. using the --checks=modernize-* switch) Clang-Tidy can tell you exactly what you could do to your C++ code to bring it up to modern standards.

We will obviously be talking more about Clang-Tidy in due course - particularly once we start looking at using it to automatically correct the issues it finds (if you are not aware, this is one of the most compelling features of Clang-Tidy. The good news is that autofixing selected issues should be fairly straightforward using the output of the Clang-Tidy --export-fixes switch.

Lockdowns or eased lockdowns, more interesting times lie ahead.

Posted by Anna at 9:59am | Get Permalink

COVID-19 Lockdown Blues

Wednesday 15th April, 2020


The roof of our office building
A corner of the roof of our office building. Even though the sea is just over 350m away to the left, sadly it's currently off-limits.

2020 is not turning out to be what we expect as - like much of the world - the UK is locked down right now as a result of the COVID-19 pandemic. As such we have been working from home for the past month and only going out for essentials.

That means no ACCU Conference, no free coffee in the office, no impromptu meetings on the beach or on our astroturfed office roof (yes, it does look like that!), no aerial yoga (cue sad face from Anna) but a whole lot of Zoom, configuring VPNs, being thankful for distributed version control systems, kicking off builds remotely and so on.

As far as Riverblade goes, it's rather fortunate that we have been set up for remote working from the outset, so from one point of view the lockdown hasn't come as a big change - although like everyone else we're really missing friends, family...and just simple experiences like going to a cafe at lunchtime or buying an ice cream at the seafront.

Quite frankly it sucks. But you already know all that - and if it saves lives, it is a tiny price to pay. We can only hope that politicians will take heed of the warnings from scientists, nurses, doctors and people who actually know what they are talking about, and that whatever we each endure proves to be enough to stop this virus in its tracks.

Needless to say our thoughts are with everyone touched by this pandemic - but especially with those who have lost loved ones and with anyone working in health and social care.

Be safe, people.

Posted by Anna at 11:54am | Get Permalink

New website and chips, please!

Tuesday 19th March, 2019


Prosecco, fish and chips
HOWTO: celebrate finishing a project.

If you are reading this you might have noticed that the Riverblade website has undergone a bit of a redesign.

This is something we've been working on for a little while in the background, and we think it's probably now at least good enough to let loose on the world. We hope that you find the new responsive website to be an improvement on the old one.

Template aside, the design and implementation was done in-house, so it's entirely our own work and therefore any bug/content fixes should be relatively quick (as an aside, we did contract out a redesign a while back, but we never released it because we weren't happy with the designs the external consultancy produced).

Along with the new design, we've also moved most of the content to a new domain - riverblade.co.

We've tried to make all of the redirects automatic, but needless to say if you discover any broken links, typos etc. please do let us know.

(and in case you are wondering: we have indeed been known to celebrate finishing a project with Prosecco, fish and chips).

Posted by Anna at 3:03pm | Get Permalink

PC-lint Plus and Gimpel's new website

Thursday 25th October, 2018


Gimpel Software (the vendor behind PC-lint and PC-lint Plus) <have recently updated their website, and it is now dedicated entirely to PC-lint Plus. If you are considering upgrading from PC-lint 9.0 to PC-lint Plus, the relevant information is available at PC-lint Plus for PC-lint/FlexeLint users.

The new website also includes an interactive demonstrator for PC-lint Plus, which allows you to try it out on sample C++ 11/14/17 or C89/99/11 code:

Gimpel's PC-lint Plus online demonstrator.

At the moment the demonstrator only includes compiler configurations for Visual Studio 2013 and 2015, but please don't let that put you off as it can work with most compilers including those based on GCC.

Also noteworthy is the following statement:

How long will PC-lint/FlexeLint Version 9 be supported?

PC-lint/FlexeLint Version 9 are no longer being maintained. The final update was Version 9.00L, released in 2014. Technical support will be provided for these products through the end of 2018.

That being the case, we intend to remove PC-lint 9.0 from our online store shortly. Gimpel are selling PC-lint Plus licences directly rather than via resellers, so if you need a quote for a PC-lint Plus licence please contact sales@gimpel.com for details or use the links below.

Useful links:

If you have any queries, please let us know.

Posted by Anna at 11:43am | Get Permalink

LintProject Pro End of Life Notice

Tuesday 23rd October, 2018


LintProject Pro is a command line only product which can perform a basic per-file analysis of a C/C++ codebase using PC-lint or CppCheck. In many ways it was the proof of concept for Visual Lint, and although it has served us well, it's getting a bit long in the tooth now.

For example, unlike Visual Lint Build Server Edition (which has inherited its capabilities), LintProject Pro only makes use of a single CPU core when running analysis and doesn't support current analysis tools such as PC-lint Plus.

The interfaces to the two products are however very similar as the command line interface of Visual Lint Build Server is based on that of LintProject Pro. In fact, Visual Lint Build Server Edition can do everything LintProject Pro can - along with much, much more.

As such we think it is now finally time to put LintProject Pro out to pasture, and to make that easier we are offering a migration path from LintProject Pro to Visual Lint Build Server Edition. This involves trading in each existing LintProject Pro licence purchased before 23rd October 2018 for a 25% discount on a corresponding Visual Lint Build Server Edition licence. As such LintProject Pro has now been removed from our online store.

To take advantage of the upgrade, just write to us quoting which LintProject Pro licence (or licences) you wish to trade-in.

We've tried to keep this process clear and simple. The value of the discount offered exceeds that of the LintProject Pro licence, so this is a lower cost route to obtain an equivalent PC-lint Plus compatible product than (for example) refunding any existing LintProject Pro licences and purchasing Visual Lint Build Server Edition licences at full price.

If you have any questions, just ask.

Posted by Anna at 1:29pm | Get Permalink

ACCU Conference 2018

Friday 27th April, 2018


We had an absolute blast at this year's ACCU Conference and if you were there we imagine you did too.

For us the highlight had to be the launch of #include <C++>, a new global, inclusive, and diverse community for developers interested in C++.

@include_cpp logo
The #include <C++> community logo.

This is an initiative that has been brewing for a while, and one we are very happy to be a part of. Above all else #include <C++> is designed to be a safe place for developers irrespective of their background, ethnicity, gender identity or sexuality. The group runs a Discord server which is moderated to ensure that it remains a safe space and which you are welcome to join.

On the technical front, one unexpected highlight of the conference was Benjamin Missel's wonderful short talk on writing a C compiler for a BBC Micro, during which he demonstrated SSHing into a BBC Model B through the serial port!



Most conference sessions were recorded so even if you weren't there you can still watch them.

See you at ACCU 2019!

Posted by Anna at 12:25pm | Get Permalink

ACCU Conference 2016

Wednesday 8th June, 2016


In late April we exhibited at the ACCU Conference (#accuconf), which in many ways is our conference home. The first time we went was all the way back in 2007, and believe it or not we've not missed a single year since then.

The conference is a great event filled with amazing people, and it's a privilege to have been able to be a part of it for the past decade.

Mouse Invaders
Mouse Invaders.

We normally attend the sessions as delegates and also run an exhibition stand (which makes for some rather hectic juggling!), but this year was a little different as our founder Anna also presented the closing keynote "Comfort Zone" (which she describes as being about "Puppies, Spiders, User Interface Cheese-Moving and the Neuroscience of Anger"....).

As ever, it was an interesting (and quite exhausting) week...but more than that, it was a week when the people who make ACCU what it is stood up and really showed what a truly amazing group of people they are. I'll talk about that specifically in a follow-up post shortly, but suffice it to say that we came away understanding just how lucky we are to have found this particular organisation...

Of course if you went, you'll know all this already. If you didn't, here's a handful of photos to give you an idea what you missed this time...

The Bristol suite at #accuconf
#accuconf keynotes were presented in the Bristol suite of the Marriot.
Pete Goodliffe presenting "The Codealow - a developer's bedtime story"
Pete Goodliffe presenting "The Codealow - a developer's bedtime story" during the Lightning Talks on Wednesday evening.
Don't panic - it's just the conference dinner!
Don't panic - it's just the conference dinner!
"Set the controls for the heart of the pudding"
Set the controls for the heart of the pudding.
Our founder Anna presented the closing keynote
OK. Now would be the time for Anna to panic...
Anna-Jayne Metcalfe from Riverblade presenting the closing keynote "Comfort Zone".
Comfort Zone
Anna-Jayne Metcalfe of Riverblade presenting the ACCU 2016 closing keynote "Comfort Zone"
Comfort Zone
Anna-Jayne Metcalfe of Riverblade presenting the ACCU 2016 closing keynote "Comfort Zone"
Comfort Zone
Anna-Jayne Metcalfe of Riverblade presenting the ACCU 2016 closing keynote "Comfort Zone"
Comfort Zone
Anna-Jayne Metcalfe of Riverblade presenting the ACCU 2016 closing keynote "Comfort Zone"
Comfort Zone
Anna-Jayne Metcalfe of Riverblade presenting the ACCU 2016 closing keynote "Comfort Zone"
Comfort Zone
Anna-Jayne Metcalfe of Riverblade presenting the ACCU 2016 closing keynote "Comfort Zone"

If you'd like to see the keynote, there's a video of it on YouTube and the slides are here.

Posted by Anna at 2:02pm | Get Permalink

PC-lint Plus is coming - and with it, full support for C++ 11 and C++ 14

Monday 14th December, 2015


Gimpel have just announced a beta of PC-lint Plus - a new product which will sit alongside PC-lint. To understand the (rather complex, I'm afraid) background and the background to why a beta of PC-lint Plus has been announced rather than one for the long awaited 9.00m patch, please keep reading...

It is no secret that PC-lint 9.0 struggles with some C++ 11/14 code - and especially any code making use of C++ 11 variadic templates. The result is errors - and nasty, hard to work around ones at that.

Under Windows, this is particularly noticeable when analysing projects written for Visual Studio 2013 and 2015, which both use variadic templates in their system headers (Visual Studio 2012 and earlier did not).

A glance at the PC-lint 9.0 C++ 11 support page on the Gimpel website illustrates this rather well, with the following C++ 11 features shown as not yet being supported as of PC-lint 9.00L:

That's just of course from C++ 11, and with C++ 14 also out and C++ 17 (which like C++ 11 promises major changes to the language) is just around the corner, keeping up has been getting more and more difficult. As Jim Gimpel said to us recently:

Unfortunately, keeping up with the evolving C++ standards which seemed to know no bounds, became more and more difficult as Gimpel Software did have bounds.

It is worth remembering that PC-lint was first introduced in 1985, so presumably the C++ front end in 9.00L is a direct descendent of that in the original product rather than one of the standard C++ front ends (EDG, Clang, GCC etc.) our industry has effectively settled upon since. As a result, every change in the language no doubt requires comparable changes in the PC-lint front end. Given how much C++ has evolved recently (and continues to evolve, looking forward to C++ 17 and beyond), that's potentially a huge ongoing task.

Like many others, for some time we have been asking Gimpel for an estimate of roughly when an update addressing the remaining C++ 11 issues were realistically likely to become available. Although throughout last year we thought that support for variadic templates issue (the missing feature which seemed to be catching most people out) would be resolved with 9.00L in the Autumn sadly it was not to be, and by the start of this year it became obvious to us that we would have to put into place a workaround to allow customers to analyse Visual Studio 2013 and 2015 projects. Hence the system headers compatibility thunk described in the blogpost Visual Studio 2013, PC-lint and C++ 11 Variadic Templates which became available in Visual Lint 4.5.9.239 onwards.

Around the same time, Gimpel also updated us on their future plans, and how they intended to offer complete C++ 11/14 support. Although we couldn't talk about that publicly at the time, now that they have announced the beta we are free to do so.

The bottom line is that rather than continue to try to keep the existing PC-lint front end up to date with changes in the C++ Standard, Gimpel have decided to develop a spin-off product using the industry standard Clang front-end. The existing PC-lint 9.0 and Flexelint 9.0 products will continue to be supported for the foreseeable future.

This is of course a major development, and in consequence is one that couldn't have been released as a PC-lint 9.0 patch anyway. As the Clang source requires a modern C++ compiler to compile it, this makes distributing PC-lint Plus as obfuscated source (as Flexelint currently is) impractical as many compilers for non-x86 platforms would not be able to compile it.

The move to Clang also means that in future PC-lint Plus will be able to keep up with changes in the C++ standard as fast as new versions of Clang can be integrated. So, if (for example) the C++ Module System proposals (N4465/N4466) (which allow imports of compiled units to replace #includes of header files, thus drastically reducing build times) make it into C++ 17, PC-lint will be able to keep up without another major hiatus.

For Windows, both 32 bit (pclp32.exe) and 64 bit (pclp64.exe) binaries will be provided along with full support for C++ 11/14, Visual Studio 2013 and 2015. For Linux, a pre-built x86 binary will be available which should simplify things for developers on that platform (and potentially allow the pricing of the Linux version of PC-lint to become more competitive with the Windows variant). For non-x86 platforms etc., Flexelint will continue to be available in its current form.

The new product supports a considerable number of new messages (far too many to list!). In addition, obsolete options such as +linebuf and +macros have been removed.

As far as our own products are concerned, Visual Lint 5.0.6.254 onwards are aware of PC-lint Plus (we've actually been testing with alpha builds since the summer) and should work with beta versions. Support for 64 bit builds of PC-lint will become available in the New Year, and now that the beta has been announced we will be adding documentation for the new messages to the message database installed with the product as information becomes available.

Overall this is a huge step forward, but we are aware that it may come as a shock to many who were expecting PC-lint 9.00m. As soon as we know the details of Gimpel's PC-lint 9.0 to PC-lint Plus upgrade policy rest assured we will be talking about it. In the meantime, please do join the beta programme and help test it!

Gimpel's beta announcement can be found in their blogpost Upcoming Support for C++14/VS2015.

Posted by Anna at 11:24am | Get Permalink

Visual Studio 2013, PC-lint and C++ 11 Variadic Templates

Monday 23rd February, 2015


Although we added support for Visual Studio 2013 some time ago, PC-lint has lagged behind somewhat and even now (well over a year after it was released) has difficulty analysing any projects for it which use the Standard Template Library (STL) to any significant extent.

In large part this is due to the fact that PC-lint has to date lacked support for C++ 11 variadic templates (which are heavily used in parts of the Visual Studio 2013 system headers). With PC-lint 9.00L (the current patch level) even a simple #include <map> will trigger an internal error (9.00k was less vocal, but still raised errors you had to suppress).

Although this was not a huge problem when Visual Studio 2013 first came out (most development teams take their time moving to new versions of Visual Studio), it is now sufficiently mature that many teams are moving to it, and that's potentially a big problem if you also use PC-lint. The arrival of the free Visual Studio Community Edition has of course accelerated this trend.

Although we were expecting this to have been fixed by Gimpel around the middle of last year they apparently found that doing so proved to be far trickier than anticipated, with the end result that this limitation has become an increasingly large problem. The latest information we have is that there will be a beta with full support for variadic templates available sometime in March, so at least there is now some light at the end of this particular tunnel.

However, that does probably mean that there won't be a complete "production" fix for at least a couple of months after that. Hence we have been looking at potential workarounds (with one of our customers who is in the process of moving their codebase to Visual Studio 2013 and has run into this issue) to see what we can do in the meantime.

The most promising approach we have identified so far is actually very simple - just substitute the system headers for an earlier version of Visual Studio while analysing Visual Studio 2013 projects by modifying the -i directives for the system headers, while leaving the rest of the analysis configuration unchanged. The major caveat is of course that you need to have an earlier version of Visual Studio co-installed, but in practice that's pretty common.

The second caveat is that you may run into problems if you are using STL functionality (e.g. std::make_unique) which is implemented in the Visual Studio 2013 system headers but absent from earlier versions. Even then, there are workarounds in some cases - it really depends on what you use in your projects. It also goes without saying that the workaround can't handle any code you write in your own projects which uses variadic templates directly.

Given all that however it does seem to work rather well (it even seems to make it practical to analyse Visual Studio 2013 projects with PC-lint 8.0, which is an unexpected bonus!) and as a result we've decided to build this into Visual Lint so that it can take care of it automatically (but optionally, of course) for you when it determines that you are using PC-lint 9.00L or earlier. For now we've limited it to using the system headers from a Visual Studio 2012 or 2010 installation on the same machine, but we can extend that if needed.

This functionality should be out as part of Visual Lint 4.5.9.239 soon, but we are happy to release preliminary builds on a case by case basis if it will help other teams who are running into the same problem. Likewise if you have any questions about the specifics of this approach or are running into this issue (not necessarily just with Visual Studio) just let us know and we will be happy to help.

Update: Visual Lint 4.5.9.239 was released on 6th March 2015.

Posted by Anna at 6:19pm | Get Permalink

How Visual Lint parses projects and makefiles

Thursday 6th November, 2014


Code analysis tools can require a lot of configuration to be useful. Whilst some (e.g. Vera++ or cpplint) need very little configuration to make use of effectively, others such as PC-lint (and even, to a lesser extent, CppCheck) may need to be fed pretty much the same configuration as the compiler itself to be useful. As a result the command lines you need to use with some analysis tools are pretty complex in practice (which is of course a disincentive to using them, and so where Visual Lint comes in. But I digress...).

In fact, more capable code analysis tools may need to be given even more information than the compiler itself to generate meaningful results - for example they may need to be configured with the built-in preprocessor settings of the compiler itself. In a PC-lint analysis configuration, this is part of the job compiler indirect files such as co-msc110.lnt do.

As a result of the above, a product such as Visual Lint which effectively acts as a "front end" to complex (and almost infinitely configurable) code analysis tools like PC-lint needs to care about the details of how your compiler actually sees your code every bit as much as the analysis tool itself does.

What this means in practice is that Visual Lint needs be able to determine the properties of each project it sees and understand how they are affected by the properties of project platforms, configurations and whatever compiler(s) a project uses. When it generates an analysis command line, it may need to reflect those properties so that the analysis tool sees the details of the preprocessor symbols, include folders etc. each file in the project would normally be compiled with - including not only the properties exposed in the corresponding project or makefile, but also built-in symbols etc. normally provided by the corresponding compiler.

That's a lot of data to get right, and inevitably sometimes there will be edge cases where don't quite get it right the first time. It goes without saying that if you find one of those edge cases - please tell us!

So, background waffle over - in this post I'm going to talk about one of the things Visual Lint does - parsing project files to identify (among other things) the preprocessor symbols and include folders for each file in order to be able to reflect this information in the analysis tool configuration.

When analysing with CppCheck, preprocessor and include folder data read in this way can be included on the generated command line as -D and -I directives. Although we could do the same with PC-lint, it is generally better to write the preprocessor and include folder configuration to an indirect ("project.lnt") file which also includes details of which implementation (.c, .cpp, .cxx etc.) files are included in the project -as well as any other project specific options. For example:

// Generated by Visual Lint 4.5.6.233 from file: SourceVersioner_vs90.vcproj
// -dConfiguration=Release|Win32
//
-si4 -sp4                     // Platform = "Win32"
                              //
+ffb                          // ForceConformanceInForLoopScope = "TRUE"
-D_UNICODE;UNICODE            // CharacterSet = "1"
-DWIN32;NDEBUG;_CONSOLE       // PreprocessorDefinitions = "WIN32;NDEBUG;_CONSOLE"
-D_CPPRTTI                    // RuntimeTypeInfo = "TRUE"
-D_MT                         // RuntimeLibrary = "0"
                              //
                              // AdditionalIncludeDirectories = ..\Include"
-save -e686                   //
  -i"..\Include"              //
-restore                      //
                              //
                              // SystemIncludeDirectories = "
                              //   F:\Projects\Libraries\boost\boost_1_55_0;
                              //   C:\Program Files (x86)\
                              //       Microsoft Visual Studio 9.0\VC\include;
                              //   C:\Program Files (x86)\
                              //       Microsoft Visual Studio 9.0\VC\atlmfc\include;
                              //   C:\Program Files\
                              //       Microsoft SDKs\Windows\v6.0A\include;
                              //   F:\Projects\Libraries\Wtl\8.1\Include"
                              //
-save -e686                   //
 +libdir(F:\Projects\Libraries\boost\boost_1_55_0)
 +libdir("C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include")
 +libdir("C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\atlmfc\include")
 +libdir("C:\Program Files\Microsoft SDKs\Windows\v6.0A\include")
 +libdir("C:\Program Files\Microsoft SDKs\Windows\v6.0A\include")
 +libdir(F:\Projects\Libraries\Wtl\8.1\Include)
 -iF:\Projects\Libraries\boost\boost_1_55_0
 -i"C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include"
 -i"C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\atlmfc\include"
 -i"C:\Program Files\Microsoft SDKs\Windows\v6.0A\include"
 -iF:\Projects\Libraries\Wtl\8.1\Include
-restore                      //
                              //
SourceVersioner.cpp           // RelativePath = "SourceVersioner.cpp"
SourceVersionerImpl.cpp       // RelativePath = "SourceVersionerImpl.cpp"
stdafx.cpp                    // RelativePath = "stdafx.cpp"
Shared\FileUtils.cpp          // RelativePath = "Shared\FileUtils.cpp"
Shared\FileVersioner.cpp      // RelativePath = "Shared\FileVersioner.cpp"
Shared\PathUtils.cpp          // RelativePath = "Shared\PathUtils.cpp"
Shared\ProjectConfiguration.cpp
                              // RelativePath = "Shared\ProjectConfiguration.cpp"
Shared\ProjectFileReader.cpp  // RelativePath = "Shared\ProjectFileReader.cpp"
Shared\SolutionFileReader.cpp // RelativePath = "Shared\SolutionFileReader.cpp"
Shared\SplitPath.cpp          // RelativePath = "Shared\SplitPath.cpp"
Shared\StringUtils.cpp        // RelativePath = "Shared\StringUtils.cpp"
Shared\XmlUtils.cpp           // RelativePath = "Shared\XmlUtils.cpp"

 

A file like this is written for every project configuration we analyse, but the mechanism used to actually read the configuration data from projects varies slightly depending on the project type and structure.

In the case of the Visual Studio 2002, 2003, 2005 and 2008 .vcproj files Visual Lint was originally designed to work with, this is straightforward as the project file contains virtually all of the information needed in a simple to read, declarative form. Hence to parse a .vcproj file we simply load its contents into an XML DOM object and query the properties in a straightforward manner. Built-in preprocessor symbols such as _CPPUNWIND are defined by reading the corresponding properties (EnableExceptions in the case above) or inferred from the active platform etc.

Similarly, for Visual C++ 6.0 and eMbedded Visual C++ 4.0 project files we just parse the compiler command lines in the .dsp or .vcp file directly. This is pretty straightforward as well as although .dsp and .vcp files are really makefiles they have a very predictable structure. Some other development environments (e.g. Green Hills MULTI or CodeVisionAVR) have bespoke project file formats which are generally easy to parse using conventional techniques.

Visual Studio 2010, 2012 and 2013 .vcxproj project files are far more tricky, as the MSBuild XML format they use is effectively a scripting language rather than a declarative format. To load them, we effectively have to execute them (but obviously without running the commands they contain).

As you can imagine this is rather tricky! We basically had to write a complete MSBuild parsing engine* for this task, which effectively executes the MSBuild script in memory with defined parameters to identifiy its detailed properties.

* Although there are MSBuild APIs which could conceivably help, there are implemented in managed code - which we can't use in a plug-in environment due to .NET framework versioning restrictions. Instead, our MSBuild parsing engine is written natively in C++.

To work out the parameters to apply to the MSBuild script, we prescan the contents of the .vcxproj file to identify the configurations and platforms available. Once we have those, we can run the script in memory and inspect the properties it generates for the required build configuration. This process is also used with CodeGear C+ and Atmel Studio projects, both of which are MSBuild based.

Eclipse projects (.project and .cproject files) are also XML based and are not too difficult to parse, but whereas it is straightforward to work out how things are defined in a .vcproj file, Eclipse project files are much less clearly defined and more variable (not surprising as they effectively represent serialised Java object data).

To make matters worse, each compiler toolchain can have its own sub-format, so things can change in very subtle ways between based projects for different Eclipse based environments such as Eclipse/CDT, QNX Momentics and CodeWarrior. In addition, Eclipse C/C++ projects come in two flavours - managed builder and makefile.

Of the two, managed builder projects are easy to deal with - for example to determine the built-in settings of the compiler in a managed builder we read the scanner (*.sc) file produced by the IDE when it builds the project, and add that data to the configuration data we have been able to read from the project file.

The scanner (.sc) file is a simple XML file located within the Eclipse workspace .metadata folder. Here's an extract to give you an idea what it looks like:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<?scdStore version="2"?>
<scannerInfo id="org.eclipse.cdt.make.core.discoveredScannerInfo">
<instance id="cdt.managedbuild.config.gnu.mingw.exe.debug.116390618;
  cdt.managedbuild.config.gnu.mingw.exe.debug.116390618.;
  cdt.managedbuild.tool.gnu.cpp.compiler.mingw.exe.debug.1888704458;
  cdt.managedbuild.tool.gnu.cpp.compiler.input.391761176">
<collector id="org.eclipse.cdt.make.core.PerProjectSICollector">
<includePath path="c:\mingw\bin\../lib/gcc/mingw32/4.5.2/include/c++"/>
<includePath path="c:\mingw\bin\../lib/gcc/mingw32/4.5.2/include/c++/mingw32"/>
<includePath path="c:\mingw\bin\../lib/gcc/mingw32/4.5.2/include/c++/backward"/>
<includePath path="c:\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include"/>
<includePath path="c:\mingw\bin\../lib/gcc/mingw32/4.5.2/include"/>
<includePath path="c:\mingw\bin\../lib/gcc/mingw32/4.5.2/include-fixed"/>
<definedSymbol symbol="__STDC__=1"/>
<definedSymbol symbol="__cplusplus=1"/>
<definedSymbol symbol="__STDC_HOSTED__=1"/>
<definedSymbol symbol="__GNUC__=4"/>
<definedSymbol symbol="__GNUC_MINOR__=5"/>
<definedSymbol symbol="__GNUC_PATCHLEVEL__=2"/>
<definedSymbol symbol="__GNUG__=4"/>
<definedSymbol symbol="__SIZE_TYPE__=unsigned int"/>
    .
    .
    .
</collector>
</instance>
</scannerInfo>

Unfortunately scanner files are not generated for makefile projects, and the enclosing project files do not give details of the preprocessor symbols and include folders needed to analyse them. So how do we do it?

The answer is similar to the way we load MSBuild projects - by running the makefile without executing the commands within. In this case however the make tools themselves can (fortunately!) lend a hand, as both NMake and GNU Make have an option which runs the makefile and echoes the commands which would be executed without actually running them. For NMake this is /n and GNU Make -n or --just-print.

The /B (NMake) -B (GNU Make) switch can also be used to ensure that all targets are executed regardless of the build status of the project (otherwise we wouldn't be able to read anything if the project build was up to date).

If we run a makefile with these switches and capture the output we can then parse the compiler command lines themselves and extract preprocessor symbols etc. from it. As so many compilers have similar command line switches for things like preprocessor symbols and include folders this is generally a pretty straightforward matter. Many variants of GCC also have command line options which can report details of built-in preprocessor symbols and system include folders, which we can obviously make use of - so the fact that many embedded C/C++ compilers today are based on GCC is very useful indeed.

There's a lot of detail I've not covered here, but I hope you get the general idea. It follows from the above that adding support for new project file types to Visual Lint is generally not difficult - provided we have access to representative project files and (preferably) a test installation of the IDE in question. If there is a project file type you would like us to look at, please tell us.

Posted by Anna at 12:32pm | Get Permalink

Business of Software Conference Europe

Wednesday 2nd July, 2014


Kathy Sierra speaking at Business of Software Europe
Kathy Sierra on 'Motivation Matters' at Business of Software Europe.

Last week our founder Anna attended the Business of Software Europe conference in Cambridge, and it was quite something indeed.

Although the Business of Software Conference has been running for several years in the USA, this is the first year an event has been held in Europe (and what better a place than Cambridge?). The conference covered everything from live Python telephony to the psychology of the internet and the organisation and management of sales teams, so it was pretty diverse.

If you are interested in more than just coding, this is an event we can strongly recommend. Photos and videos from the conference should be online soon, so if you are interested please stay tuned.

Posted by Anna at 10:34am | Get Permalink

Visual Lint and Windows Driver Kit (WDK) projects

Tuesday 2nd April, 2013


We have recently been working with Don Burn on PC-lint analysis of Windows Driver Kit (WDK) projects, and he has written an interesting article on the subject titled "Another Look at Lint" in the March-April 2013 issue of the NT Insider.

Within the article you will find the following rather complementary passage:

Finally the ultimate tool for using PC-lint with the WDK is Riverblade's Visual Lint. This is a third party tool providing an integrated package that works inside VS2012. The tool is an add-on to PC-lint which you must still purchase. The capabilities include background analysis of the project, coded display listings that - like Visual Studio - clicking on the error takes you to the line to edit and provides easy lookup of the description of the errors. The latest version of Visual Lint (4.0.2.198) is required for use with the WDK. The tool has a minor bug that if there are two subprojects with the same name, such as filter in the Toaster sample, one needs to be renamed for analysis to work. A fix is in the works.

To use Visual Lint with the WDK choose LintLdx.lnt as the standard lint configuration file for the tool. There is a 30-day free trial of Visual Lint available so if you are considering PC-lint, take a look at what Visual Lint can add to the experience. I expect to be using it for much of my work.

Our thanks to Don Burn for his patience while we worked through the issues raised by the analysis of WDK projects. As a postscript, a fix for the bug he refers to above has already been checked in and should become available in the next public Visual Lint build (most likely 4.0.3.200).

Posted by Anna at 4:29pm | Get Permalink

Visual Studio 2012 theme support

Thursday 2nd August, 2012


One of the unexpected (and I would suggest from the comments, unwelcome) changes sprung on developers in the Visual Studio 2012 Beta back in February was the "Metroification" of the development environment.

However, eye candy (and eyesores!) come and go, and within that change is a more fundamental one - direct support for themes within the Visual Studio IDE. The Visual Studio 2012 Beta and RC include two themes - light (i.e. grey) and dark. Whilst the latter has an obvious appeal within the developer community (we all know devs who prefer green text on a black background) the former hasn't exactly been welcomed, to say the least.

Personally, rather than develop custom theme support for each tool individually I wish they'd just add a "dark" theme to Windows instead and respect the theme settings of the operating system. Obviously my view just isn't "cool" enough for the Visual Studio UX team, but I digress...

Although a campaign to retain the existing Visual Studio 2010 theme has been running on the UserVoice site since the beta arrived (see the UserVoice posts Add some color to Visual Studio 11 and Leave VS 2010 theme (and the theme editor extension) as an option) Microsoft have not indicated what - if any - changes will be made to the Visual Studio 2012 themes at RTM.

Our working assumption therefore has to be that the themes in the RTM will be broadly comparable with those in the RC (i.e. light and dark). We will find out whether that assumption is correct later this month, of course.

With that in mind, we have been working on theme support in the development branch for Visual Lint for some time now, and things are now beginning to come together:

Visual Lint running with the Visual Studio 2012 RC dark theme.
Visual Lint running with the Visual Studio 2012 RC dark theme.
Visual Lint running with the Visual Studio 2012 RC light theme.
Visual Lint running with the Visual Studio 2012 RC light theme.

As Visual Lint uses standard Win32 controls for most of the UI (which for the most part do not support custom text/background colours), to get this far we have had to write custom painted WTL checkbox, radio button, combobox and header controls in addition to the usual WM_CTLCOLORxxxx voodoo. Other UI elements such as menus, scrollbars, command buttons etc. yet haven't yet been looked at, but hopefully will be in due course (there seems to be some indication in the MSDN blogs that scollbars will be auto-themed by the RTM, but we'll see).

Within the displays themselves, the text and background colours of each item are checked for adequate contrast, and the text colour adjusted (by tweaking the luminance) automatically if need be.

Although the Visual Studio interfaces expose the colours used in the active theme (via IVsUIShell2::GetVSSysColorEx()), they do not seem to provide any way of detecting if the theme has changed (or indeed, finding out which theme is actually running at the time). Our workaround for this is simply to reload the colour scheme whenever the "Tools|Options" command has been executed. We don't really care which theme is running after all - just what colour values it uses, and where.

Indeed, one of the first things we did while working on this was to dump all of the colour values used by the Visual Studio 2012 RC light & dark themes, as well as the default Visual Studio 2010 theme, into spreadsheets so we could use them for testing without firing up a host instance of the IDE (developing add-ins may be fun, but it is also much slower than working on your own executable).

Finally, it is a little known fact that the Visual Studio IDE has had colour scheme support internally for some time, so the scheme we have designed will also work with Visual Studio 2010 if you have the theme editor extension installed:

Visual Lint running with Visual Studio 2010 with a modified "Expression" theme.
Visual Lint running with Visual Studio 2010 with a modified "Expression" theme.

Needless to say, all of this is proving to be a major task, and it has therefore diverted significant resources from other things we should really have been working on this summer. As a consolation, the theme code we're developing is generic (albeit only on Windows), so can also be used with Eclipse 4.0 (I note that themes are coming to that IDE as well when the time comes.

Another obvious benefit is of course that there's potentially at least one new CodeProject article (want a themed XP button with a custom background colour? We know how to do it now) in all of this once the dust settles and the inevitable bugs have crawled away. It's about time I wrote a new one, anyway.

Once Visual Lint theme support is complete, we'll obviously also take a look at ResOrg. Beyond that, I think a new article is a foregone conclusion, once we've cleaned the code up a bit and built a good enough demo project.

Posted by Anna at 12:45pm | Get Permalink

Introducing VisualLintGui

Friday 20th April, 2012


If you have been following me (@annajayne) on Twitter, you may have noticed me talking about something called "VisualLintGui".

This is actually the second of two projects (the first being VisualLintConsole - the command line version of Visual Lint) we got underway after the release of Visual Lint 3.0.

Now that VisualLintConsole (the command line version of Visual Lint) is out in the wild, we have turned our attention to VisualLintGui. This is, as the name suggests, a standalone Visual Lint application with a graphical user interface - basically a text editor focused on code analysis:

VisualLintGui - the standalone Visual Lint application
VisualLintGui - the standalone Visual Lint application.

Although it has been fully functional in terms of analysis functions for quite some time, until recently we were not able to devote a great deal of time to the details of its user interface. That has now changed, and since February VisualLintGui has gained many essential capabilities including a syntax colouring editor with analysis issue markers, MDI tabs, Find/Replace and Source/Header flip to name but a handful of the more obvious recent changes.

VisualLintGui is currently capable of analysing projects for Visual Studio, Visual C++, Eclipse, CodeGear C++ and AVR Studio 5.0, but it can obviously potentially analyse a far wider variety of codebases than that.

Indeed, one of the reasons we have been keen to develop it is to provide a way to support embedded IDEs for which developing a Visual Lint plug-in is not a viable proposition. As such we expect to add support for further project and workspace file formats as and when our customers need them.

VisualLintGui currently resides in our Visual Lint development branch, but given the recent pace of development on it we are likely to look at porting it back into Visual Lint 3.5 in the not too distant future.

In the meantime we will have a development build on our stand at the ACCU Conference next week, so if you are going please do come and take a look.

Posted by Anna at 3:23pm | Get Permalink

ResOrg 2.0 has been released

Sunday 22nd January, 2012


It's done. After a rather extended incubation period ResOrg 2.0.0.15 (the first public ResOrg 2.0 build) was uploaded earlier this morning, and the ResOrg product pages updated to match.

If you have used ResOrg 1.x before, you will notice that the user interface of ResOrg 2.0 is subtly different from its predecessor - notably in the Visual Studio plug-in (which now of course supports Visual Studio 2008 and 2010...).

In particular, the old (and rather limited) "ResOrg.NET Explorer" toolwindow has been replaced by a much more useful "Symbol Files Display" which is also available in the standalone application.

If you are using Visual Studio 2010, it might interest you to know that ResOrg 2.0 can automatically update Ribbon Designer (.mfcribbon-ms) files when an ID referenced in a ribbon resource is renumbered.

I won't include any screenshots in this post as a couple of good ones were included in the previous post, however if you are reading this post in your RSS reader you can find them in the blogpost ResOrg 2.0 update.

Posted by Anna at 11:24am | Get Permalink

Visual Lint and Atmel AVR Studio 5

Friday 16th September, 2011


From our perspective one of the more intriguing embedded environments to appear recently is Atmel's AVR Studio 5.

When I first saw a screenshot of this IDE (it was mentioned in a post in the CodeProject Lounge) it was immediately obvious that this was some sort of Visual Studio derivative.

In fact, although it uses GCC toolchains, the environment is based on the Visual Studio 2010 isolated shell (which incidentally is something we briefly considered using ourselves for a future standalone GUI version of Visual Lint, but decided against because of its complexity and the size of the download).

It obviously occurred to us then that as a Visual Studio derivative, it shouldn't be too difficult to get Visual Lint running within it. The first step was obviously to install the IDE in a VM (XP SP3 - doesn't XP look a bit old these days...?) and experiment with some projects.

AVR Studio 5 codebases uses the Visual Studio 2010 solution file format (albeit rebadged as a .avrsln file) and a new MSBuild based project file format (.avrgccproj), so the first thing we obviously had to do was implement parsers for these files (something that will also benefit LintProject Pro, of course). Once that was done, we turned our attention to getting Visual Lint to load within the IDE itself.

This turned out to be fairly straightforward. Although AVR Studio 5 does not seem to support COM add-in registration in HKEY_LOCAL_MACHINE (which is how the Visual Lint add-in registers in Visual Studio), the corresponding registration in HKEY_CURRENT_USER\Software\Atmel\AVRStudio\5.0\AddIns does work. Although this is problematical from an installation point of view (see my previous post on the Visual Studio 11 Developer Preview) it is not a showstopper by any means.

With manual add-in registration in place, Visual Lint loaded within the IDE. Although a few minor tweaks were needed to work around issues such as AVR reporting itself as "Visual Studio Express Edition, version 1.0" (which caused the version detection code in Visual Lint to default to 16 colour command bitmaps!) those were easily addressed.

As a result, we now have AVR Studio 5 running with a development build of Visual Lint:

Visual Lint running within AVR Studio 5: Visual Lint Status View.
Visual Lint running within AVR Studio 5: Analysis Status and Results Displays.

Although we still have quite a bit to do (not least the code editor markers and installer) before AVR Studio 5 can become a supported host environment for Visual Lint this is a very promising start. Needless to say, beta testers are welcome.

Posted by Anna at 4:17pm | Get Permalink