Need to develop now, so what do I use?
I need to begin developing a GUI app for clients now. Is R3 or Red ready for such use? If not, isn't R2 ready?
What's your advice for developing GUI apps TODAY?
posted by: c.k.lester 17-Aug-2015/17:17:38-7:00
- What platform(s) are you developing for?
- What type of GUI app is it? (Game/web-based/etc.)
These should give us enough info to get started with recommendations.
posted by: Bo 17-Aug-2015/20:45:53-7:00
Platform: Windows (all versions); in the future, possibly MacOS
Type: "Installer" - We use it to install and update and uninstall our customized MS Office templates to client PCs.
Ultimately, I'd like to move our software away from the MS Office platform and create a custom app.
Thank you!
posted by: c.k.lester 18-Aug-2015/10:58:29-7:00
I can't address the question of R3 or R2, but I do have a thought about installation.
I have written some small applications where the entire application, including a copy of the REBOL 2 interpreter, is in one folder. The application has a main REBOL script that optionally calls other REBOL scripts, and that main script is started with a DOS batch file that runs the REBOL interpreter with the "-i" switch to prevent installation, and the "--script" switch to identify the main script.
With the application packaged in this manner, "installation" means to just copy the single folder to the target computer. "Uninstalling" means to delete the folder. It is easy to do this because the interpreter is so small, and including copies of it is not in violation of the license.
posted by: Steven White 18-Aug-2015/13:43:35-7:00
Atronix uses their "REBOL 3 View" in production, so you might do as well.
https://github.com/zsx/r3
http://atronixengineering.com/downloads.html
posted by: point 18-Aug-2015/14:56:09-7:00
Steven, how do you prevent the end-user from modifying the Rebol source? Not that my users would be savvy enough to try, but some might. Or it could get out into the wild somehow.
posted by: c.k.lester 18-Aug-2015/15:53:27-7:00
Use alien dialect.
http://www.rebol.org/view-script.r?script=alien.r
posted by: point 18-Aug-2015/16:05:33-7:00
Can't you create one or more apps that execute rebol source from a cental location such as a website (internal or external)? That would avoid the problem of having to update/install local files. You could also encrypt the source code with just a line or two of code.
posted by: Edoc 20-Aug-2015/19:44:05-7:00
I should mention that I give this advice because this is what I do for 30+ power-users in my company around the globe. (I don't do the encryption part, though.) Just having the Rebol source download from a remote location eliminates a bunch of headaches. The users run a single Rebol encapped .exe, which in turn reads and executes scripts from an internal web locaiton.
posted by: Edoc 20-Aug-2015/19:47:29-7:00
Edoc, the issue there is if someone figures out where the code is hosted and downloads it and saves it to their local disk. I guess if it's via HTTPS or otherwise encrypted on the server, getting the source that way would be useless. What if someone sniffs the route?
posted by: c.k.lester 20-Aug-2015/19:59:47-7:00
But, basically, what you're suggesting is to send a shell program that downloads the actual program each and every time. So, how do you prevent the end-user from getting at the source, because once it's loaded in memory, I'm sure there are ways to capture it locally.
posted by: c.k.lester 20-Aug-2015/20:01:27-7:00
I was just giving you a suggestion. I didn't know if you are selling this to different clients or proposing this as a solution within a single business or enterprise.
REBOL provides the networking, basic security and encryption. If you need uncrackable code executing on local machines-- then I think your problem is much deeper. This will be a challenge in any programming language. The prognosis is not particularly good here-- you will likely spend more time coding the protection than the actual solution, and that should make you think twice about your priorities.
I would accept the reality that your code can be intercepted by a determined person with suitable hacking skills.
posted by: Edoc 20-Aug-2015/22:48:17-7:00
Edoc, I appreciate your help! I'm new to Rebol, so bear with me. Just trying to get my head around how Rebol does certain things, or if certain things are reasonable to attempt.
I would be distributing an app to paying clients. I'll think about this more in the morning and get back to you with any further questions.
Thank you for your time! :-)
posted by: c.k.lester 21-Aug-2015/1:12:34-7:00
One way to add a hurdle to prevent users from modifying the source is to distribute it in a compressed format.
Then, in the main stub, instead of:
do %worker-script1.r
You'd have:
do load decompress read/binary %worker-script1.bin
Your users could of course decompress, save as a txt, edit, recompress, etc. But you have added a significant tamper-evident barrier to them doing so.
posted by: Ronnie 21-Aug-2015/3:57:05-7:00
Regarding distributing applications in a folder that includes the interpreter and the scripts, and the question of how to prevent the operators from changing the code either accidentally or intentionally, the answer is, I don't, for the following reasons which apply specifically to me but would be no good for others.
Reason one, I work in a fairly but not completely closed environment with people who don't care what happens behind the windows they interact with, so the odds of them fussing with the code are small. I keep master copies to guard against accidental modifications.
Reason two, I do like to show off a bit, and I try to make the scripts tidy and well annotated, to show that I actually do perform some useful work.
Reason three, I won't be working here much longer, and I want to make it as easy as possible for everyone else to find and fix what I have left behind. In the past, I have had to find and fix things left by others, and I don't want to inflict that on others any more than necessary.
If I did have to control access to the source code, the only ways I can think of would be to use the REBOL 2 SDK to encapsulate the programs into ".exe" files, with master copies of the source "in the clear" on a secure server, or, to try to use DOS batch files or Powershell scripts to run REBOL off a secured server with the scripts also on that server. We recently had an FBI security audit which has not filtered down to me yet, so who knows, it might come to that.
posted by: Steven White 21-Aug-2015/10:46:40-7:00
I've figured an executable would be the only way to go. I think you're right.
Thank you!
posted by: c.k.lester 21-Aug-2015/15:44:59-7:00
You can package your apps with iexpress, as described here:
http://business-programming.com/business_programming.html#section-13.3
If you really need to protect your code, the defacto tool for R2 was the SDK encapper.
There is a free encapper for Atronix's R3: http://r3al.org/rebol3-encapper.html
posted by: Nick 22-Aug-2015/2:01:19-7:00
Theoretically it is possible to run a Rebol script without its text present in memory unencrypted. Normally the text is translated into internal representation and then discarded. If you modify the translator (l-scan.c) to work with encrypted source, only a small part of the cleartext will be present in memory at any given time. One can modify the executable to do SAVE right after the translation, but it's not as easy as dumping the process memory and searching for a string. Also you may want to use some executable protector.
By the way, Boron has a binary serialization format, which can be used to conceal the script text.
posted by: point 29-Aug-2015/11:02:41-7:00
|