Forum
Important Notice for New User Registrations
To combat an increasing number of spam and bot registrations, we now manually approve all new user registrations. While this may cause a delay until your account is approved, this step is essential to ensure the quality and security of this forum.
To help us verify your registration as legitimate, please use a clear name as user name or an official email address (such as a work, university, or similar address). If you’re concerned that we may not recognize your registration as non-spam, feel free to email us at with a request to approve your username.
32-/64-Bit Controller DLLs
Quote from TimHH on 25. July 2023, 10:58Hello David,
As already discussed before QBlade is currently accepting 64-bit controller DLLs only. Nevertheless, I would appreciate if you could also implement the handling of 32-bit controllers in the future, because it appears to be still quite common in the wind industry. I hope this is the right place for my “service request” – at least for me the topic would have been inappropriate in the “Bugs and Errors” thread.
Best regards
Tim
Hello David,
As already discussed before QBlade is currently accepting 64-bit controller DLLs only. Nevertheless, I would appreciate if you could also implement the handling of 32-bit controllers in the future, because it appears to be still quite common in the wind industry. I hope this is the right place for my “service request” – at least for me the topic would have been inappropriate in the “Bugs and Errors” thread.
Best regards
Tim
Quote from David on 25. July 2023, 15:25Hi Tim,
I remember our previous discussion, and it seems that this is a specific concern for commercial QB-EE users who work with older “legacy” controllers and lack access to their source code.
In contrast, the research community usually employs controllers compiled in 64-bit with full source code availability.
The challenge with addressing this issue lies in the incompatibility between 32-bit and 64-bit applications due to differences in memory models and data sizes across architectures. Fixing 32-bit DLLs without access to their source code necessitates mapping data and memory between 32-bit and 64-bit applications using inter-process communication (IPC) mechanisms. Although this approach is theoretically platform-independent for Linux and Windows, practical implementation often requires custom solutions on each operating system due to slight variations in features.
To tackle this, considerable development efforts would be required. However, we are going to to undertake this work if our commercial customers demand this feature. In fact, such endeavors can be beneficial in funding the work on these features, which could then also be released for the Community Edition of QBlade.
BR,
David
Hi Tim,
I remember our previous discussion, and it seems that this is a specific concern for commercial QB-EE users who work with older “legacy” controllers and lack access to their source code.
In contrast, the research community usually employs controllers compiled in 64-bit with full source code availability.
The challenge with addressing this issue lies in the incompatibility between 32-bit and 64-bit applications due to differences in memory models and data sizes across architectures. Fixing 32-bit DLLs without access to their source code necessitates mapping data and memory between 32-bit and 64-bit applications using inter-process communication (IPC) mechanisms. Although this approach is theoretically platform-independent for Linux and Windows, practical implementation often requires custom solutions on each operating system due to slight variations in features.
To tackle this, considerable development efforts would be required. However, we are going to to undertake this work if our commercial customers demand this feature. In fact, such endeavors can be beneficial in funding the work on these features, which could then also be released for the Community Edition of QBlade.
BR,
David