flat assembler
Message board for the users of flat assembler.

Index > Main > Mixing 32/64-bit DLLs under 64-bit OS

Author
Thread Post new topic Reply to topic
Madis731



Joined: 25 Sep 2003
Posts: 2140
Location: Estonia
Madis731
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 Smile
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 - Smile 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 Smile

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 Razz 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

_________________
My updated idol Very Happy http://www.agner.org/optimize/
Post 30 Oct 2007, 09:17
View user's profile Send private message Visit poster's website Yahoo Messenger MSN Messenger Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
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.
Post 30 Oct 2007, 11:17
View user's profile Send private message Visit poster's website Reply with quote
Madis731



Joined: 25 Sep 2003
Posts: 2140
Location: Estonia
Madis731
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 Sad
Post 30 Oct 2007, 11:25
View user's profile Send private message Visit poster's website Yahoo Messenger MSN Messenger Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
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? Smile), 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.
Post 30 Oct 2007, 11:29
View user's profile Send private message Visit poster's website Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
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.
Post 30 Oct 2007, 15:55
View user's profile Send private message Reply with quote
Madis731



Joined: 25 Sep 2003
Posts: 2140
Location: Estonia
Madis731
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 Very Happy

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 Neutral

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

Thx,
Madis


Description: ASM+EXE of both apps (64-bit Win OS needed)
Download
Filename: DLL.7z
Filesize: 3.18 KB
Downloaded: 192 Time(s)


_________________
My updated idol Very Happy http://www.agner.org/optimize/
Post 06 Nov 2007, 14:23
View user's profile Send private message Visit poster's website Yahoo Messenger MSN Messenger Reply with quote
Madis731



Joined: 25 Sep 2003
Posts: 2140
Location: Estonia
Madis731
Dropped WM_COPYDATA completely. Pipes worked. I already gave an answer on another thread: http://board.flatassembler.net/topic.php?t=7877


Description: Run DIALOG64 The first textbox is for writing text, on OK its sent to the RECEIVE32 (which is opened with ShellExecute) and its sent back being capitalized (and [mem],not 20202020h). The second inputbox is the result.
Download
Filename: Tests2.7z
Filesize: 3.65 KB
Downloaded: 171 Time(s)

Post 07 Jan 2008, 08:46
View user's profile Send private message Visit poster's website Yahoo Messenger MSN Messenger Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
Memory mapping works as well, no problems across 32/64bit processes. Tested on XP64.


Description:
Download
Filename: mmap_32_64.zip
Filesize: 56.08 KB
Downloaded: 177 Time(s)


_________________
Image - carpe noctem
Post 24 Jan 2008, 12:20
View user's profile Send private message Visit poster's website Reply with quote
Madis731



Joined: 25 Sep 2003
Posts: 2140
Location: Estonia
Madis731
Wow, thx man Smile I don't know where did I go wrong... but now I know Very Happy
I guess because its so simple its awfully faster than pipes too.
Post 25 Jan 2008, 19:26
View user's profile Send private message Visit poster's website Yahoo Messenger MSN Messenger Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
Madis731 wrote:
Wow, thx man Smile I don't know where did I go wrong... but now I know Very Happy
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 Wink

_________________
Image - carpe noctem
Post 26 Jan 2008, 01:20
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on YouTube, Twitter.

Website powered by rwasa.