July 2002 - Wine-Devel - list.winehq.org

Re: .dll version detection

by 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. -- Microsoft Licensing 6.0: "Pay us now in advance, so that we can own you later."

July 22, 2002

Re: Makedll.rules.in

by Alexandre Julliard

Gregg Mattinson <gm138242(a)scot.canada.sun.com> writes: > So, my question is, why does the $(MODULE).so rule in Makedll.rules.in contain > $(LDDLLFLAGS)? Until I submitted this patch, that variable was not defined in > the makefiles for the .dlls, and the dlls appeared to work fine. Now that this > flag is defined, the .dlls don't work, but the tests do work. Should LDDLLFLAGS > be removed from the $(MODULE).so rule? What is LDDLLFLAGS defined to on Linux? > I only have a Solaris box here to test on, so my insight into the problem is > limited. The idea is that all dlls should be linked with LDDLLFLAGS; however only dlls that are properly separated can use it at this point, which is why LDDLLFLAGS is not defined in Makedll.rules, only in the individual makefiles of the dlls that have to use it. This is why your patch breaks for non-separated dlls. I have committed a different fix that I believe should work for you too. -- Alexandre Julliard julliard(a)winehq.com

July 22, 2002

Re: ShellExecute patch

by Alexandre Julliard

Duane Clark <dclark(a)akamail.com> writes: > I would use #ifndef NO_WIN16. Would that be acceptable for CVS? I need > to fix an obvious bug, so I think I will just make the change to call > CreateProcessA and put in the ifndefs and see what happens. I don't think a #ifdef is appropriate. What I would suggest is to always call WinExec, and change WinExec to behave like WinExec16 when called from a 16-bit app. -- Alexandre Julliard julliard(a)winehq.com

July 22, 2002

Re: ShellExecute patch

by Duane Clark

Steven Edwards wrote: > > Sounds cool but it really depends on if Alexandre will accept the > patch or not. At some point I will be add the configure option > --no-win16 so just doing a #ifdef NO_WIN16 should be fine. Building > on mingw already requires not including shell.c so I need to make the > Makefile and configure changes anyway. Its not that important ATM so > if it will be a problem we can wait till more ReactOS developers are > interested in fixing it. I would use #ifndef NO_WIN16. Would that be acceptable for CVS? I need to fix an obvious bug, so I think I will just make the change to call CreateProcessA and put in the ifndefs and see what happens.

July 22, 2002

Broken forwards in .spec files

by Patrik Stridvall

When I, with the help of Francois, fixed the statistics for forwarded functions in winapi_extract I notice that a few of the forwards in the .spec files are broken. winapi_check now checks for broken forward when it is run. However I'm not sure how the broken forwards are best fixed, so what I why I'm asking for people on the list with the appropriete knowledge to fix them. crtdll.spec: forward is broken: _strdec => msvcrt._strdec crtdll.spec: forward is broken: _strinc => msvcrt._strinc crtdll.spec: forward is broken: _strncnt => msvcrt._strncnt crtdll.spec: forward is broken: _strnextc => msvcrt._strnextc crtdll.spec: forward is broken: _strninc => msvcrt._strninc crtdll.spec: forward is broken: _strspnp => msvcrt._strspnp msvcrt20.spec: forward is broken: __seh_longjmp_unwind(a)4 => msvcrt.__seh_longjmp_unwind msvcrt20.spec: forward is broken: _mtlock => msvcrt._mtlock msvcrt20.spec: forward is broken: _mtunlock => msvcrt._mtunlock msvcrt20.spec: forward is broken: _tccpy => msvcrt._tccpy msvcrt20.spec: forward is broken: _tclen => msvcrt._tclen msvcrt20.spec: forward is broken: _tcschr => msvcrt._tcschr msvcrt20.spec: forward is broken: _tcsclen => msvcrt._tcsclen msvcrt20.spec: forward is broken: _tcscmp => msvcrt._tcscmp msvcrt20.spec: forward is broken: _tcscspn => msvcrt._tcscspn msvcrt20.spec: forward is broken: _tcsdec => msvcrt._tcsdec msvcrt20.spec: forward is broken: _tcsicmp => msvcrt._tcsicmp msvcrt20.spec: forward is broken: _tcsinc => msvcrt._tcsinc msvcrt20.spec: forward is broken: _tcslwr => msvcrt._tcslwr msvcrt20.spec: forward is broken: _tcsnbcnt => msvcrt._tcsnbcnt msvcrt20.spec: forward is broken: _tcsncat => msvcrt._tcsncat msvcrt20.spec: forward is broken: _tcsnccat => msvcrt._tcsnccat msvcrt20.spec: forward is broken: _tcsnccmp => msvcrt._tcsnccmp msvcrt20.spec: forward is broken: _tcsnccnt => msvcrt._tcsnccnt msvcrt20.spec: forward is broken: _tcsnccpy => msvcrt._tcsnccpy msvcrt20.spec: forward is broken: _tcsncicmp => msvcrt._tcsncicmp msvcrt20.spec: forward is broken: _tcsncmp => msvcrt._tcsncmp msvcrt20.spec: forward is broken: _tcsncpy => msvcrt._tcsncpy msvcrt20.spec: forward is broken: _tcsncset => msvcrt._tcsncset msvcrt20.spec: forward is broken: _tcsnextc => msvcrt._tcsnextc msvcrt20.spec: forward is broken: _tcsnicmp => msvcrt._tcsnicmp msvcrt20.spec: forward is broken: _tcsninc => msvcrt._tcsninc msvcrt20.spec: forward is broken: _tcsnset => msvcrt._tcsnset msvcrt20.spec: forward is broken: _tcspbrk => msvcrt._tcspbrk msvcrt20.spec: forward is broken: _tcsrchr => msvcrt._tcsrchr msvcrt20.spec: forward is broken: _tcsrev => msvcrt._tcsrev msvcrt20.spec: forward is broken: _tcsset => msvcrt._tcsset msvcrt20.spec: forward is broken: _tcsspn => msvcrt._tcsspn msvcrt20.spec: forward is broken: _tcsspnp => msvcrt._tcsspnp msvcrt20.spec: forward is broken: _tcsstr => msvcrt._tcsstr msvcrt20.spec: forward is broken: _tcstok => msvcrt._tcstok msvcrt20.spec: forward is broken: _tcsupr => msvcrt._tcsupr shell32.spec: forward is broken: StrNCpyW => shlwapi.StrNCpyW

