>But they couldn’t push the old version into the auto-updater because the client only accepts updates from higher numbered versions
This is one of the reasons why I always make my auto-updating routines as dumb as possible: The only thing the client does is to tell the server its version and then let the server decide. If it believes there's an update, it sends the (signed) update. If it doesn't, it 404s.
This way the server (easily modifyable) has full control and there's less chance for the client (hard to modify, needs to work for any kind of update to work) to end up in a non-updatable state.
Putting as much logic as possible into the server component is definitely the way to go.
I did something similar, I would send the version as well as the md5sum of the executable.
Aside from being able to tell the 32 and 64-bit versions apart, the other advantage was that I'd be able to track whether they were running an executable with the md5sum I shipped, or if it had been hacked. Add that to an ip geolocation server, and now I've got a map of who is using a legal version and who is using an illegal version. I even plotted the success and spread of different cracks over time.. in our case, the Russian cracks usually lagged the Chinese cracks, but then had a better distribution network. Our auto-update function would check once a day on startup, based on the same version string and md5sum of the last check. So, we could see the person creating the hack.. same IP address, same version string, multiple md5sums, and their final md5sum would spread.
I also added the demo status and a unique machine id, and that let us answer questions like "Do paying customers ever install a hacked version?", "Do people who start with the hacked version ever pay?", "Into what languages should I translate my software", "How many demo users are in our funnel", "How long does it take a demo user to convert to paid", etc.
To answer the questions, at least in our particular case:
- Do paying customers ever install a hacked version?
Yes, this happened fairly often.. less than 1% of the time, but still often enough for us to take it into consideration.
There were some silly suggestions about what to do when we detected it was a cracked version. If there is _any_ chance that it would occur on a paying customer's computer, you can dismiss the silly suggestions pretty quickly. In the end we decided to just save out files which were unreadable by end users, but that we could recover the data from. Our customers had to contact us, and then we could recover the data and sort out their licensing issues at the same time. We didn't have any issue with them using a crack to get their job done, we just wanted to make sure their experience was good.. sometimes the cracks broke functionality.
Non-paying users could become customers and get their data, but this didn't really happen very often.. it was enjoyable to read their reactions on the warez forums though.
- Do people who start with the hacked version ever pay?
Um, not really, as far as I could tell. IIRC it was 1 or 2 out of tens of thousands.
You have to be careful not to spend too much time on this stuff.. if you aren't converting cracked users to paid users, then the time is better spent just improving the product.
- Into what languages should I translate my software?
In our case it was Italian, Korean, Japanese, Spanish, German, and French. We had a lot of Russian and Chinese users, but almost none of them paid, so it's not worth paying for the translation.
- How long does it take a demo user to convert to paid
We switched from a time-limited demo (30 days) to a usage-limited demo (25 saves). After using up your saves you could still use the product to learn it, but just not save or export your work, and if you needed a time-limited demo or any other kind of trial extension we would provide that for the asking. We did this because we thought that our target users were very busy, and giving them one shot to try out the product over 30 days was unreasonable.. it was more reasonable that they would have a few hours here and there to learn it and evaluate it.
Anyhow, the data on conversion time did bear out the decision.. we had users who converted from demo to paid the same day, after 1 week, after 6 months, etc.
---
In general, our approach was to encourage people to pay if they're the type of people that pay for software, and not worry too much about people that don't pay for software.
Unfortunately I don't have the actual heatmap of legit / cracked users. I do have a copy of the country by country breakdown, but I'm not sure what date range it was for.
I do remember that the cracks would come out only a few hours after we released our software.
For these numbers, legit was a combination of currently in demo, and fully paid. Anything else was a cracked version. From most total users to least, here are the top few.
US: 78% legit
China: 17% legit
Korea: 37% legit
Italy: 64% legit
UK: 75% legit
Russian Federation: 18% legit
Germany: 61% legit
Japan: 80% legit
Spain: 71% legit
Turkey: 22% legit
Sweden: 83% legit
Taiwan: 37% legit
Ukraine: 27% legit
Poland: 73% legit
France: 64% legit
Czech Republic: 51% legit
Hong Kong: 17% legit
Canada: 78% legit
Most of this isn't too unexpected. We did have an amazing Polish trainer/reseller.
Here's some more data. The number of users was quite small in most of these countries, so it's not a good sample.
Countries with 100% legit copies:
Switzerland, UAE, Peru, Vietnam, Mauritius, Malta, Morocco, Latvia, Venezuela.
Countries with 0% legit copies:
Asia/Pacific Region, Bangladesh, Chile, Costa Rica, Estonia, Kenya, Singapore, Armenia, Kazakhstan, Moldova, Syrian Arab Republic, Pakistan, Georgia, Lithuania, Indonesia
I think I've got the raw data sitting around somewhere, maybe it would be nice to put it into a blog post some time. I'd have to get permission though.
>But they couldn’t push the old version into the auto-updater because the client only accepts updates from higher numbered versions
This is one of the reasons why I always make my auto-updating routines as dumb as possible: The only thing the client does is to tell the server its version and then let the server decide. If it believes there's an update, it sends the (signed) update. If it doesn't, it 404s.
This way the server (easily modifyable) has full control and there's less chance for the client (hard to modify, needs to work for any kind of update to work) to end up in a non-updatable state.