Zebediah Figura z.figura12@gmail.com writes:
For what it's worth, the error message I get for the (one) 32-bit function that I tested was identical. For 16 bit the stub gives me
wine: Call from 0x7b43c26c to unimplemented function compobj.dll16.COINITIALIZE, aborting wine: Unimplemented function compobj.dll16.COINITIALIZE called at address 0x7b43c26c (thread 0030), starting debugger...
while the nonexistent one gives me
err:fixup:apply_relocations No implementation for COMPOBJ.2, setting to 0xdeadbeef wine: Unhandled page fault on read access to 0x0000dea8 at address 0x101f:0x000017c3 (thread 0030), starting debugger...
The latter is a bit less obvious, but my reasoning is that a "no implementation" line should be enough of a red flag that the generic exception (or other misbehavior) could still be as easily fixed.
For functions that are imported at link time, we can generate a stub or a dummy pointer, and print a warning. That's not the case for GetProcAddress, so the stub entries are still needed.
Maybe we need a different kind of stub for data exports that point to a X byte large block filled with 0xdeadcode?
This could work, but there is the problem that most of the stub constants that I found weren't outputted to the console. I only noticed the one because it showed up in a FIXME line for a function I was trying to implement.
Also, is there any way of actually telling whether a DLL export is a function or a constant?
Not in general, which is why they are all marked as stub since that's the case 99.9% of the time. Once we find out that one of them is supposed to be a data export, we can comment the stub out, or better simply implement it.