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
--
> 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
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.?
Ronald, thanks for the response.