Stubs in spec files

[Alexandre Julliard]

Zebediah Figura <z.figura12 at 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.

-- 
Alexandre Julliard
julliard at winehq.org