1. Christopher Craft
  2. PowerBuilder
  3. Tuesday, 18 January 2022 19:05 PM UTC

Now that Appeon has allowed us to switch the runtimes during execution I am assuming the compiled PBD's and EXE have no dependency on the PB runtimes used during execution?  In other words - I have compiled the PBD's and EXE using runtime 2670.  I then deliver the new runtime directory 2728 and change the entry in the [exe].xml file to point to that new runtime and all is good even though the application was built with 2670?

Thanks for your input on this.

Chris Craft

Accepted Answer
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Tuesday, 18 January 2022 19:10 PM UTC
  2. PowerBuilder
  3. # Permalink

Hi Chris;

   No ... you would still need to rebuild the EXE & PBDs (DLLs) after switching the PB runtime in the IDE.

Regards ... Chris

Comment
  1. Christopher Craft
  2. Wednesday, 19 January 2022 15:40 PM UTC
Thank you Julie for the explanation. I actually like the engineers optimistic implementation. Being able to specify a newer runtime to use during execution would be great - especially in times like this where I am trying to determine if a new runtime will fix a problem at a customer site.



Chris
  1. Helpful
  1. Armeen Mazda @Appeon
  2. Wednesday, 19 January 2022 18:14 PM UTC
Hi Chris, You won't like it so much when your app blows up on your customers. This is really playing with fire and we are going to modify the documentation to not suggest our customers to do this. Brad also did excellent write-up on why this is bad idea.
  1. Helpful
  1. Christopher Craft
  2. Thursday, 20 January 2022 16:34 PM UTC
Don't worry - I am not going to do this. My comment was about Julie saying the engineer was too optimistic about implementing it. If it 'could' be implemented then that would be great!
  1. Helpful
There are no comments made yet.
Brad Mettee Accepted Answer Pending Moderation
  1. Wednesday, 19 January 2022 16:19 PM UTC
  2. PowerBuilder
  3. # 1

Since nobody has indicated why changing version of DLL's to use is a bad idea, I think it's worth a bit of detail to describe it.

A PB EXE is compiled with certain assumptions about it's runtime environment. If an internal call in a new version of the DLL's now returns a long instead of an int, or a range of values instead of a simple 0/1, the compiled EXE can, and will, have problems calling this internal function, and might work flawlessly, until it doesn't. When it crashes, it may not even be related directly to that call and just cause a generic "access violation". Worse than a simple return value change, it could be a pointer that overwrites data, and corrupts it, prior to be written to a database, in which case you'll never know how/what corrupted your data. These types of internal DLL changes can and will exist, and won't be documented by Appeon because they're internal.

As with earlier versions of PB, it's never safe to run your compiled EXE with mismatched DLL's. ALWAYS keep them in sync.

Comment
  1. mike S
  2. Thursday, 20 January 2022 23:35 PM UTC
I believe the exe that is generated is just stub code to start up the PBVM. Can't imagine that changes often, other than 16 vs 32 vs 64 bit.



The pbds (or any objects in the exe) are p-code and are interpreted by the PBVM during runtime. So in theory, updating the dlls to a newer version could work. not sure if appeon would want to add this to the list of things to officially support.
  1. Helpful
  1. Brad Mettee
  2. Friday, 21 January 2022 17:08 PM UTC
Mike,

Although the pcode is interpreted, it still has to deal with the internal function calls that the DLLs supply. Change how any of those calls work and it's a recipe for a crash. If you compile into machine code, the same issues occur.



In short, there's no way to 100% decouple the running code (pcode or machine) from it's interaction with the PBVM. When you build a PB app, the compiler creates the pcode (or machine code) for the calls with a particular set of rules on how they get handled. Change the rules on either side and something will break. There's no way around it.



I've been writing code for nearly 40 years. I've written code in a huge variety of languages, and know from experience that even MS is capable of releasing DLL updates that break things unexpectedly. Why risk using mismatched DLLs when you know it has the potential for causing problems? Is a new compile with a different version going to be more trouble than that? Lets hope not.
  1. Helpful 1
There are no comments made yet.
Roland Smith Accepted Answer Pending Moderation
  1. Wednesday, 19 January 2022 15:09 PM UTC
  2. PowerBuilder
  3. # 2

The runtime switch is for the PB IDE, not the compiled application.

Comment
There are no comments made yet.
Miguel Leeuwe Accepted Answer Pending Moderation
  1. Tuesday, 18 January 2022 19:08 PM UTC
  2. PowerBuilder
  3. # 3

Hi Chris,

That would surprise me, but you might be right? "has allowed us to switch the runtimes during execution" I'm not aware of this. I know you can choose a different runtime when compiling and building your EXE, but no way I've heard you can switch "during execution".

Maybe someone else can confirm this.

regards.

Comment
  1. Miguel Leeuwe
  2. Tuesday, 18 January 2022 19:10 PM UTC
I think the XML is more a way of telling WHERE your runtime is, but you still need to compile at whichever version is there.
  1. Helpful 1
  1. Armeen Mazda @Appeon
  2. Tuesday, 18 January 2022 19:15 PM UTC
Yes Miguel, exactly right!
  1. Helpful 1
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.