Thanks that someone revived this thread for me:-)
We have taken a closer look at 64-bit Windows 7 recently as this will be rolled out as the new standard operating system here as of practically now.
We have already found that TestStand (4.1, 4.2 as well as 2010) runs fine under 64-bit WIndows 7. As much as I would like a 64-bit TestStand version, I think there is more to it than just NI having to split their code base. We, for example, would have to port all functionality we developed for 32-bit TestStand systems so far to 64-bit also, since you cannot mix 32-bit and 64-bit code in one process (see below).
As for InterProcess Communication: Microsoft lists several types of IPC under the links given below, which can be used for communicating between processes of different bitness (identical bitness also, of course), including COM and .NET remoting. I cannot quite see the difference between an abstacted communications mechanism between TestStand and 32-bit apps and IPC as such a mechanism would be IPC by definition. And I think a layer of abstraction on top of COM, for example, would mean a set of interfaces, protocol etc. which would need to be supported by both applications, TestStand as well as the communications partner.
This is actually the approach we have decided upon: we need services of a particular 64-bit image-processing library and will implement a 64-bit EXE COM server whose interface we design according to the functions we require so that it should be fairly easy to use to for the TestStand developer. We are using COM, not .NET remoting, because both sides, the library and TestStand are native, so there is no reason to interject a .NET layer artificially ( this brought up the question whether we are not using outdated
technology, for which NI had already thankfully provided us with
the answer: not at all, since .NET is actually a COM server itself, so COM is definitely not outdated in .NET times).
If the IPC is a constraint, we do not yet know, but I think it is a matter of course that communicating with another process will add overhead compared with calling a function in the process context. So it seems important that the 64-bit process handles large chunks of work for each call, i.e., the granularity must be rather coarse. We achieve that by using a scriptable library, i.e., TestStand is not calling individual library functions but actually a script interpreted by an engine in the library. Quite comparable actually - from the outside view - to calling an Express VI.
Finally, risking to ship coals to Newcastle and bore everyone, I would like to pass on some "official" (i.e., Microsoftian) information we came upon in the process, because I met several people, including ourselves, who were not quite sure about all this stuff:
- http://msdn.microsoft.com/en-us/library/aa384249%28v=VS.85%29.aspx states explicitly: "However, 32-bit processes cannot load 64-bit DLLs for execution, and 64-bit processes cannot load 32-bit DLLs for execution. " So no mixing of bitness in one process, as Doug already said.
- In effect that means that to control 64-bit code from a 32-bit-process, you need a 64-bit "surrogate" process handling requests from the 32-bit-process and there you need some means of interprocess communication.
- Some confusion arose around the issue that kernel drivers which must be 64-bit can be called from 32-bit processes. The reason is WoW64 which is "the x86 emulator that allows 32-bit Windows-based applications to run seamlessly on 64-bit Windows. " (same link). So WoW64 catches all Win32 calls (including the IOCTL calls to kernel drivers) and thunks them to 64-bit (see http://msdn.microsoft.com/en-us/library/ff563897%28v=VS.85%29.aspx). Kernel drivers can also determine whether they were called from 32-bit or 64-bit code and possibly react accordingly (see http://msdn.microsoft.com/en-us/library/ff547059%28VS.85%29.aspx).
- It further says: "COM LocalServers can be used if both 32-bit and 64-bit proxy/stub DLLs are registered for all interfaces used. " It turns out that for a COM object the operating system can create the surrogate process (by a registry hack, actually) and map the DLL calls transparently.
After expert advice, however, we decided not to let the operating system handle the surrogate process but to implement a dedicated COM (EXE) server as stated above, since the main purpose is not to call DLL functions transparently in arbitrary sequence but to deliver specific services which we can more easily do with a set of well-defined interface functionality.
Hope I did not bore everyone
Peter
