Need to install non-PNP kernel device driver under Windows 7. Old reliable INSTDRV.EXE fails on StartService, claiming "2 -- system cannot find the file specified" although fully qualified path to driver SYS file is absolutely positively accurate. I realize Device Manager has an "install legacy driver" Action menu item, but that requires identifying a specific device, which I don't have. Why doesn't INSTDRV.EXE work under Windows 7? How can I install a non-PNP kernel device driver under Windows 7? Thanks.
As far as I know, on modern Windows you have to write .inf file. Read this short MSDN article.
There is a tool in WDK that helps installing drivers. Just copy it to your driver's folder and run it.
Update:
After submitting this answer I've found another way of installing non-pnp drivers. There is another tool, DevCon. It can be found among other WDK tools (Windows Kits\10\Tools\x64). Just copy DevCon.exe to your driver's folder and execute like this:
devcon.exe install pcscgate.inf Root\pcscgate
Root\pcscgate - device identifier that matches the one in [Model] section of .inf file (yes, you still need that file). DevCon creates an empty device node with this identifier and then installs driver.
I had a similar problem just now, finally solved it by setting Linker/Input/Ignore All Default Libraries to Yes (/NODEFAULTLIB).
Related
I am trying to build a Windows driver for a piece of hardware I am using. The build notes seem dated as they specify using DDK for Win7. I have Windows kit version 10. Are these the same thing just later version? The instructions then state to open a DDK command window environment then use "build -ceZ" in the dir where the files are located. Does v10 have this console and if so where can I find it? Thanks
https://learn.microsoft.com/en-us/windows-hardware/drivers/devtest/wdk-and-visual-studio-build-environment
"The Windows Driver Kit (WDK) 8.1 and WDK 8 introduced a major change
to the environment that you use to build a driver. The WDK no longer
uses Build.exe. The WDK build environment for drivers uses MSBuild.exe
and is fully integrated with the Visual Studio development
environment. This means that source files, makefile.inc, makefile.new
and other related build files present in the previous version of the
WDK are no longer used. The WDK now enables you to create, edit,
build, test, and deploy a driver through Visual Studio. The purpose of
this document is to provide information to help users familiar with
previous WDKs in getting started with the WDK 8.1 and WDK 8."
If you want to build the driver as is then you will need to install the Windows 7.1 DDK and build it using its tools.
https://en.wikipedia.org/wiki/Windows_Driver_Kit
https://www.microsoft.com/en-gb/download/details.aspx?id=11800
You are allowed to install different versions of the DDK on the same machine.
You might find it tricky to install DDK 7.1 on Windows 10 though, try and use this to get around any problem install.
https://stackoverflow.com/questions/32091593/cannot-install-windows-sdk-7-1-on-windows-10#:~:text=If%20you%20continue%20with%20Setup,187668%20and%20then%20rerun%20Setup.
Then it's just a case of "choosing the 7.1 ddk environment (32bit or 64bit)" so that it's tools are accessible/used when "building" your driver.
Look in your startmenu at "StartMenu -> Windows Driver Kits -> WDK XXXX -> Build Environments" to find a command prompt to open.
If you can't/don't want to install the DDK 7.1 and a WDK8+ version of your driver project isn't available then it may be possible to convert the driver from using the older "makefile" into new msbuild way of building, but might be fiddly.
https://community.osr.com/discussion/289475/build-exe-to-msbuild-exe-migration-advice
"If you go into VS you should be able to create a WDK driver project.
It will give you a solution with (I think) one C file filled with
everything necessary to make a driver which does nothing. But, most
importantly, it will generate an XML file that MSBuild will accept.
The XML format is not documented. After you have this XML file you
should be able to figure out how to add your files to it by hand, but
you could move the existing driver files to the project using the GUI.
That may be easiest."
I've just spent a very long time looking through everything on https://electron.atom.io/docs/ but I cannot find any mention of how to put the files for Mac and Linux. Only Windows, which I already have set up.
I remember that NW.js had such instructions, which I followed in the past, but it's obviously too ridiculous to accept that I should have to look at a competitor's manual to figure out how to distribute Electron apps.
I remember that at both Linux and Mac had some very fancy/weird packaging need, very unlike Windows.
I would recommend looking into electron-builder which would help you with generating packages for all of the mentioned systems (with auto-update and other goodies).
You can also take a look at electron-boilerplate to see how it can be nicely implemented (this boilerplate has a release command that allows you to generate packages).
For the mac version you can use electron packager to generate a .app file then you can use appdmg to generate a .dmg
For the linux version you can use electron packager to generate a executable although it comes with lots of other files.
I've tried electron-installer-debian but I couldn't install the output .deb
When trying to port the Calculator sample from the official Windows Bridge for iOS blog, I always get the following error after converting the project and trying to compile it:
could not acquire lock file for module 'UIKit' Calculator (Calculator\Calculator) W:\Source\Bridgetest\Calculator\Calculator\ViewController.h 9
I am using the latest version of the bridge 0.1 Preview (April 29, 2016).
Oh, and I am using Parallels for my Windows VM.
Any ideas?
I believe your question has been answered on Github, but I'll answer it here as well in case it's useful to anyone who finds this:
The problem here was the project and the WinObjC SDK were both located on a network share, which is how Windows identifies folders that Parallels shares between Windows and OS X. This causes problems for both vsimporter and Visual Studio.
Normally, vsimporter writes an absolute path to the WinObjC SDK in any imported projects. If you invoke vsimporter with the -relativepath option it will write a relative path instead. In either case, you also have the option to define WINOBJC_SDK_ROOT as an environment variable, which will take precedence over the path hard-coded in the project file.
If you would like to keep your code on a shared directory that is accessible from both OS X and Windows (so you can develop in Xcode and Visual Studio simultaneously from the same code base), you can do so. However, by default, Visual Studio will not register an app with the system if its files are on a network drive, so you'll have to change a few settings to get Visual Studio to build and run. Instructions for doing so can be found in our FAQ on Github.
I can't install the nvidia installation in cuda toolkit. I don't have a nvidia card. Does that means I can't use emgu.cv? I been on this all yesterday and emgu.cv is still giving me problems.
Here the link that still shows my problem:
Exception initializing Emgu.CV
Actually you can. Run the installer. Then go to the directory where it has unzipped all the files and choose nvcuda.dl_ and using command prompt expand it into nvcuda.dll.
Place this dll in system32 folder.
This should solve the 'nvcuda.dll not found' error.
I have a eVB application that I need to get running on newer WM6+ devices and need to know if at all its possible?
I have installed the VB Runtime files and I can manage to get the program installed but it fails to run with "Access Denied" Errors.
I have the eVB source files so if I need to re-package the installation I can.
Has anyone ever managed this?
I never tryed this before, but you can re-install the runtimes and see if it fixes.
Regards.
Microsoft doesn't support eVB on newer devices.
You can convert the program to NS Basic/CE - it will also boost the performance of your program and make it compliant with Windows phone 6.5.