Demo vs. Registration Required

[Sintax]

As my first FM project near completion I need to get thinking about how I am going to distribute it. As far as I see it I have two options:

1) Create a seperate runtime file for a demo version of my program that lets users only have a total of three records in the database at a time. There will then be a seperate file for the full version that people can buy.

2) Put that same kind of limitation on the full version of the program where they will have to unlock it with a username / password.

For those of you that have been following my progress, let me remind you that I am a fairly new FM user so I am hoping that someone can take the time and share some experience / ideas on how to accomplish this with me.

Thinking about it while I am writing this, I think a seperate demo version of the program might be the better (i.e. easier) way to go. I am waiting on my copy of FM 7 Developer to arrive so I am still using the 30 day demo so forgive me if this is an obvious option in developer but, how do I limit the ammount of records that a database could hold? Are there any tutorials for this or can someone explain to me how to do it?

Also in distributing a seperate full version of the program I made, should I worry so much about user registration? I know that DigiBuy lets you submit a whole list of "registration codes" that get emailed to buyers via email. This sounds cool as I could just make like 1,000 random registration codes and give them to DigiBuy. Would I have to make 1,000 user accounts in FM for that to work?

Sorry if this questions are newbie-ish but since there are no books out yet on FM 7 and the whole Acocunts and Privlidges stuff I can use all the help you guys care to give.

Thanks everyone!

Version: Developer v7

Platform: Mac OS X Panther

[Aussie John]

make the user create a new record via a script

then as part of that script

use a calculation

"if get(totalrecordcount)>3

exit script

endif"

[Sintax]

YEA! I am doing that now!!!

(the create a new record by script thing)

I am happy that finally it was a simple fix!

Anyone have any advice / tips on the whole distribution debate?

Thanks Aussie John

[Vaughan]

This is always a toughie.

It's interesting that you yourself are using the FMP Trial version. How (as a user) would you feel if it limited you to creating say 1 new database or 10 records? Project your feelings onto your potential users.

I think it's interesting that most trial versions are now time limited, not feature limited. There has in the past been discussions on this topic, and like many other discussions the only results are statements of option, not recommendations. But if Microsoft Adobe, Macromedia, FileMaker and other very large organisations feel that handing out time limited demos are the way to go, I'd do it too.

Now, making a time limited demo is in itself not a trivial thing. The Home Page 3.0 demo was dead simple to trick. The recent Adobe InDesign 2 demo on the other hand is very hard to trick, it really does die after 30 days and nothing short of reformatting the hard disk will let you run it again.

I think a time limited demo is the way to go. Butthere should be an opportunity for the user to unlock it after it's ended so they can continue using it.

[andygaunt]

Hi -

You could check into KeyCodeMaker by NightWing Enterprises

http://www.nightwing.com.au/FileMaker/KeyCodeMaker/

[Sintax]

Oh, I agree that a timed demo would be better but for my experience level I thought that it might be to hard to pull off sucessfully. I know I am using a demo right know of FM but I HAVE purchsed Developer 7... just waiting for it to arrive at my door.

I have read numerous posts on this already and was really looking for a simple solution. Basically I just want to give the user a chance to run the runtime on their computer to make sure they don't have any problems with it before they purchase it.

Version: Developer v7

Platform: Mac OS X Panther

[Sintax]

andygaunt said:

Hi -

You could check into KeyCodeMaker by NightWing Enterprises

http://www.nightwing.com.au/FileMaker/KeyCodeMaker/

Wow, that is awesome! Unfortunately I can't afford that price and I didn't see options for student pricing.

Are there any less expensive solutions out there? They don't have to be as robust in features or anything. There has got to be something out there for just an average guy who wants some kind of protection in releasing a new program.

[Aussie John]

script day count which runs on start up

you need a calculation which will insert the intial opening date but not modify it in subsequent openings.

have three fields

current date

start up date

key field

