Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

native 64-bit compilation on Win64 and .NET

0 views
Skip to first unread message

Dennis Landi

unread,
Sep 27, 2003, 11:04:05 AM9/27/03
to
Hello,

I have three questions:

1) I have been perusing the MSDN VC++ pages. Everything seems to be geared
towards .NET integration. Will MS continue support natively compiled code
or will they be pushing developers to do everything as "managed" C++?

2) Also, on 32-bit platforms we can call 32-bit unmanaged DLLS from managed
assemblies. On Win64 will a 64-bit .NET assembly be able to call an
unmanaged 64-bit DLL?

3) On the AMD64, thats supports the running of bot 32-bit and 64-bit code,
would we be able to call unmanaged 32-bit DLLs from a 64-bit .NET assembly?
(Sometimes its not practical/possible to recompile/port the 32-bit DLL).

Please let me know if there is a better forum for these questions...

Thanks.

-d

--

Ronald Laeremans [MSFT]

unread,
Sep 29, 2003, 12:56:12 AM9/29/03
to

"Dennis Landi" <[none][at][none]> wrote in message
news:OiRWUjQh...@TK2MSFTNGP09.phx.gbl...

> Hello,
>
> I have three questions:
>
> 1) I have been perusing the MSDN VC++ pages. Everything seems to be
geared
> towards .NET integration. Will MS continue support natively compiled code
> or will they be pushing developers to do everything as "managed" C++?
No, we fully supprt compiling native code.


> 2) Also, on 32-bit platforms we can call 32-bit unmanaged DLLS from
managed
> assemblies. On Win64 will a 64-bit .NET assembly be able to call an
> unmanaged 64-bit DLL?

Yes, it will.


> 3) On the AMD64, thats supports the running of bot 32-bit and 64-bit code,
> would we be able to call unmanaged 32-bit DLLs from a 64-bit .NET
assembly?
> (Sometimes its not practical/possible to recompile/port the 32-bit DLL).

No. You will have to use any of the supported IPC mechanisms like named
pipes, sockets, memory mapped files, COM. There is no type of thunk on
64-bit version of Windows that will allow 64-bit user mode code to call
32-bit user mode code in the same process.

> Please let me know if there is a better forum for these questions...

Ronald Laeremans
Visual C++ team


Dennis Landi

unread,
Sep 29, 2003, 4:11:34 PM9/29/03
to

"Ronald Laeremans [MSFT]" <ron...@online.microsoft.com> wrote in message
news:uPoPDYkh...@TK2MSFTNGP10.phx.gbl...

> > 3) On the AMD64, thats supports the running of bot 32-bit and 64-bit
code,
> > would we be able to call unmanaged 32-bit DLLs from a 64-bit .NET
> assembly?
> > (Sometimes its not practical/possible to recompile/port the 32-bit DLL).
> No. You will have to use any of the supported IPC mechanisms like named
> pipes, sockets, memory mapped files, COM. There is no type of thunk on
> 64-bit version of Windows that will allow 64-bit user mode code to call
> 32-bit user mode code in the same process.
>

Ronald, thanks for the response.

You mention COM as one way for 64-bit .NET assembly to communicate with a
32-bit DLL. So a 64-bit assembly could invoke a 32-bit out-of-process COM
object just like we would do it now on a 32-bit O.S.?


Dennis Landi

unread,
Sep 29, 2003, 4:14:39 PM9/29/03
to

"Ronald Laeremans [MSFT]" <ron...@online.microsoft.com> wrote in message
news:uPoPDYkh...@TK2MSFTNGP10.phx.gbl...
> > 3) On the AMD64, thats supports the running of bot 32-bit and 64-bit
code,
> > would we be able to call unmanaged 32-bit DLLs from a 64-bit .NET
> assembly?
> > (Sometimes its not practical/possible to recompile/port the 32-bit DLL).
> No. You will have to use any of the supported IPC mechanisms like named
> pipes, sockets, memory mapped files, COM. There is no type of thunk on
> 64-bit version of Windows that will allow 64-bit user mode code to call
> 32-bit user mode code in the same process.
>

Ronald, thanks for the response.

0 new messages