Forwards exports - anyone?

[Shachar Shemesh]

Hi all,

I noticed in the code that there is a concept called "forwad_export". 
Does it have anything to do with making a function in one DLL return a 
function address that belongs to another?

If that is the case, how do I activate this? Is there some spec file 
magic that will do it?

I'm trying to implement unicows.dll. The theory is quite simple - since 
unicows merely implements unicode functions that exist, theoretically, 
only in Wine, all I have to do is create forwards (i.e. - ExtTextOutW in 
unicows.dll will call ExtTextOutW in GDI). This is slightly inefficient, 
but should solve our unicows.dll problems.

If I can merely instruct the dynamic loader to return the GDI 
ExtTextOutW function when someone tries to link with the unicows 
ExtTextOutW, I can solve the inefficiency in a clean, working way 
without further problems.

I considered various loader tricks, but I'm afraid the closest I'm 
willing to come is assembler tricks, and those won't work on other 
platforms (then again - other platforms are highly unlikely to require 
unicows - hmm).

Shachar

[Robert Shearman]

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Shachar Shemesh
> Sent: 29 October 2003 13:41
> To: Wine Devel
> Subject: Forwards exports - anyone?
>
> Hi all,
>
> I noticed in the code that there is a concept called "forwad_export".
> Does it have anything to do with making a function in one DLL return a
> function address that belongs to another?
>
> If that is the case, how do I activate this? Is there some spec file
> magic that will do it?

Yes. Example from kernel32.spec:
@ stdcall RtlMoveMemory(ptr ptr long) ntdll.RtlMoveMemory
This is a function called RtlMoveMemory that forwards to the ntdll function
RtlMoveMemory (the names don't have to be the same).

I believe this is exactly the way you want to do it as the same has been
done for the *Wrap functions in SHLWAPI (which are effectively a
mini-unicows.dll).

Rob