473,322 Members | 1,347 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,322 software developers and data experts.

COM : Interface from c# to c++ problem with IntPtr type

Hi all,

I have a C++ application that load C# applets. A method use an IntPtr
parameter because I want to be 32/64-bit compatible. The problem is in
the .tlh file generated. This parameter is a long and not an INT_PTR
and I don't know why ?

Here is some code that may help you.

In C# project.

public interface IDlgCriteresRecherche
{
IntPtr HandleEditeurParent { get; set;}
}

public class AScDlgCriteresRecherche : System.Windows.Forms.Form,
IDlgCriteresRecherche
{

#region IDlgCriteresRecherche Members

private IntPtr nHandleEditeurParent = (IntPtr)0;

public IntPtr HandleEditeurParent
{
get{ return nHandleEditeurParent; }
set{ nHandleEditeurParent = value; }
}

#endregion
}

In the .tlh generated

struct __declspec(uuid("a070cc19-98cf-4433-8351-e1fc2228260f"))
/* dual interface */ IDlgCriteresRecherche;
struct /* coclass */ AScDlgCriteresRecherche;

_COM_SMARTPTR_TYPEDEF(IDlgCriteresRecherche,
__uuidof(IDlgCriteresRecherche));

struct __declspec(uuid("a070cc19-98cf-4433-8351-e1fc2228260f"))
IDlgCriteresRecherche : IDispatch
{
virtual HRESULT __stdcall get_HandleEditeurParent (
/*[out,retval]*/ long * pRetVal ) = 0;
virtual HRESULT __stdcall put_HandleEditeurParent (
/*[in]*/ long pRetVal ) = 0;
}

in C++

#import "ASCommun.tlb" raw_interfaces_only

pIDlgCriteresRecherche->put_HandleEditeurParent((INT_PTR)poActiveView->m_hWnd);

Regards,

Eric

Oct 26 '06 #1
27 3136
Hi, Eric.

You're doing COM interop, and an int in COM is 16 bits. An int in .NET
is 32 bits, which is a long in COM. This is independent of whether your
app is targeted at 32 or 64 bit processors.
Stephan


Eric wrote:
Hi all,

I have a C++ application that load C# applets. A method use an IntPtr
parameter because I want to be 32/64-bit compatible. The problem is in
the .tlh file generated. This parameter is a long and not an INT_PTR
and I don't know why ?

Here is some code that may help you.

In C# project.

public interface IDlgCriteresRecherche
{
IntPtr HandleEditeurParent { get; set;}
}

public class AScDlgCriteresRecherche : System.Windows.Forms.Form,
IDlgCriteresRecherche
{

#region IDlgCriteresRecherche Members

private IntPtr nHandleEditeurParent = (IntPtr)0;

public IntPtr HandleEditeurParent
{
get{ return nHandleEditeurParent; }
set{ nHandleEditeurParent = value; }
}

#endregion
}

In the .tlh generated

struct __declspec(uuid("a070cc19-98cf-4433-8351-e1fc2228260f"))
/* dual interface */ IDlgCriteresRecherche;
struct /* coclass */ AScDlgCriteresRecherche;

_COM_SMARTPTR_TYPEDEF(IDlgCriteresRecherche,
__uuidof(IDlgCriteresRecherche));

struct __declspec(uuid("a070cc19-98cf-4433-8351-e1fc2228260f"))
IDlgCriteresRecherche : IDispatch
{
virtual HRESULT __stdcall get_HandleEditeurParent (
/*[out,retval]*/ long * pRetVal ) = 0;
virtual HRESULT __stdcall put_HandleEditeurParent (
/*[in]*/ long pRetVal ) = 0;
}

in C++

#import "ASCommun.tlb" raw_interfaces_only

pIDlgCriteresRecherche->put_HandleEditeurParent((INT_PTR)poActiveView->m_hWnd);

Regards,

Eric
Oct 26 '06 #2
ssamuel <ss*****@gmail.comwrote:
Hi, Eric.

