If he wants to go the "whole hog", he could use our Call Home Licensing technology: http://www.tectite.com/tectitelic.php Russell Robinson (russpub at rootsoftware dot com) Author of TTMaker (Advanced Timetabling Software) http://www.rootsoftware.com

I've been deploying apps with the cut down version of InstallShield that came with Visual C++ v6 for some years. It's getting a bit old and I've had some problems with it recently. I'd appreciate comments from other C++ developers about the strengths and weakness of the commercial installer programs available (e.g. Wise, Installer VISE, InstallShield, etc.) Russell Robinson (russpub at rootsoftware dot com) Author of TTMaker (Advanced Timetabling Software) http://www.rootsoftware.com

Hi Taka, I'm the friend of Neville's. Too busy coding to watch these forums at the moment, so Nev was kind enough to prompt me about your interest. Our new product is close to release and will initially provide licensing and customer relationship management (FYI: you need automated customer relationship management to do licensing well). Later (early 2004) we'll be providing "unique to your application", heavy duty software protection; protects your software from crackers. Licensing is for protecting against normal thieves, software protection is for protecting against crackers. We also plan to interface (one way or another) to automatic payment processors. Initially, the licensing features will work with C/C++ (and PHP). Drop me a mail if you want to get involved in our early release program (ie. start using it now :rolleyes: ). (BTW, anyone who's interested is welcome to contact me regarding our early release program). Russell Robinson (russpub at rootsoftware dot com) Author of TTMaker (Advanced Timetabling Software) http://www.rootsoftware.com

Great joke, but you got the nation wrong..... That joke is told in Australia about New Zealand! Only it's not a joke. ;P Ah, New Zealand...a land where the men are men and the sheep are nervous. Did you know that thousands of New Zealanders emmigrate to Australia each year? It increases the average IQ of both countries.... Russell Robinson (russellr@rootsoftware.com) Author of TTMaker (Advanced Timetabling Software) http://www.rootsoftware.com

I hope this brings a smile to someone.... /* * To create tool tips for position information. We use tracking tooltips * which we control directly because the standard CToolTipCtrl doesn't seem to * work reliably when the whole window is filled with rectangles that require * tool tips (sometimes they display, but mostly don't). There must be some * magic, undocumented, typically-Microsoft-braindamaged way of getting them to work; * doing it this way is hard work, more code, but it works reliably! */ void WorkingTimeslotCtrl::CreateToolTips(void) { // I really hate Microsoft if (hPositionTip != NULL) { ::DestroyWindow(hPositionTip); hPositionTip = NULL; } // Microsoft is just so bad INITCOMMONCONTROLSEX icex; // Load the tooltips class from the DLL. icex.dwSize = sizeof(icex); icex.dwICC = ICC_BAR_CLASSES; // I really must sell my shares in Microsoft if(!InitCommonControlsEx(&icex)) ..... (Author not disclosed). Russell Robinson (russellr@rootsoftware.com) Author of TTMaker (Advanced Timetabling Software) http://www.rootsoftware.com

John, I feel your pain. Ouch! I've come in late on this thread, and Neville Franks has already declared my interest in this topic. Reading through though, I've noticed some really good ideas put forward - timing out registration codes, using a temporary registration code until payment is made, encrypting stuff, communication back to your server. These are all good. There's at least one bad idea too - a "drop in" library that provides crack proofing. This won't and can't work. If 100 apps use a library that protects their software, then one crack on that library cracks all the 100 apps too (or, at the very least, makes it easy to crack all the apps). Interestingly, nobody has actually said "you can't crack proof your software, so don't bother, just sell it cheaply and let anyone copy it". That's the usual diatribe one gets from at least someone when you talk about protecting your software from theft. BTW, is anyone interested in an article that debunks the Free Software Foundation's Manifesto? (I like the FSF, I'm extremely grateful to them, but the Manifesto is rubbish). The important point is that any protection system you use *will be* cracked if someone really wants to crack it. Similarly, your car *will be* stolen and your house *will be* broken into if some thief wants it badly enough - no matter what security measures you use. And that's exactly the point....people who say "don't protect your software" are missing the fact they they themselves lock their own doors! It's all about deterrents and increasing the effort required by the thief. Also, a *really* good idea, that was mentioned indirectly by someone, is to let the cracker think he has done it! They move on, and lose all their kudos when their posted crack doesn't work. I always think it's like kicking them in the groin. Oh Yeah! Enough ranting. Here's my strategy.... 1. Use strong encryption for registration codes and any other encryption you use. Weak encryption means that the thief can attack you there; and possibly generate registration codes themselves. That's the worst scenario possible. Strong encryption forces them to play by your rules. 2. Force them to crack your software (strong encryption does this for you). This knocks out all casual crackers and customers who just want to "lend it to their friends". The cracker must now play the game you've created for him. 3. Recognize that a Turing machine is a simple beast and a computer is just a glorified Turing machine. Any code in a Turing

