How to establish communication between my x86 and x64 applications?

Posted on 2014-09-08
Last Modified: 2014-09-26
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?
Question by:npaun
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
LVL 14

Expert Comment

ID: 40309873
Hmm - how about establishing some socket communication ?

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 ....
LVL 11

Accepted Solution

LordWabbit earned 500 total points
ID: 40309987
You can also use named pipes.
MSMQ if you want more reliability for the messages.

Author Comment

ID: 40310368

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?
The Ultimate Checklist to Optimize Your Website

Websites are getting bigger and complicated by the day. Video, images, custom fonts are all great for showcasing your product/service. But the price to pay in terms of reduced page load times and ultimately, decreased sales, can lead to some difficult decisions about what to cut.

LVL 11

Expert Comment

ID: 40310732
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.
LVL 11

Expert Comment

ID: 40310768
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.

Author Comment

ID: 40310883
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...
LVL 40
ID: 40311247
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.

Featured Post

On Demand Webinar - Networking for the Cloud Era

This webinar discusses:
-Common barriers companies experience when moving to the cloud
-How SD-WAN changes the way we look at networks
-Best practices customers should employ moving forward with cloud migration
-What happens behind the scenes of SteelConnect’s one-click button

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

If you need to start windows update installation remotely or as a scheduled task you will find this very helpful.
This article will inform Clients about common and important expectations from the freelancers (Experts) who are looking at your Gig.
In this fifth video of the Xpdf series, we discuss and demonstrate the PDFdetach utility, which is able to list and, more importantly, extract attachments that are embedded in PDF files. It does this via a command line interface, making it suitable …
Starting up a Project

717 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question