myShoggoth

Foundations: Future-Proofing

There are really two sides to making your application robust against future change.

1. Writing the application to maximize current and future compatibility.
2. Writing the code to maximize future maintainability and minimize necessary code and more importantly architectural changes.

64 Bit

Don't make coding assumptions that won't work for 64-bit.  This has two flavors, the first being the coding techniques used to be able to compile code for both 64 bit and 32 bit.  Interactions with APIs, COM, and dealing with pointers are all potential hazard areas.

The second major aspect of 64 bit compatibility is making sure no assumptions are being made that interfere with the conversion layer between 32 bit and 64 bit Windows called WOW64 (which follows the same patterns as WOW32, the layer that allows 16 bit applications to run on the 32 bit Windows OS).

So what do you need to do for that?  Besides getting into the appropriate beta programs and testing your applications on 64 bit versions of Windows and fixing any problems you find, make sure you're using all the APIs in the right way.  If you're sticking a pointer in a long because you expect that you'll be able to get it back later as a long, you may run into big problems if that isn't expected by the layer that translates the 32 bit addresses into 64 bit ones and back.

Version-Based Behavior Changes

If you would like to take advantage of new functionality in the operating system without increasing your WINVER (which should be set to the minimum version of Windows that you support), you can create a thunking layer where you have a set of function pointers that you fill in when running on the newer version by using LoadLibraryEx to load the library that holds the function and calling GetProcAddress to get the pointer to it.

The advantage is that you're not statically linked to the library (that's also the disadvantage), and you can modify runtime behavior based on whether the function point is NULL (the value it should be initialized to, of course).

The other way you can modify runtime behavior based on OS version is by looking at the values returned by GetVersionEx.  When would you do which?  As new service packs are released for released versions of the operating system, sometimes functions or functionality are backported.  If your logic depends on the function existing, go with the LoadLibrary/GetProcAddress as your method for determining which logic to use.  If you're based specifically on the version of the OS (much more rare, but possible), base the logic on the GetVersionEx.

Maximum Compiler Warning Level

Compiler warnings give you the information you need to know about for possible compatibility problems in the future in addition to the issues you have now.  I'm a big believer in setting the maximum compiler warning level, making warnings errors, and turning on any other compiler options I can find that can help me avoid or find problems earlier.  This would be the combination of /Wall and /WX, to turn on all warnings (even those that are off by default), and to treat all warnings as errors.

Talking again about the 64 bit section above, there is a compiler option to give you warnings on possible 64 bit compatibility issues (/Wp64).  This may give you some false positives, so you should sanity-check by actually compiling for 64 bit architectures.

IPv6

Networking code needs to be written in an IP version independent manner.  The same code would work on IPv4 and IPv6 networks without modification.  Microsoft provides a utility called 'checkv4.exe' which helps to identify code that might cause IPv6 problems and makes conversion easier.

Even if you don't plan to write to IPv6 specifically, if your program does network interaction you're better off making it IP version agnostic.

High DPI

I won't say too much about writing code for High-DPI displays beyond providing the link and saying this:  Monitors are getting better at a much faster rate than before, you should expect the resolution and DPI density to increase quite a bit.  This screws up a lot of programs in the areas of text (/ fonts), images, UI layout, and sizing issues for custom-drawn UI.  Most displays are 96 DPI, and most application developers totally assume than all displays are 96 DPI.  Weird sizing, overlap, and ugliness problems rear up when that assumption isn't true.

Re-Invent Less, Build More

I've noticed a tendency amongst many software developers to want to reinvent wheels.  Sometimes they're convinced they can do a better job, sometimes solving a well understood problem once again is a welcome comfort for a programmer who is usually coding without a net.

Things that people enjoy rewriting:

• Memory managers
• Windows controls
• Network stacks
• Caches
• Encryption

Even for cases where someone can do a better job than Windows developers for systems such as these, it is still a bad idea.  First, any new code will have bugs, and those bugs will take significant testing to work out.  This assumes that the new code gets the same scrutiny as the code built into the system platform, which is unlikely for all but the largest projects (and even then, pretty unlikely).  It must also get enhanced and evolved to match the code built into the platform as new Windows versions are released, patches and made, and service packs created.

When it gets down to it, though, the real problem is that they're rewriting code they don't need to.  They're not writing code that adds value to their product that is unique and added value for their customers, they're redoing something for minimal benefit that will cost more in terms of development, servicing, and maintenance over the long term.

Safe Computing

Here are the things I think are necessary for a safe computing environment.  Some of these are Windows specific, many are not.  If you run your computer within a corporate or otherwise managed environment, make sure to check with the administrators and/or support personal before making any major changes to your network configuration or computer settings.

Firewall

You have a few options here:

1. Hardware firewall
   Many companies have these available, whichever you choose follow the instructions to update the firmware on a regular basis.  This is the firewall's software, and needs to be updated to address any vulnerabilities found after the product was sold.
