Dmitry Timoshkov wrote:
> "Robert Shearman" <[EMAIL PROTECTED]> wrote:
>
>>> Is it possible to make it 64-bit and Wine/Windows compatible by using
>>> ULONG_PTR instead of long?
>>
>> At the moment, widl doesn't support generating 64-bit compatible
>> client, server and proxy code so doing so would be useless. FWIW,
>> MIDL outputs __int64 here instead of long when targeting 64-bit.
>
> If it doesn't take too much effort to write a 64-bit clean code, why
> avoid
> that, especially all that's required is using an appropriate cast?
1. Both of these lines are correct using Unix compilers since long is
64-bit when pointers are 64-bit:
print_file(file, indent, "memset(_StubMsg.Buffer, 0,
((long)_StubMsg.Buffer) & 0x%x);\n", alignment - 1);
print_file(file, indent, "_StubMsg.Buffer = (unsigned char
*)(((long)_StubMsg.Buffer + %u) & ~0x%x);\n",
alignment - 1, alignment - 1);
2. It's independent of my patch (even if long is 32-bits, we're not
going to have alignments above 4Gb).
3. Supporting 64-bit pointers in widl is a lot more complicated than
just casting using the correct type (it involves making anything with
embedded pointers into a complex type).
--
Rob Shearman