make the script so it will only enter the start up date if the key field is empty ( use "ifempty"

then at end of script insert anything into the key field. so next time it runs it wont ruin the start up date.

Combine that with a custom message and you can give option to enter a password to bypass the this step.

I am sure this is not a full proof method and i have never done this but am sure would satify your needs.

[Vaughan]

This is how the HP3 demo worked. It was cracked by simply setting the system clock date into the future a few years before installation. The demo then must have done the check "Quit If (InstallDate < CurrentDate - 30)" which then would let you run the demo for until you reached the date you set the system to when installed + 30 days.

To get around this you'll need to also make sure that the install date is not later than the current date. The InDesign trial senses this and figures you're trying to hustle it, so it kills itself straight away.

"was really looking for a simple solution"

That's the problem: simple solutions aren't worth mucking around with .

[Sintax]

Does anybody know anything about this program (good or bad)?

http://www.rootsolutions.de/authorize/index.htm

[Alexei]

Hi !

IMHO, this "protection" hardly can stop a more or less experienced user.

As far as I understand all the proposed protection schemas are based on calling a script in the supplied "registration" file which "halts" your script if registration is not found.

So, it's enough to replace this "registration.fp5" file with a new one, having empty scripts for all checks ("stop if unregistered", "custom alert" etc.).

[Sintax]

Yes, I believe you are correct there.

I think I am just going to release two seperate versions: a demo and full.

I have come to grips with the fact that the type of program I have written is the type that will most likely show up on MSJ and similiar type of sites where cracks and codes will be requested... and given since there are some very talented hackers lurking around over there.

That being said, I have some hope that there are enough honest individuals out there that will be interested in my program to throw a few bucks my way.

Thanks for the advice everyone.

[Singlequanta]

I have a solution that works better than KeyCoder Sintax - email me and I'll give it to you free.

[EllenG]

I do something similar in my demo. Probably not fool-proof, especially for a techno-guru, but my users are generally not computer-savvy.

I give my prospective customers a 30-day trial. They have complete access to all fuctions and can enter unlimited data. When they purchase the program, I send a registration code (16 characters, grouped in 4's). The registration code has a calculation that verifies the code. I use a combination of alpha and numeric. The code validation looks for specific characters in specific locations or a combination (i.e. the 2nd character in reg field 1 added to the 3rd character in reg field 4 must = 7.) It's pretty hard to break, unless someone reverse-engineers my code and can read the verification script. Only real problem I have is if someone shares their code with another person. But, you could lock down the code even more by matching some characters in the code to the user registration information (my users have to enter name and address in the registration screen); for example: the 1st character in reg 2 = the 1st initial of the last name and character 3 in reg 4 = the last digit of their zip.)

I like giving my potential customers full access. The more they use my program and get their data input, the more likely they are to purchase, since they do not have to re-enter the data after they register their copy! I'm getting about a 40% buy ratio, so it's working..

For the demo period, I use 2 global date fields:

gDemoEndDate

gLastDate

The first time the user logs in (gDemoEndDate is empty), gDemoEndDate is set to current system date + 30 and gLastDate is set to the current system date.

Then, until they register, the first check I do on OPEN is comparing current system date to gLastDate. If the system date is < gLastDate (system date has been set back) the program sends a message that the system date is invalid and shuts down. So, if the user sets a future date before they log in the first time, the demo end date will be way in the future, but as soon as they re-set their system date, it will be caught. Also, if they try to reset to an older date after the first time they login, the same check will catch that. So, they would have to set and leave a future date to bypass the date checks, and then the 30 days will kick in anyway! I don't think most users will do that... Anyway, my program includes important scheduling tasks (such as vaccinations due) that would be all screwed up, so there's no benefit to setting a future date.

Well, that's my 2-cents worth..

Version: Developer v6

[Sintax]

JourneyMan -

Is this something that you could share with me (as in the script and code to get it working)?

Also, on a side note to anyone who can help: My runtime solution for Windows won't let me drag and drop images into a container field (the purpose of the field is to do that). On Mac it is fine but Windows says something about it isn't part of the solution.

[EllenG]

I can do a copy and paste or an insert picture into my container fields, but not a drag and drop.

[EllenG]

Hi Sintax.

Were you responding to me..: My Welcome file is attached, if you are interested. You can see the scripts and get an idea of what they do.

Welcome.zip

[Vaughan]

I just had an interesting thought: why not put the demo time limiting code into the record access privileges, rather than interface and new record scripts... it'd be heaps more secure.

This would be really easy with FMP 7, but still possible with FMP 6.

[Sintax]

You mean inside the user accounts area of FM 7?

[Vaughan]

Yes... I just tried it, but it's not satisfactory. Record view and edit can be limited (and it's great) but record create and delete are either on or off.

