August 2004 - Wine-Devel - list.winehq.org

Re: IShellLink and non-existant exe files

by Christian Costa

Hi, I don't know much about this code but some line below there is: Stream_WriteLocationInfo( stm, exePath ); In our case exePath is still empty. Shouldn't we set exePath to the same value as This->sPath ? Christian Aric Stewart wrote: > It is possible under windows to create a .Lnk file to an exe file > before it exists. Office 2000 does this, Scientific Word does this as > do other apps as well. > > So a quick fix so that in IPersistFile_Save if the exe file is not > found, trust the path we are given and allow creation of the link. > > ------------------------------------------------------------------------ > > Index: dlls/shell32/shelllink.c > =================================================================== > RCS file: /home/wine/wine/dlls/shell32/shelllink.c,v > retrieving revision 1.70 > diff -u -w -r1.70 shelllink.c > --- dlls/shell32/shelllink.c 12 Aug 2004 23:00:53 -0000 1.70 > +++ dlls/shell32/shelllink.c 20 Aug 2004 13:27:38 -0000 > @@ -683,9 +683,14 @@ > /* if there's no PIDL, generate one */ > if( ! This->pPidl ) > { > + /* + * windows can create lnk files to executables > that do not exist yet > + * so if the executable does not exist the just trust the > path they > + * gave us > + */ > if( !*exePath ) > - return E_FAIL; > - > + This->pPidl = ILCreateFromPathW(This->sPath); > + else > This->pPidl = ILCreateFromPathW(exePath); > } > > >

Aug. 20, 2004

Re: Optimize Critical Section Functions

by Alexandre Julliard

Michael Stefaniuc <mstefani(a)redhat.com> writes: > Andreas Mohr wrote: >> Umm, this should go into a global header file, right? >> The theory being that it would be useful at many more performance critical >> Wine places... >> But I have to admit that I don't know which header file this should >> be... > Like in the Linux kernel (where this seems to come from) in compiler.h > or something like that. No, I don't think we want to do that, it would only encourage people to sprinkle this stuff all over the place believing they are "optimizing" the code. This should only be added in places where it makes a significant difference, demonstrated with benchmark results. -- Alexandre Julliard julliard(a)winehq.org

Aug. 20, 2004

Document an API difference

by Shachar Shemesh

Hi list, I'm documenting a probable API result difference between Wine and Windows. At the moment, this is no longer a problem as far as I'm concerned, so there is no point for me to write regression tests and fix it, but this may be stopping someone else. It seems that if you call "select" with a FD set that holds the same file descriptor more than once, Wine's and Window's responses are different. Under windows, you get a statement saying that only one FD is active. Under Wine, you get as many as the number of times the repeating FD is in the set. Like I said, this does not affect, as far as I know, any program, so I'm not sure we need to fix it. I just wanted the list's archive to have a mention of this issue. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/

Aug. 20, 2004

Re: Re: make CryptSetProviderEx update the provider Name and TypeName to registry

by James Hawkins

I'm working on a test app that I hope wil shine some light on how windows gets the Name and TypeName values back in the registry after they've been deleted. The problem is that the only instance of the Name and TypeName data is in the DllRegisterServer function of the provider dll. I couldn't think of any other way to get to that data to get it in the registry, but I will be testing this in windows. What im thinking is that windows might not even delete the key at all. If you have any suggestions it would help a lot. On Fri, 20 Aug 2004 12:48:07 -0700, Alexandre Julliard <julliard(a)winehq.org> wrote: > James Hawkins <truiken(a)gmail.com> writes: > > >> Changelog > >> * Call provider.dll's DllRegisterServer from CryptSetProviderEx to > >> update the Name and TypeName values in the registry properly when > >> setting the default provider > > It doesn't seem right to call DllRegisterServer from there, IMO it > should only be called when the dll is installed. Do you have evidence > that Windows does it this way? > > -- > Alexandre Julliard > julliard(a)winehq.org > -- James Hawkins

Aug. 20, 2004

Re: make CryptSetProviderEx update the provider Name and TypeName to registry

by Alexandre Julliard

James Hawkins <truiken(a)gmail.com> writes: >> Changelog >> * Call provider.dll's DllRegisterServer from CryptSetProviderEx to >> update the Name and TypeName values in the registry properly when >> setting the default provider It doesn't seem right to call DllRegisterServer from there, IMO it should only be called when the dll is installed. Do you have evidence that Windows does it this way? -- Alexandre Julliard julliard(a)winehq.org

