Runtime vs. Run Engine

[Richard Rabins]

Re: Runtime vs. Run Engine

Just to add some background.

We have had runtime licenses for Alpha Five for many years allowing developers to distribute desktop applications that they had developed.

When version 9 shipped we introduced a variation called run engines which were designed to accommodate SQL tables that were supported through "active links" that were new to version 9.

After a few months of v9 being on the market, we decided that it would be beneficial for all to introduce an attractively priced license that was very very straightforward to understand and that would apply to both dbf and SQl tables. This license is called the unlimited distribution license for desktop applications and in most cases is the most economical way for developers to distribute desktop applications.

here is the description we used to introduce the unlimited distribution license for desktop applications

Distributing your desktop applications just got a whole lot easier!

With the new Alpha Five v9 Unlimited Distribution License, once you have built your application in Alpha Five v9 Platinum you can:

Distribute your applications freely with no restrictions.

Make an unlimited number of copies of your application, including trial or demo copies
Develop an unlimited number of applications (each with an unlimited number of copies)
Thanks to all of you who completed our survey. (Yes, we really do take this stuff seriously!)

Your feedback told us that you felt that Alpha Five V9 was the ultimate tool for building web and desktop applications. You also told us that that you wanted a low cost, unrestricted and simple way to distribute an unlimited number of custom Alpha Five applications that you create.

As a result of your input, we are delighted to introduce the new Alpha Five v9 Unlimited Distribution License for deploying desktop applications.

For one low price � with the new Alpha Five v9 Unlimited Distribution License, you can distribute as many applications as you like - for as many people as you like. The people to whom you distribute your application do not need to have Alpha Five installed. (It's also ideal for creating demo or trial versions of your commercial software.)

The Unlimited Distribution License works for both SQL and non-SQL desktop applications. It does require that you first develop your application using a copy of Alpha Five V9 Platinum Edition. (If you already have Alpha Five V9 Standard, you can upgrade to V9 Platinum without having to modify anything.)



Features of the Unlimited Distribution License

Create as many applications as you need. Distribute as many copies as you need.
Works with both .DBF based and SQL based applications (such as SQL Server, MySQL, Oracle, Postgres, Access and more)
Includes software for building your own custom installation program.
Restricts users from editing (and possibly breaking) your application.
Allows users to create and edit their own reports, labels and letters (if you wish to allow them).
Create your own custom splash screen that appears when the software starts
Everything you need to distribute your Alpha Five applications, without paying royalties to Alpha Software.
Ideal for creating demo or trial versions of your commercial software.
Frequently Asked Questions
Q: Does this mean that you have discontinued Runtimes and Run Engines?
A: No. Those products are still available, however, if you plan on distributing your software to more than five people, you'll find that the Unlimited Distribution License is a better deal. For five or fewer people, see our online shop as well as additional offers below.

Q: Can I use the Unlimited Distribution License with applications developed in the Standard Edition?
A: No. You need the Platinum Edition to use the Unlimited Distribution License - however you can upgrade to the Platinum edition from the Standard edition. We will give credit for what you paid for the standard edition. Please contact sales to arrange this.

Q: Are other bundles available besides the ones listed above?
A: Yes. Please call sales at: +1 781.229.4500 x1 or send an email to [email protected]

Q: I already own a V9 runtime/run-engine package - can I upgrade to the Unlimited Runtime Distribution license?
A: Yes. Please contact sales for pricing (see above). You will receive credit.

[Michael Humby]

Re: Runtime vs. Run Engine

I own 2 x Platignum Full Versions on different PCs but only one Unlimited Runtime Engine, does it make any difference which Platignum Full version that I use to develop and distribute the Runtime applications? What would happen if say one of my customers already had a V9 Full unlimited version already installed on their PC?

Michael

[CALocklin]

Re: Runtime vs. Run Engine

I own 2 x Platignum Full Versions on different PCs but only one Unlimited Runtime Engine, does it make any difference which Platignum Full version that I use to develop and distribute the Runtime applications??

No. In fact, you could use both of them. Of course, that would make it more difficult to keep both copies in synch but it could be done.

What would happen if say one of my customers already had a V9 Full unlimited version already installed on their PC?

They could open your application and make changes to it.

This is one reason I, and many others, believe in putting all significant code in a global script or function and calling that script/function from the appropriate button or event. That way all significant code can be protected. [Edit: see below for more details.]

My philosophy is that anyone can see the forms and copy them based on what they look like on the screen so there's really very little point in password protecting the forms themselves. The real key to protecting your work is in protecting any significant code. (Something like "parentform.close()" is not significant so I'd just put that in the OnPush event of my button.)

