Hello Marc,

execution speed is worth some extra compilation time.

Check this out why you may wanna favour DLL over PBD:

https://community.appeon.com/index.php/qna/q-a/dll-vs-pbd

Best,

.m

Besides the benefits of what Marco mentioned in the post he provided, you also have benefit that DLLs cannot be decompiled to source code whereas PBDs can.

Marc,

Compiling one of our applications to m-code took half an hour. Compiling the same application to p-code took less than a minute. Execution speed was practically the same.

I don't think that for in-house, traditional business applications compiling to m-code is worth the longer compilation time since execution time is practically the same. Maybe for specific scientific or image processing applications it is worth. Or for commercial applications that are going to be distributed to the public, to protect the code.

Regards,

Ricardo

I'm very much in line with Ricardo. "Your mileage may vary!"

Performance is SO environment dependent. You have to measure P-code vs. M-code in YOUR app in YOUR environment. PB manual on compile to machine code discusses what code elements runs faster. Only certain elements are impacted at all - but your performance may be dominated be all other things like apps competing for local memory; network delays; file distribution on disks, and database performance.

In my 27+ years with PB I never had to compile to M-code due to performance bottle-necks.
Issues were always somewhere else.

Security is so much more than protect from decompile. BTW: Any PB app can export DataWindows from M-code files. Easiest way to safeguard file content is to keep app files stored on "secure" servers and only allow terminal access like RDP or Citrix.

I would argue only reason M-code version of PBD is considered "more safe" is that the format isn't publicly documented. But anyone with enough resources could analyze exactly how P-code turns to M-code -- and hence establish foundation for decompile. Start with PBL having 1 class with 1 function returning "Hello, world." Then gradually expand. It is time consuming but isn't rocket science.

Improving security should in my view start with risk assessment including gap-analysis = "What do we need to improve?" With that baseline analyze options, then decide - and finally execute.

HTH /Michael

Hi, 

This is a question for Chris (or anyone who knows the answer):

Chris commented here:

Hi Michael;

The C++ M-Code is accomplished via a C++ Code "emitter". The Emitter tokenizes the generated code - so de-compilation is virtually impossible. ;-)

My question is: So if DLL's are being "tokenized", does the same "tokenization" apply for code that goes into the EXE file?

The situation here is that management probably "ignores that benefit of DLL's" so the idea I have, is to keep using PBD's and include some pbl that holds sensitive data (like "hardcoded passwords") into the EXE instead of in some PBD.

We do have "some" encryption on those passwords, but still the encryption key is hard coded and put together from a few pieces of that encryption key in different places in the code. 

regards