Aug. 20, 2004

Re: Optimize Critical Section Functions

by Michael Stefaniuc

Andreas Mohr wrote: > Hi, > > On Fri, Aug 20, 2004 at 04:50:36PM +0100, Robert Shearman wrote: > >>Index: wine/dlls/ntdll/critsection.c >>=================================================================== >>RCS file: /home/wine/wine/dlls/ntdll/critsection.c,v >>retrieving revision 1.26 >>diff -u -p -r1.26 critsection.c >>--- wine/dlls/ntdll/critsection.c 17 Jun 2004 23:11:08 -0000 1.26 >>+++ wine/dlls/ntdll/critsection.c 20 Aug 2004 15:46:18 -0000 >>@@ -36,6 +36,14 @@ >> WINE_DEFAULT_DEBUG_CHANNEL(ntdll); >> WINE_DECLARE_DEBUG_CHANNEL(relay); >> >>+#ifdef __GNUC__ >>+# define likely(x) __builtin_expect(!!(x), 1) >>+# define unlikely(x) __builtin_expect(!!(x), 0) >>+#else >>+# define likely(x) !!(x) >>+# define unlikely(x) !!(x) >>+#endif >>+ > > > Umm, this should go into a global header file, right? > The theory being that it would be useful at many more performance critical > Wine places... > > But I have to admit that I don't know which header file this should be... Like in the Linux kernel (where this seems to come from) in compiler.h or something like that. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

Aug. 20, 2004

Re: Backtrace Dumps

by Alexandre Julliard

Mike Hearn <mike(a)navi.cx> writes: > This isn't reliable though, what about apps that swallow all exceptions > with a try/except block? Ideally you want this sort of thing to just > work and not have to figure out why your backtrace is never happening. In that case you have to start the debugger first. Of course there will be cases where it won't work as well as you'd like, you'll have the same with the in-process solution, there are many cases where it won't work. And actually the debugger solution has more chances to work reliably since being in a separate process it interferes much less with the running application. -- Alexandre Julliard julliard(a)winehq.org

Aug. 20, 2004

Re: Optimization for FindFile* (resend)

by Alexandre Julliard

Robert Shearman <rob(a)codeweavers.com> writes: > Changelog: > Handle case of mask containing no wildcards so that it is possible to > avoid searching through hundreds of directory entries. I'm afraid this doesn't work, you need to take the file position in the directory into account, and also update it properly (which will probably defeat the optimization). -- Alexandre Julliard julliard(a)winehq.org

Aug. 20, 2004

Re: Optimize Critical Section Functions

by Andreas Mohr

Hi, On Fri, Aug 20, 2004 at 04:50:36PM +0100, Robert Shearman wrote: > Index: wine/dlls/ntdll/critsection.c > =================================================================== > RCS file: /home/wine/wine/dlls/ntdll/critsection.c,v > retrieving revision 1.26 > diff -u -p -r1.26 critsection.c > --- wine/dlls/ntdll/critsection.c 17 Jun 2004 23:11:08 -0000 1.26 > +++ wine/dlls/ntdll/critsection.c 20 Aug 2004 15:46:18 -0000 > @@ -36,6 +36,14 @@ > WINE_DEFAULT_DEBUG_CHANNEL(ntdll); > WINE_DECLARE_DEBUG_CHANNEL(relay); > > +#ifdef __GNUC__ > +# define likely(x) __builtin_expect(!!(x), 1) > +# define unlikely(x) __builtin_expect(!!(x), 0) > +#else > +# define likely(x) !!(x) > +# define unlikely(x) !!(x) > +#endif > + Umm, this should go into a global header file, right? The theory being that it would be useful at many more performance critical Wine places... But I have to admit that I don't know which header file this should be... Andreas Mohr

Aug. 20, 2004

Re: Move include/async.h to include/wine/async.h

by Alexandre Julliard

Robert Shearman <rob(a)codeweavers.com> writes: > Changelog: > Move include/async.h to include/wine/async.h Actually that file should be removed, we don't want to share internal data structures like that. It will require some restructuring of the async I/O support though. -- Alexandre Julliard julliard(a)winehq.org

Aug. 20, 2004