I was curious to see if running with two processors would make a difference so I ran a quick test using my software build time as a benchmark. Runing with a single processor the build time was 140 seconds, running with two it dropped to 118 seconds, a decrease of about 15%.

Mail Print 2.0 is a ground up rewrite, no existing code has been used in the new version. This has allowed us to make some significant changes however it does mean existing settings will not be migrated.

Mail Print now uses the concept of actions to control the printing of emails, actions exist for printing messages, printing message attachments, playing a sound and deleting messages from the server.

Rules are more flexible and similar to what you would see in a traditional email client like Outlook or Thunderbird.

The main printing within Mail Print is now handled by a service which runs in the background. This means Mail Print can continue to work without having a user logged in or be run on a server in a back office.

In the past I have used an off the shelf commercial "wrapper" to handle trial protection. This had a lot of benefits at the time including cutting development time and the use of more secure encryption than I have the skills to develop. However this hasn't been without it's problems, the worst of which was the introduction of DEP (Data Execution Protection) in Windows which blocks code which changes on the fly. The vendor of this software has struggled to resolve problems in this area and offered very little constructive support.

So the choice I had to make was whether to buy another product or code my own system, I decided on the later. This post is really a specification for what I need to write.

I thought it might be useful for anybody else looking at developing their own scheme to see what my requirements are. As I sell mainly to businesses traditional piracy hasn't been a big issue for me, more of a problem are issues like under licensing within an organization and handling refunds.

There are some basic principles I apply to all my software development which are worth listing.

• The software is written for my customers benefit, not mine. This means the trial mechanism should inconvenience them as little as possible. Of course there is a trade off here, if I took away any protection then it would be very convenient for the customer but my revenue would dry up so I need to strike a balance.

• Favor simplicity over complexity, this is often more difficult than you would think. If you watch a duck glide across water and it looks very smooth, this is how the user should see my software, under the water though there is a lot of effort being expended to achieve this smoothness.

• Minimise support costs, currently a significant proportion of my support emails relate to problems with registering Mail Print. I'd really like to reduce these as much as possible even if it has a small impact on revenue.

Having laid out the principles I can cover the main functionality in the trial mechanism.

1. Trial version. The standard trial needs to work for 30 days from the point of installation, after 30 days the application can continue to work except it should stop checking messages. During the trial period Mail Print will put a banner on all the printed documents to indicate how much longer the trial period will last for. It's quite common for customers to try the software and decide not to buy only for them to come back some time later and try again, to for allow this Mail Print will reset the trial for each new version.

   The splash screen will indicate how much longer the trial will run for and give the customer an opportunity to buy Mail Print and enter their registration key.

2. Trial extensions. To extend the trial the user just needs to type extension into the keycode field. This lets us extend a users trial without having to issue a new keycode. The extension will last for 14 days and can only be done once.

3. Expiring keys. Currently when I accept a purchase order from a customer I deliver a full keycode straight away. Mostly this works OK but there are a regular stream of customers who never pay the invoice. For new purchase orders the key generator will issue a temporary key which will work for 90 days, when the customer pays their bill they will get a full keycode, this can be automated so that it is transparent to the customer.

4. Mail Print will be available in Standard and Professional editions. The mechanism which handles this can support new versions in the future.

5. Key Format. There is a trade off here between the security of the key and ease of entry. I have been surprised by how difficult some users find it to enter the key-code, I'm pretty sure some of them don't know what copy and paste is and they certainly have problems distinguishing 0 with O and 1 with l. The key-name is a frequent problem, the current key generator will use the customers business name if it is available but users still try and enter their own name when they register. To solve both of these problems I am going to disconnect the users name from the key-code and stick with a short numeric only code something like this:

   1234-5678-9012-3456-7890

   This should eliminate a lot of support issues, it remains to be seen what impact it will have on crackers. The key will be packed using modular arithmetic to make it as short as possible and have a simple checksum to make sure it is valid on entry.