July 22, 2002

Re: Makedll.rules.in

by Gregg Mattinson

Oops.. This patch fixes the linking of tests, but it breaks..well..all the .dlls, atleast for me. So, my question is, why does the $(MODULE).so rule in Makedll.rules.in contain $(LDDLLFLAGS)? Until I submitted this patch, that variable was not defined in the makefiles for the .dlls, and the dlls appeared to work fine. Now that this flag is defined, the .dlls don't work, but the tests do work. Should LDDLLFLAGS be removed from the $(MODULE).so rule? What is LDDLLFLAGS defined to on Linux? I only have a Solaris box here to test on, so my insight into the problem is limited. Any insight would be appreciated. Thanks, Gregg >From: Gregg Mattinson <gm138242(a)opcom-mail.canada.sun.com> >Subject: Makedll.rules.in >To: wine-patches(a)winehq.com >Date: Fri, 19 Jul 2002 10:39:22 -0400 (EDT) > >Changelog: dlls/Makedll.rules.in > - Added LDDLLFLAGS to Makedll.rules.in so that tests get linked properly > >Gregg Mattinson >Co-op Developer >Sun Microsystems of Canada

July 22, 2002

RE: regsvr32 with multiple arguments

by Medland, Bill

> -----Original Message----- > From: Andriy Palamarchuk [mailto:apa3a(a)yahoo.com] > Sent: Monday, July 22, 2002 7:41 AM > To: Medland, Bill; Wine devel (E-mail) > Subject: Re: regsvr32 with multiple arguments > > > > --- "Medland, Bill" <Bill.Medland(a)accpac.com> wrote: > > Did I miss something? > > > > Yesterday when I ran regsvr32 with multiple > > arguments it registered each > > one. Today it only registers the first. Yesterday > > it popped up a > > MessageBox with the result; today it puts the result > > on stdout. > > > > Does this make sense to anyone? > > Yes, the day before you used the native one, now you > are using the built-in. And didn't I feel a fool when I looked at the code and realised it (when I got home) > Thanks for the patch. My pleasure. > > Andriy > > __________________________________________________ > Do You Yahoo!? > Yahoo! Health - Feel better, live better > http://health.yahoo.com > Bill

July 22, 2002

Bug 434 Update/shot in the dark

by Rick Romero

Referring to bug: http://bugs.winehq.com/show_bug.cgi?id=434 Under normal circumstances the mouse button doesn't get released in certain applications. These include, Macromedial Flash 5, MS Visual Foxpro 5/6, and Adobe Illustrator 8. I'm working with FoxPro 5. (I have a demo app in the bug report) In *MY* testing, I've noticed that the following command allows the mouse button to be released. wine --debugmsg +scroll,+event,+toolbar,+gdi,+heap vfp.exe If, while running under this command, I _hold_ the mouse button down - longer than a 'click', it will not be released. This seems like a timing issue to me, and started after functions were moved into the wineserver. Not that I know anything about how Wine is setup, but could the 'buttonup' be 'lost', or sent out of sequence, causing it to not be executed? And that sequence is slowed by the debug message enough, that a longer 'buttondown' duration is needed before the bug shows up? Where would be the best place to insert a delay, or extend the timing for a single click (So only the mouseclick function is 'slowed')? I'm sure this isn't the best bug report ever sent, but any suggestions would be appreciated. ;) Rick -- -- Rick Romero IT Manager Valeo, Inc. ph: 262.695.4841 Sussex, WI. fax: 262.695.4850 Rick(a)valeoinc.com

July 22, 2002

Re: regsvr32 with multiple arguments

by Andriy Palamarchuk

--- "Medland, Bill" <Bill.Medland(a)accpac.com> wrote: > Did I miss something? > > Yesterday when I ran regsvr32 with multiple > arguments it registered each > one. Today it only registers the first. Yesterday > it popped up a > MessageBox with the result; today it puts the result > on stdout. > > Does this make sense to anyone? Yes, the day before you used the native one, now you are using the built-in. Thanks for the patch. Andriy __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com

July 22, 2002

Re: winedbg again :-)

by Massimo

......... > the best way would be to enhance the display functions with somethings > like > display $regs > not difficult Right, I'll try to do it on next days... Or do you plan do implement yourself ? > ........ > OTOH, it's also very awful to set a bp on memory which isn't mapped > yet... you > cannot write on it :-) > anyway, we could do something like we do now for bp setting (expressed > as a string) and automatically set the bp on DLL loading (if we can) > rather easy (just follow what's done for deferred bp) Yes, I meant deferred BP... is there already a way to set them now, at adress points ? Or it's only for source BPs ? > ....... > that's a bit harder (especially, since we don't want the user to > interact), but basically it's just setting the parser to read from a > file stream instead of stdin I don't understand the thing of avoiding user interaction.... I was thinking about a command like 'store breaks <filename>' and 'load breaks <filename>... or maybe, better, a way to store all winedbg settings on file. Regards Max

July 22, 2002