2. Software firewall
   Again, there are many vendors.  Windows XP has one built-in called the Internet Connection Firewall (ICF).  To enable ICF, log in as Administrator and:
   1. Click on the Start menu
   2. Choose Control Panel
   3. Select "Network and Internet Connections" (or "Network Connections" if you're in Classic View)
   4. Select "Network Connections" if you're in Category View
   5. Right-click on the network connection you want to enable a firewall on, and choose 'Properties'.
   6. Choose the Advanced tab
   7. Select the ICF checkbox.  Note that the Advanced tab will not be there if you are not logged in as an Administrator.
3. Dedicated computer as a firewall
   Take an older computer (because this task doesn't require a lot of horsepower), and install Windows XP or perhaps OpenBSD and set it up to act like a hardware firewall.  For Windows XP this would involve both enabling ICF as above and enabling Internet Connection Sharing (ICS), so that your internal LAN computers can share the IP address of that one computer.  ICS is another tab on the Properties page of the network connection.
   
   Using a UNIX-like operating system such as OpenBSD requires more specialized knowledge, and there are web pages at their site with instructions on how to set it up.  I bring up OpenBSD because they have made security their claim to fame, and use it myself.  Note that I have a deep UNIX background and don't think it is easy to set up without such.
   
   The computer needs to have two network interface cards, one that talks to the outside world and one that talks to the internal network.  One of the 'network cards' might be a modem if you're still using dial-up.

Virus Scanner

You should have one, and it needs to be configured to download new virus signatures as often as possible (within reason).  Running a virus scanner is great, but if you don't have the information it needs in order to protect you against the latest one that is spreading like wildfire across the Internet, mostly what it is doing is making you feel safer than you actually are.

Don't Run As Admin

I can't stress this enough, and it is the biggest reason why Windows has been such a relatively easy target for worms and viruses.  If you're logged in to your computer with an account that can only change your own files, the worst a virus can do is change your files.  It cannot change OS files, it cannot access other people's information, its impact is restricted.

If, instead, you are logged in as Administrator, or someone with Administrator rights, or in the UNIX world you're logged in as root... the virus now has free reign.  It can access anything, it can overwrite anything, it can use all the information on the computer to try to spread itself and do damage.

This is why, if you're still running Windows 95, 98, or ME, you should seriously consider upgrading.  These are old DOS-based, single-user operating systems where there is no concept of a non-Administrator.  If you're using the computer, you're the owner and administrator of it.

Create computer accounts with Power User or lower access, and log in (or use the command prompt command 'runas.exe' or right-click menu item Run As...) as the computer's Administrator when you need to do something that requires that access, such as installing certain software and changing certain settings (such as the ICF settings above).  Then, log out of that account and log back in as your lower-access normal user account.

Internet Explorer Security Settings

I agree with, use, and recommend the settings that Michael Howard wrote about in his blog entry Security Settings in Internet Explorer and then updated after talking to Internet Explorer team members.

In addition to this, I set my Privacy tab setting to 'high'.  This keeps random sites and Internet tracking outfits like DoubleClick from putting cookies on my computer unless I okay it.  Let me take you through this step by step:

Security Settings

1. Launch Internet Explorer
2. Select the 'Tools' menu (Alt-T in the English version)
3. Select the 'Internet Options...' menu item (key shortcut 'O' in the English version)
4. Select the 'Security' tab (keyboard access?  How about shift-tab then right arrow?)
5. For the Internet zone, select 'High' (you may need to click on the "Default Level" button first)
6. For the Local intranet zone, select 'High'
7. For the Trusted sites zone, select 'Medium'
8. Select 'OK' for the dialog, and you're done

Privacy Settings

1. Launch Internet Explorer
2. Select the 'Tools' menu (Alt-T in the English version)
3. Select the 'Internet Options...' menu item (key shortcut 'O' in the English version)
4. Select the 'Privacy' tab (keyboard access?  How about shift-tab then right arrow twice?)
5. Move the slider to 'High'
6. Select 'OK' for the dialog, and you're done

Adding A Trusted Site

You shouldn't trust most sites, and should only add a site as Trusted when you need to because it doesn't work correctly without it and you really do trust it.

1. Launch Internet Explorer
2. Select the 'Tools' menu (Alt-T in the English version)
3. Select the 'Internet Options...' menu item (key shortcut 'O' in the English version)
4. Select the 'Security' tab (keyboard access?  How about shift-tab then right arrow?)
5. Select the Trusted sites zone, and click on the 'Sites...' button
6. Type the name of the site into the 'Add this Web site to the zone:' input box and click on the 'Add' button
7. You will very likely need to uncheck the 'Require server verification (https:) for all sites in this zone' checkbox since you will probably want to add http:, ftp:, and other sites to this list
8. Select 'OK' for the dialog, and you're done

Allowing A Site To Use Cookies

Again, you should not have to do this with most sites, only those you trust to use cookies for good (and not evil).

1. Launch Internet Explorer
2. Select the 'Tools' menu (Alt-T in the English version)
3. Select the 'Internet Options...' menu item (key shortcut 'O' in the English version)
4. Select the 'Privacy' tab (keyboard access?  How about shift-tab then right arrow twice?)
5. Select the 'Edit...' button
6. Type the name of the site into the 'Address of Web site:' input box and click on the 'Allow' button (don't hit enter here, the default is the Block button)
7. Select 'OK' for the dialog, and you're done

Program Updates and Patches

Just like virus scanners, security patches for operating systems and applications don't do you any good if you haven't installed them.

Log in as Administrator and visit http://windowsupdate.microsoft.com/, download and install at least all the critical updates.  You can choose which Recommended Updates are relevant to you.

To keep your computer up to date, I recommend having Windows XP automatically download and install the updates on a regular schedule.  To take advantage of this:

1. Click on the Start menu
2. Choose Control Panel
3. Select "Performance and Maintenance" (or "System" if you're in Classic View)
4. Select "System" if you're in Category View
5. Choose the "Automatic Updates" tab
6. Verify that the "Keep my computer up to date" checkbox is checked
7. Select the "Automatically download the updates, and install them on a schedule that I specify" radio button, choosing the schedule that works best for you

If you use Microsoft Office, you should also visit http://office.microsoft.com/home/ and click on 'Check for updates' to make sure you've got all the relevant service packs and security fixes for those programs.  This is particularly important if you use Microsoft Outlook to read email.

For other software, check with the manual to determine where to find updates and check regularly, especially for those applications you use on a regular basis.  Anything involved with communications is especially important, such as web browsers, email readers, instant messaging clients, etc.

Senior Developer vs. Junior Vol. I

I recently made a modification to an internal company tool that, as I thought more about it, really helps illustrate differences between how senior developers and junior developers go about their jobs, and thought I would share some of those ideas since I've been a bit lazy about posting new articles of late.

Junior Developers

I've seen a number of traits in junior developers I've worked with, taught, and managed:

1. Getting completely road blocked by an issue and waiting for others to unblock them.
2. Jumping to the easiest (in the short term) solution and not looking back.
3. Jumping to the 'best' (in the long term) solution and not looking back.
4. Trying random ideas until one seemed to work.

Senior Developers

Senior developers will do things like:

• Take a bug report as an opportunity to fix a deep, fundamental bug instead of addressing only the symptoms that led to the one bug report.
• Turn a bug fix into a new, useful feature.
• Add defensive code to the application to make it easier to find similar bugs in the future.
• Educate fellow developers on the issue they invested significant amounts of time in so the whole group can benefit and not repeat it.
• Create tools that help avoid repeated patterns of mistakes in the future.

Developer Tools

The tool was originally created by Raymond Chen, who is a member of my previous team (I only interacted with him on a few occasions) and the author of hands-down my favorite blog.  The first thought:

Senior Developers Save Everyone Time

I have no doubt this tool, nor any of the others ones Mr. Chen has written, were never officially part of his job description at any time.  There was a process that was painful and could be made faster and less error-prone, and he took the time to write the tool and make it available to others.  Many developers claim to be lazy and would rather write code to do something rather than do it manually every time, but not very many put their time where their mouth is and make it happen.  The mark of a better developer is to make a tool available to others to save everyone time, and then maintain it.

I ran into a problem while doing my brand new job.  I considered a number of different options and determined that a particular feature in Mr. Chen's tool would be the minimal-impact way of solving it, and a potentially useful feature even if I was wrong.  Second thought:

Senior Developers Make Productive Use Of Problems

Rarely is a decision for the easiest versus 'best' clear cut, and many times neither are correct.  There are many factors to consider, and the weighting of each depends on the circumstances, not the personalities involved:

• Code quality - the ongoing fight against code base entropy
• Schedule - how much time can you actually afford to spend on this issue?
• Risk - is the change likely to have cascading effects?  is the new behavior optional and opt-in?
• Nature of the change - is the change an added feature that may be useful regardless?
• Criticality - how important is the change?
• Confidence - exactly how sure are you of your estimation of all of the above?

So I sent email to him and a few others who wrote similar tools and asked if any had the feature.  Quickly I got responses from all three saying they had not, and that the feature in question was very counter-intuitive and would have the unfortunate side-effect that I was in fact counting on.  So I set out to add the feature to Mr. Chen's tool myself.

Senior Developers Don't Demand Features, They Add Them (With Permission)

I could have demanded one of them add this feature to their tool, but not only had they not heard the request before from any of their users, none of them were official products or supported tools in any way.  They created and maintained them because they needed them.  Maybe one would have someday added the feature, but not until far after I needed it and had come across as a jerk for making demands on their time.

The combination of a shared tool, the only benefactor (at least immediately) being myself, and the lack of clear value for the code itself means it makes the most sense to bite the bullet and do it myself.

Senior Developers Adopt Existing Code's Style

There's a tendency to impose one's style on any code one touches.  Real skill involves changing the code in the same way the author/maintainer would.  This is both for the benefit of the quality of the code (readability, maintainability, etc.), but also because it means you're thinking about it the right way, and are less likely to cause bugs and side effects unexpected by the original design.

I spent a lot of time with the tool's code trying to understand it, made the change a few different ways before finding the way I believed was most in the spirit of the existing style.  As usual, the best changes are the ones that minimize the churn to the code.  This leads to the fewest side effects, potential bugs, and helps make sure the changes are maintainable for the owner of the code -- now and in the future.