I am wondering how I will be able to integrate my KMDF driver into a Universal App. Currently I have the user download a KMDF driver which is used in my desktop application. If I transition to a universal app, how will I be able to use my drivers? Does "Universal Driver" mean it can run in a "Universal App"?
How does the phone or xbox download my driver?
I think this is what I gather from my research:
it more relates to the fact it can run on any Microsoft device (Desktop, phone, tablet, xbox). However those devices must be UWP (Universal Windows Platform) which pretty much means they must have at least Windows 10.
The Universal Driver and Universal App are two separate things. The Universal App can implement the Universal Driver, but it can also implement a KMDF driver (but only in a Windows 10 desktop application). A Universal Driver can be used by WPF application (but only on a Windows 10 desktop).
If I turn my application into a Universal App, and change my drivers to be universal, any platform should be able to use my app.
Is this correct?
Still unsure how something besides a desktop runs a Universal Driver.
As you surmised, Universal Drivers mean that the drivers can run on any device running Windows 10 (PC, Phone, IoT, etc. -- in theory Xbox as well but that's a closed platform). A Universal Windows App can also run on any device running Windows 10, but it can't contain drivers; drivers must come from Windows Update or from a legacy installer like MSI for the desktop.
Whether or not your Universal App can talk to your Universal Driver depends on whether you need to pass Store certification or not; how the driver is exposed (eg, via HID or something else); etc.
Related
I am developing a Win10 C# application dependent on a third party library, which enables me to control a USB3 device.
By trial and error, I found that I needed to run FTD3XXDriver_WHQLCertified_v1.3.0.4_Installer.exe, which in the end populated the SysWOW64 with FTD3XX.dll and System32\Drivers with FTDIBUS3.sys and the ancillary files and folder.
I would like to run my application from a USB thumb drive on different PC's in my organization without installing any of the drivers. Is there a way to do that?
Bad news: To the best of my knowledge you cannot address an FTDI device if the driver is not installed.
But windows normally install the driver automatically via the windows updater. At least, this is the case for the USB 2 devices of FTDI i.e. 232 family. I do not have a FT60X here to test if the windows updater has a driver ready for this as well.
If the driver is installed via the updater you have to bundle the FTD3XX.DLL with your application as it is not part of the "windows standard" driver. At least this was the case for the FTD2XX.DLL.
Long story short: connect your device to a computer without preinstalled driver. Check if the driver is installed via the windows updater. If this is the case, you mostlikely just need to bundle the FTD3XX.DLL with you application.
I'm trying to test a website using Windows 10's touchscreen gestures. We don't actually have a Windows 10 device with a touchscreen, but www.browserstack.com and www.saucelabs.com/ do not have this option.
What's the right way to test via Windows 10 touchscreen, short of actually buying a Windows 10 device with a touchscreen?
While SauceLabs do provide real devices they rely on Appium to interact with the devices.
Microsoft have released a windows hardware lab kit ("Windows HLK").
There is more documentation here.
This appears to the "right" way perform this testing.
To make my program could communicate with Nokia phone I have setup libusb-win32 library. But after I have this library installed any standard Nokia soft like PC Suite refuses not only to communicate but even to detect my phone! The phone is still available only to my program through libusb-win32 now. Removal of the libusb0.sys driver helps and phone becomes again accessible through Nokia PC Suite, but then it is no more visible to my app via libusb-win32 library. Whether it is somehow possible to get the phone accessible as through libusb-win32 for my application as for standard Nokia phone programs (Nokia PC Suite, NSU, NSS, etc.)?
I run Windows 7 Enterprise and libusb-win32 1.2.6.0
Answer to myself. Yes, it is possible. The driver libusb-win32 should be installed in the filter drive option, not in the device file option.
I am looking to implement the use of a Bluetooth 4.0 Smart Ready device (Polar H6/H7 Heart Rate Sensors) in my application. I am forced to target Windows 7 OS. However, I'm only seeing Windows 8 support for Smart Ready devices. I will not be able to upgrade clients to windows 8 in order to use these devices.
The first problem I found is that Windows 7 does not even see the device in order to pair with it. This might be the dongle I'm using. I have tried 2 different ones. The first is a CSR V4.0 (I'm not sure the actual model number). The second is StarTech USBBT1EDR4. Both seem to be using a CSR chipsets. Maybe I should try a different chipset based dongle? Such as Broadcom or TI?
I do see and can pair with the device with my Windows 8.1 Surface Pro.
Is there no way to get Bluetooth Smart implementation for Windows 7 OS platform?
I've recently faced the same problems! I need to run an application in o older version of windows (win xp) and I cannot find any support to that with my dongle (one based in broadcom bcm20702).
What I've found is that windows prior to windows 8, has no bluetooth low energy support, so you would not be able to use the windows bluetoth stack, and broadcom doesn't have a sdk for BLE (I've contacted them, and they said it).
So I've looked for other alternatives and BlueGiga bluetooth 4.0 dongle has a C SDK that you can use to develop your applications in Windows XP and 7. In that page (after register) you can find all the documentation you need.
I've also found a C# Wrapper and a Java Wrapper to its API.
Hope it can help.
[EDIT] : just received my dongle, tried it with win XP and it worked. Guess this is a solution for you also!
Strange thing is, I installed windows 10 and I could use bluetooth smart from my Logitech MX master mouse, but I had to go back to windows 7 because of display drivers and now it does not support it anymore. Windows 7 does not support smart bluetooth. It's just a driver I would presume, but Logitech does not provide it.
I find it realy strange that the old bluetooth device in my laptop worked fine with bluetooth smart devices in Windows 10 but in windows 7 it can only connect to plain old bluetooth devices.
Before I ask my question, here's some background information so that you might have a better understanding of what I am trying to accomplish. I have searched around and found similar questions but none that are specifically what I am asking.
I am trying to port over a modified 32-bit PLX Pci9056 device driver to 64-bit. I also have a few User apps that utilize the driver. PLX provides a complete SDK, including the PLX API in a dll, driver source code, and tools to create and debug user apps. It uses the Windows DDK build environment to build the drivers. The following is how they all interact:
User app --> PLX API --> PLX Pci 9056 driver --> PLX chip
The 32-bit driver has been tested on Windows 7 32-bit and works properly. I believe I should be able to simply rebuild the driver in the 64-bit Windows DDK build environment (Of course after handling any pointer casting. Please correct me if I am wrong.) At this point the driver should run properly on a 64-bit Windows 7 machine.
I understand that usually 32-bit apps will run fine on a 64 bit machine, but in this case the User app is using the PLX API which was initially built only to support 32-bit. Will my User app still work in a 64-bit OS without updating it, or will I run into issues?
The PLX PCI SDK (now Broadcom PCI/PCIe SDK) has supported both 32b/64b drivers with the same source code for many years now. Special macros are used when required, etc. In Windows, your 32-bit app will work fine due to WOW layer. The PLX IOCTL structures always store pointers in 64-bit fields to ensure the structure does not vary if you build a 32-bit app. The SDK also provides 64-bit build of the API library, so you can also build your app as native 64-bit. The same app level source code, for the most part, should work in both Windows & Linux. The samples provided in the SDK are all identical source for both Win/Linux.