npaun
asked on
How to establish communication between my x86 and x64 applications?
I have two applications written, one working as x86 (written in vb6) and another as x64 (written in VB.Net). What would be the easiest and most elegant way to establish communication between them, so that they can share some data and calls between them. For instance, app A sends some data (a number, string, array…) and the app B as soon it receive it, respond to it, and vice versa.
And by elegant, I mean I don’t want to use for instance a shared disk file or a database, and the method should be reasonably fast (e.g. if the method can send a short string in a millisecond, or perform a thousand sending in a second, it would be enough).
Something as a shared dll, (or maybe ActiveX exe) would be fine, but I believe it is not viable, as they cannot be shared: x64 can communicate only with x64 libraries and x86 only with x86?
Right now I’m using SendMessage to send messages to a dedicated TextBox controls on a hidden form in respective applications, but I consider it inelegant, cumbersome, not very configurable, although reasonably fast.
So, is there a better and smarter way to do it?
And by elegant, I mean I don’t want to use for instance a shared disk file or a database, and the method should be reasonably fast (e.g. if the method can send a short string in a millisecond, or perform a thousand sending in a second, it would be enough).
Something as a shared dll, (or maybe ActiveX exe) would be fine, but I believe it is not viable, as they cannot be shared: x64 can communicate only with x64 libraries and x86 only with x86?
Right now I’m using SendMessage to send messages to a dedicated TextBox controls on a hidden form in respective applications, but I consider it inelegant, cumbersome, not very configurable, although reasonably fast.
So, is there a better and smarter way to do it?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
@LordWabbit
a) Can named pipes be used both in VB6 and VB.Net? The same question for MSMQ?
b) Does they allow "synchronous" communication, i.e. Application A sends data to Application B, and Application B a soon as it receives the data, can fire an "event" or procedure and execute some code?
a) Can named pipes be used both in VB6 and VB.Net? The same question for MSMQ?
b) Does they allow "synchronous" communication, i.e. Application A sends data to Application B, and Application B a soon as it receives the data, can fire an "event" or procedure and execute some code?
Named pipes are supported in .Net from 3.5 onwards (IIRC) so that should not be a problem, in VB6 it seems to be supported but not as simple. Named Pipes in VB6
As for MSMQ - both should support it - it does however require activating it in Add Remove programs, and some minor config. Both have asynchronous modes although for MSMQ it would require configuring two channels. Both listen for events (messages) and will execute the code specified to handle a message event.
If you are willing to hand over message handling to another app which will communicate between your applications there is also Event Driven Web Services although in testing we found they tend to time out if there is a long gap between messages, and ultimately we decided to go another route. Timeous message processing was important and there were large gaps when no messages were coming in.
Regardless what you decide to do it's best to thread the messaging so it doesn't lock the main thread while waiting for a message. There is a way to use background workers in VB6 so that the main UI thread can process application events.
As for MSMQ - both should support it - it does however require activating it in Add Remove programs, and some minor config. Both have asynchronous modes although for MSMQ it would require configuring two channels. Both listen for events (messages) and will execute the code specified to handle a message event.
If you are willing to hand over message handling to another app which will communicate between your applications there is also Event Driven Web Services although in testing we found they tend to time out if there is a long gap between messages, and ultimately we decided to go another route. Timeous message processing was important and there were large gaps when no messages were coming in.
Regardless what you decide to do it's best to thread the messaging so it doesn't lock the main thread while waiting for a message. There is a way to use background workers in VB6 so that the main UI thread can process application events.
Forgot to add, in MSMQ every message would need to be serializable - which generally should not be a problem, There is a way to store binaries but I think they get MIME encoded and tend to be a lot larger than the original binary. At one company I worked they would scan the network and delete any mp3 they found, so we stuck them into MQ and peeked them to play it instead of popping it off the queue. Which broke one of the ten commandments of MQSeries (IBMMQ instead of MSMQ, but it's basically the same thing) - Thou shalt not use a queue as a database. Eventually we just stuck the MP3's in a database as BLOBS on a staging server.
ASKER
@LordWabbit
Thanks
One more thing if you maybe know: of course, dll cannot be used as such message mediators, since 32bit dll cannot be used by 64bit apps, and vice versa, but what about ActiveX EXE? Do they also have such limitation? I would expect so, but I would like to be sure...
Thanks
One more thing if you maybe know: of course, dll cannot be used as such message mediators, since 32bit dll cannot be used by 64bit apps, and vice versa, but what about ActiveX EXE? Do they also have such limitation? I would expect so, but I would like to be sure...
An ActiveX EXE is nothing more than an ActiveX DLL, except that it has a starting point and can be launched by a user, while a DLL can only be used by an application and is useless by itself for a user.
Do you really need to compile your .NET application in 64-bit? For most applications, you won't feel the difference if you compile them for x86 (32-bit).
In such a case, communications are easier. You can use any method that you find will work, such as the ones that were provided up to know.
Passing information then is easy. The only thing to take into consideration is that some types have changed. A VB6 Integer is a Short in .NET, a VB6 Long is an Integer. The VB.NET Long and Char do not exist in VB6. The VB6 Variant does not exist in VB6. Date variables also have a different representations, but this can be handled on the .NET side through the FromOADate and ToOADate methods of the Date structure.
Personnaly, at that point, I would try to use a Mutex object to pass the information. That class has been designed specifically for interprocess synchronization. I have never used it with VB6 however, you might have to go through the Windows API to handle a Mutex on the VB6 side. However, it is flagged with a ComVisibleAttribute, so maybe there is a direct way. I unfortunately do not have the time to search on the use of a Mutex with VB6.
Do you really need to compile your .NET application in 64-bit? For most applications, you won't feel the difference if you compile them for x86 (32-bit).
In such a case, communications are easier. You can use any method that you find will work, such as the ones that were provided up to know.
Passing information then is easy. The only thing to take into consideration is that some types have changed. A VB6 Integer is a Short in .NET, a VB6 Long is an Integer. The VB.NET Long and Char do not exist in VB6. The VB6 Variant does not exist in VB6. Date variables also have a different representations, but this can be handled on the .NET side through the FromOADate and ToOADate methods of the Date structure.
Personnaly, at that point, I would try to use a Mutex object to pass the information. That class has been designed specifically for interprocess synchronization. I have never used it with VB6 however, you might have to go through the Windows API to handle a Mutex on the VB6 side. However, it is flagged with a ComVisibleAttribute, so maybe there is a direct way. I unfortunately do not have the time to search on the use of a Mutex with VB6.
That should be available in both environments, is independent from the disk layout and disk access rights, fast, would work on the same station as well as distributed and would be quite elegant ... wouldn't it ?
Could (logical, not lexically) be handled similar to communication via a serial port ... I don't have examples at hand, but I think that the net is full of 'em ....