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
Related
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>
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.
I have a DLL which is develeoped in VB.Net. I am trying to call its functions from my vc++ code. The dll has successfully loaded using LoadLibrary function.
But when I try calling any function within the dll, it gives a null pointer exception.
I used the dumpbin command to confirm the function arguments within my dll. But it is not listing any functions. Could it be a problem with the dll or does dumpbin support few dlls only? Please help!
C:\Program Files (x86)\Microsoft Visual Studio 11.0>dumpbin ECR.dll
Microsoft (R) COFF/PE Dumper Version 11.00.51106.1 Copyright (C)
Microsoft Corporation. All rights reserved.
Dump of file ECR.dll
File Type: DLL
Summary
2000 .reloc
4000 .rsrc
2000 .sdata
16000 .text
Try writing before any function in your DLL file (header .h files) the name of the project with _API at the end (ECR_API).
for example, lets say we want to create a constructor and destructor for a class called Loader:
class Loader{
public:
ECR_API Loader();
ECR_API ~Loader();
}
also dont forget to add export and import statements at the beggining of your header file:
#ifdef ECR_EXPORTS
#define ECR_API __declspec(dllexport)
#else
#define ECR __declspec(dllimport)
#endif
hope this helps!
worked fine for me.
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.
Edit: unlike the case in the question noted in the vote-to-close, the offending code here is CRT code, not mine. Even if it has a problem (which I'm pretty sure it doesn't), I have no way of fixing its source.
We have some legacy memory-leak tracing code that uses some CRT internals (nothing too exotic, essentially _CrtMemBlockHeader which is sort-of documented). While trying to migrate from VS2010 to VS2013 the code seems to cause sporadic build failures, and the offending part can be reduced to this:
#include <windows.h>
#define _CRTBLD
#include <..\crt\src\dbgint.h>
#include <fstream>
void Func()
{
std::ofstream myfile;
myfile << 8;
}
I.e., these 10 lines alone builds fine in VS2010 and in VS2013 give:
c:\program files (x86)\microsoft visual studio
12.0\vc\include\xlocnum(1105): error C2491: 'std::numpunct<_Elem>::id' : definition of dllimport static data member not allowed
I suspect the error message is not accurate - there are indeed several potential definitions of id, none of them at line 1105. There is also a considerable spew of warnings:
1>c:\program files (x86)\microsoft visual studio 12.0\vc\include\xlocnum(1105): warning C4273: 'id' : inconsistent dll linkage
1> c:\program files (x86)\microsoft visual studio 12.0\vc\include\xlocnum(80) : see previous definition of 'public: static std::locale::id std::numpunct<char>::id'
1> c:\program files (x86)\microsoft visual studio 12.0\vc\include\xlocnum(80) : while compiling class template static data member 'std::locale::id std::numpunct<_Elem>::id'
1> with
1> [
1> _Elem=char
1> ]
1> c:\program files (x86)\microsoft visual studio 12.0\vc\include\xlocnum(1185) : see reference to function template instantiation 'const _Facet &std::use_facet<std::numpunct<_Elem>>(const std::locale &)' being compiled
1> with
1> [
1> _Facet=std::numpunct<char>
1> , _Elem=char
1> ]
1> c:\program files (x86)\microsoft visual studio 12.0\vc\include\xlocnum(1179) : while compiling class template member function 'std::ostreambuf_iterator<char,std::char_traits<char>> std::num_put<char,std::ostreambuf_iterator<char,std::char_traits<char>>>::do_put(_OutIt,std::ios_base &,_Elem,std::_Bool) const'
1> with
1> [
1> _OutIt=std::ostreambuf_iterator<char,std::char_traits<char>>
1> , _Elem=char
1> ]
1> c:\program files (x86)\microsoft visual studio 12.0\vc\include\ostream(306) : see reference to class template instantiation 'std::num_put<char,std::ostreambuf_iterator<char,std::char_traits<char>>>' being compiled
1> c:\program files (x86)\microsoft visual studio 12.0\vc\include\ostream(292) : while compiling class template member function 'std::basic_ostream<char,std::char_traits<char>> &std::basic_ostream<char,std::char_traits<char>>::operator <<(int)'
1> c:\users\ofek\documents\visual studio 2013\projects\testcamsys2013\testcamsys2013\source.cpp(10) : see reference to function template instantiation 'std::basic_ostream<char,std::char_traits<char>> &std::basic_ostream<char,std::char_traits<char>>::operator <<(int)' being compiled
1> c:\program files (x86)\microsoft visual studio 12.0\vc\include\fstream(921) : see reference to class template instantiation 'std::basic_ostream<char,std::char_traits<char>>' being compiled
1> c:\users\ofek\documents\visual studio 2013\projects\testcamsys2013\testcamsys2013\source.cpp(9) : see reference to class template instantiation 'std::basic_ofstream<char,std::char_traits<char>>' being compiled
For now I'm pasting the definitions of _CrtMemBlockHeader and some macros around it directly to my code. But still - can anyone see what broke?
I realize it is not fully supported, but one can hope: is there a more robust way of using _CrtMemBlockHeader?
Looking at this error on my system, it seems to be only related to the #define _CRTBLD and the fstream header. The included dbgint.h is irrelevant (you can comment out that #include and still get the same error.
So, this seems to be a problem in the fstream header. Changing the order of inclusion removes the compilation errors:
#include <windows.h>
#include <fstream>
#define _CRTBLD
#include <..\crt\src\dbgint.h>
Perhaps this helps?