Subscribe via RSS
Toggle Submenu
  1. Categories
  2. Recent
  3. Tags
View Replies (5)

Resolved DLL vs PBD

  1. How-to
1
Votes
Undo
  1. Marc James
    Marc James
  2. PowerBuilder
  3. Saturday, 7 March 2020 11:26 AM UTC

When compiling for a Windows 10 machine, is there any benefit to being DLLs as apposed to PBDs?

 

Compile time is so much longer for dll, which is fine, just want to know the benefit.

Search & Replace dwo editor bug in 4k
Update and Retrieve images in datawindow using MS...
Responses (5)
Miguel Leeuwe
Miguel Leeuwe Accepted Answer Pending Moderation
  1. Wednesday, 11 March 2020 11:31 AM UTC
  2. PowerBuilder
  3. # 1

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

Comment
Load more comments
Chris Pollach @Appeon
  1. Chris Pollach @Appeon
  2. Wednesday, 11 March 2020 13:26 PM UTC
Correct
  1. Helpful
Roland Smith
  1. Roland Smith
  2. Wednesday, 11 March 2020 17:57 PM UTC
If you need to embed a password in code, encrypt the string outside the app and put the encrypted string in the code. Then when you need to use it, decrypt the password. That way the plain text of the password is only in memory.

This would be a good use case for indirect variables. Code that uses the password would think it is just assigning one variable to another but behind the scenes the indirect function would decrypt the hard coded value.

https://www.topwizprogramming.com/freecode_indirect.html
  1. Helpful
Miguel Leeuwe
  1. Miguel Leeuwe
  2. Wednesday, 11 March 2020 19:10 PM UTC
Hi Roland, yes that's a very good tip, I'll certainly have a look at it. (when time's available).

Personally I was thinking to use the windows AD vault. That way if things aren't secure enough it won't be the programmers fault (but MS's). Regretfully I wasn't assigned to this task.
  1. Helpful
There are no comments made yet.
Michael Kramer
Michael Kramer Accepted Answer Pending Moderation
  1. Sunday, 8 March 2020 05:58 AM UTC
  2. PowerBuilder
  3. # 2

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

Comment
Chris Pollach @Appeon
  1. Chris Pollach @Appeon
  2. Sunday, 8 March 2020 16:29 PM UTC
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. ;-)

Having DWO code exposed is really not a threat. Exposing "Protected B" (or higher) sensitive data in your app is a much higher exposure. For example, PB Apps that encrypt / decrypt data via SQL. That means that exposed sensitive data like bank account numbers, SSN (SIN), Credit Card, etc data can be easly sniffed via network packet sniffers. Sensitive data like aforementioned, can also be gleaned off instance variables if the data does *not* remain encrypted. Basically, no sensitive data should be stored in DWO buffers, global or instance variables in its decrypted form.

Food for thought.

Regards ... Chris
  1. Helpful
There are no comments made yet.
Ricardo Jasso
Ricardo Jasso Accepted Answer Pending Moderation
  1. Sunday, 8 March 2020 00:50 AM UTC
  2. PowerBuilder
  3. # 3

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

 

Comment
There are no comments made yet.
Armeen Mazda @Appeon
Armeen Mazda @Appeon Accepted Answer Pending Moderation
  1. Saturday, 7 March 2020 21:07 PM UTC
  2. PowerBuilder
  3. # 4

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.

Comment
Chris Pollach @Appeon
  1. Chris Pollach @Appeon
  2. Saturday, 7 March 2020 21:29 PM UTC
Hi Armeen ... Yes, M-Code compiles have a superior code privacy! An excellent benefit when your PB App's have sensitive code or corporate algorithms that you do not want to ever expose. Another PRO for DLL's (M-Code compiles) for me is that the C++ compiler is much more stringent on your PowerScript code. I always do both (M-code & P-Code) compilations on my frameworks. Just to make sure that the new PowerScript compiles 100% clean & there are *no* Linkage-Editor errors/warnings. Once is see that, I am now super confident in my subsequent P-Code compiles. So in essence, I use the M-Code compiles as a 1st super Q/A code check. Food for thought.

One other PRO for M-Code compiles is that you can trap the generated C++ code in the background & then run that through commercial security analysis software. Makes your IT security people get the "warm & fuzzies". ;-)
  1. Helpful
There are no comments made yet.
Marco Meoni
Marco Meoni Accepted Answer Pending Moderation
  1. Saturday, 7 March 2020 15:45 PM UTC
  2. PowerBuilder
  3. # 5

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

Comment
Chris Pollach @Appeon
  1. Chris Pollach @Appeon
  2. Saturday, 7 March 2020 21:15 PM UTC
Hi Marco ... Thanks for posting that link over to my answer on this aspect.
  1. Helpful
There are no comments made yet.
  • Page :
  • 1


There are no replies made for this question yet.
However, you are not allowed to reply to this question.