You're doing COM interop, and an int in COM is 16 bits. An int in .NET
is 32 bits, which is a long in COM. This is independent of whether your
app is targeted at 32 or 64 bit processors.
An int in COM is 32 bits. A short in COM is 16 bits. A long in C++ is the
word length of your platform (32 bits on x86 and 64 bits on x86_64). I am not
sure off hand how this affects long in COM, but I suspect long follows the
same convention as it does in C/C++.

--
Thomas T. Veldhouse
Key Fingerprint: D281 77A5 63EE 82C5 5E68 00E4 7868 0ADC 4EFB 39F0
Oct 26 '06 #3
>
You're doing COM interop, and an int in COM is 16 bits. An int in .NET
is 32 bits, which is a long in COM. This is independent of whether your
app is targeted at 32 or 64 bit processors.
Ok, so to be compatible 32/64-bit I have to use Int64 in .NET for not
having pointer troncation in the case of 64-bit processors?

I thought IntPtr was more convenient

Eric

Oct 26 '06 #4
Eric <cl**********@gmail.comwrote:
>
>>
You're doing COM interop, and an int in COM is 16 bits. An int in .NET
is 32 bits, which is a long in COM. This is independent of whether your
app is targeted at 32 or 64 bit processors.
Ok, so to be compatible 32/64-bit I have to use Int64 in .NET for not
having pointer troncation in the case of 64-bit processors?

I thought IntPtr was more convenient
IntPtr should work fine as a pointer, is by definition, defined by the word
length of the CPU. The platform should not matter for IntPtr.

--
Thomas T. Veldhouse
Key Fingerprint: D281 77A5 63EE 82C5 5E68 00E4 7868 0ADC 4EFB 39F0
Oct 26 '06 #5
An int in COM is 32 bits. A short in COM is 16 bits. A long in C++ is the
word length of your platform (32 bits on x86 and 64 bits on x86_64). I am not
sure off hand how this affects long in COM, but I suspect long follows the
same convention as it does in C/C++.
The problem Microsoft doesn't follow standard. int and long are still
32-bit on 64-bit processors in C++. So, in COM using a long will cause
pointer troncation.

Regards,
Eric

Oct 26 '06 #6
IntPtr should work fine as a pointer, is by definition, defined by the word
length of the CPU. The platform should not matter for IntPtr.
Yes, that's what I thought. The problem, the IntPtr is changed for an
long when the COM interface is created from an C# project (Visual
Studio 2005). That's what I don't understand.

Regards,
Eric

Oct 26 '06 #7
Eric <cl**********@gmail.comwrote:
>
>An int in COM is 32 bits. A short in COM is 16 bits. A long in C++ is the
word length of your platform (32 bits on x86 and 64 bits on x86_64). I am not
sure off hand how this affects long in COM, but I suspect long follows the
same convention as it does in C/C++.
The problem Microsoft doesn't follow standard. int and long are still
32-bit on 64-bit processors in C++. So, in COM using a long will cause
pointer troncation.
No they aren't. You will only see the length of a long as 32-bit on a 64-bit
processor if you use 32-bit Windows. If you install Windows XP 64-bit and
compile your application with XP64 as a target you will be able to verify
this.

--
Thomas T. Veldhouse
Key Fingerprint: D281 77A5 63EE 82C5 5E68 00E4 7868 0ADC 4EFB 39F0
Oct 26 '06 #8
Eric <cl**********@gmail.comwrote:
>
>IntPtr should work fine as a pointer, is by definition, defined by the word
length of the CPU. The platform should not matter for IntPtr.
Yes, that's what I thought. The problem, the IntPtr is changed for an
long when the COM interface is created from an C# project (Visual
Studio 2005). That's what I don't understand.
long is the the same bit size as a pointer on the OS ... that is why. See my
other post; you have to be running Windows XP 64-bit on a 64-bit processor to
see long as a 64-bit type [as IntPtr will also be].

