Shachar Shemesh wine-devel@shemesh.biz writes:
What do you mean by "delayed imports". When I defined, proper, the entire spec as actual functions, I got conflicts when I tried to define GetProcAddress. In any case, even then I'm going to need to call GetProcAddress (yes, I guess I can use the same strange macros to do that, or call the native NT function. I'd rather not do that, however).
These problems are apparent in the experimental patch I sent (http://www.winehq.org/hypermail/wine-devel/2003/11/0098.html).
That patch builds just fine for me. You know, I'd really like to help you, but this is very frustrating: I'm sure I could give you a solution in 2 minutes if I actually saw the problem; instead of that you waste your time trying to modify the generated .spec.c file, and I waste my time trying to guess what error you are seeing. How about sending me the exact code that fails, with the exact error messages?
OK, in the meantime I'll try to continue guessing. I suppose you called your implementation GetProcAddress, which of course makes it impossible to call the kernel32 one. If that's the problem, you should simply use a different name for your function, and do the mapping in the spec file. So you do something like:
@ stdcall GetProcAddress(long ptr) UNICOWS_GetProcAddress
and implement UNICOWS_GetProcAddress by calling the real GetProcAddress.
Next, note that calling GetProcAddress at all is unnecessary; you can let the linker do the work, by implementing the other functions the same way (with a UNICOWS_xxx function that calls the real xxx).