{"id":1719,"date":"2016-09-27T10:00:00","date_gmt":"2016-09-27T08:00:00","guid":{"rendered":"https:\/\/alax.info\/blog\/?p=1719"},"modified":"2016-09-24T20:00:23","modified_gmt":"2016-09-24T18:00:23","slug":"c-import-and-x64-builds","status":"publish","type":"post","link":"https:\/\/alax.info\/blog\/1719","title":{"rendered":"C++ #import and x64 builds"},"content":{"rendered":"

I already wrote earlier on 32\/64-bit issues with Visual Studio<\/a>. The problems are not frequent but when they happen they are pretty confusing. Here is another one today.<\/p>\n

C++ code is simple:<\/p>\n

    #import \"libid:59941706-0000-1111-2222-7EE5C88402D2\" raw_interfaces_only no_namespace\r\n\r\n    CComPtr<IObject> pObject;\r\n    ATLENSURE_SUCCEEDED(pObject.CoCreateInstance(__uuidof(Object)));\r\n    BYTE* pnData;\r\n    ATLENSURE_SUCCEEDED(pObject->Method((ULONG_PTR) (BYTE*) pnData));\r\n<\/code><\/pre>\n
A COM method returns a pointer to data – pretty straightforward, what could have gone wrong?<\/p>\n
COM server vendor designed the library for easy .NET integration and defined the pointer argument as an integer value. They suppose the values to be used further with System.Runtime.InteropServices.Marshal<\/a> class.<\/p>\n
32-bit builds worked well and 64-bit builds experienced memory access violations. An attempt to consume the COM server from C# project showed the same problem: unexpected exception in the call.<\/p>\n
The problem is that cross-compiler importing COM type library using LIBID takes 32-bit library even when it builds 64-bit code. This is the problem for both C++ #import \"libid:...\"<\/code><\/a> and .NET COM reference using the identifier.<\/p>\n
The type library imports as the following IDL in 32-bits:<\/p>\n
[id(1)]\r\nHRESULT Method(\r\n                [in] unsigned long bufPtr);\r\n<\/code><\/pre>\n
It is supposed that 64-bit builds get the following import:<\/p>\n
[id(1)]\r\nHRESULT Method(\r\n                [in] uint64 bufPtr);\r\n<\/code><\/pre>\n
Effectively though, 64-bit builds get the 32-bit import and the argument which is supposed to carry casted pointer value is truncated to 32-bits, ULONG<\/code> type. Cast to ULONG_PTR<\/code> in 64-bit C++ code is, of course, not helpful since it’s trimmed anyway further fitting the IDL argument type.<\/p>\n
The same happens with C# build.<\/p>\n
It was developer’s choice to publish ordinal type argument, they wanted this to be “better” and ended up in bitness mess. If the argument remained a pointer type in the IDL then even incorrect bitness would not necessarily result in value truncation.<\/p>\n
All together it is unsafe to import [an untrusted] type library using LIBID when it comes to 64-bit builds. It’s 32-bit library to be taken and it can result in incorrect import. Instead, such build should explicitly point to 64-bit type library, for example:<\/p>\n
#if defined(_WIN64)\r\n    #import \"Win64\\ThirdParty.DLL\" raw_interfaces_only no_namespace\r\n#else\r\n    \/\/#import \"libid:59941706-0000-1111-2222-7EE5C88402D2\" raw_interfaces_only no_namespace\r\n    #import \"Win32\\ThirdParty.DLL\" raw_interfaces_only no_namespace\r\n#endif\r\n<\/code><\/pre>\n
Too bad! libid<\/code> looked so nice and promising.<\/p>\n","protected":false},"excerpt":{"rendered":"
I already wrote earlier on 32\/64-bit issues with Visual Studio. The problems are not frequent but when they happen they are pretty confusing. Here is another one today. C++ code is simple: #import “libid:59941706-0000-1111-2222-7EE5C88402D2” raw_interfaces_only no_namespace CComPtr<IObject> pObject; ATLENSURE_SUCCEEDED(pObject.CoCreateInstance(__uuidof(Object))); BYTE* pnData; ATLENSURE_SUCCEEDED(pObject->Method((ULONG_PTR) (BYTE*) pnData)); A COM method returns a pointer to data – pretty straightforward,… <\/p>\n
Read the full article<\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[538,536,38,95,537,58],"class_list":["post-1719","post","type-post","status-publish","format-standard","hentry","category-uncategorized","tag-net","tag-bitness","tag-c","tag-com","tag-interoperability","tag-visual-studio"],"_links":{"self":[{"href":"https:\/\/alax.info\/blog\/wp-json\/wp\/v2\/posts\/1719","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/alax.info\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/alax.info\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/alax.info\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/alax.info\/blog\/wp-json\/wp\/v2\/comments?post=1719"}],"version-history":[{"count":0,"href":"https:\/\/alax.info\/blog\/wp-json\/wp\/v2\/posts\/1719\/revisions"}],"wp:attachment":[{"href":"https:\/\/alax.info\/blog\/wp-json\/wp\/v2\/media?parent=1719"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/alax.info\/blog\/wp-json\/wp\/v2\/categories?post=1719"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/alax.info\/blog\/wp-json\/wp\/v2\/tags?post=1719"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}