--
Thomas T. Veldhouse
Key Fingerprint: D281 77A5 63EE 82C5 5E68 00E4 7868 0ADC 4EFB 39F0
Oct 26 '06 #9
An int in COM is 32 bits. A short in COM is 16 bits. A long in C++ is the
word length of your platform (32 bits on x86 and 64 bits on x86_64). I am not
sure off hand how this affects long in COM, but I suspect long follows the
same convention as it does in C/C++.
The problem Microsoft doesn't follow standard. int and long are still
32-bit on 64-bit processors in C++. So, in COM using a long will cause
pointer troncation.

No they aren't. You will only see the length of a long as 32-bit on a 64-bit
processor if you use 32-bit Windows. If you install Windows XP 64-bit and
compile your application with XP64 as a target you will be able to verify
this.
int and long are still 32-bit in the Microsoft Standard.

see this article
Everything You Need To Know To Start Programming 64-Bit Windows Systems
http://msdn.microsoft.com/msdnmag/is...4/default.aspx

Maybe is don't understand the COM part

Regards,
Eric

Oct 26 '06 #10
Eric <cl**********@gmail.comwrote:
>
int and long are still 32-bit in the Microsoft Standard.

see this article
Everything You Need To Know To Start Programming 64-Bit Windows Systems
http://msdn.microsoft.com/msdnmag/is...4/default.aspx

Maybe is don't understand the COM part
There is a lot of text there, so perhaps I missed it, but I do not see
anywhere where it indicates that long is a 32-bit length type on a 64-bit
Windows XP system (running on a 64-bit CPU obviously). You need to compile
the application (COM and .NET) for a 64-bit target. In fact, that article, a
little more than 1/3 of the way down, indicates how it differentiates
addresses depending upon the mode the CPU is running in (it is running in
64-bit mode if you are running Windows XP 64-bit).
--
Thomas T. Veldhouse
Key Fingerprint: D281 77A5 63EE 82C5 5E68 00E4 7868 0ADC 4EFB 39F0
Oct 26 '06 #11
"Thomas T. Veldhouse" <ve*****@yahoo.comwrote in message
news:5g*****************@textfe.usenetserver.com.. .
ssamuel <ss*****@gmail.comwrote:
>Hi, Eric.

You're doing COM interop, and an int in COM is 16 bits. An int in .NET
is 32 bits, which is a long in COM. This is independent of whether your
app is targeted at 32 or 64 bit processors.

An int in COM is 32 bits. A short in COM is 16 bits. A long in C++ is
the
word length of your platform (32 bits on x86 and 64 bits on x86_64). I am
not
sure off hand how this affects long in COM, but I suspect long follows the
same convention as it does in C/C++.

--
Thomas T. Veldhouse
Key Fingerprint: D281 77A5 63EE 82C5 5E68 00E4 7868 0ADC 4EFB 39F0


A long in C++ (Microsoft specific) is still a 32bit integer type. A long
long or __int64 is 64 bit in VC++ (VS2005).

Willy.

Oct 26 '06 #12
"Eric" <cl**********@gmail.comwrote in message
news:11*********************@b28g2000cwb.googlegro ups.com...
Hi all,

I have a C++ application that load C# applets. A method use an IntPtr
parameter because I want to be 32/64-bit compatible. The problem is in
the .tlh file generated. This parameter is a long and not an INT_PTR
and I don't know why ?

Here is some code that may help you.

In C# project.

public interface IDlgCriteresRecherche
{
IntPtr HandleEditeurParent { get; set;}
}

public class AScDlgCriteresRecherche : System.Windows.Forms.Form,
IDlgCriteresRecherche
{

#region IDlgCriteresRecherche Members

private IntPtr nHandleEditeurParent = (IntPtr)0;

public IntPtr HandleEditeurParent
{
get{ return nHandleEditeurParent; }
set{ nHandleEditeurParent = value; }
}

#endregion
}

In the .tlh generated

struct __declspec(uuid("a070cc19-98cf-4433-8351-e1fc2228260f"))
/* dual interface */ IDlgCriteresRecherche;
struct /* coclass */ AScDlgCriteresRecherche;

