It's a common technique to rely on the fact that exports from kernel32 reside at the same address to use CreateRemoteThread calling LoadLibrary for remote code injection (this is not what Vitaliy's App is doing here but the assertions are the same).
It's hard to implement that in Wine, because dlls are loaded using dlopen() and there's no way to specify which address to load the dll at.
I would say that the only relatively sane way to do it is to re-implement dlopen to support such functionality. The ELF tables that dlopen needs are documented. It doesn't seem like a trivial task to reimplement it, but it should be doable. Last time I checked, ELF tables are at least manageable to deal with given a rainy afternoon: http://hrabia.ibib.waw.pl/~winnie/qtbeheader.html
There is also other way to do it. Wine could create the jump table (I don't know if it's good name in English) that would look like: jmp <func1> jmp <func2> ... where func1 is what dlsym returns and GetProcAddress could return address to this jump instruction. This table could be mmaped in fixed place.
That's clever too! I didn't think of it. Now the question is if the copy protection guys didn't think of doing checksumming of the actual functions in question, or if they won't eventually. That'd firmly lock their products to Windows, unless their checksumming was insecure. Then code could be fabricated to match the signature while doing the jump that one needs. One hopes they don't read wine-devel ;)
Well they actually took care of that. They don't really use GetProcAddress. At least safedisc doesn't. They pretty much implemented their own GetProcAddress that does work on wine. I don't know details of it but it suffers form the same problem :-(
Something tells me that their GetProcAddress will not work with such a jump table.
Vitaliy