Source code question

[Blakey43]

Hi,

I know very little about programming in Progress 4GL. Can somebody give me an overview about how the code is translated into programs?
Is it compiled into executable files and then installed onto a machine (as a C++ program would be, for example), or does it run without further compilation (as an MS Access macro would, for example)?
If the latter, is it possible to protect the source code from being viewed?

Thanks
Steve

 

[Cringer]

The code is compiled into rcode which is then run on the machine. It can be distributed as individual files or as libraries of code. It's not strictly executable though - you still need the Progress 4GL runtime installed on each machine to run the code.

 

[Blakey43]

Hi

If the programs are running from a server, would the source code itself have to stay on the server in order for it to work properly, or can it be kept on the developer's machine? Can the rcode be decompiled to give an editable source code?

By the way, I'm asking about Progress 9.10E and Progress 10.n running on Windows machines.

Thanks for your help,
Steve

 

[Cringer]

In theory you can't decompile the code although there are people out there who will attempt it for you. The best way IMO is to distribute the code to each machine, although I believe it is possible to keep the compiled libraries centrally on a server. I doubt the performance would be that good though.

 

[Cringer]

By the way - we get around this by making each program aware of whether it's the latest version or not compared to the version on the server. If it's not re refresh from the server and force the user to rerun the process.

 

[Blakey43]

Thanks for your help

Steve

 

[RealHeavyDude]

You can compare the way the ABL is compiled into platform independent byte code ( files with the extension .r ) with the way Java does it. You can call the Progress run time the PVM ( Progress Virtual Machine ) in that sense. There are just some restrictions: Before OpenEdge 11 the Bitness ( 32 / 64 Bit ) was not compatible and there are some Windows specific UI functionalities that will only run on a Windows machine. In general, if you have UI elements in your code it does matter whether it is compiled for ChUI ( _progres.exe ) or for GUI ( _prowin32.exe ). Be aware that GUI is only supported for Windows, ChUI is supported on each platform.

While it is possible to de-compile an ABL byte code, in practice it is not. There once was a solution out in the internet but AFAIK it is not available anymore and when it is, it might be pretty much outdated and will probably not be able to de-compile thing like OO-ABL that were introduced in more recent releases.

Keeping the run time ( by that I mean the .r files ) in a centralized space is a matter of performance and reliability of the network. You can pack the .r files into procedure libraries ( just like you can pack compiled Java classes into jars ) and make the run time load the .r file only once per session, but the performance might be bad and as soon as the run time session loses contact with the location where the .r files are located it will crash on you. Therefore, although it is possible and I know that people do it, I would not recommend it to you. There are better deployment strategies to ensure that clients will always have the latest version of the compile files, IMHO.

Heavy Regards, RealHeavyDude.

 

[tamhas]

FWIW, it is called the AVM - ABL Virtual Machine, not the PVM.

 

[RealHeavyDude]

Please forgive me, it's been such a long time ago since I had the chance to talk with somebody from Progress as they have abandoned all their subsidiaries in most European countries that I only did remember the term PVM. I guess that was before they re-branded the 4GL to ABL ...

Heavy Regards, RealHeavyDude.

 

[tamhas]

Been a while, then ...