Different versions of the same program
-
Use #ifdefs to conditionally compile the portions of code that implement the additional features. For example:
#ifdef SPECIAL_VERSION
// ... code for some special feature here
#endif#ifdef PRO_VERSION
// ... code for pro feature here
#endifThen you just need three targets in your workspace, Standard (which defines neither symbol), Pro (which defines PRO_VERSION), and Special (which defines SPECIAL_VERSION). --Mike-- http://home.inreach.com/mdunn/ This posting is provided "as was" with no warranties, guarantees, lotteries, or any of those little bags of peanuts you get on planes. You assume all risk for crossing the street without holding mommy's hand. © 2001 Mike's Classy Software. Member FDIC. If rash develops, discontinue use. :love: your :bob: with :vegemite: and :beer:
We did it this way with our last release, and I have to say it quickly became a nightmare. The code was so full of #ifdef's that it became hard to read, people ( not me, of course ;)) always seemed to stuff up the #endif so that some builds didn't work, etc. I think it can work, but my preferred way now is to have each function blocked in whole by #ifdef's so that I can plainly read what each function does within a single block. I've also read the proposition that #ifdef is a debugging nightmare because you essentially have several different programs you are building, while I tend to agree with, but needing different versions, there really isn't much choice. I would prefer the idea of using dll's overall, although we are looking for cross platform solutions with our project, so that is not really an option. Christian After all, there's nothing wrong with an elite as long as I'm allowed to be part of it!! - Mike Burston Oct 23, 2001
-
Hi, I need to create different versions of my program. For example, there will be a professional, a standard and a special version. Standard version is the basic version. Special and Professional versions will include more features. Creating 3 projects for such a thing seems silly. For example, when I change a part of the code, then I must change it for all three projects. :(( I am really in a big trouble. :confused: I am sure that there are easy ways to do this, but I dont know them. Do you know any programs or ways to do this? Thank you very very much for any helps in advance Kind regards Mustafa Demirhan
What about a license key limitation? You can switch off different parts according to the key, with the advantage that there is only one codebase. Also if customers want to upgrade, all they have to do is pay for an upgraded key. Steve. "God Mike, you're sick!" "If people weren't sick we wouldn't need penicillin."
-
What about a license key limitation? You can switch off different parts according to the key, with the advantage that there is only one codebase. Also if customers want to upgrade, all they have to do is pay for an upgraded key. Steve. "God Mike, you're sick!" "If people weren't sick we wouldn't need penicillin."
I think that is the best solution. But the disadvantage of this approach is that; professional version of my program has an additional components that are about 1 MB. So, these components must be distributed with all verions. Anyway, I think I will use license key limitation. Thanks for all answers. :rose: :rose: :rose: Kind regards Mustafa Demirhan
-
I think that is the best solution. But the disadvantage of this approach is that; professional version of my program has an additional components that are about 1 MB. So, these components must be distributed with all verions. Anyway, I think I will use license key limitation. Thanks for all answers. :rose: :rose: :rose: Kind regards Mustafa Demirhan
That's not necessarily true. If you dynamically load your plug-ins then you don't need to package them with the lower level versions. It takes a bit more work to make the interface and system dynamic but it will save you testing and development time in the long run. IMHO In testing mode all you have to do is set the proper level of security and then jsut restart the program or if you make an unload and load function then you can do it without restarting.
Todd Smith
-
That's not necessarily true. If you dynamically load your plug-ins then you don't need to package them with the lower level versions. It takes a bit more work to make the interface and system dynamic but it will save you testing and development time in the long run. IMHO In testing mode all you have to do is set the proper level of security and then jsut restart the program or if you make an unload and load function then you can do it without restarting.
Todd Smith
Yep. That's better! ;) Mustafa Demirhan
-
I think that is the best solution. But the disadvantage of this approach is that; professional version of my program has an additional components that are about 1 MB. So, these components must be distributed with all verions. Anyway, I think I will use license key limitation. Thanks for all answers. :rose: :rose: :rose: Kind regards Mustafa Demirhan
I would also suggest using License Keys to resolve this. This has several advantages; you don't need to clutter the code with lots of ifdefs; you can upgrade your customers by simply issuing a new license key; you can provide trial versions of the professional (or any other) version so the customer can evaluate the full product and then just license whatever they purchase. I have just started using License keys in ED for Windows for the first time. Previously I had separate Trial and Full Versions, which was always a pain to manage. Moving to license keys has had more than its fair share of problems, but I hope it is settling down now. I'm using a complex home grown scheme and the problems have been largely of my own making. I would avoid using any third party licensing systems. The License Keys in ED4W give me a lot of control including the ability to specify an Upgrade Protection Period. This is the period in which the customer can get upgrades free of charge, and is typically 12 months from the date of purchase, but can be anything. And finally they give me improved control over piracy, which unfortunately is a big problem for us all. You can download a copy of ED (see sig) and get a feel for the licensing scheme, if thats of interest. Neville Franks, Author of ED for Windows. Version 4.01 just released, with a C++ Class View that actually works. www.getsoft.com
-
I would also suggest using License Keys to resolve this. This has several advantages; you don't need to clutter the code with lots of ifdefs; you can upgrade your customers by simply issuing a new license key; you can provide trial versions of the professional (or any other) version so the customer can evaluate the full product and then just license whatever they purchase. I have just started using License keys in ED for Windows for the first time. Previously I had separate Trial and Full Versions, which was always a pain to manage. Moving to license keys has had more than its fair share of problems, but I hope it is settling down now. I'm using a complex home grown scheme and the problems have been largely of my own making. I would avoid using any third party licensing systems. The License Keys in ED4W give me a lot of control including the ability to specify an Upgrade Protection Period. This is the period in which the customer can get upgrades free of charge, and is typically 12 months from the date of purchase, but can be anything. And finally they give me improved control over piracy, which unfortunately is a big problem for us all. You can download a copy of ED (see sig) and get a feel for the licensing scheme, if thats of interest. Neville Franks, Author of ED for Windows. Version 4.01 just released, with a C++ Class View that actually works. www.getsoft.com
I downloaded your program. It is really great. I am also using a similar protection system in my program ( Macro Angel ) and I will surely use different types of License Keys to resolve this. PS: Which protection system are you using? Are you using a third-party protection library, or did you write your own functions? Kind regards Mustafa Demirhan
-
I downloaded your program. It is really great. I am also using a similar protection system in my program ( Macro Angel ) and I will surely use different types of License Keys to resolve this. PS: Which protection system are you using? Are you using a third-party protection library, or did you write your own functions? Kind regards Mustafa Demirhan
I downloaded your program. It is really great. Thanks - many years of hard work :) I am also using a similar protection system in my program ( Macro Angel ) and I will surely use different types of License Keys to resolve this. I've just download MacroAngel and look forward to trying it. From the info on your site it looks and sounds impressive. I've been using Pitrinec Software, WinSchedular www.getsoft.com/rec_software_tools.html#WinSchedular which is quite good. PS: Which protection system are you using? Are you using a third-party protection library, or did you write your own functions? Everything I've ever read says don't use third-party protection as they are often cracked, with hacks posted on the Web. There are posts about this in the lounge and there are some good Web sites about Software Protection. If you would like some URLs let me know. Some of the commercial schemes are very easy to crack for people with just a little experience and the right tools. So to answer the question we have written our own. I could be fooling myself in that it is easy to crack as well, and I'd certainly be interested to know if any CP'ers out there can crack it. I'll happily give a free copy of ED to anyone that cracks it.:-D The downside is that designing and implementing your own scheme is a lot of work. The upside is you have total control and can implement precisely what you need instead of trying to work around what some commercial system offers. And it is less likely to be attacked, and hopefully cracked. Neville Franks, Author of ED for Windows. Version 4.01 just released, with a C++ Class View that actually works. www.getsoft.com
-
I downloaded your program. It is really great. Thanks - many years of hard work :) I am also using a similar protection system in my program ( Macro Angel ) and I will surely use different types of License Keys to resolve this. I've just download MacroAngel and look forward to trying it. From the info on your site it looks and sounds impressive. I've been using Pitrinec Software, WinSchedular www.getsoft.com/rec_software_tools.html#WinSchedular which is quite good. PS: Which protection system are you using? Are you using a third-party protection library, or did you write your own functions? Everything I've ever read says don't use third-party protection as they are often cracked, with hacks posted on the Web. There are posts about this in the lounge and there are some good Web sites about Software Protection. If you would like some URLs let me know. Some of the commercial schemes are very easy to crack for people with just a little experience and the right tools. So to answer the question we have written our own. I could be fooling myself in that it is easy to crack as well, and I'd certainly be interested to know if any CP'ers out there can crack it. I'll happily give a free copy of ED to anyone that cracks it.:-D The downside is that designing and implementing your own scheme is a lot of work. The upside is you have total control and can implement precisely what you need instead of trying to work around what some commercial system offers. And it is less likely to be attacked, and hopefully cracked. Neville Franks, Author of ED for Windows. Version 4.01 just released, with a C++ Class View that actually works. www.getsoft.com
In my years of hacking/cracking, I discovered 1 thing. Figuring out how to generate a registration code wasn't important. Figuring out how to just trick the program into ignoring the registration code was much easier. So many application have this type of thing. if (CheckRegistration ()) exit (1) (you get the idea) So all you have to do is comment out that one line (or NOP to be more specific) and the program is broken. Things you can do to help yourself. 1. Make it such that the registration code has to set many differnent variables in the program for the program to work. 2. Set these variables in different places in the program. (Thus they have to find many pieces of code to hack.) But still, that doesn't really protect you. Just makes it a little bit harder. Side note about hacking data files. To help make data files more secure, they need to be: 1. Encoded. (Make it harder to spot key text or data) 2. If saved multiple times with the same dataset they should generate GREATLY different output. Such things as seeding an encoder with a random variable works. (This help to protect against the "change 1 thing and compare data files to see what changed" attack. 3. Use multiple encoding/crytography systems. (This just really makes a hackers day. 99% of them are expecting 1 level of encoding.) In our data files for our program, we use standard crytography, random seed encoding and positional encoding. It makes for very hard to decode data files. Good hackers can always locate your code that reads and writes the files. So ultimately, your data files can be hacked. As long as the hacker has the program that can read/write the data, there is NOTHING you can ever do to protect yourself 100%. A hacker can always break your program at ::WriteFile and then track backwards. Tim Smith Descartes Systems Sciences, Inc.
-
In my years of hacking/cracking, I discovered 1 thing. Figuring out how to generate a registration code wasn't important. Figuring out how to just trick the program into ignoring the registration code was much easier. So many application have this type of thing. if (CheckRegistration ()) exit (1) (you get the idea) So all you have to do is comment out that one line (or NOP to be more specific) and the program is broken. Things you can do to help yourself. 1. Make it such that the registration code has to set many differnent variables in the program for the program to work. 2. Set these variables in different places in the program. (Thus they have to find many pieces of code to hack.) But still, that doesn't really protect you. Just makes it a little bit harder. Side note about hacking data files. To help make data files more secure, they need to be: 1. Encoded. (Make it harder to spot key text or data) 2. If saved multiple times with the same dataset they should generate GREATLY different output. Such things as seeding an encoder with a random variable works. (This help to protect against the "change 1 thing and compare data files to see what changed" attack. 3. Use multiple encoding/crytography systems. (This just really makes a hackers day. 99% of them are expecting 1 level of encoding.) In our data files for our program, we use standard crytography, random seed encoding and positional encoding. It makes for very hard to decode data files. Good hackers can always locate your code that reads and writes the files. So ultimately, your data files can be hacked. As long as the hacker has the program that can read/write the data, there is NOTHING you can ever do to protect yourself 100%. A hacker can always break your program at ::WriteFile and then track backwards. Tim Smith Descartes Systems Sciences, Inc.
Yes, when I first learned Assembly, I realized that such thigs are really easy. Especiall with some tool like Sofice, I dont believe that a non-crackable protection system can be written. Anyway, there are some GOOD guys that purchases our programs. So we should mainly focus on satifying our potential market. :cool: Mustafa Demirhan
-
In my years of hacking/cracking, I discovered 1 thing. Figuring out how to generate a registration code wasn't important. Figuring out how to just trick the program into ignoring the registration code was much easier. So many application have this type of thing. if (CheckRegistration ()) exit (1) (you get the idea) So all you have to do is comment out that one line (or NOP to be more specific) and the program is broken. Things you can do to help yourself. 1. Make it such that the registration code has to set many differnent variables in the program for the program to work. 2. Set these variables in different places in the program. (Thus they have to find many pieces of code to hack.) But still, that doesn't really protect you. Just makes it a little bit harder. Side note about hacking data files. To help make data files more secure, they need to be: 1. Encoded. (Make it harder to spot key text or data) 2. If saved multiple times with the same dataset they should generate GREATLY different output. Such things as seeding an encoder with a random variable works. (This help to protect against the "change 1 thing and compare data files to see what changed" attack. 3. Use multiple encoding/crytography systems. (This just really makes a hackers day. 99% of them are expecting 1 level of encoding.) In our data files for our program, we use standard crytography, random seed encoding and positional encoding. It makes for very hard to decode data files. Good hackers can always locate your code that reads and writes the files. So ultimately, your data files can be hacked. As long as the hacker has the program that can read/write the data, there is NOTHING you can ever do to protect yourself 100%. A hacker can always break your program at ::WriteFile and then track backwards. Tim Smith Descartes Systems Sciences, Inc.
Hi Tim, Your comments are spot on and are some of the things I do in ED for Windows. The ïf (Registered()) .. issue is a serious problem with many commercial schemes. ie. "Protect your app with only 2 lines of code". I don't agree about the Registration code though. It is my understanding that many applications are cracked using Key Generators, so if for no other reason you need to make this as difficult as possible. The other issue is where someone posts a valid registration key on a Web site, enabling anyone to turn your app into a fully working version. I've taken measures against this as well. Neville Franks, Author of ED for Windows. Version 4.01 just released, with a C++ Class View that actually works. www.getsoft.com
-
Hi Tim, Your comments are spot on and are some of the things I do in ED for Windows. The ïf (Registered()) .. issue is a serious problem with many commercial schemes. ie. "Protect your app with only 2 lines of code". I don't agree about the Registration code though. It is my understanding that many applications are cracked using Key Generators, so if for no other reason you need to make this as difficult as possible. The other issue is where someone posts a valid registration key on a Web site, enabling anyone to turn your app into a fully working version. I've taken measures against this as well. Neville Franks, Author of ED for Windows. Version 4.01 just released, with a C++ Class View that actually works. www.getsoft.com
In the end you're spending time on a feature that's not used by your "paying" cutomers. I think you just need a simple protection scheme that prevents casual copying of your program. Since any program can be cracked what's the point of spending time on writting protection code? my .02
Todd Smith
-
In the end you're spending time on a feature that's not used by your "paying" cutomers. I think you just need a simple protection scheme that prevents casual copying of your program. Since any program can be cracked what's the point of spending time on writting protection code? my .02
Todd Smith
But where does "casual copying" end? If a company purchases two licenses and has five or ten people using a product, is that "casual copying"? It isn't in my opinion, and this is one of the issues that I face on a regular basis. I can't afford to forgo this lost revenue, especially when all 5/10 users request and expect support. We may need to agree to disagree on this. Neville Franks, Author of ED for Windows. Version 4.01 just released, with a C++ Class View that actually works. www.getsoft.com