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.
Visual Lint 8.0.13.364 has now been released
Sunday 13th August, 2023
Visual Lint 8.0.13.364 has now been released.
This is a maintenance update for Visual Lint 8.0, and includes the following changes:
-
When a Visual Studio 2017/2019/2022 project configuration using the
/external:I
switch is loaded, the specified folder will now be added to the include folders in the generated analysis configuration. -
If Visual Lint fails to read the version of the active analysis tool its folder path (if configured) will now be displayed instead.
-
Improved VisualLintConsole command line validation.
-
Added a new
/reportfolder
command line switch to the VisualLintConsole command line. This switch replaces the"output folder"
positional option, which has now been deprecated. -
Improved the way the Configuration Wizard searches for a PC-lint Plus 2.0 installation folder.
-
Fixed a bug in the handling of system include folders which affected Visual Studio 2022.
-
Fixed a bug which caused duplication between the contents of the additional include and system include directories properties for Visual Studio 2019/2022 makefile projects.
-
Backward relative paths can again now be generated when saving
.vlconfig
files. This change (which was made at customer request) reverts one made in Visual Lint 8.0.2.338. -
Updated the PC-lint Plus compiler indirect file
co-rb-vs2022.lnt
to support Visual Studio 2022 v17.7.0. -
Updated the PC-lint Plus compiler indirect file
co-rb-vs2019.lnt
to support Visual Studio 2019 v16.11.29. -
Updated the PC-lint Plus compiler indirect file
co-rb-vs2017.lnt
to support Visual Studio 2017 v15.9.56.
Download Visual Lint 8.0.13.364
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:
-
Added support for
$([MSBuild]::GetDirectoryNameOfFileAbove())
,$([MSBuild]::GetPathOfFileAbove())
,$([System.IO.Path]::Combine())
and$(MSBuildToolsVersion)
to the Visual Studio 2010-2022 project (.vcxproj
) file parser. Together, these allow Visual Lint to correctly loadDirectory.Build.props
property files located in the solution file folder. -
Updated the PC-lint Plus compiler indirect files
co-rb-vs2017-shared.h
,co-rb-vs2019-shared.h
andco-rb-vs2022-shared.h
to check if_MSVC_LANG
is defined before checking its value. -
Added support for PC-lint Plus 2.0:
-
Visual Lint is now compatible with PC-lint Plus installations containing
pclp64.exe
but notpclp32.exe
. This change is necessary to support PC-lint Plus 2.0, which does not includepclp32.exe
. -
Dedicated support files for PC-lint Plus 2.0 are now installed into the
C:\Program Files (x86)\Riverblade\Visual Lint\Tools\PC-lint Plus\2.x
folder. -
Updated the PC-lint Plus Visual Studio 2022 compiler indirect file
co-rb-vs2022.lnt
to enable C++ 20 support. -
Added a PC-lint Plus 2.x message database.
-
Updated the user interface and online help to reflect the fact that PC-lint Plus is now a product of Vector Informatik GmbH, following their acquisition of the assets of Gimpel Software LLC.
-
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
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:
-
Fixed an MSBuild parsing issue which affected the definitions of the vcpkg project variables
$(_ZVcpkgRoot)
,$(_ZVcpkgManifestRoot)
and$(_ZVcpkgInstalledDir)
. -
Added support for Codegear C++ Builder 11.2 project files.
-
Updated the PC-lint Plus compiler indirect files
co-rb-vs2022/19/17.lnt
to prevent a warning (553 - "undefined preprocessor variable, assumed 0") being issued for the Visual C++ built-in compiler symbol_MSVC_LANG
in some circumstances. -
Updated the PC-lint Plus compiler indirect file
co-rb-vs2022.lnt
to support Visual Studio 2022 v17.4.3. -
Updated the PC-lint Plus compiler indirect file
co-rb-vs2019.lnt
to support Visual Studio 2019 v16.11.22. -
Updated the PC-lint Plus compiler indirect file
co-rb-vs2017.lnt
to support Visual Studio 2017 v15.9.51.
Download Visual Lint 8.0.11.357
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:
-
The VisualLintConsole command line parser now accepts spaces between the name and value of a command line switch. As a result, switches of the form.
/switchname = <value>
are now accepted, whereas previously only/switchname=<value>
would work. -
Entries in the file list within manually created custom project (
.vlproj
) files can now use wildcards. Note however that if the project file is subsequently edited by VisualLintGui, the file list will be expanded to explicitly reflect the files actually found. As such, this feature is intended for use with hand-created.vlproj
files (which are really just.ini
files, and as such lend themselves nicely to hand-editing). -
Fixed a bug opening analysis tool manual PDFs located on UNC drives.
-
Fixed a bug in VisualLintGui which could cause some file save operations to fail.
-
Updated the PC-lint Plus compiler indirect file
co-rb-vs2022.lnt
to support Visual Studio 2022 v17.2.6. -
Updated the PC-lint Plus compiler indirect file
co-rb-vs2019.lnt
to support Visual Studio 2019 v16.11.17. -
Updated the PC-lint Plus Boost library indirect file
lib-rb-boost.lnt
. -
Removed nonfunctional "Print" menu commands from VisualLintGui.
-
Updates to various help topics.
Download Visual Lint 8.0.10.355
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:
-
Added support for Codegear C++ Builder 11 Alexandria.
-
Fixed a crash in the Visual Studio plugin when a file was opened in Visual Studio 2022 v17.2.0 Preview. The crash was apparently caused by a change or regression in the VS2022 implementation of
EnvDTE::DocumentEvents::DocumentOpening()
. -
When analysing Visual Studio projects the appropriate
-std
and-m32
or-m64
switches are now automatically added to generated Clang-Tidy command lines. -
Fixed a bug in the Clang-Tidy analysis results parser which caused issues containing multiple square brackets to be parsed incorrectly.
-
Updated the PC-lint Plus compiler indirect file
co-rb-vs2022.lnt
to support Visual Studio 2022 v17.1.6. -
Updated the PC-lint Plus compiler indirect file
co-rb-vs2019.lnt
to support Visual Studio 2019 v16.11.13. -
Updated the PC-lint Plus compiler indirect file
co-rb-vs2017.lnt
to support Visual Studio 2017 v15.9.47. -
Updated the PC-lint Plus compiler indirect files
co-rb-vs2017.lnt
,co-rb-vs2019.lnt
andco-rb-vs2022.lnt
to limit the value of_MSVC_LANG
to201703L
. This is necessary as the version of the Clang front-end used by PC-lint Plus 1.4.x and earlier does not include C++ 20 compiler intrinsics. -
Updated the installer to terminate any instances of
mspdbsrv.exe
(the Visual Studio program database symbol server) before installing the Visual Studio plugin to VS2017/19/22. -
Updated the text on the "Analysis Tools" page of the installer.
-
Updated the readme and help documentation to reflect the fact that Windows 11 is now supported.
Download Visual Lint 8.0.9.353
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.
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:
-
Fixed a bug in the handling of preprocessor symbol properties in Visual Studio projects.
-
VisualLintGui will now open files dropped on its main window.
-
Updated the PC-lint Plus compiler indirect files
co-rb-vs2019.lnt
andco-rb-vs2022.lnt
to filter out errors in<xutility>
when analysing some Visual Studio 2019 and 2022 projects. -
Updated the PC-lint Plus compiler indirect file
co-rb-vs2022.lnt
to support Visual Studio 2022 v17.0.5. -
Updated the PC-lint Plus compiler indirect file
co-rb-vs2019.lnt
to support Visual Studio 2019 v16.11.9. -
Minor updates to the online help.
Download Visual Lint 8.0.8.351
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:
-
The Visual C++ project (
.vcxproj
) file parser now defines the value of_MSVC_LANG
appropriately if/std:c++14
,/std:c++17
,/std:c++20
or/std:c++latest
are used within a Visual Studio 2015, 2017, 2019 or 2022 project configuration. -
Fixed a bug in the Clang-Tidy analysis results parser which could cause some "note" issues to be hidden.
-
Fixed a bug in the handling of UTF-8 files in VisualLintGui.
-
Updated the PC-lint Plus compiler indirect file
co-rb-vs2022.lnt
to support Visual Studio 2022 v17.0.4. -
Updated the PC-lint Plus compiler indirect file
co-rb-vs2019.lnt
to support Visual Studio 2019 v16.11.8. -
Updated the PC-lint Plus compiler indirect file
co-rb-vs2017.lnt
to support Visual Studio 2017 v15.9.42. -
Updated the PC-lint Plus library indirect file
lib-rb-atl.lnt
. -
Updated the help topic for the Clang-Tidy Analysis Configuration Dialog "General" page.
Download Visual Lint 8.0.7.349
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.
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:

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:
-
Added direct download links for open source analysis tools such as Clang-Tidy and CppCheck to the Configuration Wizard, Options Dialog and Active Analysis Tool Dialog.
-
When the installation folder of an analysis tool is set in the Configuration Wizard for a particular IDE/project type, the path will now be used as the default for all project types. It can of course still be overridden on a project type by project type (or solution/workspace/project by solution/workspace/project) basis as required.
-
Updated the PC-lint Plus compiler indirect file
co-rb-vs2022.lnt
to support the public release of Visual Studio 2022 v17.0.0. -
Updated the Clang-Tidy message database to reflect changes in Clang-Tidy 13.0.0.
-
Corrected the "Status" text in the "Active Analysis Tool" dialog.
Download Visual Lint 8.0.6.347
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:

The following changes are included:
-
The Visual Studio plugin is now compatible with Visual Studio 2022 Preview.
-
The Visual Lint installer now includes dedicated VSIX extensions for Visual Studio 2017 (
VisualLintPlugIn_vs2017.vsix
), Visual Studio 2019 (VisualLintPlugIn_vs2019.vsix
) and Visual Studio 2022 (VisualLintPlugIn_vs2022.vsix
). -
If makefile output is read while loading a C/C++ project, it is now used to determine which files will be built.
-
The Project Properties Dialog now includes a dedicated field for built-in (i.e. compiler defined) preprocessor definitions. Note that these include those inferred by other project settings, e.g. the Visual C++ "Runtime Library" property (compiler switches
/MD[d]
,/MLd
and/MT[d]
) which infer_DEBUG
/NDEBUG
,_MT
and_DLL
. -
Built-in (i.e. compiler defined) preprocessor symbols are now written separately in generated PC-lint/PC-lint Plus project indirect files from those specified directly.
-
Updated the PC-lint Plus compiler indirect file
co-rb-vs2022.lnt
to support Visual Studio 2022 v17.0.0 Preview 5.0. -
Updated the PC-lint Plus compiler indirect file
co-rb-vs2019.lnt
to support Visual Studio 2019 v16.11.5. -
Updated the PC-lint Plus compiler indirect file
co-rb-vs2017.lnt
to support Visual Studio 2017 v15.9.40. -
Updated the VisualLintConsole help screen to reflect support for Visual Studio 2022 project and solution files.
-
Updated the installer to clarify that the "Remove Visual Lint commands from Visual Studio" option only applies to Visual Studio 2002-2008.
Download Visual Lint 8.0.5.346
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:

The following changes are included in this build:
-
Added support for Visual Studio 2022 Preview.
-
The ResOrg installer now includes dedicated VSIX extensions for Visual Studio 2017 (
ResOrgVsPlugIn_vs2017.vsix
), Visual Studio 2019 (ResOrgVsPlugIn_vs2019.vsix
) and Visual Studio 2022 (ResOrgVsPlugIn_vs2022.vsix
). -
The Visual Studio plug-in now uses a fully VSPackage based implementation when hosted in Visual Studio 2010, 2012 or 2013 (Visual Studio 2008 and earlier are still supported via an add-in).
-
The installer now checks if Visual Studio or ResOrg are running before allowing the installation to proceed.
-
Fixed a bug in the generation of HTML reports.
-
The AboutBox now shows the name of the host development environment (if any) and the platform (x86 or x64).
-
Updated the website address shown on the Aboutbox, in reports etc. from riverblade.co.uk to riverblade.co.
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:

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:

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:

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.
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:
-
The Eclipse C/C++ project (
.cproject
) file reader now attempts to take into accountbuildTools.path
andtoolchain.path
properties defined in preferences (.prefs
) files while reading the properties of makefile builds. If not specified, the make tool and compilers used by the makefile are assumed to be available on thePATH
. -
The VisualLintGui "Open Containing Folder" command now works with local HTML files (e.g. HTML analysis reports).
-
The "Makefile output text" control in the Makefile Properties Dialog now wraps text.
-
Updated the PC-lint Plus compiler indirect file
co-rb-vs2017.lnt
to support Visual Studio 2017 v15.9.39. -
Updated the PC-lint Plus compiler indirect file
co-rb-vs2019.lnt
to support Visual Studio 2019 v16.11.3. -
Updated the PC-lint Plus compiler indirect file
co-rb-vs2022.lnt
to support Visual Studio 2022 v17.0.0 Preview 4.0. -
When loading a project which uses makefiles, the following variables will be defined for troubleshooting purposes:
$(MakeToolPathName)
,$(MakeToolchainFolderPath)
,$(MakeWorkingFolder)
,$(MakeExecutedCommandLine)
and$(MakeOutputText)
. -
Added additional logging when loading projects which use makefiles.
-
Updated the information on supported platforms etc. in the readme and online help.
The Visual Lint plug-in included in this build is not compatible with Visual Studio 2022 Preview.
Visual Lint beta builds with full support for Visual Studio 2022 Preview are however available. Please contact us if you would like to become a beta tester.
Download Visual Lint 8.0.4.342
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:
-
Visual Studio 2022 now appears as a supported project type in VisualLintGui and VisualLintConsole.
-
Added a stub PC-lint Plus compiler indirect file for Visual Studio 2022 (
co-rb-vs2022.lnt
) to the installer. This will be replaced by an expanded implementation in due course. -
Updated the values of
_MSC_VER
and_MSC_FULL_VER
in the PC-lint Plus compiler indirect fileco-rb-vs2019.lnt
to support Visual Studio 2019 v16.10.4. -
Fixed a bug in the Visual Lint Options Dialog which caused a "Visual Studio has encountered an unexpected error" message when the dialog was invoked while the Visual Studio plugin was loaded but turned off.
-
The Eclipse C/C++ project (
.cproject
) file reader now takes into account the value ofbuildPath
attributes when parsing the<builder>
elements which define the properties of makefile builds. If not specified, the value ofbuildPath
is assumed to be${ProjDirPath}
. -
Fixed a handful of typos in the helpfile.
The Visual Lint plug-in included in this build is not compatible with Visual Studio 2022 Preview.
Visual Lint beta builds with full support for Visual Studio 2022 Preview are however available. Please contact us if you would like to become a beta tester.
Download Visual Lint 8.0.3.340
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:

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:


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.
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.
Installed @VisualStudio 2022 Preview 1 to see what's changed on the VSIX extension front. #cplusplus #programming
— Anna-Jayne Metcalfe 🌈🍦🏃♀️⚡️🦞🙉 (@annajayne) June 21, 2021
The short answer is that VSPackages are now x64 (we knew this already), but it doesn't look like the proposed new out-of-proc extension architecture has landed yet. pic.twitter.com/MHwSoHUqIb
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:
-
Recompile the existing plugins to target the x64 platform, using the new (VS2022 specific) 64 bit Visual Studio COM interfaces and the new (and also VS2022 specific) version of the Visual Studio SDK.
-
Add Visual Studio 2022 specific VSIX packages to deploy the x64 version of the plugins.
-
Update the installers to recognise Visual Studio 2022 and install the new x64 version of the plugin.
-
Try really, really hard not to break support for earlier Visual Studio versions in the process (those cannot load 64 bit plugins, so the existing 32 bit versions still have to be maintained).
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.


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:
-
Updated the values of
_MSC_VER
and_MSC_FULL_VER
in the PC-lint Plus compiler indirect file `co-rb-vs2019.lnt
to support Visual Studio 2019 v16.10.0. -
Updated the values of
_MSC_VER
and_MSC_FULL_VER
in the PC-lint Plus compiler indirect fileco-rb-vs2017.lnt
to support Visual Studio 2017 v15.9.36. -
Project (e.g.
$(ConfigName)
or${ConfigName}
) and environment (e.g.%COMPUTERNAME%
) variables can now be used in the values of the "Analysis configuration" [PC-lint/PC-lint Plus], "Warning policy" [PC-lint/PC-lint Plus] and "Generate reports in..." properties of a solution/project specific analysis configuration. [Visual Lint Professional and Enterprise Editions] -
Project (e.g.
$(ConfigName)
or${ConfigName}
) and environment (e.g.%COMPUTERNAME%
) variables can now be used in the values of the "Analysis tool installation folder", "Analysis tool executable", "When solution analysis completes..." and "Post-process PC-lint indirect (project.lnt
) files after generation..." properties of a solution/project specific analysis configuration. [Visual Lint Enterprise Edition] -
Fixed a bug in the implementation of the Solution/Project Analysis Configuration Dialog "Analysis tool executable" property. [Visual Lint Enterprise Edition]
-
Fixed a bug in the implementation of the Solution/Project Analysis Configuration Dialog "Warning policy" property. [PC-lint/PC-lint Plus] [Visual Lint Professional and Enterprise Editions]
-
Modified the Visual Studio plug-in to prevent duplicated entries for projects from appearing in the Analysis Status Display (this could be caused by the IDE sourcing duplicated "ProjectAdded" events, and these are now filtered out).
-
The Configuration Wizard "Analysis Tools" page no longer allows multiple analysis tools to be selected.
Download Visual Lint 8.0.2.338
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:
-
If the Visual Studio plugin is selected for installation and the Visual Studio Debug Console (
VsDebugConsole.exe
) is running, the installer will now ask you to close it before installation can proceed. -
Updated the interface with IncrediBuild to support IncrediBuild 9.5.x. [also in Visual Lint 7.0.12.336]
-
IncrediBuild analysis tasks can now be colour coded in the IncrediBuild Build Monitor from within the Visual Studio, Atmel Studio and Eclipse plug-ins. [also in Visual Lint 7.0.12.336]
-
Fixed a bug which could cause duplicate IncrediBuild analysis tasks to be queued. [also in Visual Lint 7.0.12.336]
-
Updated the prompt displayed if an IncrediBuild installation was not found when IncrediBuild analysis was enabled. [also in Visual Lint 7.0.12.336]
-
Updated the values of
_MSC_VER
and_MSC_FULL_VER
in the PC-lint Plus compiler indirect fileco-rb-vs2019.lnt
to support Visual Studio 2019 v16.4.4. -
Updated the values of
_MSC_VER
and_MSC_FULL_VER
in the PC-lint Plus compiler indirect fileco-rb-vs2017.lnt
to support Visual Studio 2017 v15.9.35. -
Various corrections and updates to help topics.
Download Visual Lint 8.0.1.337
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.

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:
-
Projects whose physical location is defined using system environment variables within Visual Studio, AVR Studio 5.0 or Atmel Studio solutions (
.sln
,.avrsln
or.atsln
) files can now be loaded correctly. -
Improved support for Eclipse project/build variables. In particular, variables of the form
${workspace_loc:/<projectname>/<resource_path>}
and${workspace_loc:/${ProjectName}/<resource_path>}
should now be resolved correctly, even if the project is physically located outside of the workspace folder and<resource_path>
is a linked resource. -
Updated the values of
_MSC_VER
and_MSC_FULL_VER
in the Visual Studio 2017 PC-lint Plus compiler indirect fileco-rb-vs2017.lnt
to support VS2017 v15.9.34. -
Updated the values of
_MSC_VER
and_MSC_FULL_VER
in the Visual Studio 2019 PC-lint Plus compiler indirect fileco-rb-vs2019.lnt
to support VS2019 v16.9.2. -
Added support for the Clang-Tidy analysis tool. Clang-Tidy is an open source C++ analysis tool from the LLVM Project which is especially notable for its ability to automatically fix some of the analysis issues it detects.
-
Updated the PC-lint Plus message database to reflect changes in PC-lint Plus 1.4.
-
Added PC-lint Plus library indirect files
lib-rb-stl.lnt
andlib-rb-boost.lnt
. -
The PC-lint Plus library indirect file
lib-rb-win32.lnt
no longer includes tuning directives for the ATL, WTL and MFC libraries - instead, dedicated indirect files for these libraries (lib-rb-atl.lnt
,lib-rb-wtl.lnt
andlib-rb-mfc.lnt
respectively) are now supplied.
If you analyse ATL, WTL or MFC code your PC-lint Plus analysis configuration will need to be updated accordingly. The implementations oflib-rb-win32.lnt
for PC-lint 8.0 and 9.0 are unaffected. -
Added a "Exclude files matching these wildcard masks" option to the Advanced Analysis Options Dialog. This can be used to (for example) automatically exclude generated files such as Qt
moc_*.cpp
files from analysis. Multiple masks can be specified by delimiting them with semicolons. -
Revised the
.vlconfig
file format. The changes are backward compatible, so old format files can still be read and will be updated when saved. -
Analysis Configuration files now include the name and major/minor version of the product which wrote them. Note that the full build version is not included, as that could cause unnecessary diffs in the resultant
.vlconfig
files. -
Added the ability to override the preprocessor symbol and include folder properties of arbitrary project types using the Project Properties Dialog. This allows the analysis configuration of a project to be further customised (e.g. by injecting additional preprocessor symbols) without affecting the build environment. If the properties of the project are overridden in this way, a
<projectfilename>.vlproj
file will be written alongside the project file to store the overridden properties. [Visual Lint Professional, Enterprise and Build Server Editions]` -
Various changes to the implementation of options.
-
The "Auto" value of the Maximum background analysis tasks option now allocates threads at 75% of the CPU logical core count.`
-
Manual analysis can now optionally automatically fix some detected issues. To enable this option, select Clang-Tidy as the active analysis tool and check the "Apply suggested fixes" option in the Clang-Tidy Analysis Configuration Dialog. [Visual Lint Enterprise and Build Server Editions]`
-
Added the Clang-Tidy Analysis Configuration Dialog, which contains a variety of options for configuring Clang-Tidy analysis. For example, the dialog allows header and line filters to be defined and includes options to define which Clang-Tidy checks are active.
-
The Issue Documentation Display can now show documentation for CppCheck and Clang-Tidy issues.
-
Replaced the TeeChart charts in the Analysis History and Results Displays with JqPlot (Javascript) equivalents as already used in HTML analysis reports. As part of this change the "Stacked Bar Chart" view has been removed from the Analysis History Display.
-
The Project Properties Dialog (and comments within generated project indirect ("
project.lnt
") files) now explicitly shows any project variables within the system include path unless the "Use VS2012/VS2010 system headers for compatibility with PC-lint 9.00L or earlier" option on the "Analysis Tool" Options page is active. -
The Property List Dialog now filters out blank lines when displaying include folder paths etc.
-
The Project Variables Dialog now displays IAR Embedded Workbench format variables (e.g.
$PROJ_DIR$
) correctly. -
The Analysis Results Display "Raw Analysis Results" view now attempts to normalise newlines for display purposes. This affects the Clang-Tidy analysis tool specifically, as it can generate output with a mixture of line endings.
-
The CppCheck Analysis Configuration Dialog "Checks" control is now an MRU combo box.
-
The Send Feedback Dialog is now modeless.
-
The Active Analysis Tool Dialog is now resizable and its contents sortable. In addition the meaning of the "Status" column has been made clearer.
-
The Advanced Analysis Options Dialog is now resizable.
-
The Configuration Wizard is now resizable.
-
The CppCheck Analysis Configuration Dialog is now resizable.
-
The Options Dialog is now resizable.
-
Display filters are now host and toolchain independent.
-
Moved code editor marker options from the "Displays" Options page to the "Editor" Options page.
-
Removed the "Auto-show the Analysis Results Display when analysis results are available" option from the "Displays" Options page.
-
Moved the "Check for new blogposts" option from the "Displays" Options page to the "Updates" Options page.
-
When a solution/workspace is closed, the displays are now cleared first and (in VisualLintGui only) a "Solution Closed" message written to the Status Bar when the process is complete.
-
The "Insert Directive" command on the Analysis Results Display context menu can now also be used to suppress Clang-Tidy analysis issues.
-
The "Lookup Meaning" command on the Analysis Results Display context menu is now available when analysing with CppCheck or Clang-Tidy.
-
Added an "Apply Fixes" command to the Analysis Status Display context menu. This command applies all fixes identified by Clang-Tidy to the selected implementation files.
-
Added a "Troubleshooting | View Fixes" command to the Analysis Status Display context menu. This command displays the contents of the Clang-Tidy
.fixes
file (if any) corresponding to the selected implementation file. These are YAML files associated with the clang-apply-replacements tool and which contain details of the issues Clang-Tidy has identified - and any changes it identified to fix them. -
Fixed a bug in the expansion of project variables in multi-field strings where more than one field expands to the same variable. This manifested in Visual Studio 2019 where the include path "
$(VC_IncludePath);$(WindowsSDK_IncludePath)
" only expanded the first instance of$(WindowsSdkDir)
. -
Fixed a bug which could affect the parsing of VisualDSP project files in the 64 bit version of VisualLintConsole.
-
Fixed a crash which which could occur while generating a Clang-Tidy command line for a standalone source file which is not part of any project.
-
Fixed a bug in the Analysis Results Display charts when rendering summaries of issues with embedded quotes in the issue title.
-
Fixed a bug in the Analysis Statistics Display which could cause some issues to be incorrectly displayed with the wrong issue category. The bug was identified while adding support for Clang-Tidy to the display.
-
Fixed a bug in the Analysis Status Display "Delete Analysis Results" context menu command which could cause an analysis task to be created for a file which was excluded from background analysis.
-
Fixed a bug which could prevent affected source files from being marked as stale when a header file was changed. The bug was identified while adding support for Clang-Tidy.
-
Fixed a bug which could cause uncommitted changes in the Property List Dialog to be lost if the "Expand project variables" checkbox was checked.
-
Fixed a bug in the x64 build of the Eclipse plugin.
-
Fixed a minor bug in the "Command Line" Options page.
-
Parsing operations on MSBuild project files can now be aborted part way through. This should make certain operations (e.g. changing configurations immediately after loading a solution) more responsive.
-
The Display Filter will no longer automatically attempt to suppress instances of issue 974 (
note -- worst case stack usage...
) if the active analysis tool is not either PC-lint or PC-lint Plus. -
The Solution/Project Analysis Configuration Dialog now resizes correctly.
-
Corrected the tab order of the Solution/Project Analysis Configuration Dialog.
Host Environments:
Analysis Tools:
Installation:
Configuration:
Analysis:
User Interface:
Commands:
Bug Fixes:
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.
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.

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.
Wednesday 15th April, 2020

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.
New website and chips, please!
Tuesday 19th March, 2019

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).
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:

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.
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.
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++.
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!
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.

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...












If you'd like to see the keynote, there's a video of it on YouTube and the slides are here.
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:
- Allowing move constructors to throw [noexcept] (N3050)
- Variadic templates (N2242)
- Extending variadic template template parameters (N2555)
- Initializer lists (N2672)
- Generalized attributes (N2761)
- Generalized constant expressions (N2235)
- Inheriting constructors(N2540)
- Unicode string literals (N2442)
- Raw string literals (N2442)
- Universal character names in literals (N2170)
- User-defined literals (N2765)
- Inline namespaces (N2535)
- Unrestricted unions (N2544)
- Minimal support for garbage collection and reachability-based leak detection (N2670)
- Extended integral types (N1988)
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.
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.
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:
// -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:
<?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.
Business of Software Conference Europe
Wednesday 2nd July, 2014

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.
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).
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:


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:

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.
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:

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.
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.
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:


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.