So you'd need to use a combination of the access privileges and scripted interface controls, and turn the menus off.

[Ocean West]

Another option you might consider?

Create a system that on startup displays a KEY they take this key to your website.they register and insert their key. You use your magic calculation to verify the key and give them an install code.

They then can type in the code and then your solution is "registered"..

Or

Create a table with a few thousand records of random keys. and also have in there a digit that determine if the solution is to run in demo mode or not.

You can provide them a SN from your list. when you distribute your solution. Perhaps the code itself

could be a fancy encoded date so that this code is only valid if they use it in the month of April.

-

Just thinking out loud

[Sintax]

Thanks for the help everyone!

Singlequanta did an awesome job helping me and my program was listed on version tracker this morning.

On a side question: I have downloaded programs made with FM Developer and all the files are housed in one package (so you just add ONE file to your programs folder in mac). My runtime has two files and a folder full of files... how do I get them to merge to just one "package"?

I have OS X developer tools if that matters.

[andygaunt]

So -

You want to share your program name with us? Tell us what it does? Give us a link to it on version tracker?

Maybe some people here will want it

[stefangs]

just stumbled onto this thread... on running the risk of tooting my own horn as the developer of this idea, i'd like to point out that you couldn't just fill the scripts with null data. to do that, you'd have to have the proper password. i'm not saying my setup is unbreakable, but it's not that simple either.

regards,

stefangs

[Tripod]

IMO, it's a lot more protection just to limit the record numbers. Sure FMP has a time limit demo, but they are huge compared to any of us. If someone wants the solutn, they will buy it from a record number limited demo. It will not sell quite as well perhaps, to those who are really fence-

sitters, because they won't commit their data to it and become dependent (more of the current, large, commercial sales approach.) The other real reason they do this is because on high volume, it's very nice to be able to tell user to unlock--they only dl it once from the servers for which you are paying hosting or bandwidth, etc... If you are low volume, it's less of an issue, I would think.

Amature time-limit stuff just encourages folks to 'outsmart' it. Not everyone will want to do that, obviously, but what I mean is it can be kind of a thrill to outsmart it (mark of true geek? :-) OTOH, I am quite sure some of you are talented enough to write (nevertheless crack) something like this. Also, any kind of dependent file is trivial to crack, of course. Just delete the mysterious new files that crop up during install or (in our case) first run. Maybe the 80/20 rule applies, but who wants to lose 20% of your sales?

[Tripod]

Oops, I didn't mean to just imply that any of these suggestions are amature!!! I posted without reading all of the replies. (sorry, I'm just a newbie!) I was referring to some of the shareware I have seen, not filemaker runtimes.

Some of these ideas are really great!

[Brewser]

I use ExeShield and it rocks. www.exeshield.com. If the user back dates their pc it will void out the trial period and they will have to register to continue using.

Good stuff.

[digitalchaos]

Here is a thought why does filemaker not just implement demo and registration abilities into developer and allow you to pick various type of encryption, blowfish, aes, pgp, etc this should be built in at the program level, i want to spend my time building my product and designing the interface i should only have to worry about demos and registrations only if i want to develop them my self this kind of thing should be built in.

[Brudders]

I ran against the same problem and found a really good solution. Exeshield it costs $70 and what it will do is protect the runtime exe. You then have a choice if you want it to be a time trial or a maximum number of clicks trial.

I downloaded the trial version and not joking I had my application protected within 25 minutes and how advanced your are with FM has nothing to do with it. I myself am a novice at FM.

What this app does is takes your runtime exe and effectivly packs it into its own protective exe, once protected and executed the user has a choice of registering or continuing with app on trial.

If the end user wants to register they have to send you a code that your now protected exe has generated. You then put this code into exeshield and it generates an unlock code and username. This is unique to that particular computer so non transferable.

