Compiler for AmigaDOS scripts?

[Piru]

@AMIGA-FAN

Legality?

You can't redistribute AmigaOS parts, such as C commands ("unless he actually intends to include the DOS commands he uses into the exe that is. However, I would be doubtful of the legality of that."). You couldn't for example upload such compiled binaries to Aminet.

[Wol]

Why not use AREXX for your scripts, and then compile them with....

"REXECUTE" the comlete Arexx Compiler by Horizon Software ;-)

[TheMagicM]

AMIGA-FAN:

If the script is very complicated, post it here..maybe it needs to be re-written.  j/k.  :-)

[Karlos]

AMIGA-FAN wrote:
>>> However I would be doubtful of the legality of that.

Legality? If you can put together simple DOS commands or whatever and build a complex shell-script that you can use without copyright issues, why would you not be able to do the same thing from within an executable file, i.e. a binary, obtained by just compiling this script? You are just making use of DOS commands/external programs that you are eligible to use as a owner of the AmigaOS. At least this is my opinion.

Sure, as long as the DOS commands you use are not *physically* included into the binary of your executable.

This would mean your executable contains object code you have no right to redistribute.

Making a compiled script that simply calls dos commands from their usual location (in other words exactly like a normal script) would be fine.

As Thomas suggests, you could simply have the script as a string constant within a C program and execute it. If you want to ensure nobody can reverse engineer (by viewing a hex dump of your exe and seeing the string inside), you could encrypt your scripts with a small program and then use the encrypted data in your executable. It would decrypt the text back to a normal string and then execute it.

[AMIGA-FAN]

>>> You can't redistribute AmigaOS parts, such as C commands...

In fact I'm in no way willing to do that sort of things... What I want
to achieve is EXACTLY what a shell-script does, i.e. executing
commands, either internal or external, the same way a shell-script
does but possibly from within an executable (binary) file. AmigaDOS
commands would simply be executed from their location, as well as any
other tool/utility that anyone can use in his own scripts.
Incorporating a binary code for execution in my executables is far
beyond my knowledge anyway and complicating things beyond what is
necessary and, in any case, a practice which is obviously breaking
copyright laws, I'm perfectly aware of this. Anyway, to cut things
short, I might consider switching to AREXX if porting those script is
not gonna take a considerable amount of effort. At least a compiler
for this exists. I will go through all other posts here regarding this
topic and see what is possibly thye best solution, given the problems
highlighted here. Would nevertheless be very much pleased of any other
suggestions that may come about that.

[AMIGA-FAN]

>>> Sure, as loong as the DOS commands ... are not "physically"
included into the binary...

In fact they will not be. As mentioned in my other post, the DOS
command will be simply executed, NOT included in my binary. Including
a binary into my executable is something far beyond my knowledge and
even if I DID know how to achieve this, I would NOT do that as this is
a breach of copyright. Encripting commands into a string to avoid
"reverse engineering" is a good suggestion here. ALl I do need now is
to have a compiler in the first place or find a way to compile
scripts, either AmigaDOS, AREXX or whatever. Then will think about how
to encript the commands themselves, mainly to hide all the technical
aspects of my software.

[AMIGA-FAN]

Using AREXX is something I thought about. Problem is I need to re-code
all that stuff and this is something I would rather avoid as the code
I wrote is already functioning as it is and it consts of several
hundreds lines of code!. To save time on my work it would have been
great to have an AMIGADOS script compiler. If that doesn't exist, well
will be forced to find other solutions... unfortunately  ;-(

[Piru]

@Karlos

As Thomas suggests, you could simply have the script as a string constant within a C program and execute it. If you want to ensure nobody can reverse engineer (by viewing a hex dump of your exe and seeing the string inside), you could encrypt your scripts with a small program and then use the encrypted data in your executable. It would decrypt the text back to a normal string and then execute it.

And this could be broken with simple SetFunction to _LVOExecute, or even SnoopDos.

Or by just simple "set echo on", if you're afraid of patching. :-)

[AMIGA-FAN]

>>If the script is very complicated, post it here... may be it needs
to be re-written.

No, it's complicated in what it does, not in how it does it, which
would mean my code is badly written.. I don't think it's badly written
but I DO think that it would be a lot complicated to write several
(custom) "C" programs each devoted to a specific task. As I said in my
previous post, a shell-script of a few tens of lines could mean an
equivalent "C" programs of several hundreds lines of code! So the
overall effort is greater.

[AMIGA-FAN]

>>> ... SetFunction to _LVOExecute .. or even SnoopDos

Mmmhh, interesting to know. I guess there's no easy way to avoid such
"intrusions" in somebody else's code....

[Karlos]

@Piru

Well sure, but I did only say "basic" reverse engineering (somewhere) ;-) It would at least eliminate the problem of hex editors and so on.