_COM_SMARTPTR_TYPEDEF(IDlgCriteresRecherche,
__uuidof(IDlgCriteresRecherche));

struct __declspec(uuid("a070cc19-98cf-4433-8351-e1fc2228260f"))
IDlgCriteresRecherche : IDispatch
{
virtual HRESULT __stdcall get_HandleEditeurParent (
/*[out,retval]*/ long * pRetVal ) = 0;
virtual HRESULT __stdcall put_HandleEditeurParent (
/*[in]*/ long pRetVal ) = 0;
}

in C++

#import "ASCommun.tlb" raw_interfaces_only

pIDlgCriteresRecherche->put_HandleEditeurParent((INT_PTR)poActiveView->m_hWnd);

Regards,

Eric


Change your INT_PTR into a void*, IntPtr is marshaled as void* type by the
interop marshaler.

Willy.

Oct 26 '06 #13
Eric <cl**********@gmail.comwrote:
>
int and long are still 32-bit in the Microsoft Standard.

see this article
Everything You Need To Know To Start Programming 64-Bit Windows Systems
http://msdn.microsoft.com/msdnmag/is...4/default.aspx

Maybe is don't understand the COM part
As a followup to my previous message. Try the following (compiled and run on
Windows XP 64-bit with all 64-bit tools and targets).

#include <iostream>
using namespace std;

int main(int argc, char ** argv)
{
cout << "long size = " << sizeof(long) << endl;

return 0;
}

--
Thomas T. Veldhouse
Key Fingerprint: D281 77A5 63EE 82C5 5E68 00E4 7868 0ADC 4EFB 39F0
Oct 26 '06 #14
Willy Denoyette [MVP] <wi*************@telenet.bewrote:
>
A long in C++ (Microsoft specific) is still a 32bit integer type. A long
long or __int64 is 64 bit in VC++ (VS2005).
It is 32-bits on my machine (Intel 32-bit CPU with 32-bit windows)..

// Test.cpp : Defines the entry point for the console application.
//

#include "stdafx.h"

#include <iostream>
using namespace std;

int _tmain(int argc, _TCHAR* argv[])
{
cout << "long length is " << sizeof(long) << " bytes" << endl;

return 0;
}

Output:

long length is 4 bytes

4 bytes is 32-bits, which indicates the C-library is working as it should and
defining the long variable as the word size of the CPU.

--
Thomas T. Veldhouse
Key Fingerprint: D281 77A5 63EE 82C5 5E68 00E4 7868 0ADC 4EFB 39F0
Oct 26 '06 #15
Thomas T. Veldhouse <ve*****@yahoo.comwrote:
<snip>

