Stubs in spec files

[Zebediah Figura]

Hi,

I am a novice developer with a question about the spec files.

Currently the .spec files contain stub lines for functions which have no
implementation, and the compiler creates assembly thunks to
__wine_spec_unimplemented_stub, which raises an exception when the
function is called.

However, some entries in the spec files are actually not functions but
data, and when applications attempt to read this data they instead read
the instruction code of the thunks. I recently was debugging a 16-bit
application [1] which was referring to a GUID that I could not find
defined anywhere, and only after some time was able to figure out that
the application was reading the thunk code for _IID_IClassFactory in
this way.

The NE segment loading code in krnl386.dll16 will print a warning if an
application attempts to request the location of a symbol not defined in
the library. However, since the stubs are defined, no such message is
printed, but the program will effectively be given a pointer to junk
memory. As far as I can tell there is no way to add such a message either.

What would in fact work is not to implement stub code in the libraries
at all. In 16-bit code this results in a warning when the value is
accessed, followed by a crash if it is a function which the code
attempts to call. In 32-bit code this seems to behave identically to a
stub function. Thus the only difference is that in 16-bit code (and
possibly 32-bit code, but I could not find any variable that I could
test with) a warning is printed (and 0xdeadbeef is returned instead of
junk memory), which I see as a definite improvement. By commenting out
all of the stub lines in compobj.dll16.spec I was able to locate several
more that the program requested, but I may still be missing some in
other DLLs.

My question, then, is—is there any purpose of the stub lines besides to
directly call __wine_spec_unimplemented_stub, or any other reason why
this proposal would be detrimental?

Thanks,
Zebediah Figura