I want to build a WDM driver in the latest WDK. What's the difference between the sources file for WDM and WDF? How can I specify the build taget as WDM instead of WDF?
KMDF is just a wrapper library around WDM, so a SOURCES file with no references to KMDF build a WDM driver. Usually the only reference to KMDF in a SOURCES file is:
KMDF_VERSION_MAJOR=1
See the WDK documentation and samples for more info.
-scott
Related
I am building a universal macOS app which uses sqlite3.
The library that comes with the system is of course architecture specific.
So when archiving, XCode ignores the system library and emits linker errors because there is not an intel version.
So will I have to download and embed a multi-architecture version of the library?
Or is there a weak link flag I can use?
Also the compiler emits a warning about sqlite version built for newer OS version (13) than being linked (deployment target macOS 12).
TIA
Mark
Sorry about noise. Discovered I could embed the sqlite3 source directly into my project.
Downloaded amalgamation source file and it just worked (with some minor warnings about int sizes).
I just created a KMDF Sample driver using Visual Studio 2013 Express with WDK 8.1 on a Windows 7 (64 bit) computer. When I build the solution I get no errors. As I want to check later if my driver is running I inserted the common Debug-Line into my DriverEntry-Routine:
NTSTATUS DriverEntry(...)
{
DbgPrint("Test\n");
// ...
}
By the Windows Device Manager I can install the driver manually, by adding a legacy device. Of course Windows will complain about the fact that the driver is not signed. But anyway later I can see the installed driver in the device manager, preceeded by a warning symbol:
With DebugView (from Sysinternals Suite) I am waiting for my debug message to occur, but nothing happens. The only debug messages I get during driver installation is this:
[1768] WdfCoInstaller: [02/07/2018 12:43.22.162] DIF_INSTALLDEVICE: Pre-Processing
[1768] WdfCoInstaller: [02/07/2018 12:43.22.168] ReadComponents: WdfSection for Driver Service KMDFDriver1 using KMDF lib version Major 1, minor 11
[1768] WdfCoInstaller: [02/07/2018 12:43.22.177] DIF_INSTALLDEVICE: Coinstaller version: 1.11.0
[1768] WdfCoInstaller: [02/07/2018 12:43.22.185] DIF_INSTALLDEVICE: KMDF in-memory version: 1.11.0
[1768] WdfCoInstaller: [02/07/2018 12:43.22.188] DIF_INSTALLDEVICE: KMDF on-disk version: 1.11.0
[1768] WdfCoInstaller: [02/07/2018 12:43.22.191] Service Wdf01000 is running
[1768] WdfCoInstaller: [02/07/2018 12:43.22.194] DIF_INSTALLDEVICE: Update is not required. The on-disk KMDF version is newer than or same as the version of the coinstaller
[1768] WdfCoInstaller: [02/07/2018 12:43.22.305] DIF_INSTALLDEVICE: Post-Processing
So this leads me to the question why my driver is not running? I guess it has something to do with the signing of the driver, but I also don't know how to sign it. Or maybe DebugView is the wrong tool for this?
Use OSRLOADER to load your device driver for testing purposes. You also may need to perform some registry changes.
You can download OSRLOADER from here: https://www.osronline.com/article.cfm?article=157
Check this question's replies for insight on what to do next regarding DebugView and the registry: No output from DebugView
As for driver signing, go to project properties and choose the Driver Signing tab. You can set the certificate type for testing and then just create a random test certificate. The environment the driver will be tested on however will need to have Test Mode enabled, or be started up with DSE disabled for that session. You can find out more here:
https://learn.microsoft.com/en-us/windows-hardware/drivers/install/how-to-test-sign-a-driver-package
https://learn.microsoft.com/en-us/windows-hardware/drivers/install/the-testsigning-boot-configuration-option
Everything is already documented, all you need to do is a simple Google and you'll have all the information. MSDN alone has quite a lot of content about getting into driver development, driver routine documentation, example source code, even videos sometimes.
I have the Kodi source code from github.com and I want to compile the source for an external media player.
I am able to compile the source to run on the Mac (El Capitan) using xcode.
Can I compile the source into an img (or file I can convert to an img) from which I can then create an SD card for an IMX6 Freescale device? I don't know Xcode very well and can't see how I would add a new target (if that is it) or if I need additional libraries or source to compile something for a linux platform.
I basically have a CuboxTV but I want to use Kodi v17 (krypton) so want to see if I am able to have that running on my CuboxTV (with v17).
Kodi v17 compiles and runs on the Mac - I just need to find out how I can compile it to run on a linux platform using an IMX6.
Any help would be greatly appreciated.
Thanks again :)
CuboxTV comes preloaded with OpenELEC, which is a Linux distribution specifically designed for Kodi.
If you want to compile the source code of KODI from github for the i.MX6 platform and write it to an SD card, you will need to take a distribution from the Cubox Download page (Debian, Archlinux, etc) to install Kodi on top of it.
You can take a look at the kodi-imx PKGBUILD for Archlinux in order to check the compiling instructions and dependencies.
https://github.com/archlinuxarm/PKGBUILDs/blob/master/alarm/kodi-imx/PKGBUILD
The binaries for Linux, OSX, and Windows are all embedded in the sqlite-jdbc.jar...
org/sqlite/native/Linux/amd64/libsqlitejdbc.so
org/sqlite/native/Linux/i386/libsqlitejdbc.so
org/sqlite/native/Mac/i386/libsqlitejdbc.jnilib
org/sqlite/native/Mac/x86_64/libsqlitejdbc.jnilib
org/sqlite/native/Windows/amd64/sqlitejdbc.dll
org/sqlite/native/Windows/x86/sqlitejdbc.dll
My problem is, that while I'm running Linux, I am not on amd64 or i386. The Raspberry Pi is ARM. Where can I get a sqlite-jdbc.jar with the ARM binaries embedded?
A lib provided by someone who claims to have build it: https://bitbucket.org/xerial/sqlite-jdbc/issue/79/compile-for-arm
Instructions for build https://pidome.wordpress.com/2013/10/01/java-goes-hard-on-the-raspberry-pi-so-does-pidome/
and
Error opening connection SQLite on Raspberry pi
#dacracot
I'm not sure if i'm prohibited by offering help this way but:
I have the library available when you would download the whole PiDome server package.
For convenience, and multiple requests i have added it as a separate download. The library has been compiled against the hard float abi and is currently using sqlite-jdbc-3.7.15.
The jar file contains the default supported platform libraries and has the arm support added.
It is available at: https://bitbucket.org/pidome/pidome-server/downloads
I'm currently developing a driver in osx and i'm having problem using XNU files in my Xcode project. I built XNU according to the instructions here:
http://shantonu.blogspot.co.il/2013/10/building-xnu-for-os-x-109-mavericks.html
It successfully builds.
Should I install it in a specific directory for XCODE to find the library and header files?
thanks.
For developing kernel extensions to use with regular OSX kernels, you shouldn't be using a self-compiled kernel, but use the Kernel.framework that Apple supplies with Xcode and the bundled OS X SDK. If you're using Xcode for your build process anyway, the easiest way is to use one of the kext target templates (I/O Kit driver or generic kext) to set up the build system and include the kernel.framework.
If you have an existing Xcode project to which you want to add a kext build, open it and create a new target, then choose one of the kext templates under "system plugin". You get the same choice when you create a new project altogether.
As for choosing between the two templates:
Generic kext is mainly useful if your userspace application will explicitly load the kext.
I/O kit kexts can be loaded automatically on device hotplug or on system boot, so they are usually the most useful if your kext doesn't have some kind of userspace trigger.