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".
Related
I have a enterprise c++ application that I'd like to ship out and I do use the dbghelp library to get a stacktrace if my application crashes. What is the best practice for doing this?
My target users are windows10 and according to this page, I should be okay to ship out the dbghelp.dll along with it?
"The redistribution policies for these included DLLs were specifically designed to make it as easy as possible for people to include these files in their own packages and releases."
I am working on project which is trying to migrate some legacy application running on QNX neutrino operating system to other open source RTOS based on linux.
I have listed all the third party library and device drivers which must be ported and now analyzing design and source code which depends on some special QNX features like QNX IPC MsgSend, MsgReply, MsgSendPulse etc.
I want to know is there any tools which will help me to make a list of all QNX related system calls or functions which is getting used in code from normal user defined functions or functions provided by third party library and C++ library. Since code is written by other organisations we don't know much details about code except how to compiler and how to run it.
Thanks
Please refer link: https://sourceforge.net/projects/simpl/
You don't have direct API calls in linux which are equivalent to MsgSend, MsgReply etc.. but you can achieve it through using existing pipes/POSIX MQs (or) You can install above tgz package (Which is available in https://sourceforge.net/projects/simpl/).
I want to check if I could successfully load the dll's for WinPCAP and want to do it by writing a simple C/C++ console application. However I do not have neither experience nor an idea about how to do it. What I know is according to its def file:
LIBRARY Packet32
EXPORTS
PacketOpenAdapter
PacketSendPacket
PacketAllocatePacket
PacketInitPacket
PacketFreePacket
PacketResetAdapter
PacketReceivePacket
PacketCloseAdapter
PacketSetHwFilter
PacketGetAdapterNames
PacketRequest
PacketSetBuff
PacketSetBpf
PacketGetNetType
PacketSetReadTimeout
PacketSetNumWrites
PacketGetNetInfo
PacketSetMinToCopy
PacketSetMaxLookahead
PacketCancelPacket
PacketLoadDriver
PacketUnloadDriver
I must be checking these things. But how? Could you please help me?
Best Regards
Those are functions in the packet32 library, not in the WinPcap library. Packet32 is a library of routines that provide access to the lower-level packet capture mechanism that WinPcap uses, in a fashion that hides from WinPcap the differences between "Windows OT" (95, 98, Me) and Windows NT (modern versions of Windows, up to and including Windows 8); it's not intended to be used by users. See the page about packet32 in the WinPcap documentation.
You don't need a console application that checks any of the packet32 routines. What you need is a console application that checks the WinPcap routines; if packet32 isn't working, those routines won't work, either. So you should look at some of the sample programs on the Internet for libpcap/WinPcap.
I have a Windows library developed in C++ that uses ATL collections, ATL CString and COM interfaces with CComPtr heavily. I removed all non-winrt-allowed API calls from the library, and it builds fine, so I wrapped the library in a C++/CX ref-class and I am trying to use it from a Windows Store App. The application runs fine, but the Win-Store App certification fails with the following error:
Error Found: The supported APIs test detected the following errors:
API GetModuleHandleW in kernel32.dll is not supported for this
application type. MyLibrary.dll calls this API. API
InitializeCriticalSectionAndSpinCount in kernel32.dll is not supported
for this application type. MyLibrary.dll calls this API.
The VS project for my library is configured for Windows Store with the following settings:
These settings activate/deactivate the required macros (WINAPI_FAMILY as WINAPI_FAMILY_APP for example) in the SDK as expected.
I am 100% sure I am not calling GetModuleHandleW or InitializeCriticalSectionAndSpinCount directly in my library, so I thought this issue must be coming from a method of some ATL class that was not filtered properly in the Windows 8 SDK.
Diving into ATL header files was not very useful, since everything looks properly filtered there, for example see this fragment from ATL::CComCriticalSection::Init
#if !defined(_ATL_USE_WINAPI_FAMILY_DESKTOP_APP) || defined(_ATL_STATIC_LIB_IMPL)
if (!_AtlInitializeCriticalSectionEx(&m_sec, 0, 0))
#else
if (!InitializeCriticalSectionAndSpinCount(&m_sec, 0))
#endif
In order to prove my theory, I took an hex-editor and edited out GetModuleHandleW from my Kernel32.lib file, which gives me the following linking error:
atls.lib(atlwinverapi.obj) : error LNK2001: unresolved external symbol
__imp__GetModuleHandleW#4
So it seems my theory is not wrong. Note that I am doing all this using release builds, since debug builds do not pass the certification.
Now the question:
Is there any way for me to know exactly which class inside ATL is sabotaging my library other than looking at the header files?
Same question in MSDN forums
I have added a bug report on microsoft connect with a small sample code that reproduces this issue.
Here is what I guess. Look at the file atlwinverapi.h. There the macro _ATL_NTDDI_MIN is conditionally defined one way for x86/x64 and another way for ARM.
I think this might have changed during the recent VSUpdate that added XP support. Now in the file atlwinverapi.cpp (which goes into atls.lib I guess), in the method _AtlInitializeCriticalSectionEx, you will notice that it's calling InitializeCriticalSectionAndSpinCount if _ATL_NTDDI_MIN < NTDDI_VISTA.
I am assuming your building x86 or x64 that's why you are seeing this problem. If you build for ARM, you will not see this problem.
Of course you will not be able to run WACK on ARM but you can run dumpbin /imports on your binary and see if it still uses those non-compliant API.
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.