DelphiUdIT

@Rollo62: No, both old (Acer I7 Intel) and new PC (Asus I7 Intel) have the integrated Bluetooth. The old one was ( RIP) 3 years old, the new is less then one year old. I think that the malfunction of the old one was about the compatibility with BLE radio spectrum, may be the Bradcomm Bluetooth was not fully certified for BLE. I tried also in the past with old versions of Windows 10 and different Bluetooth constructors with no success. But the failure probably also depends on the implementation of the Windows Bluetooth (stack), which only in Windows 10 and after several releases of the same has been made fully functional. In an old test, while in Windows 10 the BLE devices were not seen, in an Oracle virtual machine with MAC OSX (I don't remember the exact version, I think Sierra) the BLEs were seen .... very curious. Now, in the next weeks (thanks LOCKDOWN ) i restart testing BLE on Windows with various hardware. Bye

Now that you have tickled the Bluetooth topic, which I had filed, I tried again with the new PC, which has an Intel Bluetooth compared to the one I tested with which had a BroadComm, and in fact the BLE devices are seen correctly without pair them. To see them I use the TBluetoothLE component and the DiscoverLEDevice event which is called for each BLE device found.

From Help: You should "have" the event immedialtly if all is working. I doubt that the BLE is working without any pairing (i cannot try beacuse i don't have any BLE that Windows can see …). If you want to test it after a period, I recommend that you test it after 10.24 seconds. This time comes from a Bluetooth 4.0 specification and is the maximum (worse) response time of a Bluetooth device. I use half of that time (5.2 seconds) and BLE devices always respond ... obviously not tested on Windows platform but on Android. I normally use around seven BLE devices via GATT. There are some answers on Stackoverflow about that (if i remember good). Since I have to work with BLE devices that Windows cannot see, I have given up on developing BLE applications on Windows. Tell us if you will be luckier. Bye

This is the explanation why in Windows 10 it is not necessary to "pair" BLE devices. But the devices must be able to pair, which normal BLEs don't.

Bluetooth "classic" and Bluetoooth "LE" are different things !!! With Windows (any version) you can use BClassic after pairing the devices. And you can use normal api from (TBlutooth component for example). To use BLE in Windows application the BLE devices should be able to pairing with OS. But BLE pure devices (like industrial sensor devices, or other commercial devices) doesn't understand the "piairing" conditions, because it's a no sense. They work on the GATT services basis. So the normal Windows application cannot use BLE. Again, the BClassic and BLE use different radio spectrum tipologies. Microsoft told that the UWP applications using the WinRT api (that are different from the standard Blutooth api) are able to use the BLE. Also, there should be some Bluetooth stacks that may work in Windows with BLE. Take care: some devices (like many smartphones) have the Blutooth radio that works both in BClassic and BLE. This means that you can pair a smartphone and somtimes use the BLE. @emailx45: i'll look at you suggestions, but i think that they speak about BLE with pair conditions. Bye

I have never been able to connect a BLE device with any version of Windows. If you want to use BLE with Windows you have to use WinRT api (i.e. you have to create a UWP application). I've heard you can use BLE with Windows with a special BL stack, but I don't know anything about it. Like you I was able to use BLE with other devices like Android 32 or 64 without any problem. Bye

Using the pkcs11-tool available at this address: you should be able to extract the certificate (not the private ones of course) from the usb token. This is a very old openssl discussion about that: In that discussion (still true ?) they explain how to extract the certificate and convert it in "pem". I think that the "pkcs11 module" needs to extract the certificate is a dll normally available with the USB Token (look in the system32 directory or in the syswow64 for something with *pki*.dll). In Italy very often the dll is "bit4xpki.dll" (used also by Firefox). I hope these informations are useful to you, although I'm not sure. Bye

By the way, you can also use the hardware CPU timer (rdtsc instruction) to get the maximum accuracy in timing (with a resolution to the nanosecond or even lower, depending on the CPU), but obviously in an environment like Windows (also for Linux and other non-real time operating systems) the analysis of processing times can only be understood as an "average" value.

You can use the System.Diagnostic unit, and the TStopWatch for high precision timing. With that you can "timing" every line of your code (of course if the code is blocking). If you use not blocking code the free method is recording all the "Windows messages" in that time (10 seconds) and analyze the events timing. For those who are old enough, they will surely remember WinSight. I never used tools other the TStopWatch, with this i resolved all the issues.

Hallo to all, since 10.4 (and 10.4.1) debugging c++ DLL for x64 Windows S.O. is impossible (for me of course). ALL THE PROJECTS ARE COMPILED FOR X64. If I launch standard debug from Delphi project, the DLL source code (made in c++) is ignored and no breakpoints are used in the DLL. If I launch LLDB debug from c++ DLL (setting the correct host of course), an error like this is generated and the app doesn't start. If you launch the app with or without Delphi debugger all is working. Same situation with remote debugger (via "old style debugger" or paserver). Before LLVM all is working and i can debug DLL c++ code. I miss something or do something wrong ? Attached is a very simple project group to test. Thanks for your attention. Test.zip

Reported, https://quality.embarcadero.com/browse/RSP-30893

LOL … That is really strange: hoping that it's only my problem. I will insert a ISSUE in QP as soon as possible.

I strongly doubt that the eventual problem is due to a "logic" error linked to multithreading, because normally this would generate exceptions with memory access errors recorded in the Windows system log. Many years ago I also made the mistake of calling CoInitialezeEx without CoUninitialize and there were several problems especially when closing the application. Since then I ALWAYS use the CoInitializeEx (nil, COINIT_MULTITHREADED) at the beginning of the threading EXECUTE method (not in the while block, of course) and the CoUninitialize at the end of EXECUTE (when the thread terminates. Obviously, ONLY within the EXECUTE method (or in the methods subsequently called by it) will it be possible to access the OLE / ACTIVEX resources for that thread.

Hallo, I have tried to create a "standard" component using RFC guidelines, but this fails to overcome the different interpretation of the standard (tag, CRC, UDP or TCP, hidden channels, video compressor, ...) that the manufacturers of cameras and video recorders (speaking of video surveillance) have then applied on their products. I have not found anything better than VLC (I use PASLIB VLC as a wrapper) for the general use of RTSP. I hope you find something better and independent. Report it if you find it.