Hi,
This is a help-seeking thread. As you know its *impossible* to access 32-bit DLLs with a 64-bit app and vice versa. As assembly programmers you also know why
http://www.intel.com/cd/ids/developer/asmo-na/eng/microprocessors/itanium/optimization/19109.htm
Intel is only one answer that I found, but 90% say COM is the way to go. Accessing DLL results from a file (that is inter-architectural) is not an option
because all of the caches and HDD speed and API overhead, that might
make simple queries into "millisecond hell".

I had an idea to pass info through registry, but its slow too. And slow is not
always the first excuse. Clumsy :S I might say. There's one more way, that
I've considered - the web - basically some TCP packages.

WHY?
Lets say you have two closed source DLLs - one of them 32-bit, other 64.
You NEED to use them in your project and their creators' e-mails are down

What I'm hoping to do is use some mechanism to copy all the valuable
data from a 32-bit DLL to a "shadow" 64-bit DLL. Maybe there are even tools
for that I haven't found yet. There's FASM\EXAMPLES\DLL\ERRORMSG.ASM
for starting. Tell me if you have any ideas.

64APP => calls 64DLL("shadow") would be the best, but
64APP => calls 64DLL => maybe a conversion here => re-calls 32DLL with the parameters

Thank You in advance,
Madis

You could always make a marshalling 32bit app that uses the DLL... the idea would be to use pipes, sockets, or some other form of IPC, call the 32bit DLL, and return stuff back.

Of course this gets "pretty interesting" if any of the DLL functions take complex data structures with a bunch of pointers, but it's doable, you need some serialization format though.

Yup - IPC - but the problem is 32/64 boundary :S they can't have access to each-others' process space. One is 32 and the other - logically 64 bits

32- and 64-bit app can still surely talk to eachother via pipes/sockets/etc, though? Yeah, you probably can't just set up a named memory mapped file and access that (try, though? ), hence the marshaling of data through your pipe/socket/whatever.

Yes, it does mean a speed hit and annoying code... COM might be the answer to avoid writing marshaling code yourself, although I dunno what it has to say about 32<>64.

Hey, why shared memory can't be used? I think that it would be just a matter of size limits between them but every process has its own page table and hence every process maps a memory region at the virtual addresses them want.

I'm half-way marshaling events through WM_COPYDATA messages. The only problem is that event gets delivered and message properties, but not the message itself :S
Ref#1= http://msdn2.microsoft.com/en-us/library/ms649009.aspx
Couldn't understand Ref#2 quite well: http://docs.hp.com/en/5966-9844/ch02s08.html
maybe its HP only ^o)

I've been extremely busy, but I'll try to put up some samples in the near days...

EDIT:

...thankfully there are weekends

I'll attach a 7z file and some instructions follow:
DIALOG64 should be the one sending messages, but the message written isn't sent right now.
RECEIVE32 should take the message and do sth with it and then sending sth else back. Now it only prints the .dwData which shouldn't be a string at all, but a DWORD value. .lpData seems to be pointing *somewhere*, but its empty. .cbData is lost

Can anyone point me to an error or misleading documentation perhaps...!?

Thx,
Madis

Dropped WM_COPYDATA completely. Pipes worked. I already gave an answer on another thread: http://board.flatassembler.net/topic.php?t=7877

Memory mapping works as well, no problems across 32/64bit processes. Tested on XP64.

Wow, thx man I don't know where did I go wrong... but now I know
I guess because its so simple its awfully faster than pipes too.

It's the fastest form of IPC you can do, since there's no kernel detours involved once the mapping is established - you share the same physical memory, even if the virtual addresses are different. Of course you still need to find a way to synchronize access, but I'll leave that pain to you