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.
All applications using .NET have been upgraded to .NET version 4.7.2.
All applications have been upgraded to Visual Studio 2019.
New examples for Python and Visual Studio Code had been added. Another example had been developed for the SlaveDLL.
The runtime behavior of time-critical processes has been improved.
The SlaveX control has the baud rate for Hart communication as a new property.
The last version had additional documents. Their content was transferred to the central document.
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.
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.
Visual Studio 2019
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.
The Color Set 2 has been replaced with a new one for Dark Colors.
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.
The delay of the function BHDrv_CloseChannel was reduced.
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.
Microsoft requires a 64-bit architecture for controls that are to work with Office64. Therefore we have introduced a new directory for it.
HartX with Office32
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.