On the face of it, there is no way to absolutely safeguard code from a determined reverse engineering effort. Even if you wrote your own dos interpreter so you didnt have to call Execute(), people could simply reverse engineer the program itself to find out what it does.

[Thomas]

The initial concern was to prevent the user from accidentally changing the scripts. Any effort to reengineer the compiled program cannot be called accidentally.

So saving the script as text in an executable, perhaps calcuclating a checksum to inhibit any changes, will surely prevent mistaken changes.

You won't keep anybody from reengineering the program if he really wants to.

Bye,
Thomas

[AMIGA-FAN]

>>>REXECUTE, the complete Arexx Compiler by Horizon Software.

Do you know what is their WWW address? I'll have a look at their compiler.

Thankx

[AMIGA-FAN]

@Thomas

As I mentioned in my other posts, the scripts have been designed to provide the user with a comprehensive set of tools designed to allow for the development and building of Realtime SW applications, in other words the user of this product will (very likely) mainly concentrate on the development of Realtime SW applications rather than breaking into their code (therefore would not care much about how application building is achieved) by mean of this Realtime SW Development platform, which includes, among other things, all the development tools and the Realtime Executive (core scheduler). A Realtime Debugger is also on the to do list but probably the SAS/C Debugger can be used too, with all the features I need (if it is possible to access data and code in realtime). In fact, what's the point in rewriting a Realtime Debugger?). So, there's no much point in breaking the code of the building tools themselves provided with the product, which only serve, as I said, to build up realtime applications. The development of these applications is left to the user. But would be nevertheless advisable to prevent the user modifying these tools (voluntarily or not) in the first place as they are very "critical" in what they do and are primarily something like standard tasks that need not be modified / changed / rewritten by anyone.

[Karlos]

@Amiga-Fan

As stated, there is no way to counter a concerted reverse engineering attempt. All you can do is to make it more or less difficult.

Accidental changes to a script are trivial to prevent. Thomas' suggestion of putting the dos script into a C string and executing it from within your compiled binary is a very practical way to accomplish this.

To prevent casual "I wonder how this script works?" attempts, encrypting the string (and decrypting at runtime) would suffice.

This is possibly a better approach than Rexxecute since you don't have to rewrite your dos scripts in Arexx. Also, good as Rexxecute is, it is not truly a compiler - as far as I know, at least - it simply wraps arexx scripts into an executable loader in much the same way as we are describing here. There was something on aminet ages ago (written itself in arexx) that did pretty much the same thing. I can't for the life of me remember what it was called, however.

Lastly, someone with the required expertise and determination to find out how any code works, will. You simply cannot prevent this.

[AMIGA-FAN]

@Karlos

>>> ... All you can do is to make it more or less difficult.

Precisely.

>>> Accidental changes to a script are trivial...
Well, those scripts are provided to accomplish tasks that the user needs not modify. They are provided as they are and do not need modificationa whatsoever. The purpose here is precisely to avoid, mainly, accidental modificationa that might cause errors or malfunctions that would ultimately cause problems in the compilation process and, therefore, a complete failure in the application building process (for instance) and/or software configuration control process. It's just a method of protecting the final user, in the first place. I would rather worry about other sort of things, i.e. breaking into the core scheduler code to find out how it works....