Wine compatibility checking tool

[robert lippmann]

Hi all,

I had an idea for something that might be useful and wanted to know everyone’s thoughts.

Basically, create a program that will take a Windows executable/dll, find all the imports and check Wine’s .spec files to see if the imports are stubs or don’t exist.  Obviously could also go recursive through imports of other dlls down to the win32 sdk level too.

It might help figure out some “why is this program crashing” issues.

Thoughts?
Rob

[Esme Povirk]

I don't think it'd be very useful, at least for understanding crashes. 
If the program actually calls those functions before the crash, there 
will be a fixme or exception that tells us that (with the possible 
exception of using GetProcAddress, but we can't detect that from a PE 
image anyway).

On 2025-03-09 22:49, robert lippmann wrote:
> Hi all,
>
> I had an idea for something that might be useful and wanted to know everyone’s thoughts.
>
> Basically, create a program that will take a Windows executable/dll, find all the imports and check Wine’s .spec files to see if the imports are stubs or don’t exist.  Obviously could also go recursive through imports of other dlls down to the win32 sdk level too.
>
> It might help figure out some “why is this program crashing” issues.
>
> Thoughts?
> Rob

[robert lippmann]

I was thinking more to pro-actively determine if a program might crash so that wine developers can (possibly) focus efforts on implementing those stub functions to increase overall app compatibility.
> On Mar 10, 2025, at 12:05 PM, Esme Povirk  wrote:
>
> I don't think it'd be very useful, at least for understanding crashes. If the program actually calls those functions before the crash, there will be a fixme or exception that tells us that (with the possible exception of using GetProcAddress, but we can't detect that from a PE image anyway).
>
> On 2025-03-09 22:49, robert lippmann wrote:
> > Hi all,
> >
> > I had an idea for something that might be useful and wanted to know everyone’s thoughts.
> >
> > Basically, create a program that will take a Windows executable/dll, find all the imports and check Wine’s .spec files to see if the imports are stubs or don’t exist.  Obviously could also go recursive through imports of other dlls down to the win32 sdk level too.
> >
> > It might help figure out some “why is this program crashing” issues.
> >
> > Thoughts?
> > Rob

[Stefan Dösinger]

> Am 10.03.2025 um 21:29 schrieb robert lippmann :
>
> I was thinking more to pro-actively determine if a program might crash so that wine developers can (possibly) focus efforts on implementing those stub functions to increase overall app compatibility.

Relatively few bugs are actually because a missing or stub export. Just because the export is there doesn't mean it behaves the way the application expects.

And not everything an application imports is actually called. That's why we have the @stub lines in the first place. It shuts up a lot of spam at program load time and still writes clear information when the function is actually called. FIXME lines/warnings aren't free - they tend to mislead users into thinking the crash is because of the last FIXME they saw.

Library imports also don't find COM interfaces used.

[robert lippmann]

> Relatively few bugs are actually because a missing or stub export. Just because the export is there doesn't mean it behaves the way the application expects.
>
> And not everything an application imports is actually called. That's why we have the @stub lines in the first place. It shuts up a lot of spam at program load time and still writes clear information when the function is actually called. FIXME lines/warnings aren't free - they tend to mislead users into thinking the crash is because of the last FIXME they saw.
>
> Library imports also don't find COM interfaces used.

Ah, that’s what I was wondering.  I must have found a rare case of an application that uses a rarely used part of the Win32 SDK which hasn’t been implemented yet.

[Elizabeth Figura]

On Monday, 10 March 2025 14:55:47 CDT robert lippmann wrote:
> > Relatively few bugs are actually because a missing or stub export. Just because the export is there doesn't mean it behaves the way the application expects.
> >
> > And not everything an application imports is actually called. That's why we have the @stub lines in the first place. It shuts up a lot of spam at program load time and still writes clear information when the function is actually called. FIXME lines/warnings aren't free - they tend to mislead users into thinking the crash is because of the last FIXME they saw.
> >
> > Library imports also don't find COM interfaces used.
>
> Ah, that’s what I was wondering.  I must have found a rare case of an application that uses a rarely used part of the Win32 SDK which hasn’t been implemented yet.

I don't know if I'd call it rare necessarily; it happens fairly often (as you can tell by the number of new stubs that show up on the list), but the amount of development time it takes up is certainly proportionally minuscule.

I would simply say that the compatibility checking tool you're describing already exists, and is called "Wine". It's overwhelmingly clear when a program fails that way.