I am in the process of writing an application to communicate with Usb devices using WinUsb.dll. This is a user-mode library that allows communication with a device through winusb.sys installed as its driver in the kernel.
I am writing this application in C++ with Visual Studio 2008.
The header WinUsb.h is found in the Windows DDK so I add the include path "D:\WinDDK\7100.0.0\inc\ddk". I then get an error that Usb.h cannot be found which WinUsb.h includes, Usb.h is also in the ddk but in a different directory, so I add "D:\WinDDK\7100.0.0\inc\api" as an include dir.
Once I add that path then everything goes in the toilet and I start getting compile errors in stdio.h and a bunch of other weird places.
I really don't want to use the DDK build system and compiler in order to simply use this DLL, thats one of the main reasons I'm using WinUsb instead of writing a proper driver.
Has anyone built an application using WinUsb.dll and Visual Studio?
I am working on writing a cross-platform USB library and using the DDK build environment would make my build process much more complicated.
WinUsb is meant to be used by client applications for devices who load WinUsb.sys as their driver. However there doesn't seem to be a version of the WinUsb headers packaged for use in user-mode programs (not including UMDF drivers).
What I ended up doing was copying the few headers that support winusb.h out of the DDK and into a private directory, I then reference that directory as an include directory during the build.
These are the headers I needed to copy:
POPPACK.h
PSHPACK1.h
usb.h
usb100.h
usb200.h
winusb.h
winusbio.h
Once I had these included in a private directory and linked with winusb.lib in the DDK I was able to compile and run my project in Visual Studio.
I don't know if I'd recommend this method as it could be bad when the headers change between DDK releases, but I will open a CONNECT bug to see if I can get MS to create a package of WinUsb headers for use in client user-mode applications.
Historically the DDK and the SDK haven't played well together, but that problem was fixed sometime before Vista was released. However, it seems like you might be mixing parts of one SDK with another, which isn't good. I'd either use the DDK build environment or at least take a look at the INCLUDE path the DDK environment sets up and replicate it exactly in the VS project settings.
Note that you can use the DDK build environment and still use the VS IDE by creating a 'makefile project' or you might be able to use something like OSR's or Hollistech's DDKBUILD tools:
OSR's: http://www.osronline.com/article.cfm?article=43
Hollistech's: http://www.hollistech.com/Resources/ddkbuild/ddkbuild.htm
I haven't used these, so I'm not sure how well they work, but note that in spite of their similar names and uses they are different tools.
Related
I'm working on an embedded linux project. In this project, when i code, i usually go back and forth between a c++ user space application and a linux driver used by the user space application.
I use VSCode and in my C/C++ properties, to allow intellisense to be helpful when working on the linux driver, i needed add to the "includePath" the path to the linux include directory ("${workspaceFolder}/.../linux/include").
This is working fine from the linux driver point of view, the only problem is that this include path is used by intellisense also when i work on the user space application and obviously a few names and macros end up in conflict here and there (e.g. std::min and std::max conflict with the min and max macros from the linux include files).
So my question is: is it possible to specify an include path only for a subfolder of my project and not for the whole project? I would like intellisense to consider the linux/include folder as includePath but only for a specific subfolder of my project (the linux driver one). If it's possible, how can this be achieved?
I know i could consider the userspace application and the driver as two different and separate projects, each with its own cpp properties, but that would make switching between the two subprojects a bit more cumbersome.
I just wanted to ask if anyone has been able to setup your GLFW/GLAD project in VS Code to work both in Mac and Windows, as I usually have to switch between those 2 OS and I would like to be able to work on my project on both of them.
These libraries work across multiple platforms, and program code that uses them can too. Building your projects is your primary issue, which you can do either by writing a build script for both of your platforms, a makefile, or by using something like MSYS2/Cygwin to make your Windows environment more like your Mac one. I'm sure there are many other options too!
You'll want to set up version control to allow you to work on the same project from both environments without having to copy files over manually. Unless you want to compile all our libraries from source (which you might), your best bet would be to ignore your library folders from the main version control branch so that they can differ between environments.
I need to use ZwLoadDriver function from ntddk.h. I installed Windows Software Development Kit (SDK) for Windows 8. Set all includes (#include <ntddk.h>). And I have lots of errors like type/sruct redefinition, ... already has a body. I think that my headers from the SDK mixes with the ones from the DDK. How to fix this ?
The DDK should only ever be used to develop a driver. It is water and fire in user mode, lots of declarations overlap with the SDK headers.
Using NtLoadDriver() from user mode is undocumented, no header is available to get a declaration and there is no import library available for ntdll.dll. It is a native operating system api function, even its argument uses a non-standard format for the registry key. The native OS is very different from the Win32 api. If you really, really want to do this then you'll have to write your own declaration and use GetProcAddress() to get the entrypoint in ntdll.dll
But loading drivers from user mode code is already well supported in Windows. Best to use the documented and supported way, OpenSCManager + CreateService. A sample project is available here.
You shouldn't do this. DDK headers are exclusively for driver development and shouldn't be included in applications source code. If you need to load driver, you should use the NtLoadDriver function which is a user mode version of ZwLoadDriver. Read more here and here.
Also from here:
"User-mode applications use the native system services routines by calling the entry points in the Ntdll.dll dynamic link library. These entry points convert calls to Nt and Zw routines into system calls that are trapped to kernel mode. To access these entry points, a user-mode application statically links to the Ntdll.lib library, which is available in the WDK. The routines that are implemented in Ntdll.lib are stubs that dynamically link to the entry points in Ntdll.dll at run time".
I have some C++ code which uses boost's GIL image library, and wants to write files using boost::gil::png_write_view from boost/gil/extension/io/png_io.hpp. That header itself includes png.h, and of course results on a link dependency.
On Debian it compiles and links fine. If it did complain about anything missing, the necessary headers and libs would be a few seconds away via an aptitude install libpng-dev.
On Windows (VisualStudio 2008 on XP64), I'm having to face the idea that it looks like I'll have to build libpng from source (and so also its zlib dependency) myself. If there's an obvious packaging already out there, I'm not seeing it. Can anyone enlighten me if there is such a useful resource anywhere ?
Libpng's own packaging itself seems to supply project files for vc6 and VC7.1 (VS2003). And more recent releases also come with VC10 project files. But nothing for VC8(VS2005) or VC9(VS2008). However there are instructions here (which I've yet to try) which describe building for 2008 after running the 7.1 project files through the conversion wizard.
I did initally try the GnuWin32 build of libpng, but (apart from being 32 bit only) it crashed in a libpng call to fwrite when passed a FILE* from VS2008's CRT. libpng's own documentation has something to say about this and the perils of mixing different versions of MSVC but their suggested workround is only relevant to direct libpng users (and I'm using it via boost GIL).
Update: the converted project files do work pretty well (maybe some minor obvious fixups). By far the biggest part of the job was creating the 64bit builds; the original and converted project files don't include any such configuration and while visual studio will have a go at creating them, there was a fair amount of config dialog editing to get consistent folder/file names etc.
I made a little app and built a release version. Now I want to upload it to my site. I have never done this before with Qt, so I'm unsure as to what I should include along with the binary.
How do I figure out which DLLs should be included with my app? And where do I get them? I'm running Windows, but I'd also like to know what I should do in case I want to release a Linux version.
For windows:
You can use dependency walker to see what Qt libraries (or others) you should ship. This is the depends.exe executable that is included with Visual Studio, but you can download it separately from: http://www.dependencywalker.com/
Load your app into that and it will list out all the modules it expects at runtime. You might also have to ship a Visual C++ Runtime Redistributable compatible with the compiler that you built the executable with (if it's VC++).
Do note that dependency walker does not account for things like Qt's plugins. An example of this would be the QtAssistant system (for help menu-type functionality), which as of Qt4 relies on Qt's sqlite functionality, which is typically built as a plugin (qtsqlite4.dll if I remember).
For Linux:
This is trickier because of wider disparities in Linux distributions. You can of course use the GNU build system if you want to ship source, but if you're shipping binaries, and want to support a variety of distros, you might do best to build packages for each platform you want to release on.
In my past, a company I worked for switched to using cmake and after setting up all the project and build files, used that to generate builds and packages for different OSes. On Windows, this meant hooking in with Inno Setup, and for Unix-like systems, cmake knows how to generate things like installable shell scripts. Definitely made life much easier.
Our QA department would test our software in virtual machine instances of our supported platforms, completely clean, and see if anything was missing.
If you're talking about DLLs, I assume it is about Windows.
Use Dependency Walker to see the DLL dependencies.
Or... take a clean system, with no dev tools installed, and put your executable, try to run it there, and see what DLLs are reported as necessary and inexistent. Put the DLLs near the executable.
For a Linux version, you can either create platform targeted releases of installers for each Linux fork or you can let people compile from source. If your app is new, the only way you get exposure is supply people with readymade installers, the targeted installers. New users loathe compiling packages from source.
You can try debian (.deb) and redhat (.rpm) packages first. These two are extremely popular lines and will let you have a taste of things.