I want to create Virtual Microphone for Windows platform.
Which driver framework out of Windows Driver Frameworks (Kernel-Mode Driver Framework (KMDF) and User-Mode Driver Framework (UMDF)) and Windows Driver Model should I choose to make it work on Windows 10 and above?
By Default, any new driver development should be done in WDF, as for today the syntax of KMDF or UMDF (2.0) is the same.
you should be able to switch between KMDF and UMDF (unless you are using some special function only for KMDF or UMDF)
WDM is only used in special cases and I would not recommend writing drivers in it. (In most cases you can port WDM drivers to KMDF, you can always use WDM function in KMDF drivers if you don't find equivalent solution for it)
I recommend you start reviewing the [Microsoft Driver samples][1] repo
[1]: https://github.com/microsoft/Windows-driver-samples
Related
We have an application which uses an off-the-shelf Bluetooth USB dongle (CSR8510-A10).
Unfortunately, our app needs better control over the BLE hardware than Windows generic driver can provide. Our solution was to write our own BLE-HCI code, which works great, but requires the user manually replace the generic BLE driver with WinUSB (e.g. by using Zadig).
Our next step is to streamline the user experience to something like:
1. install our application, which can run some WinUSB driver installer
2. plug-in the dongle
3. --> Windows 7/8/10 should recognize it and use the WinUSB driver supplied in step 1
The dongle comes pre-loaded with firmware, which I cannot modify. It is possible, however, to change many attributes, including VendorId, ProductId, WCID etc, which we have - the VID/PID are now our own.
Questions:
- Is it possible to install a inf file, such that Windows ignores the WCID provided by the dongle's firmware?
- If not, is there another way to achieve this functionality, without modifying the dongle's firmware?
I'm trying to use connection to postgres with Qt Creator for embedded device with the Raspberry Pi 3, however the driver is not loaded. The same application on the desktop is ok.
My example is quite simple.
I have a console project with a main class and in it a log with
QSqlDatabase::drivers();
In raspberry list only QSQLITE, and desktop list QSQLITE, QPSQL, QMYSQL among others.
I am using oQt Creator Enterprise, connecting to the device with Boot2Qt, that comes with Qt Creator, compilation and execution is everything correctly, however is not listed PSQL driver in device.
QSqlDatabase::drivers() lists only the drivers that can be loaded on that particular platform, in many cases to have a working driver you need the Qt driver and a specific client library.
Probably there is a postgresql client library for raspberry with your specific linux version somewhere but Boot2Qt does not load it automatically to your board.
You have to find the client library for your specific version of linux (maybe you will have to compile it) then manually copy the postgresql Qt driver onto the board and the QSqlDatabase::drivers() should show you the postgresql driver available.
We have code to connect to various databases and we get the driver version after connecting using the SQLGetInfo() call with the parameter SQL_DRIVER_VER.
However, we want the driver version in other cases too, e.g., before connecting, and in case of an error on trying to connect. The only way to get the driver version in these cases at least on Windows seems to be via the file metadata information of the driver DLL. The drivers on other platforms do not even have this file metadata.
So, is there a way to get the driver version using ODBC when we are not connected?
Thanks,
Ed
The ODBC API doesn't support this interrogation until the connection is live.
There are tricks you can bring to bear, such as those used by the iODBCÂ Administrator.app on OSÂ X. You might look into that source code.
We are running an AS400 v5r2 and I have iSeries Client access installed. Since v5r2 does not support a x64 ODBC driver does anyone know how I can either install two versions (v5r4 supports x64) of iSeries Client Access on the same box or just install the x64 odbc driver from the more recent version without uninstalling all of v5r2 components.
Installing two versions of Client Access is probably not going to work, since both register their ODBC drivers with the same name, so only one would be available at a given time.
OTOH the PC side of V5R4 Client Access would probably work without problem with a V5R2 OS/400; perhaps even 6.1 iSeries Access, too. So you can upgrade the x64 box and check whether everything is working. FYI, I had problems with the first versions of 6.1 iSeries Access when running on x64 boxes, later versions were a bit better; also, I do not remember that V5R4 Client Access had a 64-bit variant at all.
Do not forget that on a x64 PC, there are two different ODBC drivers, one for 32-bit applications (stored on C:\WINDOWS\SysWOW64\cwbodbc.dll and that you can manage with the 32-bit administradorC:\WINDOWS\SysWOW64\odbcad32.exe), and another one for 64-bit applications (stored on C:\WINDOWS\System32\cwbodbc.dll and that you can manage with the 64-bit administrador C:\WINDOWS\System32\odbcad32.exe.) Unless your application is recompiled for 64-bit, what you are interested in is the former one, and if V5R2 Client Access runs flawlessly on that PC, everything is fine. Some applications like Office 2010 come in two flavours, but precisely for compatibility reasons like ODBC, it is still recommended to run the 32-bit variant even on 64-bit workstations.
1) V5R2 is very dead. You aren't going to get a lot of help when it comes to supporting an OS this old.
2) V5R4 is also dead.
3) Generally speaking, IBM intends that Client Access will work for operating systems two levels back and two levels ahead, so you could try using a V5R4 ODBC driver against a V5R2 DB2. The issue is going to be getting a V5R4 version of Client Access.
4) If you have questions about admin issues like this, Server Fault is probably the better choice.
EDIT: Add details of Client Access installation
Client Access has two logical pieces, a server side component and a client side component. Both pieces are available in the IFS, in the QIBM directory tree. If you have an already-working setup of Client Access on the server side, you can install the client side one of two ways:
1) Map a network drive to the IFS and run setup from there. This obviously won't be helpful to you because the V5R2 software doesn't support x64. If you are still under software maintenance, you could order a newer version of Client Access and install it on the server, and then use the newer version to install the needed ODBC driver.
2) Use the IBM-supplied CD to install the client component directly on the client. This allows you to install a different client version than the one on the server. Not generally recommended but in the case where you're migrating away from an unsupported machine, it's probably not a big worry. If your company ordered V5R4 at any time, you have the Client Access CDs.
The key thing for you is that you don't need to install the full Access product if all you need is the ODBC driver.
The biggest problem facing you is the age of the software. IBM stopped supporting V5R4 in Sep 2013. You aren't going to be able to place an order for it with IBM. You might be able to order V6R1 but the ODBC driver may not work with V5R2 - you'd have to try it. See the IBM i Access web site for details, but it's not downloadable.
If you can use OLEDB, try IBM's FTP site.
I am trying to get the mapviewer running. Whatever I do I get either one of these error messages:
Data source cannot be created : C:\oraclexe\app\oracle\product\11.2.0\server
\bin\ocijdbc10.dll: Can't load IA 32-bit .dll on a AMD 64-bit platform
Data source cannot be created : C:\oraclexe\app\oracle\product\11.2.0\server
\bin\ocijdbc10.dll: %1 is not a valid Win32 application
I understand that it has to do with the jdk/dll bit version. However, as I have tried all possibilities can someone please suggest a solution which I may have overlooked? Thanks.
It looks like you are using the OCI driver. Try using the thin JDBC driver instead. This is platform agnostic.
http://www.orafaq.com/wiki/JDBC
The OCI driver works with the installed Oracle client and therefore requires native DLLs. The thin driver is pure Java.