There are two ways to protect the global scripts/functions that are in the Code tab:

The method I always use is just password protecting all my code. This is done by adding one "comment line" like this at the top of the script:
'password MyPassword
This works in xbasic scripts. I also know it can be added to Action Scripts but, since I never use AS, I'm not sure whether or not it can be done in a "normal" manner. I created an utility that will add the password to all my xbasic global scripts and functions and discovered that this procedure also works with the Action Scripts. (If anyone is interested, this is part of my Grab Bag addin - a compilation of misc utilities I've created for myself over the years.)

The important thing to remember when password protecting global scripts/functions (the ones in the Code tab) is that all other passwords are far less secure. For that reason, the password used for the global scripts/functions should ONLY be used in the global scripts/functions. Nothing else in the application should use that same password.

[Edit: The forms, tables, buttons, etc. can also be password protected but those passwords are actually fairly easy to break. In my opinion, password protecting those things does more to annoy the developer than it does to improve security. The passwords in global scripts/functions are much, much harder to break. FYI: NEVER password protect a scripted field rule event because field rule events don't recognized the password - anybody with a full version of A5 can open the field rule event, read the password, and use it to open any other event script that uses the same password.]

The other way to protect the code in the Code tab is to create an aex file from them and then delete all the scripts and functions from the Code tab. Making an aex file is easy. Removing all the code from the Code tab can be the hard, or at least time consuming, part. This also creates another issue related to removing the code - how to either restore the code or keep two copies in synch where "development copy #1" contains the code and "development copy #2" is used just for creating the distribution files.

Frequently asked questions I've received about aex files from other users:

Do I have to remove the code from the Code tab? The whole purpose in creating the aex file is to protect the code from curious eyes. Leaving the code in the Code tab would defeat that purpose.

Can't I just restore the code from the aex file? Again the whole purpose of the aex file is to protect the code. Allowing it to be restored from the aex file would defeat that purpose. One way to restore code is to export it to a text file before removing it - this is a built-in feature of A5.

What if I have a script in the aex file and another by the same name in the Code tab? The one in the Code tab will take precedence over the one in the aex file.

Is there an easy way to remove the code from the Code tab? Yes and No. I and a few others have created utilities that do this very quickly but it requires a good understanding of the data dictionaries to create something like this. Most people I've talked to have been leery of doing it this way and tend to use the "two development copies" method. For that reason, I've never taken the time to "finish" mine so that it would be appropriate for general distribution. There may be something in the Code Archive but I haven't checked. Of course, one way of keeping a copy of the code to restore later is to export the code to a text file - that's a built-in feature of A5. (My own utility also restores the code and does it much faster than copying it back in from the text file.)

Breakfast time! over and out.:)

[Michael Humby]

Re: Runtime vs. Run Engine

Cal,

Is the only way to remove scripts from the code tab by right clicking and delete one by one? There does not seem to any way of highlighting multiple scripts. Dr Wayne explains a method compiling the script .aex to the same folder containing the dbase then deleting the alb library via the dbase properties. I can never get this to work, OK the scripts all disappear but they re-appear again the next time that I open the dbase.


Also you did not mention the 'Option ENCRYPTED_TOKENS' function to place in a script, I am not certain, but my understanding, if you place this in a script before compiling then this will lock the .aex from prying eyes without the need to ' password mypassword. I would like clarity on this from someone in the know and also does Option ENCRYPTED_TOKENS need to be in all the compiled scripts or is it OK to have with only one.

