The number of questions and answers depends on whether you are logged in.
Yes, our real-time drivers—in general, all our installation and application files—are already signed. Especially, for 64 bit systems this is compulsory required to use the software correctly. However, a signed driver shows reliability.
That implies also that our software can simply used as a driver for your PCI/PCIe or USB device. For this reason, the included INF files have to be upgraded by an entry on the documented way. This is even needed to address hardware safely on every system.
Our offer: Send us the required hardware IDs and we will insert them into the INF file, making them signed by the CAT file in the process.
Please note: exception and solution
Yes, Kithara RealTime Suite included a C# class, which supported by the API. By this class it is possible to activate the entire range of functions with a C# application. However, parts of the program, which contains real-time capable code, have to be embedded and swapped in a DLL with native machine code (x86 or x64) or Delphi. In order to keep this stage of development as simple as possible we deliver a project template, which shows how does it work. This project file can used immediately for own developments.
In principle, it is possible to use VB6 to use our software. But since VB6 is very old now, there are only a few sample programs. The main goal of our software is to offer libraries for implementing "real-time under Windows". This can only be done on the kernel-level of Windows. So, languages that can run on the kernel-level are needed. Those languages are currently only C/C++ and Delphi. For many examples, we also support C# projects, because it is possible to program the main application in C# and put only the time-critical parts into a DLL written in C++.
If you would use VB.NET, then it would be easy for you to use the C# interface. But still it would be necessary to program a DLL written in C or C++ for time-critical code. If it is not time-critical (real-time), then you could stay on the application level and write everything in C# or VB.NET.
Even if it would be possible to program in VB6, we do not recommend this, because VB6 is not capable to execute multi-threaded applications properly. The same occurs for OCX, so it should be clear why we do not made any attempt to develop OCX components.