I had had a look at nightwings version evidently works with FM6 needs updating for FM7 I spent 20 minutes with it scratching my head then decided to look for something easier.

Hope this helps

www.exeshield.com

[stefangs]

exeshield looks pretty cool for all kinds of purposes, but remember it only protects the runtime which is barely part of your solution!

anyone with FM can open your solution and exeshield will never know. plus, anyone with FMD can rebind your solution and exeshield will be out of the picture completely. if you are serious about protection, this won't do the trick.

[TheTominator]

I do something similar in my demo. Probably not fool-proof, especially for a techno-guru

For the demo period, I use 2 global date fields:

gDemoEndDate

gLastDate

What is to prevent any user from importing a single record that

inserts an arbitrarily high value into gDemoEndDate?

Do you disable the ability to import information into your database?

I don't think this requires a techno-guru.

Is there a way to protect the contents of a global from user-tampering

without disabling the import feature somehow?

In my demo version I maintain a global field gUsageCounter that

keeps track of the user's usage of the database to preiodically

nag the user into registering. I don't implement a time limit.

I just increase the frequency of the nagging as the usage increases.

I realize that the user can reset my global counter with the import technique

but that just resets the interval for the nagging. It doesn't unlock the database.

[stefangs]

> What is to prevent any user from importing a single record that

> inserts an arbitrarily high value into gDemoEndDate?

if the field is not accessible, then you can't tamper with it. importing will not change it.

> Is there a way to protect the contents of a global from user-tampering

> without disabling the import feature somehow?

that's pretty easy: presumably you have already locked out the menu bar and are using a scripted interface. in your import script, after the import step you can add steps to set global fields to whatever you want. of course, you must also remove the global from visible layouts.

that said, i do disable importing in my stuff until the app is registered. otherwise, people could just keep downloading demos and import their data from expired demos.

[TheTominator]

if the field is not accessible, then you can't tamper with it. importing will not change it.

By "not accessible", if you mean by denying access using the password locking,

then you are right that importing will not be successful. By denying write access,

that field can't be used in the import mapping. But it also can't be changed

by any script run during that user's session. The scripts run with the same

access privileges as the user. So this method of locking down the globals

is not helpful if you need to change its value when a user runs the code.

So this is probably not what you meant by "not accessible". (I felt that

I needed to clarify this for other forum readers who might have received

the wrong impression.)

> Is there a way to protect the contents of a global from user-tampering

> without disabling the import feature somehow?

that's pretty easy: presumably you have already locked out the menu bar and are using a scripted interface.

Yes. That is essentially what I meant by disabling the import feature.

Thank you for clarifying. It sounds like you have a tight solution to this

problem. Well done.

At this point in my development experience, I still like the idea of providing

my users with the full FileMaker menus so that the experienced or ambitious

users can have that power if they want to learn it. Maybe with more experience

in sharing my solutions, I will change my tune.

[stefangs]

[email protected] wrote:

> By "not accessible", if you mean by denying access using the password locking,

> then you are right that importing will not be successful. By denying write

> access,

actually, i just meant to put the field on a layout that's not accessible. in fact, you don't need to have it on a layout at all. then again, if you allow access to everything, then this wouldn't work for you.

i prefer to lock out the menu bar, because then i have control over which features i want to be available and which ones i don't. in addition, if you funnel the user through a button interface, it's easier to automatically run all kinds of scripts compared to them choosing say, 'new record' from the menus. if you want people to pay for your solution, it also helps if you can just disable printing, for example, or disable more than some number of records until registered, etc. etc.

[Brewser]

I agree about Exeshield only protecting the executable, but you have to think how many people would have FMP that is running your app? It all depends on what type of app your are writing. Also they wouldn't be able to change your scripts and layout if you password protect the file. They could still use the program.

Exeshield and FMP combo is not perfect, but it is still a cost effective way to somewhat protect your program to the normal PC user.

It has worked for me so far, but I am not sure if anyone with FMP is using my program either.

I wish FM would just create the DB as a one file executable and not put the DB as a seperate file. Problem solved....FM are you listening?

I don't think there is a program that will lock down all the files. I emailed Exeshield support and he told me it will only lock the .exe file.