Michael
www.instantnurserymanager.co.uk

[CALocklin]

Re: Runtime vs. Run Engine

Is the only way to remove scripts from the code tab by right clicking and delete one by one?

No but it's the only "built-in" method.

There does not seem to any way of highlighting multiple scripts.

True.

Dr Wayne explains a method compiling the script .aex to the same folder containing the dbase then deleting the alb library via the dbase properties. I can never get this to work, OK the scripts all disappear but they re-appear again the next time that I open the dbase.

This works - with some reservations. First, you have to delete all 3 files - the .alb, .alm, and .alx files. Second, you need to be aware that this will remove EVERYTHING stored in those files. That includes A5 security settings, user defined toolbars and menus, the network optimize number, any user-defined settings (a5_save_settings()), backup settings(?), certain (all?) saved queries, and possibly a few other things.

Also you did not mention the 'Option ENCRYPTED_TOKENS' function to place in a script, I am not certain, but my understanding, if you place this in a script before compiling then this will lock the .aex from prying eyes without the need to ' password mypassword.

Password protection is not required when you compile the scripts to an aex file.

The aex file is fairly hard to decrypt even if you do not use that option. However, some parts of the code will still appear as plain text which, in some cases, may allow someone to figure out something that you didn't want them to know. If you do use the ENCRYPTED_TOKENS option, none of the code will appear as plain text.

also does Option ENCRYPTED_TOKENS need to be in all the compiled scripts or is it OK to have with only one.

I'm pretty sure it needs to be in each script.

Here's another potential issue with using password protection on Action Scripts. First, as mentioned in the previous post, I don't know if there is a "normal" way to add passwords to an Action Script but the utility that's in my Grab Bag will do it. Second - and this is the issue - editing an Action Script that was password protected with my utility will remove the password. As a result, I would always need to run the utililty again to add the password just before making a new installation/update file. That's not a big deal as long as I don't forget it - the whole process takes about 5 seconds to add/remove passwords from 566 scripts and functions. (Passwords in xbasic scripts - which is all I use now - are not removed as a result of editing the script.)

FWIW: There seem to be two basic philosophies about protecting scripts and I believe the choice is a matter of personal preference. Which is better for you depends on your feelings about how much security you need and how much work you are willing to go through to get it. Personally, I do not compile my application scripts to aex files anymore. Instead I feel that password protecting my global scripts is adequate - not as secure as an aex file but adequate. The issues with removing and restoring scripts plus the simplicity and security of adding password protection is enough for me.

An aex file is even more secure than password protected scripts and an aex file created with OPTION ENCRYPTED_TOKENS is even more secure. However, neither is 100% secure.

I should also point out that most of my generic apps are sold to smaller companies who don't really have an IT group (heck, it sometimes seems like they are lucky to know how to turn on their computer!) so the chances of them trying to hack my code is pretty remote. When I build an application for a specific company I do not protect the code at all unless I feel there is a reasonable chance that they will try to sell the app themselves. Some companies have expressed a desire to sell the app and, in that case, (a) I get a written agreement that it will not be sold without my knowledge/consent and (b) I explain to them all the issues I've gone through trying to build other generic apps and they usually decide not to do it.

FWIW: A generic app that does something very simple might not be an issue. However, some customer(s) will want to see new features and if you build a complex app there will be even more demands for changes and new features plus more issues just due differences in computers. I've been amazed at the differences I've seen in problems using exactly the same application at different companies.

Cal's Programming Rules:
1. Every time you fix/update something for someone, something else will go wrong.
2. The more complex the application gets - i.e., the more fixes and updates you do - the more things will go wrong AND the more likely that it will have different errors on different systems.
3. Every time you fix something that went wrong with the previous update, something else will go wrong.
GOTO #1.
If you eventually get to step 4, take a rest and don't change ANYTHING for a few months:D....
4. It's working correctly on all systems.