Archive for December, 2005

If my installer… had a brain…

Recently, I was evaluating obfuscators for Moon River Milestones, and after going through all of the motions, I finally settled on one. Now, being as tight with money as I am these days, not to mention the massive costs I’ve incurred while starting up my business, I decided that I’d wait a little while before I bought it so I could decide on an installer to use as well.

So Thursday afternoon, I pulled out the Moon River Software credit card, and proceeded to spend a few thousand dollars. This software isn’t exactly cheap, which makes the evaluation process that much more important. After all was said and done, I laid out nearly $3,500. Unfortunately, not everyone is up on the times about ordering things on the internet and instant gratification. So, I had to wait until Friday afternoon somewhere around 7pm EST before I finally got all of the software I ordered.

So, back in the bat-cave I’ve spent the last two days trying to get my build environment fully automated. The ultimate goal was to have a single script that I fire off, and when it’s finished, I get a shiny new msi package which I can install and it will work, everyone will be happy, and the Wicked Witch of the West melts into a puddle. Or at least that was the plan.

Let me back up to the beginning so I can explain why all of this was necessary. When I was evaluating the installers, I decided that I liked the Wise for Windows installer the best. It seemed to have great support for web applications, could integrate very easily with Microsoft SQL Server, and it was very easy to learn. The problem that I ran into was that I wanted the user to be able to select the SQL Server database to install Moon River Milestones to. I know that some people have naming conventions they want to follow and I wanted to provide them with the flexibility to do what they wanted. But the installer was giving me the same problems I ran into back when I did my evaluation.

The Wise for Windows (WfW) has the ability to do find and replace on text strings, which seemed to work well enough during my evaluation. I ran into a problem where it stopped working entirely at one point, and after contacting support, and wasting well over 25 hours of time on it, I tried recreating my project. Everything seemed just peachy. I still had to do some work to create the custom dialog boxes which let people type the name of their database, but I decided to leave well enough alone. Support confirmed that there seemed to be some sort of problem, but they weren’t able to duplicate it. Other people had workarounds that also involved recreating their projects. I certainly didn’t want to have to recreate my project every time I wanted to make a minor change, but luckily I have something better. Source control. I have all of my code backed up in Vault, which is an incredibly great source control tool from Source Gear.

So, I had purchased WfW, and now needed to make the aforementioned changes. I had received my license for the obfuscator on Thursday night, and tried installing it on my build machine. Insert barf noises here. My build machine choked on it, and hard. The installation instructions clearly state to uninstall the evaluation version before installing the full version. Every time I tried though, it choked and died on me. Since it was integrated with Visual Studio, it fired up four separate msiexec.exe files. FOUR of them! And it still couldn’t uninstall properly.

Finally, I decided to do a repair, and it seemed to work ok. My build machine is a VMWare image, so taking snapshots isn’t a big deal for me. Speaking of which, VMWare has a great deal going. It’s called a VMWare Technology Network subscription, or VMTN for short. It gives you access to VMWare Workstation, GSX Server, ESX Server, Virtual SMP, and P2V Assistant, all for under $300. Talk about a sweet bargain. The lone caveat is that you can’t use any of the software for production use. It’s all for development use only, and you must have a VMTN license for each developer. You also can’t give demos to clients using any of the software, but since I’m just using it for development, it works out great for me.

So, with my VMWare image loaded with my obfuscator, and my new installer, I started pulling all the final pieces together for my automation. But I ran into my arch-nemesis again. The replacement feature stopped working. I spent most of Saturday trying to figure this out. Most of Sunday as well. I’d previously spent 25 hours on this one problem, so I’ve probably logged 35-40 hours for this one problem. To be specific, there’s a replace function that sets the name of the database the user wants to install to. Having had my share of problems with the obfuscator, and seen the sort of problems that installations can cause, I wanted to make sure that the user got everything right on the first try.

The installer is the first thing the customer is going to run when they download your product. They’ve already paid for it, but you want their experience to be as painless as possible. The very reason they bought your software is because they have a problem they need to solve. So, do everyone a favor and make sure your installer works, and test it as many times as you can, and in as many different situations as possible. Your customers don’t want any surprises, and neither do you.

So, after flipping through countless menus, and attempting numerous times to get the damned SQL code to execute properly, I finally noticed a seemingly innoccuous dialog box under the files I was installing. Notice anything?

fileDialog.JPG

I did too. ‘Read Only’. On a hunch, I did some experiments. It turns out that the WfW Installer copies all of the files to the target machine (even the temporary ones) with the same properties you have on your machine. And since I’m using mutually exclusive mode in Vault, my sql files were also being created as Read Only on the target machine. The replace function was failing because the installer does post-processing on the files!!

