There are basically 3 companies that control the computer graphics market; Intel, ATI (a.k.a AMD), and nvidia. Total these 3 companies have something like 99% of the market, so you have to try very hard to find a computer with another chipset.
Intel owns the commanding share, greater than 50%. But they don't own this much because their product is better, but because embedded graphics are cheap and most computer manufacturers go with that option. It's long been know that Intel graphics are basically unplayable in 3D games. You'll get such low frame rates that if you want to do any gaming you need ATI or nvidia. Because of this, for more than a decade I've always spent the extra money for a dedicated graphics card. That said, Intel has put forth some major effort into improving the graphical capabilities of their cards, probably due in large part to Windows Vista/7 and the aero glass effects. This improvement combined with the fact that I don't have time to "game" at home on my computer has lead me to build several computers lately using the default Intel graphics.
Well I can say, Intel still has work to do here. The problem isn't so much the graphics performance. I was able to play some older games just fine. No, the problem is graphical stability and glitches. On one system, if the computer went into standby power mode, when coming out of power standby Windows had graphical glitches. The text on many Windows was gone never to return, and the mouse would sometimes track slow or jump around. On the second machine, it would experience random HARD reboots - typically during graphical applications such as watching a video.
In both of these cases, installation of an nvidia card cleared up the problems. On the first machine I suspect the problem is driver related, but I have installed the latest and greatest version of the driver. The second machine (hard reboot) is a hardware problem. Either way, Intel still has work to catch up here. I'm hopeful Intel will fix these problems and continue to close the gap in performance just because they hardware is so common. I guess you could say they are the slowest person on the team, but the team can't finish until the slowest person crosses the line. So we all benefit from a better performing Intel graphics.
Tuesday, August 5, 2014
Tuesday, July 29, 2014
Forgotten Windows Password
Recently at work a server lost contact with it's domain which invalidated all domain accounts on the machine. So the only way to login was using a local account, of which there was only one - the local administrator. The problem is, no one knew the password, it had been almost a decade since the local admin account had been last used. So is there a way to recover from this type of problem? Turns out the answer is yes - and it's so easy it's almost scary.
What you need is a program called OphCrack. Windows stores users passwords as hashes, and OphCrack cracks the password by comparing the password hash against pre-generated hashes stored in what they call "rainbow tables." OphCrack can be run in two different ways. Probably the most common is from a "live CD." Once you burn the CD you boot the computer from that CD, from there OphCrack does everything automatically - it finds the registry hives storing the password hashes, begins the cracking process, and displays the results. The other way to run OphCrack is on your computer directly. This is useful if you can login to one account but need to crack another account's password. You can also load up the registry hives of a computer - I believe it requires the SYSTEM, SAM, and SECURITY registry hives.
The scary thing is how quickly and easily OphCrack can work its magic. Using the default tables it was able to crack the password in 7 minutes and 2 seconds!
There are other methods to crack your password, or otherwise login to an account without knowing the password. But OphCrack is the easiest and least invasive I've seen.
I wanted to be clear here, this is not a security flaw in Windows. Similar software exists for Linux and Mac, so anyone computer can be hacked into. It's taking advantage of your relatively weak password. If you're paranoid about this type of thing, what can you do to prevent it? Below are some tips that will help prevent this type of attack (if you're concerned about such things).
What you need is a program called OphCrack. Windows stores users passwords as hashes, and OphCrack cracks the password by comparing the password hash against pre-generated hashes stored in what they call "rainbow tables." OphCrack can be run in two different ways. Probably the most common is from a "live CD." Once you burn the CD you boot the computer from that CD, from there OphCrack does everything automatically - it finds the registry hives storing the password hashes, begins the cracking process, and displays the results. The other way to run OphCrack is on your computer directly. This is useful if you can login to one account but need to crack another account's password. You can also load up the registry hives of a computer - I believe it requires the SYSTEM, SAM, and SECURITY registry hives.
The scary thing is how quickly and easily OphCrack can work its magic. Using the default tables it was able to crack the password in 7 minutes and 2 seconds!
There are other methods to crack your password, or otherwise login to an account without knowing the password. But OphCrack is the easiest and least invasive I've seen.
I wanted to be clear here, this is not a security flaw in Windows. Similar software exists for Linux and Mac, so anyone computer can be hacked into. It's taking advantage of your relatively weak password. If you're paranoid about this type of thing, what can you do to prevent it? Below are some tips that will help prevent this type of attack (if you're concerned about such things).
- Use disk encryption. Windows, Linux, and Mac all have software that can encrypt the disk.
- Use long passwords and at least one symbol or extended character. OphCrack works by having pre-calculated hashes for shorter passwords (up to about 10 characters) and using letters and numbers. Since this covers 99% of the passwords people use, this works most of the time. But if your password is longer and uses special characters (e.g. '^' and '&') the possible number of passwords increases exponentially and so does the time to crack.
- Do whatever you can to ensure physical security of the computer. Once someone has physical access to your computer, there's almost no stopping them. Even if you have a long password, they may not be able to crack your password but they can still access your files (unless you used disk encryption). Of course, if your computer is a laptop, tablet, or phone and you lose it or it's stolen - well consider your data compromised.
OphCrack is a cool little program that helped us login to this server. Tools like this are not merely "hacking" tools but they do have useful purposes.
Monday, July 21, 2014
What a real quality pair of headphones looks like
I see a lot of people these days walking around listening to their Beats Audio headphones. Every time I see that I think "idiot - you fell for their marketing ploy and spent way too much money on sub-par headphones." Now that's very judgmental for me to say that, especially since I've never actually listened to a pair of Beats. But I have listened to true high-quality headphones, and I've read enough reviews (e.g. here and here) to know that Beats is popular strictly because of a great marketing engine. They have created this illusion that their product is great and desirable and as such, anything with their name and logo can command top-dollar prices.
Several years ago I purchased a pair of Sennheiser HD 590 headphones. I'm going to talk about these headphones. Again, I've never listened to Beats so I can't do a direct comparison, but I suspect Beats has few, if any, of the the following features. I guess you could think of the following as a way to design the best headphones, the feature to include that give you a truly great product.
The first thing you notice with a pair of headphones like this is how comfortable they are. The strap across the top of the head is fully padded, but most importantly the ear pieces very softly padded. They are also large and fit around the ear instead of lying flat on the ear. This makes them very comfortable for long periods of time. Another great feature of these headphones is they are an "open" design. An open headphone is one that allows both air and noise to pass through the headphones. While wearing these headphones you can still hear the world around you as clearly as without the headphones. This has one major benefit when it comes to comfort. A typical "closed" headphone tries to isolate you from the sound world around you. To do this, the ear cup must be pressed against your skull to try and block a lot of noise. Since the open design is not trying to isolate you, the ear cups do not need to squeeze onto your head. The end result is a VERY comfortable headphones. You can listen to these for hours and never feel like you need to remove them to give your head and ears a break.
Another great feature is the thought that went into the wire. Many headphones have one wire coming out each ear, whereas these headphones have a single wire on one side. You don't realize how much the two-wire design gets tangled up until you use a single wire design. Sennheiser also has a detachable wire at the ear piece. So if the wire gets caught on something it won't rip the headphones from your head, instead the wire just comes unplugged. They even include the adapter to let you listen to 1/4" headphone jacks in addition to the standard 1/8" jacks. And to top it all off, all connectors are plated in gold which prevents them from oxidizing over time. You could argue that good headphones should be wireless, but a wireless design has circuity in them and, more significantly, lots of battery. Both of which add weight to the headphones which makes them less comfortable to listen to for long periods of time. It also adds the hassle of having to charge them.
But the list of top quality features and components doesn't stop there. The speakers use Neodymium magnets, which are the strongest known magents and produces better sound. Also, all the wiring in the headphones is oxygen-free copper (OFC). This is copper that has been smelted in a special way to prevent oxygen from bonding to the copper. It's a more pure form of copper, it transmits electricity better than regular copper, which again results in better sound quality. Both OFC and Neodymium cost more money which is why few manufactures use it.
Another great feature of Sennheiser headphones is the company support. Sennhesier has been around for decades, and they support all of their products for a long time. You can buy replacement parts for their products decades after the product was last manufactured.
To sum up, these Sennheiser HD 590 headphones are the most comfortable and best sounding headphones I've ever used. It goes to show you when a company takes the time to design a truly great product, the results speak for themselves. Of course, headphones like these aren't cheap. I forget how much I paid for them, but it was about $300. And that's where Beats headphones rub me the wrong way. You can spend that much and more on Beats, and do they offer any of these features?
The one thing I've read over and over about Beats is they offer bass and volume. Well if you want crappy bass and high volume from an overpriced headphone, by all means order some Beats. But if you want good quality music with properly represented bass then look for a high-quality brand like Sennheiser or Grado.
Recently it was announced that Apple is buying Beats. To me this perfectly sums up the point I'm trying to make. To me, Apple is the pinnacle of average hardware that commands extremely high prices because their marketing department has convinced people "it's worth it."
Several years ago I purchased a pair of Sennheiser HD 590 headphones. I'm going to talk about these headphones. Again, I've never listened to Beats so I can't do a direct comparison, but I suspect Beats has few, if any, of the the following features. I guess you could think of the following as a way to design the best headphones, the feature to include that give you a truly great product.
The first thing you notice with a pair of headphones like this is how comfortable they are. The strap across the top of the head is fully padded, but most importantly the ear pieces very softly padded. They are also large and fit around the ear instead of lying flat on the ear. This makes them very comfortable for long periods of time. Another great feature of these headphones is they are an "open" design. An open headphone is one that allows both air and noise to pass through the headphones. While wearing these headphones you can still hear the world around you as clearly as without the headphones. This has one major benefit when it comes to comfort. A typical "closed" headphone tries to isolate you from the sound world around you. To do this, the ear cup must be pressed against your skull to try and block a lot of noise. Since the open design is not trying to isolate you, the ear cups do not need to squeeze onto your head. The end result is a VERY comfortable headphones. You can listen to these for hours and never feel like you need to remove them to give your head and ears a break.
Another great feature is the thought that went into the wire. Many headphones have one wire coming out each ear, whereas these headphones have a single wire on one side. You don't realize how much the two-wire design gets tangled up until you use a single wire design. Sennheiser also has a detachable wire at the ear piece. So if the wire gets caught on something it won't rip the headphones from your head, instead the wire just comes unplugged. They even include the adapter to let you listen to 1/4" headphone jacks in addition to the standard 1/8" jacks. And to top it all off, all connectors are plated in gold which prevents them from oxidizing over time. You could argue that good headphones should be wireless, but a wireless design has circuity in them and, more significantly, lots of battery. Both of which add weight to the headphones which makes them less comfortable to listen to for long periods of time. It also adds the hassle of having to charge them.
But the list of top quality features and components doesn't stop there. The speakers use Neodymium magnets, which are the strongest known magents and produces better sound. Also, all the wiring in the headphones is oxygen-free copper (OFC). This is copper that has been smelted in a special way to prevent oxygen from bonding to the copper. It's a more pure form of copper, it transmits electricity better than regular copper, which again results in better sound quality. Both OFC and Neodymium cost more money which is why few manufactures use it.
Another great feature of Sennheiser headphones is the company support. Sennhesier has been around for decades, and they support all of their products for a long time. You can buy replacement parts for their products decades after the product was last manufactured.
To sum up, these Sennheiser HD 590 headphones are the most comfortable and best sounding headphones I've ever used. It goes to show you when a company takes the time to design a truly great product, the results speak for themselves. Of course, headphones like these aren't cheap. I forget how much I paid for them, but it was about $300. And that's where Beats headphones rub me the wrong way. You can spend that much and more on Beats, and do they offer any of these features?
The one thing I've read over and over about Beats is they offer bass and volume. Well if you want crappy bass and high volume from an overpriced headphone, by all means order some Beats. But if you want good quality music with properly represented bass then look for a high-quality brand like Sennheiser or Grado.
Recently it was announced that Apple is buying Beats. To me this perfectly sums up the point I'm trying to make. To me, Apple is the pinnacle of average hardware that commands extremely high prices because their marketing department has convinced people "it's worth it."
Wednesday, July 9, 2014
PKZip through rose-colored glasses
PKZip is a piece of software that I've looked fondly upon - until recently. Most computer users are aware of PKZip (a.k.a. just "zip") which is probably the most common and ubiquitous file compression format. It's been around since the late 80s and is extensively used in computers - so even if you don't directly use this format I can pretty much guaranty many of the software and services you rely on do use this format. And what's not to love about this format? It offers very good compression, it's fast, and it's royalty free unlike some other compression software.
Well, it turns out not everything is peachy-keen in Zip-land. Recently at work I've had the need to directly read and write zip files. I cannot rely on existing code to read and write the zip file for me, I must do it myself. Fortunately the actual compression and decompression code I don't have to write, but all the metadata inside the zip file I must write myself. Basically the internal structure of a zip file is a lot of smaller structures that contain file into such as compressed/uncompressed sizes, filename, attributes, etc. These structures also point to relative positions of other structures in the file, etc. This is all standard stuff if you've ever written code to process a binary file. So what's the problem then? Simple, the way these structures are laid out is horrible. You have to start off parsing the file from the end which is counter-intuitive, some structures have signatures ids whereas others do not, the contents of structures varies depending on bit flags, etc. But by far the biggest headache is the zip64 extensions. The original zip format cannot handle large files, so they had to extend the format to support 64-bit file addresses. I understand they wanted to maintain backwards compatibility, but what they should have done was create a new format and zip/unzip tools would adjust accordingly. It would actually be the same code to maintain backwards compatibility, just where that code goes would have been different.
Oh well, I can't fault them too much. I mean the zip format became wildly popular, probably more popular than they had ever anticipated. They might have put more thought into the design had they known. Also, it would have been hard to foresee the need for 64-bit support back in a time when hard drives were only a few megabytes in size.
PKZip has definitely stood the test of time. But its age is showing. Newer formats like Rar and 7Zip offer better compression ratios. Personally I would recommend 7Zip. But zip is so ubiquitous it's going to be around for a while. I just wish the internals of the file weren't so bad.
Well, it turns out not everything is peachy-keen in Zip-land. Recently at work I've had the need to directly read and write zip files. I cannot rely on existing code to read and write the zip file for me, I must do it myself. Fortunately the actual compression and decompression code I don't have to write, but all the metadata inside the zip file I must write myself. Basically the internal structure of a zip file is a lot of smaller structures that contain file into such as compressed/uncompressed sizes, filename, attributes, etc. These structures also point to relative positions of other structures in the file, etc. This is all standard stuff if you've ever written code to process a binary file. So what's the problem then? Simple, the way these structures are laid out is horrible. You have to start off parsing the file from the end which is counter-intuitive, some structures have signatures ids whereas others do not, the contents of structures varies depending on bit flags, etc. But by far the biggest headache is the zip64 extensions. The original zip format cannot handle large files, so they had to extend the format to support 64-bit file addresses. I understand they wanted to maintain backwards compatibility, but what they should have done was create a new format and zip/unzip tools would adjust accordingly. It would actually be the same code to maintain backwards compatibility, just where that code goes would have been different.
Oh well, I can't fault them too much. I mean the zip format became wildly popular, probably more popular than they had ever anticipated. They might have put more thought into the design had they known. Also, it would have been hard to foresee the need for 64-bit support back in a time when hard drives were only a few megabytes in size.
PKZip has definitely stood the test of time. But its age is showing. Newer formats like Rar and 7Zip offer better compression ratios. Personally I would recommend 7Zip. But zip is so ubiquitous it's going to be around for a while. I just wish the internals of the file weren't so bad.
Friday, June 13, 2014
LED light bulbs
If you have been to the hardware store recently to buy a light bulb then you should already know that LED light bulbs are fast taking over the market. The old incandescent light bulbs are becoming illegal and are being phased out around the world. The options for consumers are CFL (compact fluorescent lights) and LED (light emitting diode). If you are looking to buy a new light bulb, let me strongly encourage you to buy LED and not CFL. And here is why:
- CFLs contain mercury, which is toxic. I read an article once on how to cleanup a broken CFL. In short, you do not want to ever break a CFL because cleanup will be a major pain!
- CFLs do not like being cycled on and off. Constant turning on and off of the bulb greatly diminishes the life of a CFL, but LEDs do not have a problem with this.
- LEDs use less energy. CFLs are efficient, but LEDs are even more efficient.
- LEDs produce higher quality light. The light LEDs produce is closer to what an incandescent light produced.
- LEDs produce less heat.
- LEDs have longer projected life.
- LEDs are not sensitive to temperature. CFLs do not work in the cold.
As far as I know, the only reason to buy CFL over LED is because of the cost of the bulb. LED bulbs do cost more. But, LEDs are dropping in price fast! A bulb that cost $40 a year or two ago now costs $10. I predict that very soon it will be impossible to buy CFLs - they will stop manufacturing them. As the cost of LEDs drops so fast, there is no reason to buy a CFL. CFLs were basically a stop-gap measure, to bridge the time when incandescent were being phased out, but before LEDs were advanced enough to be a viable option.
For more comparisons between LED, CFL, and incandescent lights read this article.
Hopefully I've convinced you to buy LED light bulbs. But not all bulbs are created equal. Some produce better light than others, some have barely perceivable flicker, some have even light distribution, etc. So how do you know what is a good bulb? I found this awesome youtube channel called electronupdate. In it he does a very thorough analysis of dozens of LED bulbs, including tearing the bulb apart to look at the quality of the electronics.
If you just want the summary of his ongoing efforts, as of now the best bulbs are Cree and Philips. You cannot go wrong with either. I personally have some of the Cree bulbs at home and I love them. Another thing I like about the Cree bulbs is they are manufactured in the USA, plus they use top-quality capacitors inside them which means they will last longer than other LED bulbs.
Tuesday, May 27, 2014
C++: Testing for NULL
Like any good developer I'm constantly learning more about the programming language I work in (C++). But several of the things I've learned lately have gone against years of working the opposite.
Take for example the following code:
CStudent *pStudent = new CStudent(nStudendId);
if(pStudent)
{
pStudent->DoSomething();
}
This is a very typical snippet of code. What's of interest here is the test if pStudent is NULL after the allocation. If the allocation fails then pStudent would be NULL, and you want to test NULL pointers before dereferencing them which would result in an application crash. I used to believe that programmers that didn't test the pointer first we being "lazy." Well, it turns out testing the return value is not only unnecessary, it's actually wasted CPU cycles - so in other words it's bad to test the return from a performance reason. At the heart of the matter here is the C++ operator 'new.' If new is unable to allocate the requested block of memory, new throws an exception. So in the above code, it's impossible for pStudent to ever be NULL. It will either be a valid block of memory, or an exception will be thrown.
Knowing this is kind of nice. Code is usually cleaner and easier to read without all these tests against NULL after calling 'new.' Now let me be clear, this is only when calling 'new.' Other allocaters such malloc do NOT throw an exception. So it's still a good idea to test their return.
Related to this, it turns out it's also pointless to test the pointer before freeing the memory.
if(pStudent)
delete pStudent;
This is a pointless test because 'delete' checks the pointer before proceeding. So testing the pointer first is again wasted CPU cycles.
Unlike malloc, the same thing is true with 'free.' The function 'free()' tests the pointer, so there is no need to test before calling free(). But this is not true of all functions that cleanup resources. The Windows API CloseHandle() does not check, so as the developer it's your job to test before calling CloseHandle().
Take for example the following code:
CStudent *pStudent = new CStudent(nStudendId);
if(pStudent)
{
pStudent->DoSomething();
}
This is a very typical snippet of code. What's of interest here is the test if pStudent is NULL after the allocation. If the allocation fails then pStudent would be NULL, and you want to test NULL pointers before dereferencing them which would result in an application crash. I used to believe that programmers that didn't test the pointer first we being "lazy." Well, it turns out testing the return value is not only unnecessary, it's actually wasted CPU cycles - so in other words it's bad to test the return from a performance reason. At the heart of the matter here is the C++ operator 'new.' If new is unable to allocate the requested block of memory, new throws an exception. So in the above code, it's impossible for pStudent to ever be NULL. It will either be a valid block of memory, or an exception will be thrown.
Knowing this is kind of nice. Code is usually cleaner and easier to read without all these tests against NULL after calling 'new.' Now let me be clear, this is only when calling 'new.' Other allocaters such malloc do NOT throw an exception. So it's still a good idea to test their return.
Related to this, it turns out it's also pointless to test the pointer before freeing the memory.
if(pStudent)
delete pStudent;
This is a pointless test because 'delete' checks the pointer before proceeding. So testing the pointer first is again wasted CPU cycles.
Unlike malloc, the same thing is true with 'free.' The function 'free()' tests the pointer, so there is no need to test before calling free(). But this is not true of all functions that cleanup resources. The Windows API CloseHandle() does not check, so as the developer it's your job to test before calling CloseHandle().
Thursday, May 22, 2014
Static Code Analyzers
Recently at work I tried a class of software I've never used before, something called "static code analyzers." Basically it is software that scans your source code and looks for bugs and optimizations. They call them "static" because they only analyze the source code, there is a separate class of tools to analyze your program at runtime. Anyway, I've never used this type of software before and I tried a number of different tools so I thought I'd comment about each tool I used.
Before I talk about each tool, I'll say that I work with the language of C++ using the Microsoft Visual Studio compiler. So the tools I tried were all geared towards that environment. Also, it is true that because of the rules and structure of newer languages (Java, C#, etc.) that tools like this are most useful in C++. However; any language it's entirely possible to make a mistake in code that is perfectly valid syntactically (so the compiler/interpretor won't catch it) but yet it is still a bug. That is the goal of these static code analyzers. A tool to help the developer catch his own mistakes. If the compiler is like a spell-checker, then a code analyzer is like a grammar-checker.
CppCheck: The first tool I tried is called CppCheck, which is a free open-source project. This tool ended up being the easiest tool to run. What I liked about this tool was you merely give it a directory (and optionally some additional Include folders) and it analyzes all the source code in that folder. It had a clean simple UI. Incredibly easy, and the results were pretty good too!
PVS-Studio: PVS-Studio is a commercial product, but does offer a free trial version. I was hesitant to try a commercial product mainly because lately I've been using a lot of free and open-source software. But I was very pleased with PVS-Studio. It operates a little differently than CppCheck. PVS-Studio integrates with Visual Studio, after a successful build PVS-Studio automatically starts and analyzes the code that was used during that build. PVS-Studio also has a second standalone mode of operation. You run the tool, then compile your code using the compiler of your choice, after which it analyzes the source. Where PVS-Studio shined was in its results. It's was pretty quick to analyze, much quicker than CppCheck on the same code. Also, the way in which it filters and displays the issues it finds makes navigating and fixing the results very easy. The downside is this is commercial software. I would actually consider buying PVS-Studio for my own personal use, but I don't like their licensing model. It's clearly geared towards corporations and large development teams. They also sell the product on, what I would call, a subscription model. You buy a license for a year, and after that year if you still want to use the product you must license it again. I hate this type of licensing. If I buy the product, I want to be able to use it indefinitely.
Eclipse C++ IDE w/ CDT-CODAN: I read that the Eclipse IDE includes a module called "CODAN" for code analysis. CODAN is a portmanteau for CODe ANalysis. Since Eclipse is free I thought I'd give it a try. I have never really used the Eclipse IDE before so there was a bit of a learning curve to get my source code from Visual Studio into an Eclipse project. I didn't care if the code compiled, in fact I knew it wouldn't because it's MFC-based code and the compiler Eclipse uses (MinGW) doesn't handle MFC. I just wanted to be able to run the code analyzer against my code. After several hours of trying I got the code in and was able to run the analyzer. My results with CODAN were mixed. The problem I had was the vast majority of my code, the code analyzer had a problem with. This was due to the undefined Windows symbols throughout my code. Even though I pointed the compiler at the appropriate Windows SDK Include folders, it still could not resolve the symbols. I'm sure the problem is my lack of experience with Eclipse and knowing how to configure it. Now all of that said, CODAN still was able to find a number of problems in my code which no other tool found. So it was worth while, I just wish I was able to analyze more of my code with this tool.
Visual Studio: Starting in Visual Studio 2005 Microsoft includes a code analysis tool of their own. So the good news is it's free (more on that later), and it's already integrated with Visual Studio. All you have to do is go into your project settings and enable C/C++ code analysis. When you run your next compilation it will report the issues it finds. Unfortunately, this tool is not available with every version of Visual Studio. The Express, Academic, and Professional versions do not include it. Only the top-of-the-line "Team" version includes this tool. So there's a good chance you don't have access to it. But if you do, it's there so use it. For me, this tool didn't find as many issues as I was hoping. It did find some, but I was hoping for more. Of course, I had already used the above 3 tools so there were fewer issues to find at that point.
PreFast: Turns out there is another free tool from Microsoft called PreFast. This tool is included for free in the Windows DDK (driver development kit). It's designed to analyze driver source code, but I read on the Internet that it can be used to analyze user-mode code as well. I didn't actually run my source code through PreFast. I may go back and do so in the future.
Your Compiler: As it turns out, you probably have a free simple code analyzer already on your system - your compiler. Most compilers have different warning levels, but may default to a lower setting. Visual Studio has 4 levels but defaults to 3. If you turn the warning level up and recompile you'll get a lot of extra warnings. The quality of these warnings won't be as good as the above dedicated tools, but there is still a good chance you'll find at least one issue using this free technique.
CppDepend: CppDepend is another commercial product that I read great things about on the Internet, and they offer a free trial, so I decided to give it a try. However; I didn't go very far with this tool. Right out of the gates it wouldn't run because it required the .NET runtime which wasn't installed on my system. It also turns out this tool does not support my version of Visual Studio. So in the end I was never able to get this tool to run.
So there's my review of several static code analyzers. To be honest, I wasn't expecting much going in. When I write code, I'm very attention-to-detail oriented. You could even say "anal" although I prefer "fastidious." So I wasn't expecting much from these tools. I was surprised by the number of "issues" it found. I would definitely use them again in the future, and recommend others use them as well. If you're trying to decide which tool to use - don't choose, use them all. Run your source code through multiple tools to get even more results. It's not like you're cheating on your spouse, there is no harm in using multiple tools and only gains if you do. Happy coding!
Before I talk about each tool, I'll say that I work with the language of C++ using the Microsoft Visual Studio compiler. So the tools I tried were all geared towards that environment. Also, it is true that because of the rules and structure of newer languages (Java, C#, etc.) that tools like this are most useful in C++. However; any language it's entirely possible to make a mistake in code that is perfectly valid syntactically (so the compiler/interpretor won't catch it) but yet it is still a bug. That is the goal of these static code analyzers. A tool to help the developer catch his own mistakes. If the compiler is like a spell-checker, then a code analyzer is like a grammar-checker.
CppCheck: The first tool I tried is called CppCheck, which is a free open-source project. This tool ended up being the easiest tool to run. What I liked about this tool was you merely give it a directory (and optionally some additional Include folders) and it analyzes all the source code in that folder. It had a clean simple UI. Incredibly easy, and the results were pretty good too!
PVS-Studio: PVS-Studio is a commercial product, but does offer a free trial version. I was hesitant to try a commercial product mainly because lately I've been using a lot of free and open-source software. But I was very pleased with PVS-Studio. It operates a little differently than CppCheck. PVS-Studio integrates with Visual Studio, after a successful build PVS-Studio automatically starts and analyzes the code that was used during that build. PVS-Studio also has a second standalone mode of operation. You run the tool, then compile your code using the compiler of your choice, after which it analyzes the source. Where PVS-Studio shined was in its results. It's was pretty quick to analyze, much quicker than CppCheck on the same code. Also, the way in which it filters and displays the issues it finds makes navigating and fixing the results very easy. The downside is this is commercial software. I would actually consider buying PVS-Studio for my own personal use, but I don't like their licensing model. It's clearly geared towards corporations and large development teams. They also sell the product on, what I would call, a subscription model. You buy a license for a year, and after that year if you still want to use the product you must license it again. I hate this type of licensing. If I buy the product, I want to be able to use it indefinitely.
Eclipse C++ IDE w/ CDT-CODAN: I read that the Eclipse IDE includes a module called "CODAN" for code analysis. CODAN is a portmanteau for CODe ANalysis. Since Eclipse is free I thought I'd give it a try. I have never really used the Eclipse IDE before so there was a bit of a learning curve to get my source code from Visual Studio into an Eclipse project. I didn't care if the code compiled, in fact I knew it wouldn't because it's MFC-based code and the compiler Eclipse uses (MinGW) doesn't handle MFC. I just wanted to be able to run the code analyzer against my code. After several hours of trying I got the code in and was able to run the analyzer. My results with CODAN were mixed. The problem I had was the vast majority of my code, the code analyzer had a problem with. This was due to the undefined Windows symbols throughout my code. Even though I pointed the compiler at the appropriate Windows SDK Include folders, it still could not resolve the symbols. I'm sure the problem is my lack of experience with Eclipse and knowing how to configure it. Now all of that said, CODAN still was able to find a number of problems in my code which no other tool found. So it was worth while, I just wish I was able to analyze more of my code with this tool.
Visual Studio: Starting in Visual Studio 2005 Microsoft includes a code analysis tool of their own. So the good news is it's free (more on that later), and it's already integrated with Visual Studio. All you have to do is go into your project settings and enable C/C++ code analysis. When you run your next compilation it will report the issues it finds. Unfortunately, this tool is not available with every version of Visual Studio. The Express, Academic, and Professional versions do not include it. Only the top-of-the-line "Team" version includes this tool. So there's a good chance you don't have access to it. But if you do, it's there so use it. For me, this tool didn't find as many issues as I was hoping. It did find some, but I was hoping for more. Of course, I had already used the above 3 tools so there were fewer issues to find at that point.
PreFast: Turns out there is another free tool from Microsoft called PreFast. This tool is included for free in the Windows DDK (driver development kit). It's designed to analyze driver source code, but I read on the Internet that it can be used to analyze user-mode code as well. I didn't actually run my source code through PreFast. I may go back and do so in the future.
Your Compiler: As it turns out, you probably have a free simple code analyzer already on your system - your compiler. Most compilers have different warning levels, but may default to a lower setting. Visual Studio has 4 levels but defaults to 3. If you turn the warning level up and recompile you'll get a lot of extra warnings. The quality of these warnings won't be as good as the above dedicated tools, but there is still a good chance you'll find at least one issue using this free technique.
CppDepend: CppDepend is another commercial product that I read great things about on the Internet, and they offer a free trial, so I decided to give it a try. However; I didn't go very far with this tool. Right out of the gates it wouldn't run because it required the .NET runtime which wasn't installed on my system. It also turns out this tool does not support my version of Visual Studio. So in the end I was never able to get this tool to run.
So there's my review of several static code analyzers. To be honest, I wasn't expecting much going in. When I write code, I'm very attention-to-detail oriented. You could even say "anal" although I prefer "fastidious." So I wasn't expecting much from these tools. I was surprised by the number of "issues" it found. I would definitely use them again in the future, and recommend others use them as well. If you're trying to decide which tool to use - don't choose, use them all. Run your source code through multiple tools to get even more results. It's not like you're cheating on your spouse, there is no harm in using multiple tools and only gains if you do. Happy coding!
Subscribe to:
Posts (Atom)