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.
Tuesday, May 19, 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 skeleton Visual Studio 2019 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.
Visual Lint 7.0.7.318 has been released
Tuesday, April 21, 2020
This is a recommended maintenance update for Visual Lint 7.0. The following changes are included:
- The Visual C++ built-in preprocessor symbol _MSC_VER is now defined on the generated CppCheck command line when analysing Visual Studio 2019 projects.
- Appropriate defaults (e.g. the compiler indirect file co-rb-vs2019.lnt) are now offered when creating a PC-lint Plus analysis configuration for Visual Studio 2019.
- Updated the values of _MSC_VER and _MSC_FULL_VER in the PC-lint Plus compiler indirect file co-rb-v2017.lnt to reflect those in the latest Visual Studio 2017 update (VS2017 v15.9.21).
- Updated the values of _MSC_VER and _MSC_FULL_VER in the PC-lint Plus compiler indirect file co-rb-vs2019.lnt to reflect those in the latest Visual Studio 2019 update (VS2019 v16.5.1).
- Fixed a bug in the Configuration Wizard "Select Analysis Tool Installation Folder" page.
- Fixed a bug in the implementation of the "Active Analysis Tool" option.
- Fixed a bug in the implementation of the .vlconfig file "Solution specific Analysis Tool" property [Visual Lint Enterprise and Build Server Editions].
- Fixed a display bug in the Configuration Wizard "Information" page. Note that this page is PC-lint and PC-lint Plus specific.
- Corrected the title of the "PC-lint" page in the Analysis Configuration Dialog to "PC-lint Plus" when the active analysis tool is PC-lint Plus.
Download Visual Lint 7.0.7.318
Wednesday, April 15, 2020
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.
Visual Lint 7.0.6.316 has been released
Tuesday, March 3, 2020
This is a recommended maintenance update for Visual Lint 7.0. The following changes are included:
- Fixed a bug in the parsing of Visual Studio MSBuild expressions using the [MSBuild]::GetDirectoryNameOfFileAbove() function which was preventing the system include folder path from being read correctly in Visual Studio 2019 v16.4.4.
- 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.4.4.
- Modified the PC-lint Plus Visual Studio 2019 compiler indirect file co-rb-vs2019.lnt to suppress an instance of error 4392 (constexpr declaration follows non-constexpr declaration) in the header file $(VCToolsInstallDir_160)\include\intrin0.h.
- Added help documentation for the fields (e.g $(index), $(SourceFile) and $(LineNo) ) which can be used in exported analysis results files.
- Updated the helpfile to explicitly reference the PC-lint Plus analysis tool throughout.
- Added a "PC-lint/PC-lint Plus multipass analysis" help topic.
- Updated links within the online help as necessary.
Download Visual Lint 7.0.6.316
Visual Lint 7.0.5.314 has been released
Thursday, January 23, 2019
This is a recommended maintenance update for Visual Lint 7.0. The following changes are included:
- If an output report folder is specified on the command line and its path is relative, VisualLintConsole now resolves it before starting analysis. This ensures that the path referenced in any status/progress messages is is unambiguous.
- Fixed a bug in VisualLintConsole in the copying of Javascript baggage files to the (optional) output report folder.
- Fixed a minor display bug in the VisualLintGui "Projects" Display.
Download Visual Lint 7.0.5.314
Visual Lint 7.0.4.313 has been released
Tuesday, December 3, 2019
This is a recommended maintenance update for Visual Lint 7.0. The following changes are included:
- Added support for wildcards to the text filters in the Analysis Status, Analysis Statistics, Analysis Results and Stack Usage Displays and Display Filter Dialog.
This allows (for example) files to be easily excluded from analysis by using a wildcard text filter in the Analysis Status Display.
- Added a /writevlconfigfiles switch to VisualLintConsole to allow the user to use VisualLintConsole to incrementally update analysis configuration (.vlconfig) file(s) for the current solution/workspace/project.
- Added the environment variable _RB_CONFIGURATION to the generated PC-lint/PC-lint Plus command line. This includes the name of the configuration, and like _RB_PLATFORM can be used to dynamically select options within an indirect (.lnt) file.
- The "Delete Analysis Results" command now correctly deletes per-project analysis results and report baggage files.
- Improved a prompt which was shown by the Configuration Wizard if it was unable to write any affected files on completion.
- Locked out the program information (+program_info) option on the Command Line Options page if the active analysis tool is PC-lint Plus, as this directive is currently PC-lint 9.0 specific.
- Generated PC-lint Plus command lines now escape the pathname of the stack usage report file if it contains quotes (generated PC-lint 9.0 command lines are unaffected as spaces in the pathname do not cause issues for it).
- Fixed a bug in the parsing of ExcludedFromBuild attributes in Visual C++ 2010-2019 (.vcxproj) project files.
- Fixed a bug which affected projects containing more than one file with the same name.
- Fixed a bug in the parsing of cpplint analysis results of the format: "<filename>(<lineno>): error cpplint: [<ID>] <description> [<category>]".
- Corrected a help topic.
Download Visual Lint 7.0.4.313
Visual Lint 7.0.3.311 has been released
Tuuesday, September 24, 2019
This is a recommended maintenance update for Visual Lint 7.0. The following changes are included:
- Fixed a bug in the Visual Studio 2017/2019 installation process which can cause an invalid filename to be specified for VSIX logfiles written to the %TEMP% folder.
- The timestamps of any property (.props, .targets or .vsprops) files referenced by a Visual Studio project are now taken into account when determining whether a new PC-lint/PC-lint Plus indirect (.lnt) file needs to be written.
- Added a breadcrumb bar to HTML solution, project and file reports to make navigating to the report for the parent entity (e.g. from file to project) easier.
- Fixed a bug which could cause an invalid -setenv() directive to be generated on the PC-lint Plus analysis command line if a platform name referenced in a project contained one or more spaces.
- Replaced the "invalid key entered" balloon tip in the Registration Key Dialog with an inline text field.
- Added a missing help topic.
Download Visual Lint 7.0.3.311
Visual Lint 7.0.2.310 has been released
Wednesday, July 24, 2019
This is a recommended maintenance update for Visual Lint 7.0. The following changes are included:
- Added a +rw(noexcept) directive to the Visual Studio 2015 and 2017 PC-lint 9.0 compiler indirect files co-msc140.lnt and co-rb-vs2017.lnt respectively. This allows code which uses the noexcept keyword to be analysed more cleanly.
As PC-lint 9.0 does not officially support modern C++ code other analysis errors may still occur when you analyse modern C++ code with PC-lint 9.0. As such we recommend that you update to PC-lint Plus to analyse code for modern C++ compilers such as GCC 4.x/5.x or Visual Studio 2013/15/17/19. Please contact us for details. - Fixed a bug in the installer which could prevent the Visual Studio plug-in from being installed to Visual Studio 2019.
- Fixed a bug in the VisualLintGui Products Display "Add Existing File" context menu command.
- Fixed a bug in the update check process which could result in incorrect text being displayed for a major update (e.g. to Visual Lint 7.x) [also in Visual Lint 6.5.8.309].
Download Visual Lint 7.0.2.310
Visual Lint 7.0.1.308 has been released
Monday, June 10, 2019
This is a recommended maintenance update for Visual Lint 7.0. The following changes are included:
- System include folder and for loop compliance settings can now be read from Visual Studio 2019 project files which use the v142 toolset.
- Device specific includes (e.g. "<ProjectFolder>/RTE/Device/TLE9879QXA40") are now read when loading Keil uVision 5 projects.
- Updated the value of _MSC_FULL_VER in the PC-lint Plus compiler indirect files for Microsoft Visual Studio 6.0, 2008, 2010, 2012, 2013, 2015, 2017 and 2019 to reflect the version of the most recent update of the compiler shipped with each. Also enabled C++ 17 support (-std=c++17) with Visual Studio 2017 (VS2017 update 9.4 is C++ 17 complete) and Visual Studio 2019.
- Removed an erroneous directive from the PC-lint Plus library indirect file rb-win32-pclint10.lnt (an implementation file invoked by lib-rb-win32.lnt).
- Fixed a bug in the Analysis Tool Options Page which could prevent the "Browse for installation folder" button from working correctly.
- Fixed a bug in the Project Properties Dialog which affected the editing of configurations within custom projects.
- Fixed a bug in the VisualLintGui Products Display "Remove File" context menu command.
- The Configuration Wizard "Select Analysis Tool Installation Folder" page no longer indicates that you can buy PC-lint licences from Riverblade as this analysis tool has now been superseded by PC-lint Plus.
- VisualLintGui now displays the correct page title when loading the "Blog" page on the Riverblade website.
- Fixed a typo in the "Product Not Configured" dialog.
Download Visual Lint 7.0.1.308
ResOrg 2.0.8.28 has been released
Wednesday, June 5, 2019
This is a maintenance update for ResOrg 2.0. The following changes are included:
- Added support for Visual Studio 2019 to the Visual Studio plug-in (note that the standalone ResOrg application already supported VS2019 projects).
- Various minor updates to the documentation, readme etc.
Visual Lint 7.0 has been released
Saturday, March 30, 2019
The first public build of Visual Lint 7.0 has just been uploaded to our website.
As of today, Visual Lint 7.0 replaces Visual Lint 6.5 as the current supported Visual Lint version. Customers with active Visual Lint 6.x priority support, floating and site licence subscriptions should shortly receive updated licence keys for the new version, and upgrades for Visual Lint 5.x and 6.x per user licences will become available in our online store soon. Older editions can be upgraded manually - please contact us for details.
In addition, most customers who have purchased per-user Visual Lint licences since the start of January will shortly receive new Visual Lint 7.x compatible licence keys.
Full details of the changes in this version are as follows:
General
- Replaced Visual Lint Standard Edition with Visual Lint Personal Edition.
Note: Visual Lint Personal Edition is licenced for use by individual and freelance developers rather than organisations. If your organisation has more than one member of staff, you must use Visual Lint Professional Edition or above.
As such organisations which have purchased Standard Edition licences in the past must upgrade them to Visual Lint 7.x Professional Edition or above if they wish to use Visual Lint 7.x.
See Visual Lint Product Editions for details of the available product editions.
Host Environments:
- Added support for Microsoft Visual Studio 2019 to the Visual Studio plug-in. VisualLintGui and VisualLintConsole have also been updated to support Visual Studio 2019 solution and project files.
Note: Support for the v142 toolset is not yet complete so you may (for example) find that you need to add details of the Visual Studio 2019 system include folders to your PC-lint Plus std.lnt file in order that your analysis tool can locate system include files.
- Removed support for Windows XP, Windows Vista and Windows Server 2003 (although the software should still function on these platforms, we no longer test on them).
Analysis Tools:
- PC-lint Plus is now recognised as a distinct analysis tool from PC-lint 8.0/9.0. As a result it is now straightforward to switch between the two products.
- Added PC-lint Plus specific compiler indirect file co-rb-vs2019.lnt for Visual Studio 2019.
- The environment variable _RB_PLATFORM on the generated PC-lint Plus command line now includes the string name of the platform rather than an enumerated value.
- Added the environment variable _RB_TOOLCHAIN to the generated PC-lint Plus command line. This is used to determine which compiler indirect file to use in Atmel Studio projects where the AVR platform (which can be either 8 bit or 32 bit) is used. In such cases the toolchain (e.g. 'com.Atmel.AVRGCC32') is unambiguous and can be used instead.
- Added a PC-lint Plus indirect file (co-rb-as7.lnt) for Atmel Studio 7.x to the installer. This conditionally invokes compiler indirect files for either ARM (32 bit), AVR (8 bit) or AVR (32 bit) compilers based upon the active platform and toolchain.
- Added additional PC-lint Plus suppression directives to the indirect file lib-rb-win32.lnt supplied within the installer.
Installation:
- The installer will now ask you to close third party development environments (devenv.exe, atmelstudio.exe, eclipse.exe etc.) before installation can continue only if the corresponding plugin is selected for installation.
- Removed the PC-lint 8.0 message database.
Configuration:
- If it has not yet been configured, Visual Lint no longer prompts to run the Configuration Wizard when it is started. Instead, the user is prompted only when they attempt to start manual or background analysis.
Analysis:
- When a Visual Studio solution is loaded, the version reported is now that corresponding to the highest version of platform toolset in the solution. e.g. If a Visual Studio 2019 project contains Visual Studio 2015 and 2017 projects, the solution will be reported as being for Visual Studio 2017 for analysis purposes.
User Interface:
- The elapsed time in the Manual Analysis Dialog is now displayed in minutes and seconds rather than just seconds.
- Increased the size of the "Active Analysis Tool" and "Options" dialogs.
- The Message Lookup View can now switch dynamically between message databases for PC-lint and PC-lint Plus.
- Revised Configuration Wizard page text to differentiate between PC-lint and PC-lint Plus where appropriate.
- "Project" nodes in the VisualLintGui Projects Display now include details of the active configuration and project type in the same way as the root "Solution" node.
- The Analysis Status, Statistics, History and Results Displays now indicate the name of the active analysis tool.
Bug Fixes:
- Fixed a potential crash in the Analysis Results Display.
- Fixed a bug which prevented PC-lint Plus analysis from being run on an IncrediBuild grid.
- Fixed a couple of bugs in the Configuration Wizard which affected PC-lint Plus.
- Fixed a bug in some of the displays which could cause one of the columns to be oversized.
- PC-lint Plus user defined messages (8000-8999) are now correctly categorised as informational.
- Fixed a bug which could cause PC-lint Plus command lines containing the obsolete PC-lint +linebuf or +macrobuf directives to be generated if the analysis tool was set to PC-lint but the analysis tool installation folder was overridden to point to a PC-lint Plus installation folder.
Download Visual Lint 7.0.0.307
Tuesday, March 19, 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 design 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 and fish and chips).
Thursday, October 25, 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:
- Static Analysis with PC-lint Plus
- PC-lint Plus for PC-lint/FlexeLint users
- Interactive Demo
- Evaluate PC-lint Plus
- Order PC-lint Plus
- PC-lint Plus Support
- New PC-lint Plus Community Forum
If you have any queries, please let us know.
LintProject Pro End of Life Notice
Tuesday, October 23, 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, April 27, 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 we're 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!
ResOrg 2.0.7.27 has been released
Friday, April 27, 2018
ResOrg 2.0.7.27 has just been released. This is a maintenance update for ResOrg 2.0, and is compatible with all ResOrg 2.0 licence keys.
The following changes are included:
- Fixed a bug in the Symbols Display which could cause some "OK" symbols to be incorrectly shown in the "Problem Symbols Only" view.
- Corrected the upper range limit for control symbols from 28671 (0x6FFF) to 57343 (0xDFFF).
- ResOrg binaries are now dual signed with both SHA1 and SHA256.
- Added support for Visual Studio 2017.
- Corrected the File Save Dialog filters used by the ResOrgApp "File | Export" command.
- The ResOrgApp "File | Export", "File | Save", "File | Save As" and "File | Properties" commands (which apply only to symbol file views) are now disabled when the active view is a report.
- Fixed a crash in the Symbol File Properties Dialog.
- Fixed a typo on the Symbol File "Next Values" page.
- Various minor improvements to the installer.
Wednesday, June 8, 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 year since!
Invaders...from Bournemouth
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"....).
Anna-Jayne Metcalfe from Riverblade presenting the closing keynote "Comfort Zone"
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.
This is where the keynotes take place on Wednesday, Thursday and Friday morning...and at the close of the conference on Saturday afternoon
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!
Set the controls for the heart of the pudding...
OK. Now would be the time to panic...
Anna-Jayne Metcalfe 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.
PC-lint Plus is coming - and with it, full support for C++ 11 and C++ 14
Monday, December 14, 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 noticable 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 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 Visual Studio 2013, PC-lint and C++ 11 Variadic Templates and 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 the blogpost Upcoming Support for C++14/VS2015.
ResOrg 2.0.6.25 has been released
Monday, November 9, 2015
This is a maintenance update for ResOrg 2.0. The following changes are included:
- Added support for Visual Studio 2015.
- Added support for Windows 10.
- Added a helpfile.
- Removed support for Windows 2000.
- ResOrgApp now declares itself as system DPI aware to reduce the likelihood of DPI virtualization.
- Icons used within the ResOrg displays now reflect the current system defined icon sizes rather than being hardcoded to 16x16, 32x32 etc.
- Tweaked the layout of the AboutBox.
Visual Studio 2013, PC-lint and C++ 11 Variadic Templates
Monday, February 23, 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 2013 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: The build is now available. Download Visual Lint 4.5.9.239
How Visual Lint parses projects and makefiles
Thursday, November 6, 2014
Code analysis tools can require a lot of configuration to be useful. Whilst some (e.g. Vera++ or cpplint.py) need very little configuration to make use if 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 iteself 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, 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, July 2, 2014
Our founder Anna attended the Business of Software Europe Conference in Cambridge last week, 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, April 02, 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, Aug 2, 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 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 VS2012 RC light & dark themes, as well as the default VS2010 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, April 20, 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, January 22, 2012
Well, 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 at https://www.riverblade.co/blog.php?archive=2011_12_01_archive.xml#2011121501.
Visual Lint and Atmel AVR Studio 5
Friday, September 16, 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 occured 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.