(For myself, I've always used unlock codes in the past.)

Curry

------------------

One other benefit of the key-code version: only one .exe (and thus only one project to maintain/distribute.

One idea I'm playing with for my next release (which will use reg key) is putting checksum checks in the code as well, which will also minimize cracking.

------------------

Westwood Games uses both strategies: They have a demo version with features stripped, and when you finally do buy the full version, it comes with a reg key and other forms of copy protection.

------------------
There are only 10 types of people - those who understand binary, and those who don't.

My advice to people looking to protect their demo software would be firstly: always avoid dialog boxes that ask for serial numbers. The cracker simply sets GetWindowText and GetDlgItemText calls as breakpoints, and then steps through the proceeding code to see where the real serial no. gets loaded from (or finds the comparison code and hacks that). Using a file with the serial no, and opening it with a low level function would probably be better.

I don't think there is such a thing as a non-crackable program - tho as Cobra says - if your program is sufficiently unpopular you don't have to worry because no cracker is going to be bothered.

Maybe you should just accept that it will be cracked and put a nice message in your program for the would-be cracker. If you were to place a string in memory right after the real serial number they'll see it in their debugger window. Tell them God loves them

It *is* fun to crack programs, I also like the puzzle aspect of it. It's just as fun to make cracking as hard as you can.

Rowan, I *really* like your string idea to send messages to crackers, that's awesome.

------------------

------------------

------------------
Fight(as in overkill) the Good Fight of Faith...

I should be able to only have to maintain one source code though, not two sets. All you have to do is throw in some #defines... for example, at the top of your source have:

#define SHAREWARE

Then later in your source you come to a function that isn't allowed in the shareware version so you do a check...

#ifndef SHAREWARE
void full_version_function()
{
...
... code
...
}
#endif

#ifdef SHAREWARE
void shareware_function()
{
...
... code
...
}
#endif

When you compile this, the code that is only meant for the full version won't get compiled in the shareware version, instead, a limited shareware function will get compiled. When you wish to compile the full version simply remove or comment out the #define SHAREWARE... or do the reverse, have a #define FULLVERSION at the beginning and only compile sections if FULLVERSION is defined.

Either way, you only need to maintain one source code yet you can easily compile both versions.

Of course, the downside to sending out a seperate full version of your game is that the person who gets it can then give it away to friends without the need for any registration code at all. You could always personalize the full version that you send out, perhaps with the person's full name imbedded? Hmmm...

Anyhow, that was a good article, glad I read it. It has made me rethink how to go about minimizing my losses due to pirates. Not that I think anything I create will be pirated in a big way anyhow.

------------------
Neil Roy

"O that there were such an heart in them, that they would fear me, and keep all my commandments always, that it might be well with them, and with their children for ever!" - Deuteronomy 5:29