My guess is that it’s relatively simple to write out the file, and then search through the text for certain strings, as opposed to extracting the file into memory and then searching for strings to replace before writing them out. But I swear if the developer who made that decision was within arms reach when I finally realized that, I’d probably still be choking his lifeless body. So, I made a few changes, and everything seems to work fine now.

I had been hoping to do a full launch of Moon River Milestones as of Monday morning this week, but that’s simply not going to happen now. I’m so close to being completely done that I can taste it. No, I think that’s peanuts and beer. But it’s 5 minutes past midnight, and I’ve got a long day ahead of me tomorrow. Customer demos and such. You understand. So, I’m still working on the final details of the launch, but it is certainly within arms reach. Within the next few days, you’ll be able to see Moon River Milestones in all its glory.

And then the real work begins.

Post Piracy damage control

You’ve spent months, possibly years working on what you think will be your virtual cash cow. Your software will take four hundred doohickeys and turn them into over fifty thousand thingamabobs without wasting a cpu cycle. In under ten seconds and affordably priced at a mere $49.95, you’re ready to make a killing on the internet selling your software. One day, while doing some web searches to find out how prolific your marketing efforts have been, you realize the brutal truth. Your software has been pirated.

It may just be some unlocking codes that are posted, or it could be a fully cracked program that’s ready to go. The typical responses include fear and anger. Who would do such a thing and why? The fact is that it doesn’t matter. The deed has been done, and you must act in order to minimize your losses. But first, you need to know what your options are.

A typical developer would do everything he can to track down the people who are responsible and make them pay. Let’s face it. If you’re developing software, you should be well aware that tracking someone down on the internet to file a lawsuit without the help of the FBI is going to be next to impossible. The RIAA had no trouble with Napster because they used centralized servers. With the advent of distributed file sharing networks like Kazaa, Gnutella spin offs, eDonkey and dozens of others, the RIAA doesn’t stand a chance at doing it in a cost effective manner, and neither do you.

If the pirates are hosting your files or codes on a website, it is often easy to shut them down by tracking down their ISP, sending a friendly email citing your software on the site in question, and asking to have the site shut down. Simple, but not very effective. It takes two or three days to get a new service provider. The pirates are back in business, you’re out a bunch of time and effort that could have been better spent. Worse yet, copying files is easy and pirated software can spread like wildfire. In five minutes your software can be on fifty sites instead of one.

Assuming you can get a contact email address, asking them to stop isn’t usually worth the effort. Someone who didn’t care that they are depriving you of your livelihood isn’t going to care that you might not get paid for every copy. After all, they are doing the world a favor by providing your software to people cheaper than you can. Many will cite the Free Software Foundation, various freeware utilities that are better, how much your software sucks, why you should be using the GPL licensing, and why your dog needs a tummy tuck. All that is assuming you get any response at all.

You do have some worthwhile options. First of all, before you release your software at all, make their lives difficult. Don’t use an off the shelf copy protection package. Almost every one of them has been cracked, and once one has been cracked, any other software using that system can also be cracked. Second, encrypt everything. The hard coded data, error messages, registration strings, etc. Everything you can encrypt in your files should be encrypted. Second, validate your data. Use checksums to ensure that none of your files have changed. If they have changed, your software has probably been hacked and should refuse to work properly. Third, change your copy protection for major version upgrades. This makes all of your future releases immune to previous cracks.

None of these procedures addresses what to do if you haven’t taken the necessary precautions prior to release. In truth, there is really only one thing you can do to protect your software after it has been released. Find out how it was cracked, fix the software so it can’t be done again, and release a new version. Many pirates will crack one version and move on, never to return because they have already won the challenge. If you’re lucky, they will not realize that things have changed since they last cracked it.

It’s important to note that it is not always in your best interest to track these people down, nor is it always in your best interest to make changes to your software to prevent it from being pirated.

Remember that there are three types of customers. Definitely buy, definitely not buy, and maybe buy. Your goal is to divert the ‘maybe’ group from using pirated versions. Give them reasons to buy it versus using a cracked version. Chances are, if they can’t find an up to date cracked version, they will grudgingly pull out their credit cards to get the latest and greatest because bigger version numbers correspond to better software.

How long will it take you to update your software? Bare minimum, it will be a day or so, and that assumes that it’s simply a leaked license key. That’s simple enough to ban inside the software. It certainly doesn’t help for all those copies that are floating around on Kazaa though. You didn’t really expect to track all those down as well did you? Chances are, you are going to want to be thorough

Twitter Delicious Facebook Digg Stumbleupon Favorites More