RE: Errors running winapi_extract --stub-statistics

[Patrik Stridvall]

> I think this is because the module name is no longer in the 
> .spec file.  Lines 
> 71-73 of winapi_extract look for "name" in the .spec file, 
> which no longer 
> exists.  Should we be using the file name as the module name?

Correct. Patch for this and other problem with
winapi_extract coming soon.

Errors running winapi_extract --stub-statistics

[Francois Gouget]

On Fri, 19 Jul 2002, Patrik Stridvall wrote:
[...]
> Correct. Patch for this and other problem with
> winapi_extract coming soon.

Thanks a lot of the patch, it works much better now.

I noticed another 'problem' of sorts: winapi_extract does not count
forward functions. For instance for msvcrt20 it says:

*.c: msvcrt20: 427 of 429 functions are stubs (427 real, 0 pseudo)

But in fact there are also 697 forward functions. So I began checking in
more details and found other inconsistencies. For instance for comctl32
it says:

*.c: comctl32: 107 of 244 functions are stubs (88 real, 19 pseudo)

But comctl32.spec has only 197 lines so it cannot declare 244 functions.
Also, a grep stub comctl32.spec | wc -l says there are only 24 matches
(one is commented out). So I tweaked things a bit and arrived at the
attached patch. I'm not sure I did things right. Does it make sense?

With the patch, I get the following statistics:

*.c: comctl32: 42 of 179 functions are stubs (23 real, 19 pseudo) and 0 are forwards

And for msvcrt20:
*.c: msvcrt20: 427 of 1126 functions are stubs (427 real, 0 pseudo) and 697 are forwards

--
Francois Gouget         [e-mail]        http://fgouget.free.fr/
    I haven't lost my mind, it's backed up on tape around here somewhere...

.dll version detection

[Jan Hurst]

Hello,

I have been digging around attempting to get ICQ 2002a to install.
(appdb
->http://appdb.codeweavers.com/appview.php?appId=55&versionId=986)

(o/t ok shoot me, I like the windows client ;)

When attempting to install I notice that wine appears to be testing for
the presence of a native shdocvw.dll. From my limited debugging ability
it looks like the ICQ installer is testing for the physical presence
(and version) of the shdocvw.dll file and then aborting rather than
attempting to call a missing function and falling over.

Copying over a win98/winme version of shdocvw.dll allows the installer
to continue on and unpack its files into their location and (hopefully!)
setting up some registry entries. (Unfortunately, ICQ itself crashes
without the presence of some further dll's... The installer tries to
launch ICQ an produces some problems)

Is this scenario possible or am I way off track???? Sorry I'm rather new
to wine devel :(

Regards,

-jan

--
Jan Hurst
[e-mail]

.dll version detection

[Andreas Mohr]

On Sun, Jul 21, 2002 at 10:55:59PM +0800, Jan Hurst wrote:
> Hello,
>
> I have been digging around attempting to get ICQ 2002a to install.
> (appdb
> ->http://appdb.codeweavers.com/appview.php?appId=55&versionId=986)
>
> (o/t ok shoot me, I like the windows client ;)

*BANG* !
> When attempting to install I notice that wine appears to be testing for
> the presence of a native shdocvw.dll. From my limited debugging ability
> it looks like the ICQ installer is testing for the physical presence
> (and version) of the shdocvw.dll file and then aborting rather than
> attempting to call a missing function and falling over.

"limited" ?
Sounds like your debugging ability is pretty good ;)
(at least this is a frequent thing to happen, dunno whether this really
happens with your program)

We do have a problem here.
Some programs really query the version information of physically existing DLLs.
(or at least they first try a CreateFile() or similar on them)
We should create "stub" DLLs that only contain the file header (MZ/NE/PE)
and some dummy version information resource.
I had already coded some support for that, but I lost it when I once
accidentally deleted the *remote* Wine tree instead of the *local* one ;-\

One way to do that would probably be to enhance winebuild to also build these
"stub" DLLs.