6. Key Verification. Rather than focussing too much on strong encryption of the key I'm going to rely on partial verification of the key-code, there will be a section of the key with a secret bit pattern. Each new release of the software will only check one of these bits which should frustrate anybody trying to create a key generator, as soon as one is released I can produce a new build which checks an extra bit and makes the generator useless.

7. Upgrading. Currently I rely on a back end system to handle upgrades, customers get a completely new key-code. This works well so I don't plan to change it.

8. Volume licenses. The key-code will hold the quantity of licenses the customer has bought. One area I know I loose business at the moment is from customers who purchase a single license then install the software on many machines. Although I don't have an accurate figure for this I see enough support emails hinting at it that I am convinced it is costing me revenue. Although I'm not going to implement it straight away at some point in the future I will write some local network checking code to identify overuse.

9. Online Activation. Up to now I have been quite negative about online activation schemes, the mechanisms in Windows and Office have caused me problems a number of times even though I am using fully licensed software. However there is a problem with the use of stolen credit cards which results in chargebacks and to a lesser extent people continuing to use the software after a refund has been issued.

   Mail Print will use a passive activation scheme so if it can't make a connection to the server for some reason it will assume everything is OK and there is a legitimate reason for this, only if it can reach the server and the server tells it the key-code is illegitimate then it will stop working. This will provide a mechanism to deactivate the software without inconveniencing any legitimate customers.

Now all I have to do is write the code!

It was quite a substantial amount of work but relatively simple to do, I'm just glad I developed in C++ from the start. If I'd been using Delphi as some of my competitors have I'd be stuck at this point.

I can now get back to the Mail Print upgrade which has been taking much longer than expected.

It looks like a fairly small change to the code and a recompile of the port monitor is all I need although I'm going to take the opportunity to pull wxWidgets out of the port monitor at the same time.

There is however one large problem for me in using FogBugz and that is it isn’t easy to install on most web hosts. The solution to this up until has been to setup a separate hosting account at Server Intellect. After some initial problems this has been OK but I really wanted to offer my customers the ability to track issues in our web site, this was proving to be more difficult than it should have been.

I looked at a number of open and closed source solutions, installing most of them on a local test server. Sadly it seems there is a lot of software out there with reliability and security problems, a quick glance through the PHP code showed many opportunities for sql-injection type attacks.

One application I looked at some time ago is HelpSpot written by Ian Landsman. I have been following Ian’s blog about developing HelpSpot for some time but had initially ruled it out because one of it’s requirements is the installation of the Zend Optimizer. This wasn’t available on my original shared web hosting account but I have just recently upgraded to a dedicated server so I decided to take another look.

Installation was very straight forward, first I needed to setup a database in the control panel on my host then upload the application. There is a configuration file to edit with the database details and an install script to run. The whole process is very simple and took less than ten minutes.

Configuration is a bit more complex, a couple of options I needed to change were quite hard to find. The upside to this of course is you are likely to find just about anything you need to modify. There is quite a nice category system which lets you split different types of calls, sales vs support for instance. Each category can then have a set of tags which you tick for each call, in my case I setup tags for different products and call types. Once I have been using it for a while I should be able to gather stats on each product’s support load.

During normal day to day use I spend most of my time in the workspace, an in-box for support requests. The look and feel is very similar to a web based email client with a general in-box and my own queue. When a customer open’s a request you can see the complete history of the request and you have the option to add both public and private notes. This can be slightly confusing as by default notes are private so if your aren’t careful enough your customer might not see your replies. The next release of HelpSpot has an option to make note public by default so this should resolve this issue.

It’s still early days for HelpSpot but it has got off to a good start, it has a nice polished feel to it, well done Ian.