Never mind my last post, I misread your [Willy's] post.

--
Thomas T. Veldhouse
Key Fingerprint: D281 77A5 63EE 82C5 5E68 00E4 7868 0ADC 4EFB 39F0
Oct 26 '06 #16
"Thomas T. Veldhouse" <ve*****@yahoo.comwrote in message
news:wI****************@textfe.usenetserver.com...
Willy Denoyette [MVP] <wi*************@telenet.bewrote:
>>
A long in C++ (Microsoft specific) is still a 32bit integer type. A long
long or __int64 is 64 bit in VC++ (VS2005).

It is 32-bits on my machine (Intel 32-bit CPU with 32-bit windows)..

// Test.cpp : Defines the entry point for the console application.
//

#include "stdafx.h"

#include <iostream>
using namespace std;

int _tmain(int argc, _TCHAR* argv[])
{
cout << "long length is " << sizeof(long) << " bytes" << endl;

return 0;
}

Output:

long length is 4 bytes

4 bytes is 32-bits, which indicates the C-library is working as it should
and
defining the long variable as the word size of the CPU.

--
Thomas T. Veldhouse
Key Fingerprint: D281 77A5 63EE 82C5 5E68 00E4 7868 0ADC 4EFB 39F0


Check this:
http://msdn2.microsoft.com/en-us/library/s3f49ktz.aspx

Willy.

Oct 26 '06 #17
"Eric" <cl**********@gmail.comwrote in message
news:11**********************@e3g2000cwe.googlegro ups.com...
>
An int in COM is 32 bits. A short in COM is 16 bits. A long in C++
is the
word length of your platform (32 bits on x86 and 64 bits on x86_64).
I am not
sure off hand how this affects long in COM, but I suspect long follows
the
same convention as it does in C/C++.

The problem Microsoft doesn't follow standard. int and long are still
32-bit on 64-bit processors in C++. So, in COM using a long will cause
pointer troncation.

No they aren't. You will only see the length of a long as 32-bit on a
64-bit
processor if you use 32-bit Windows. If you install Windows XP 64-bit
and
compile your application with XP64 as a target you will be able to verify
this.

int and long are still 32-bit in the Microsoft Standard.

see this article
Everything You Need To Know To Start Programming 64-Bit Windows Systems
http://msdn.microsoft.com/msdnmag/is...4/default.aspx

Maybe is don't understand the COM part

Regards,
Eric
http://msdn2.microsoft.com/en-us/library/s3f49ktz.aspx

The C++ standard doesn't define the precise length of (most of) the
fundamental integer datatypes, the individual integer lengths are
implementation specific.

Willy.

Oct 26 '06 #18
>
Change your INT_PTR into a void*, IntPtr is marshaled as void* type by the
interop marshaler.
pIDlgCriteresRecherche->put_HandleEditeurParent((void*)poActiveView->m_hWnd);

I can't do this because the parameter is a long in
put_HandleEditeurParent(long pRetVal)

That is the problem that I have.

pIDlgCriteresRecherche->put_HandleEditeurParent((INT_PTR)poActiveView->m_hWnd);
warning C4244: 'argument' : conversion from 'INT_PTR' to 'long',
possible loss of data

In my case, IntPtr was generated as long in my .tlb file. Why not
void* ?

Regards,
Eric

Oct 26 '06 #19

"Thomas T. Veldhouse" <ve*****@yahoo.comwrote in message
news:NA****************@textfe.usenetserver.com...
Eric <cl**********@gmail.comwrote:
>>
int and long are still 32-bit in the Microsoft Standard.

see this article
Everything You Need To Know To Start Programming 64-Bit Windows Systems
http://msdn.microsoft.com/msdnmag/is...4/default.aspx

Maybe is don't understand the COM part

There is a lot of text there, so perhaps I missed it, but I do not see
anywhere where it indicates that long is a 32-bit length type on a 64-bit
Windows XP system (running on a 64-bit CPU obviously). You need to
compile
It does say it, right next to where it says that a HANDLE is still 32-bits.
Look for the red "Editors' Note" noting that the previous sentence is wrong.
the application (COM and .NET) for a 64-bit target. In fact, that
article, a
little more than 1/3 of the way down, indicates how it differentiates
addresses depending upon the mode the CPU is running in (it is running in
64-bit mode if you are running Windows XP 64-bit).
--
Thomas T. Veldhouse
Key Fingerprint: D281 77A5 63EE 82C5 5E68 00E4 7868 0ADC 4EFB 39F0


Oct 26 '06 #20
Willy Denoyette [MVP] <wi*************@telenet.bewrote:
>
Check this:
http://msdn2.microsoft.com/en-us/library/s3f49ktz.aspx
Indeed ... and this suprises me greatly. I hold little respect for the
implementation then as there is absolutely no difference between int and long,
which with the advent of 64-bit architectures, should be obvious. It IS
implemented "correctly" on Linux, FreeBSD, Solaris ... yada yada yada.

--
Thomas T. Veldhouse
Key Fingerprint: D281 77A5 63EE 82C5 5E68 00E4 7868 0ADC 4EFB 39F0
Oct 26 '06 #21
Ben Voigt <rb*@nospam.nospamwrote:
>
It does say it, right next to where it says that a HANDLE is still 32-bits.
Look for the red "Editors' Note" noting that the previous sentence is wrong.
Yeah, it says the HANDLE is a pointer type and is actually 64-bit (what it
indicates is wrong was the previous sentence saying it was still 32-bit).

--
Thomas T. Veldhouse
Key Fingerprint: D281 77A5 63EE 82C5 5E68 00E4 7868 0ADC 4EFB 39F0
Oct 26 '06 #22
>
Change your INT_PTR into a void*, IntPtr is marshaled as void* type by the
interop marshaler.
OK, I find the problem. IntPtr have no built-in type in C++ data type.

http://msdn2.microsoft.com/en-us/library/hfa3fa08.aspx

So, I have two solutions for manipulate pointer values.

1- Always use 64-bit data type (like Int64)
2- Create two version of the code (one for 32-bit and one for 64-bit)

Which solution will be the best (performance and practical way) ?

Eric

Oct 26 '06 #23
"Eric" <cl**********@gmail.comwrote in message
news:11**********************@h48g2000cwc.googlegr oups.com...
>
>>
Change your INT_PTR into a void*, IntPtr is marshaled as void* type by
the
interop marshaler.

OK, I find the problem. IntPtr have no built-in type in C++ data type.

http://msdn2.microsoft.com/en-us/library/hfa3fa08.aspx

So, I have two solutions for manipulate pointer values.

1- Always use 64-bit data type (like Int64)
2- Create two version of the code (one for 32-bit and one for 64-bit)

Which solution will be the best (performance and practical way) ?

Eric
Not sure why you consider Int64 as valid, what you are passing is a HWND
which is a void pointer, that is, a 64 bit integer value on 64 bit windows
and 32 bit on 32 bit windows, so you can't use this type for both.
Regasm (the tool used to build the tlb), produces long* for an IntPTR wheh
run on 32 bit, it produces a Int64* when run on 64 bit, which is
semantically correct (a void is not oleautomation compliant).

However, when you want platform independence, you need to declare your
pointer as void* (in IDLE), you can't use regasm in this case, you need to
declare your C# interface definition by hand coding.

Willy.


Oct 26 '06 #24
"Thomas T. Veldhouse" <ve*****@yahoo.comwrote in message
news:Dg*****************@textfe.usenetserver.com.. .
Willy Denoyette [MVP] <wi*************@telenet.bewrote:
>>
Check this:
http://msdn2.microsoft.com/en-us/library/s3f49ktz.aspx

Indeed ... and this suprises me greatly. I hold little respect for the
implementation then as there is absolutely no difference between int and
long,
which with the advent of 64-bit architectures, should be obvious. It IS
implemented "correctly" on Linux, FreeBSD, Solaris ... yada yada yada.
The difference here is that the decision to leave long at 32 bits for 64 bit
Windows was based on analysis of 100's of millions of lines of existing code
which showed that leaving long at 32 bits would break less code than
changing it to 64 bits, while the *nix compilers just did what they thought
was "right" and backward compatibility be damned. Both decisions are valid,
but have different ramifications. Both are completely valid and consistent
with the C and C++ standards. The C99 decision to add sized integral types
to the language is really the best answer.

-cd
Oct 26 '06 #25
"Thomas T. Veldhouse" <ve*****@yahoo.comwrote in message
news:Dg*****************@textfe.usenetserver.com.. .
Willy Denoyette [MVP] <wi*************@telenet.bewrote:
>>
Check this:
http://msdn2.microsoft.com/en-us/library/s3f49ktz.aspx

Indeed ... and this suprises me greatly. I hold little respect for the
implementation then as there is absolutely no difference between int and
long,
which with the advent of 64-bit architectures, should be obvious. It IS
implemented "correctly" on Linux, FreeBSD, Solaris ... yada yada yada.

--
Thomas T. Veldhouse
Key Fingerprint: D281 77A5 63EE 82C5 5E68 00E4 7868 0ADC 4EFB 39F0

The size of integral types is "compiler" implementation dependent, the
Windows team decided (long ago) to maintain the sizes of these types as is.
Please refer to this for more info:
http://msdn.microsoft.com/library/de...ata_models.asp

Willy.

Oct 26 '06 #26
Carl Daniel [VC++ MVP] <cp*****************************@mvps.org.nospamwr ote:
The difference here is that the decision to leave long at 32 bits for 64 bit
Windows was based on analysis of 100's of millions of lines of existing code
which showed that leaving long at 32 bits would break less code than
changing it to 64 bits, while the *nix compilers just did what they thought
was "right" and backward compatibility be damned. Both decisions are valid,
but have different ramifications. Both are completely valid and consistent
with the C and C++ standards. The C99 decision to add sized integral types
to the language is really the best answer.
There is no real issue of backward compatibility with precompiled binaries, as
they are linked against 32-bit version of the C library. If you port to a new
platform (i.e. Win64), then a responsible plan will be to test just such a
thing. My opinion, as stated, is that long should be 64-bit. May as well
just remove it for all it is worth now. I seem to recall a time when
Microsoft resisted the move to ANSI C++, mainly because of all the compiler
hacks in place to get MFC to work [and later ATL]. Backward compatibility
with source code seems rather evasive to me as in then end, Microsoft has
always complied with the majority [in this case, just about every other 64-bit
platform defines "long" as 64-bits]. Heck, in C, preprocessor macros are the
name of the game to stay compatible between versions of windows ...

--
Thomas T. Veldhouse
Key Fingerprint: D281 77A5 63EE 82C5 5E68 00E4 7868 0ADC 4EFB 39F0
Oct 26 '06 #27
Willy Denoyette [MVP] <wi*************@telenet.bewrote:
>
The size of integral types is "compiler" implementation dependent, the
Windows team decided (long ago) to maintain the sizes of these types as is.
Please refer to this for more info:
http://msdn.microsoft.com/library/de...ata_models.asp
I agree with you that it "conforms". I don't agree that it is "correct". I
think the correct thing to do was to make long 64-bits [like just about the
rest of the 64-bit world].

--
Thomas T. Veldhouse
Key Fingerprint: D281 77A5 63EE 82C5 5E68 00E4 7868 0ADC 4EFB 39F0
Oct 26 '06 #28

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

3
by: Sai Kit Tong | last post by:
I posted for help on legacy code interface 2 days ago. Probably I didn't make it clear in my original mail. I got a couple of answers but none of them address my issues directly (See attached...
3
by: Rui Mota | last post by:
hello there! I've been trying to translate some code in C++ into C#. I've an object in a DLL wich has a Method that recieves an Interface pointer as parameter. something like this: HRESULT...
2
by: David | last post by:
hello... how can i use IActiveDesktop COM interface from shell32.dll? thanx...
0
by: LGS | last post by:
These three lines work fine in c++. hr = CoInitialize(NULL); hr = CoCreateInstance(CLSID_WiaDevMgr, NULL, CLSCTX_ALL, IID_IWiaDevMgr, (LPVOID *)&iDM); hr = iDM->SelectDeviceDlg(NULL, 0, 0,...
2
by: Black Ninja | last post by:
''''''''''''''The class needs to be called clsRAS, paste the following Imports System.Runtime.InteropServices Public Class ras Private Const RAS_MaxEntryName As Integer = 256 Private Const...
0
by: Robin Tucker | last post by:
I need to create my own explorer-style control - I don't seem to have access to IShellFolder - assuming I need it (which I think I do), how can this be done? I've imported shell32.dll into my...
0
by: Yatin Bhuta | last post by:
Hi, I have an interface in vb 6.0. It has a property set member, which takes a parameter by reference. When I try to implement this interface in my vb.net project it gives me an error saying...
0
by: Yatin Bhuta | last post by:
Hi, I have an interface in vb 6.0. It has a property set member, which takes a parameter by reference. When I try to implement this interface in my vb.net project it gives me an error saying...
1
by: yadolov | last post by:
I have COM-object with Iface interface: typedef struct { .... } TStruct; interface Iface : IUnknown {
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.