Windows 11
All components and examples in Hart Tools have been thoroughly tested on Windows 11 and
eventually been corrected. All corrections made were also subjected to another backward
test under Windows 10.
.NET Version
All applications using .NET have been upgraded to .NET version 4.7.2.
IDE Version
All applications have been upgraded to Visual Studio 2019.
Examples
New examples for Python and Visual Studio Code had been added. Another example had been
developed for the SlaveDLL.
HartDLL
The runtime behavior of time-critical processes has been improved.
SlaveX
The SlaveX control has the baud rate for Hart communication as a new property.
Documentation
The last version had additional documents. Their content was transferred to the central document.
Source Code
All source code files have been reviewed and modified so that they all have the same style.
According to Microsoft, the differences between Windows 10 and 11 are not that big (Windows 10 vs Windows 11). But the problem here, as always, lies in the detail. The following work resulted from this.
Console Concept
The day has finally come! Windows Terminal is now the default command line experience on
Windows 11 22H2! This means that all command line applications will now automatically open
in Windows Terminal.
Luckily there is only a small example in Hart Tools 7.6 of C++ programming using the
console. The source code of this example has been adjusted accordingly.
Especially in Windows 11 it can be seen that not all API functions for the console really
work anymore. Most of these functions are no longer recommended for use. We have therefore
partly switched to the Virtual Terminal concept, which uses escape functions as a basis in
order to become independent of a platform.
Future examples of a similar kind must also be implemented like this. However, at least
for the near future, sufficient backwards compatibility on Windows 10 must also be ensured.
Furthermore, in the future we will abstract such implementations to such an extent that
they can also be easily adapted to other systems such as Linux.
Struct Member Alignment
The C/C++ headers in the Windows SDK assume the platform's default alignment is used. Don't
change the setting from the default when you include the Windows SDK headers, either by
using /Zp on the command line or by using #pragma pack. Otherwise, your application may
cause memory corruption at runtime.
In communication applications it is common to design structures in such a way that they use
the available space optimally. It is therefore essential to set the struct member alignment
to 1 byte. Since it no longer seems advisable to do this globally, we have explicitly
changed all structure declarations.
However, this only applies to C++/C sources.
For the most parts, FrameAlyst has been left as it is. There were only two small changes regarding the baudrate of the slave.
Baudrate Slave Simulation
The baud rate of the hard slave simulation is adjustable. However, one should be careful
with its use, because the required timing also changes with the baud rate.
Dark Colors The Color Set 2 has been replaced with a new one for Dark Colors.
Function Calls The function calls of the DLL remained untouched. Only the name of the DLL has changed from BaHartDrv75 to BaHartDrv76. However, some small improvements were made in the implementation.
CloseChannel The delay of the function BHDrv_CloseChannel was reduced.
Semaphore Handling The locking of other threads in critical sections has been reduced to a minimum to make parallel runtime processes faster.
Thread Naming (Internal) Previously, the name of the communication thread was set via an exception. It turned out that this doesn't always work properly with the debugger. Therefore, this internal function was removed in version 7.6. See also: Thread Naming.
Debug(x64) Microsoft requires a 64-bit architecture for controls that are to work with Office64. Therefore we have introduced a new directory for it.
Windows 11 is preferably shipped with Office64. But it is also possible to install
Office32. However, both offices cannot exist together on one computer.
I think that the plan is that at some point there will only be office64. What applies to
Office also applies to individual .Net controls. Therefore we have provided a 64-bit
registry in the setup for the HartX HartTools 7.6.
However, it must also be possible to support a 32-bit variant in the development
environment.
Therefore you have to register the HartX control with the 32 bit assembly DLL. The
sequence of the workaround is as follows.
If you are interested in more information about the regasm tool, please point your browser to this link: Regasm.
office@walter-borst.de
Hart Communication Protocol Software
Walter Borst, 3.11.2025