But why do Dell have to install so much stuff on it, so far I have removed Adobe Acrobat Update, Adobe Reader, AOL Coach, AOL Connectivity Services, AOL Spyware Protection, AOL UK, AOL Screensaver, ARTEuro, Corel Paint Shop Pro, Corel Photo Album, Learn2 Player, various McAfee tools, MyWay Search Assisnant, Real Player Basic, Sonic Update Manager, Tiscali Internet, Viewpoint Media Player, Wanadoo Europe Installer, Microsoft Works, Modem Helper, Digital Line Detect, Dell Cineplayer, Dell Cineplayer Update, Dell Media Experience and Dell Support.

There is still some more to go once I have figured out if it is important, ugh!

As is often the case the reality is often quite different from the theory, over the last week I have been working with several frustrating problems in third party components in my own software.

Most commercial software has bugs, it would be quite unreasonable to expect components to be any different from the rest of the software world. The problem comes when your component supplier’s priorities don’t match your own. My business is small and flexible enough to address most issues in the product within a day or two, this gives us a huge advantage over bigger competitors who might not be so nimble.

Unfortunately even if your component vendor is able to respond as quickly as you you are still looking at double time to fix and resolve any problems. Sadly it’s usually much worse than that, it’s quite rare to find a component developer who gives support a high priority.

One option is to purchase source code to the components you are using, you can then dive in and fix any problems you encounter yourself. Back in the real world this isn’t much of a solution, the code is usually written with different conventions to your own and the learning curve is often substantial. Right now I’m struggling with some code in a HTML printing library, the issue I have will require many changes throughout the code.

Having gone through these problems with every third party library or component I have used I am coming to the conclusion that I will end up rewriting the code for all of them myself in the end. As to whether it makes sense to avoid using components from the start I’m not so sure, getting your product to market quickly is probably more important.

There is a cost to listing on these sites, a small fee to get listed quickly or at all but more importantly the time managing updates or fixes for stolen key codes. My problem is I don’t know whether this investment in time and money gives me a large enough return, one of the most important things I figured out about this business is not to invest if you can’t measure the return you are getting.

Normally I track customers at my site by setting a cookie when they first arrive so by the time they get to order the software I can see where they first came from. For both CNet and Tucows this isn’t feasible as they host the software on their servers so the customer will download and try without visiting my sites.

The way I am doing this is by embedding the id of the download site in the file name of the program, for instance setup.exe is named setup_cnet.exe for the CNet site and setup_tucows.exe for the Tucows site. The installer stores the setup name in the registry and a small linking tool reads that information and embeds it in the url when launching the web browser, when the customer lands at my sites a cookie is set and tracking is working again.

Serving up a different file for all the download sites and affiliates would be a nightmare but fortunately Apache the server software on my web host supports a facility called url rewriting. This allows you to serve a different file to the one requested in the url, in my case CNet links to setup_cnet.exe and Tucows to setup_tucows.exe but the actual file downloaded is setup.exe. The important thing is this isn’t a redirect so the filename remains intact when downloaded. Enabling this required just two lines in my .htaccess file:

    RewriteEngine on
    RewriteRule ^setup_[a-zA-Z0-9]*\.exe$ /dl/setup.exe

This works by matching the url with a regular expression, anything starting with setup_ and ending with .exe and serving up the setup.exe file instead.

Storing that information in the registry is fairly easy, I use Inno Setup to create my installers and that has a variable {srcexe} which holds the path and name of the setup program. I just store that whole path in the registry ready to be read and interpreted when the user selects a link in the software to my web site.

If you want to have a play around with this I have created a sample (1 kb) which demonstrates the concept.

A simple example of the steps you go through follow, here I will create a simple function to add two numbers:

1. The first stage is to write a small test, in this case we can check that 2 + 2 = 4

ASSERT(AddTwoNumbers(2, 2) == 4);

2. Now we have our test we can write a function to implement just enough to pass the test:

int AddTwoNumbers(First, Second)
{
return 4;
}

3. You can see here we have taken a pretty extreme example but it shows the principle that you take very small steps forward to make sure your tests and code are thorough.