Hey, does anyone remember when 32 bit microprocessors became readily available...back in 1980-81? What happened between 1981 and the mid-90's is what I call the "dark age of computing". It's when Microsoft and Intel set back computing by 15 years. Why would you use 32 bit processors when you can go back to 16 bit? Duh! We already had "real cpus" and those twirps made the world use sticks and stones. :(( Russell Robinson (russellr@rootsoftware.com) Author of TTMaker (Advanced Timetabling Software) http://www.rootsoftware.com

I'm in the process of finalising a product that addresses all these issues for you and includes a Customer Relationship Management system and copy protection. If you're not in a hurry and you're happy to look at a new product, just send me some email and I'll keep you informed of progress. At this stage, the first version will be available in the next couple of months. The price will be low and the copy protection will not be easily cracked like other systems such as Armadillo. I don't want to do a sales pitch on CodeProject, so I'm not going to tell you the website or the product name. Just contact me directly for more info. Russell Robinson (russellr@rootsoftware.com)

A text report I print from my MFC program is different in Print Preview versus hard copy. In fact zooming in and out in Print Preview changes what's displayed. Example: one column in my report might be:

My dog has fleas.

But in Print Preview, this might show as:

My dog has fl

Given Microsoft Word also shows these sorts of anomalies in Print Preview, I've always assumed it's a difference between rendering on the screen versus rendering on the printer. So, a sanity check please: should I worry about a bug in my program or not? (PS I've spent an hour checking the web for something that says "print preview is only an approximation and may never be an accurate representation of the printed output" - but haven't found any such statement.) Russell Robinson (russellr@rootsoftware.com) Author of TTMaker (Advanced Timetabling Software) http://www.rootsoftware.com

Well, I'm easily old enough to be your father (and to many more around here). But I know of at least one person who's old enough to be your grand father. And he's still coding every day. :-) (oh, that smile was an effort.....I'll have to go and have a little sleep now...) Russell Robinson (russellr@rootsoftware.com) Author of TTMaker (Advanced Timetabling Software) http://www.rootsoftware.com

Paul Ingles wrote: mighty large corporations -- Flexlm and Macrovision -- and these have been broken. Sure, but as is often the case, mighty corporation doesn't always equate to good software. Paul Ingles wrote: Going back to your questionnaire I would think most people would want actual source code, and this could then be modified/suited to an application with further guidance etc. Kind of a protection consultancy as it were. I'll give you a little hint of where we're going with this... Our product is not going to be a straight binary library that you plug in and use. That will be a small part of our offering I suspect (mainly to protect our product from theft!) The aim is that you'll buy our product and then spend less than a day adding the security to your system. We also plan to have a "lite" version that you can plug in in about 10 minutes, but with, obviously, less security. So, the developer is completely in control at all times. And, of course, part of our product is to put in serious anti-debugging, anti-cracking code. Given the responses to the survey, it looks as though C++ is the target. VB has some interest, but we're likely to look at that down the track. Java has almost no interest. As for schedules, it's looking like late May for Beta testing. Russell Robinson (russellr@rootsoftware.com) Author of TTMaker (Advanced Timetabling Software) http://www.rootsoftware.com

Paul Ingles wrote: I still think the best way that protections can be produced is by doing them yourself, the problem is that it does require thought on the part of the developer. Not only that, but quite specialist thought. That's the issue. Why don't we all write our own C++ compilers? Because it's quicker and easier to buy someone else's; one that's proven, etc. Paul Ingles wrote: I accept the point about not providing a single interface, however, assuming that crackers do ever reverse code that implements your routines, there will effectively be code fingerprints. Things that would identify it as being an X Protection routine, for example, certain system calls that were used to identify hardware etc. By knowing that it could be a protection implementing your code, it might be possible to glean some light from other attacked applications to help its cracking. Yes, that's the main "electronic warfare" we're entering into. My system addresses this very issue. Again, it won't be completely uncrackable, but the idea is to make it sooooo hard, and sooooo time-consuming, and different in every product where it is used. The distributed stuff is fine (with the problems you've mentioned) for apps that must work with the net. But what about most apps that don't require the net to operate? That's the first place I'll be focussing on. Paul Ingles wrote: I might start doing a little thought into this and post an article over the weekend about my thoughts, set out possible plans for authentication, securing the communication and how it could then be called from an App. I look forward to hearing your thoughts. Russell Robinson (russellr@rootsoftware.com) Author of TTMaker (Advanced Timetabling Software) http://www.rootsoftware.com

I guess I'm an optimist in most things. It took nearly 5000 years (or maybe 35000 years) to create the concept of a Liberal Democratic Society. Clearly, they are the most prosperous of societies on Earth and many people have died either creating them or defending them. Our only real threat (apart from global annihilation through terrorism and/or war) is the really rich people who want to have absolute power too. I guess that's what you're talking about Chris: a couple of rich industries wanting to control our societies and take away freedoms. I think Liberal Democratic Societies are more resilient to those attacks than we might believe. However, it's people like yourself, who are passionate about the issue, that keep us on our toes and help to defend the freedoms we already have. I'm so inspired now :). Being an Aussie, can I write to congress or is a waste of time? Cheers. Russell Robinson (russellr@rootsoftware.com) Author of TTMaker (Advanced Timetabling Software) http://www.rootsoftware.com

Some in congress. Also, Microsoft and IBM are against it. And it Microsoft, which was recently convicted of rather nasty activity, can get away scot-free, then I'm not too worried about the congress bill(s) getting very far. You've got an election in the US soon (couple of years) haven't you? Russell Robinson (russellr@rootsoftware.com) Author of TTMaker (Advanced Timetabling Software) http://www.rootsoftware.com

Chris Losinger wrote: Russell Robinson wrote: I can't actually think of any way to stop an executable file from being read or written. the same way they'll make it impossible to read or write video and audio files: through a combination of software and compliant hardware. Like DVDs region restrictions. I don't own a DVD player, but I believe it's easy to get one that plays any DVD. Yes, I suppose it could happen, but it really would require a sea-change in the law in democratic countries. No-one would build a computer that provided hardware enforcement unless everyone *had* to. Imagine all US companies being forced to build computers that way....that would create a good market for Taiwanese computers; even if it had to be a black market. My guess is it's very unlikely.....And if we can come up with adequate software protection, there won't be a need for hardware protection. Russell Robinson (russellr@rootsoftware.com) Author of TTMaker (Advanced Timetabling Software) http://www.rootsoftware.com

Paul Ingles wrote: Protection routines have to be interwoven with the rest of your application. A simple check like "If isRegistered Then EnableWindow Else DisableWindow" is easy to remove, since you can either change the parameter for enablewindow to true, and its enabled even with a wrong code, or, change the comparison so it checks the generated code, with the generated code etc. Absolutely right. Paul Ingles wrote: Of course, if it was this simple then there would be masses of great protections. Some are better than others, but its really no substitute for creating one yourself. I'm not saying it is simple. I'm just saying it's possible. In fact, Paul, with respect, your second sentence contradicts your first one. If it isn't simple, why would you try to create one yourself? Everyone is basically saying "you can't sell a protection product that everyone can use without it being easily broken". I think this is based on these assumptions:

1. a Software Protection System will have a single interface that can be targeted by crackers
2. you can't spread the protection throughout your product
3. coming up with your own solution will always be better

On this last point, what about cryptography? The best cryptographic systems are open source. Everyone gets to see how they work. But they are still difficult/impossible to break. We're still thinking about the source code issue, and we may well provide the source as part of our offering. In other words, we'll take the challenge that a cracker might say "I'll break it if I know how it works". Our system overcomes the first two assumptions. You *won't* have a single interface that can be targeted. You *will* be able to spread the protection throughout your product. I really like the idea of a collaborative area where we can test and discuss ideas. This will definitely be part of our offering. I'm simply asking whether developers would like a system that incorporates the good ideas, the ones that work, into a product they can purchase. Russell Robinson (russellr@rootsoftware.com) Author of TTMaker (Advanced Timetabling Software) http://www.rootsoftware.com

I have worries about OS support:

1. I can't actually think of any way to stop an executable file from being read or written. The OS has to provide low level access to the disk in some way (e.g. for defragging and checking the disk), so even if the high level prevents access to the exe, you can still get to it at a lower level.
2. If the OS supports protection, then breaking everyone's protection is easy because you just break the OS code. Does anyone know a good OS manufacturer?
3. If it also relies on some hardware device (such as a dongle), I've already listed the problems with this in an earlier post.
4. How are developers going to compile programs? If the OS has a "switch off protection - development in progress" mode, then that's pretty straightforward for anyone to use.

The two ends of this problem are:

• software can always be changed
• hardware is damned inconvenient to ship

So, it seems to me that most software products (excluding the really expensive stuff) need a cheap and simple but effective software protection solution. (PS does anyone know why using HTML list causes the post to go bold?) Russell Robinson (russellr@rootsoftware.com) Author of TTMaker (Advanced Timetabling Software) http://www.rootsoftware.com

Hardware protection is really good stuff. No argument from me. But it does have some drawbacks: 1. Can be inconvenient to the user when he/she buys 5 or 10 products that each require a dongle-like object. 2. Can be expensive - for each sale you have an extra expense. 3. Probably overkill for most software systems. 4. Inconvenient to the provider and the user - the user must wait until the physical dongle has been delivered to them. With more and more software being delivered electronically, this kind of defeats the whole concept. So, I think there's still room for a good software-only system. Hopefully, the survey will tell us (and everyone - we'll publish the results). Russell Robinson (russellr@rootsoftware.com) Author of TTMaker (Advanced Timetabling Software) http://www.rootsoftware.com

Our system overcomes this difficulty.

This isn't necessarily how our product will work, but, imagine if we sold you source code and a manual.

With the source code, using some clever #define's (in C/C++) and other techniques, the protection code in your application could be:

1. spread around your app and therefore difficult to find
2. disguised; not obviously anything to do with protection
3. critical to the operation of your app - so any removal or disablement would cause your app to stop working
4. unique to your application

That's just an idea of how we can overcome these difficulties.

I recommend the following site to give you some other ideas of what can be achieved: http://inner-smile.com/nocrack.phtml Russell Robinson (russellr@rootsoftware.com) Author of TTMaker (Advanced Timetabling Software) http://www.rootsoftware.com

Your "I wonder" is accurate - previous products have been ineffective. Yes, probably any protection scheme can be overcome, but would you spend 3 months cracking a program that costs $30? Or, what if the author releases a new version every 2 months? If we were offering a Software Protection System that worked the same for every product that uses it, then, yes, it would be a gold mine for crackers. That's one of the main problems with the current protection systems that are available. Our system is different. Each product that uses our system will have protection that's unique to the product. So, if you crack our system on one product, that's all you've got. Participate in the survey (anonymously if you like). If no one wants this stuff, then we won't release it. Russell Robinson (russellr@rootsoftware.com) Author of TTMaker (Advanced Timetabling Software) http://www.rootsoftware.com