Bindable
Optionally specify that all variables in the RECORD structure are available for use in dynamic expressions at runtime. The compiler will allocate memory to hold the full Prefix:Name for each variable, instead of using its own internal reference for each variable. Therefore the BINDABLE attribute increases the amount of memory necessary for the application.
A GROUP, RECORD, or QUEUE structure declared with the BINDABLE attribute has space allocated in the .EXE for the names of all of the data elements in the structure. This creates a larger program that uses more memory than it normally would. Also, the more variables that are bound at one time, the slower the EVALUATE procedure will work.
BIND (declare runtime expression string variable)
BIND Identifies variables allowed to be used in dynamic expressions.
There is another angle here to consider which is something I have not seen mentioned or discussed ever since I’ve been using Clarion Professional Developer 2.1 in the DOS days. It ties in with my posts on this thread:
The point being (Kernel) Address Space Layout Randomisation (K)ASLR.
The art of pulling data out of memory.
Bind and Bindable are potential security risks for pulling data out of memory. A variable that is bound becomes more at risk for as long as its bound which could be the life of the app or procedure or section of code/report/process its wrapped around.
Bindable lets us bind all our variables in a (File/Table), Group or Queue structure. Its quick, easy, arguably lazy, and all files/tables that use this attribute, bind variables for as long as the app is running which could be hours, days, weeks or months, like a service.
The slow, harder, more secure route is to bind fields only when required, so using Bind/Unbind in a procedure ideally wrapped around the code that needs it and not at the start and end of a procedure.
This reduces the amount of time a variable is bound in memory, to maybe a split second if its used in a service, report or quick process or for the length of time a user has a procedure window open and is using a control/code that uses Bind. Noting some processes and reports can still takes hours to complete.
So Bind can make a clarion app smaller, faster and more secure in memory, but larger & slower on disk, perhaps even less secure when considering decompilers like the Ghidra (nsa.gov), than using Bindable in the dct file/table.
But how do you sell it to a customer or whoever pays the bills?
If the customer wants the job done properly ie as secure as possible, faster and requiring less powerful workstations and servers, then they have to pay for all the extra time that is required to bind fields at the procedure level and not use the Bindable option seen in the dct editor.
Anyway…
Considering there will be code out there that is using bind/unbind at the start and end of a procedure and knowing some procedures will be running for hours, days, weeks, months, closing these down more frequently could also introduce an element of “active” ASLR because other procedures could be opened between calls which moves the bind variables around in memory further.
And finally, another way to introduce ASLR into an app, is when an app is started, it spawns a random number of new instances and thus memory allocations taken from Windows, and then hides all but one from the user. The memory allocation being used by the app by the user will be random and should work all the way back to the earliest versions of Clarion for Windows.
Depending on how this done, it could be fast or slow, but this is one way to implement your own form of ASLR because complaints exist even with MS’s implementation of ASLR. So if you wanted to be a bit more secure this would do it.
Comparing Memory Allocation Methods - Win32 apps | Microsoft Docs
Comments? Corrections? Anything missed?