4. Running our test will now pass but we know we need to do a bit more, so now we can add a new test to break the code:

ASSERT(AddTwoNumbers(1,2) == 3)

5. Now our test fails and we need to add some more code to fix the test:

int AddTwoNumbers(First, Second)
{
return First + Second;
}

Ultimately we will end up with a suite of tests which cover the code extensively however this isn’t the final stage. There may be some duplication in the code so we should refactor it to remove any repeated sections while continuing to run the tests to make sure nothing gets broken. The tests provide a check on the quality and should be run with every build and check-in to make sure nothing gets broken.

So how does this relate to writing a printer driver, the main problem I face with the driver is I haven’t written one before so everything is new. There is documentation as part of the DDK but it is pretty poor and if you visit the DDK newsgroups a substantial number of replies to new driver writers just point people to the samples in the DDK. This is fine except the samples are standard driver code, they obviously haven’t been in any way to help people understand what is required of the various functions.

My solution to this problem has been to write tests which exercise the sample driver, as I implement each function I can load up the DLL’s from the sample plotter driver and create tests for each exported function which let me explore the way it works. Once I have a complete and rounded set of tests for the sample I can then run those tests against my own code and start fixing the failures and adjusting the tests which should be different.

After a bit of research the decisions become a bit clearer. The product the driver is going to become part of only runs on Windows NT type systems, ie NT, 2000, XP and 2003 server and we have no intention of supporting the 95/98 series which has been obsolete in business for at least 5 years now.

The first choice is whether to use the Microsoft universal driver model, this is a set of standard driver dll’s which come with Windows and support PCL and PostScript type printers out of the box. As a driver writer all you need to do is write the configuration information on what features your printer has and how to select them in the print file. This is a nice easy model which gives you quick results but has a couple of problems for what I need to do. The PCL output is really quite unlike PDF so there is no way I could bend it to do what I needed, PostScript is a little better but to support it I would need a full blown PostScript interpreter which is what Adobe Distiller has, a project far too large to produce on my own. The alternative to this is to write a full blown printer driver which is what I am doing.

This gives me flexibility to do pretty much what I want in the driver, the only weakness I can see so far is I can’t support encapsulated PostScript which is probably not a huge issue.

The final decision is whether the driver is going to run in user mode or kernel mode. To give you a little background to this printer drivers used to run in user mode in NT 3.51 which is the safer place for them to be, a crash in the driver won’t result in a blue screen. When NT 4 was one of the main features was an increase in performance over 3.51, to achieve this some of the drivers were moved into the kernel and so to support NT 4 I have to write a kernel mode driver. In Windows 2000 I have a choice of kernel and user mode and finally in Longhorn the choice is gone and its user mode all the way.

Debugging a kernel mode driver seems like a pretty painful process and as the long term trend is towards user mode I have decided to abandon NT 4 support and stick with a user mode driver. If I look through my web logs it seems there aren’t many NT4 clients being used and by the time the project is released I don’t think this is going to have a commercial impact.

There are two reasons I started this project which will become a standard module of the main product of my software Print Distributor. The first is I have been finding a substantial number of my customers are using my software to create PDF files in conjunction with Adobe Acrobat Distiller. Making this work is far from trivial, it involves configuring my software to print to file using a PostScript driver then setting up Distiller with watched folders to convert that file to a PDF or calling Distiller with some command line options. Wanting to avoid customers having to configure options like the dialog above I decided it would be much better if the PDF creation was handled right in my software taking away the need to install Acrobat at all.

The second problem I have is customers who need to modify their output after they have printed. There are lots of reasons they might want to do this from selecting different paper trays for copies through to water-marking the final print. At the moment Print Distributor doesn’t have an option for this because we pick up the print job after it has been rendered by the printer driver, this means we can’t really modify the file because we can’t hope to understand every different format of prn file being used. By using a restricted set of PDF functions it should be reasonably easy to use PDF as an interim format as jobs pass through Print Distributor.