Licensing: there’s just nothing sexy about it. It is a reality in the software business, like deadlines and defects.

After years of using a third-party license manager, we decided to write our own License Manager. The old one worked reasonably well, but the company tried to gouge us when we wanted to add two new platforms: 64-bit Windows and 64-bit Linux.

As a product company, it’s never an easy decision to have someone work on something like licensing. It’s not the kind of feature that motivates people to buy your product. But there was just no arguing with the economics of the situation.

As part of finalizing the release, I write up the list of new features. Usually, this is pretty straightforward. This year, it was a little tougher. We had fewer new features due to the amount of time spent updating existing capabilities. And one of my few new features is the License Manager. How do I make that look really interesting on the list?

Maybe if I gave it a clever name like, “License Manager: License to Code”.

Hmm, Roman numerals make things look cool, “License Manager XVI”.

Maybe if I shortened the name it would sound more high tech, “LicMan”. No, not that!

Perhaps, the language of business obfuscation could be used, “Product Enablement System”. That doesn’t work either.

I know! How about an acronym that spells out something awesome, like “SlickEdit License Instance Capture Knowledgebase for Efficient Distribution, Inventory, and Tracking (SLICKEDIT)”. No, that just makes the name of this thing the same as the product.

In the end, there’s just nothing I could do to make this sound like more than it is. It’s a License Manager. We did everything we could to make it fast and convenient. In the end, it’s like getting blood drawn: the best you can hope for is that it is over quickly and you can get on with things.

I haven’t written a ton of posts for the SlickEdit blog.  I tend to save it for instances where I find something humorous that I can cross-reference.  I actually do not have a lot of humor to offer this time, but having worked through our 64-bit port in the last few months I do have a few interesting observations that are worth sharing.  Also, my manager asked if I would write something, and assured me that something noteworthy must have occurred during the 64-bit port.  He also mentioned that it should not involve any of the colorful string of adjectives that came out of of my cubical during that period of time.  It occurs to me as I write this that he might ask this again, so I’ve gone with the “Volume 1″ naming scheme… of course if I never write about this topic again it wouldn’t be the first time that something named “Volume 1″ is never followed up with a “Volume 2″.

As we began the 64-bit port we faced the same challenges as any company dealing with a large established code base.  A lot of typing issues.  In the 64-bit world, long means different things on different platforms.  In some cases it doesn’t make any difference, in others it does.  These cases have to be carefully examined.  In some cases the solution was not to use long at all.  There were cases where we had used long because it seemed like the right thing to do, but on careful examination, int is completely sufficient.

However, the most interesting case we came up against was a call to the X-Windows library.  The specific call had looked like this for years:

   XtVaSetValues(xftXtTopLevelShell,
               XtNx, -1000,
               XtNy, -1000,
               XtNwidth, 100,
               XtNheight, 100,
               XtNmappedWhenManaged, False,
               0);

And it was fine in our initial builds and testing.  But as we approached our first beta and started to compile our release configuration, the editor would crash on this line.  I spent an evening trying different compiler options, and different versions of the compiler, because I simply did not see a problem with this line.  But there is one.

The functions that start with XtVa take a variable number of arguments.  In this case, that last argument – the ’0′ – is a pointer.  On a 32-bit system, a pointer is 32-bits wide, and an int is 32-bits wide.  So passing 0 works just fine.  On a 64-bit system, pointers are 64-bits wide, and NULL is a 64-bit unsigned number. 0, however, is a 32-bit signed number.  Which actually works fine… until you turn on compiler optimizations.

Here is the corrected code:

   XtVaSetValues(xftXtTopLevelShell,
               XtNx, -1000,
               XtNy, -1000,
               XtNwidth, 100,
               XtNheight, 100,
               XtNmappedWhenManaged, False,
               NULL);

This wasn’t the most confusing problem I encountered, in fact I’m sure to a seasoned 64-bit Linux guru it should not have a been a problem at all.  But it was one of the things I felt was interesting enough to share here.

Anybody have a good 64-bit porting horror story?  Let’s hear them.

SlickEdit 2011 is an unusual release. Typically, a release contains a good number of new features that enhance your ability to edit source code. This year, the words “updated” and “enhancements” play more prominently in the list:

• 64-bit Versions for Linux and Windows
• Multithreading the Context Tagging Engine and Auto-Reload
• Support for Ruby Debugging
• Support for Git Version Control
• Dynamic Debugger Enhancements
• Updated Microsoft Visual Studio 2010 Support
• Updated JUnit Support
• SlickEdit License Manager

So what happened? Choosing what goes into a release is the toughest job for a product manager; there is never enough time to develop everything we’d like to get done in a given year. So we have to make hard choices.

We look at our customer base as a set of constituencies, each with different needs and change requests. Each language we support represents a different constituency with different needs, likewise for each platform. Fixing a tagging problem in C++ does little to help a Python programmer and vice versa. Some features, like Backup History, introduced in SlickEdit v9.0, are useful no matter what language or platform you are using.

Another way to divide constituents is into existing customers and new customers. Generally speaking, new features are considered more helpful in going after new customers, while bug fixes are aimed at existing customers. One consistent piece of feedback from existing customers is that they don’t really want new features; they just want the existing features to work better. In each release, we try to strike a balance between features to lure new customers and bug fixes for existing customers.

When we made the feature plan for this year, it became clear that there were parts of SlickEdit that really needed updating. As a product with a very long history—the first version of SlickEdit was released 23 years ago—we have seen some dramatic changes in the platforms we run on and the expectations of our customers.

In the early versions, resources were scarce so you needed to be as lean as possible, use as little memory and CPU as you can. This also makes your program very fast, which is one of our top goals. Now, a typical development machine has 4 cores and 4GB of memory or more. In this environment it’s frustrating to wait for an answer while the program is only using 25% of your available resources. That’s why the multithreading work was so important.

Don’t get me wrong. We’re not out to become a resource hog. We do believe that, for programmers, coding is the most important thing they are doing and that sufficient resources should be brought to bear.

As code bases grow, it’s even more important to have an editor, like SlickEdit, that knows the location and type of your symbols. Being able to generate that information efficiently and access it quickly is always our top priority. SlickEdit 2011 is a big step in giving you the fastest possible code navigation.