Having found https://devblogs.microsoft.com/cppblog/broken-warnings-theory/ we tried it out in the hope of focussing our /Analyze builds on finding problems in our own code. We used c /analyze /analyze:stacksize131072 /analyze:WX- /experimental:external /external:anglebrackets /external:W0 in our compiler invocations but found this triggered lots of warnings=errors from Windows Kit header files. e.g.
c:\program files (x86)\windows kits\10\include\10.0.17763.0\shared\rpc.h(65): error C2220: warning treated as error - no 'object' file generated
c:\program files (x86)\windows kits\10\include\10.0.17763.0\shared\rpc.h(65): warning C4103: alignment changed after including header, may be due to missing #pragma pack(pop)
c:\program files (x86)\windows kits\10\include\10.0.17763.0\shared\rpc.h(223): warning C4103: alignment changed after including header, may be due to missing #pragma pack(pop)
c:\program files (x86)\windows kits\10\include\10.0.17763.0\shared\rpcndr.h(47): warning C4103: alignment changed after including header, may be due to missing #pragma pack(pop)
c:\program files (x86)\windows kits\10\include\10.0.17763.0\shared\rpcndr.h(3300): warning C4103: alignment changed after including header, may be due to missing #pragma pack(pop)
How can we avoid these errors? They directly oppose the whole point of the 'external' options.
Related
I have been looking at the example code from Microsoft for using WinHTTP over COM, see: https://learn.microsoft.com/en-us/windows/win32/winhttp/iwinhttprequest-open
The first few lines of the code are as follows:
#include <windows.h>
#include <stdio.h>
#include <objbase.h>
#include "httprequest.h"
#pragma comment(lib, "ole32.lib")
#pragma comment(lib, "oleaut32.lib")
// IID for IWinHttpRequest.
const IID IID_IWinHttpRequest =
{
0x06f29373,
0x5c5a,
0x4b54,
{0xb0, 0x25, 0x6e, 0xf1, 0xbf, 0x8a, 0xbf, 0x0e}
};
int main()
{
// Variable for return value
HRESULT hr;
// Initialize COM
hr = CoInitialize( NULL );
IWinHttpRequest * pIWinHttpRequest = NULL;
I am confused with the correct way to #include the IWinHttpRequest type. I think it comes from the httprequest.h file which is not a system include file.
Also, I guess httprequest.h is the result of compiling httprequest.idl. Am I supposed to manually compile httprequest.idl, or as this is part of the Windows SDK is there a better way to access this type?
There are just missing instructions on how to get the httprequest.h file. The Windows SDK only has the .idl file. This is somehow unusual, many Windows APIs have the .idl and the .h, some only have .h, some only have .idl ... But you can create the .h from the .idl:
open Visual Studio's developer command prompt
type 'midl httprequest.idl /out [your project path]'
This is a sample output:
**********************************************************************
** Visual Studio 2019 Developer Command Prompt v16.5.1
** Copyright (c) 2019 Microsoft Corporation
**********************************************************************
C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional>midl httprequest.idl /out D:\MyPath\MyAppDir
Microsoft (R) 32b/64b MIDL Compiler Version 8.01.0622
Copyright (c) Microsoft Corporation. All rights reserved.
Processing C:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\um\httprequest.idl
httprequest.idl
Processing C:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\um\oaidl.idl
oaidl.idl
Processing C:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\um\objidl.idl
objidl.idl
Processing C:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\um\unknwn.idl
unknwn.idl
Processing C:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\shared\wtypes.idl
wtypes.idl
Processing C:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\shared\wtypesbase.idl
wtypesbase.idl
Processing C:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\shared\basetsd.h
basetsd.h
Processing C:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\shared\guiddef.h
guiddef.h
Processing C:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\um\oaidl.acf
oaidl.acf
It will create 3 files: httprequest.h, httprequest.tlb and httprequest_i.c in your project directory.
Now you should be able to compile the sample code. Note if you include the httprequest_i.c file, you can even remove the manual declaration of IID_IWinHttpRequest in the sample.
Well, knowing absolutely nothing about this beforehand, I looked up the interface you gave, IWinHttpRequest. I went to the registry and searched for it in HKCR\Interface, found the typelib for the interface in the registry. The typelib is HKEY_CLASSES_ROOT\TypeLib\{662901FC-6951-4854-9EB2-D9A2570F2B2E}. From the typelib, looked up HKEY_CLASSES_ROOT\TypeLib\{662901FC-6951-4854-9EB2-D9A2570F2B2E}\5.1\0\win32. The win32 entry shows where the location of the typelib on disk is: %SystemRoot%\system32\winhttpcom.dll
Since the %SystemRoot%\system32 directly is always in the path, you can use the typelib simmply like this:
#import "winhttpcom.dll"
Behind the scenes, the Visual C++ compiler will create files named winhttpcom.tlh and winhttpcom.tli. You can ignore those files. The compiler just automatically includes and links with those files.
It will declare COM smart pointers in the .tlh file:
_COM_SMARTPTR_TYPEDEF(IWinHttpRequest, __uuidof(IWinHttpRequest));
_COM_SMARTPTR_TYPEDEF(IWinHttpRequestEvents, __uuidof(IWinHttpRequestEvents));
All of this will be wrapped in a C++ namespace:
namespace WinHttp {
// definitions in here
}
If you don't want namespaces, you can do something like:
#import "winhttpcom.dll" no_namespace
Documentation for #import is at https://learn.microsoft.com/en-us/cpp/preprocessor/hash-import-directive-cpp?view=vs-2019
I have created a simple Managed C++ project where I access CPoint from Atltypes.h. When compiling I am getting error 'errno.h' header not found. But I checked the project -> Properties -> VC++ Directories -> Include Directories... The header path is included.
The file errno.h is available in SDK path 'C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\ucrt'
But while compiling it is not able to pick it up. Is it due to any environment issue in my pc? Or is my visual studio settings corrupted?
After some more googling found that windows.h is key header which has all types. After adding below 2 headers in managed C++, it works fine
#include <Windows.h>
#include <msclr/marshal.h>
I'm developing an Universal Windows App that uses the camera and I need to create a custom effect for the camera. The app is written in C# and the effect is a C++ DLL that uses Media Foundation and an IDL to define a custom WinRT component.
I already successfully do this several times on Windows 8.1 with the following trick documented here, or here.
I now want to port this on Windows 10 UWP. I'm aware there is a known issue on Windows 10 which make the compiler fail with the error "Failed to load a dependency file. Windows.winmd" (see here). But even with that fix, I'm not able to successfully build the component.
Here is the IDL:
import "Windows.Media.idl";
#include <sdkddkver.h>
namespace MyEffect
{
[version(NTDDI_WIN10), activatable(NTDDI_WIN10)]
runtimeclass MyEffect
{
[default] interface Windows.Media.IMediaExtension;
}
}
The MIDL command line (formatted for better readability):
/env win32 /h "MyEffect_h.h" /W1 /char signed /enum_class
/tlb "$(OutDir)\MyEffect.tlb" /ns_prefix
/metadata_dir "$(WindowsSDK_MetadataFoundationPath)"
/nologo /winrt
/winmd "$(OutDir)\MyEffect.winmd"
This command succeeds. Then I add the following custom build step:
mdmerge -metadata_dir “<metadata_dir>”
-i “$(OutDir).”
-o “$(OutDir)merged”
-partial
-v
and this command fails always with different errors according to the following :
If I put $(WindowsSDK_MetadataFoundationPath), which resolves to c:\Program Files (x86)\Windows Kits\10\References\windows.foundation.foundationcontract\1.0.0.0, or $(WindowsSDK_MetadataPath), which resolves to c:\Program Files (x86)\Windows Kits\10\References it returns the error:
MDMERGE : error MDM2002: The type "Windows.Media.IMediaExtension" defined in file <...>\MyEffect.winmd was referenced by type MyEffect.MyEffect but could not be found.
If I put $(TargetPlatformSdkMetadataLocation), which resolves to c:\Program Files (x86)\Windows Kits\10\References\CommonConfiguration\Neutral, it returns the error:
MDMERGE : error MDM2012: Error 3 has occured while enumerating files in C:\Program Files (x86)\Windows Kits\10\References\CommonConfiguration\Neutral\*.winmd.
Does anyone figured out how to compile a custom Windows Media effect for UWP ?
Setting -metadata_dir to "C:\Program Files (x86)\Windows Kits\10\UnionMetadata" worked for me.
I am trying to link glew32.lib in vc++ and I am getting unresolved externals. I set show progress to verbose to see what was happening and I get this output:
...
Referenced in OpenGL32.lib(OPENGL32.dll)
Loaded OpenGL32.lib(OPENGL32.dll)
Searching C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\lib\glew32.lib:
Searching C:\Program Files (x86)\Windows Kits\8.0\lib\win8\um\x86\kernel32.lib:
Found _imp_GetLastError#0
Referenced in main.obj
...
So it looks to me like its just skipping the .lib entirely? At the end of the output it tells me that glew32.lib is unused. I'm including the header, and getting no errors other than the unresolved externals. Why is it skipping over linking this file?
VS C++ 2008
I am just working through a DirectX tutorial.
In the source code had this line:
#pragma comment (lib, "d3d9.lib")
When I compiled everything linked ok.
However, I commented out this line and tried to include the header and library myself under properties, like this:
C/C++ - General
Additional include directories: "C:\Program Files\Microsoft DirectX SDK (August 2009)\Include"
Linker - General
Additional library directories: "C:\Program Files\Microsoft DirectX SDK (August 2009)\Lib\x64"
Linker - Input: d3d9.lib
However, I got this linker error:
1>main.obj : error LNK2019: unresolved external symbol _Direct3DCreate9#4 referenced in function _initD3D
However, when I just use the pragma I didn't get any linker errors. Only when I try and include them with the properties as above.
What is the real difference in using pragma and including the header/libraries using the properites?
Many thanks,
at first, #pragma comment(lib) is just linker configuration
at second, the SDK should be in path, so dont set additional library directories (you may override it with wrong version), just add d3d9.lib to linker's input.
As far as I know, there is no difference. pragma lib simply says to the linker to look for a specific library by name.
Also, since the path is not specified in the pragma, the linker relies on the current lib paths for your project. Try not add any path to your linker options (by default DX SDK adds paths to any visual studio installed, directly modifying the global visual studio paths. See Tools/Options/Projects and Solutions/VC++ Directories/Show Directories for Library files)
Some things to check:
you are indeed building for x64
your path is really pointing to the DX SDK (it is installed to Program Files(x86) if you are on x64)
verify if there are not other linker warnings