December 2003 - Wine-Devel - list.winehq.org

Silly question, sloghtly off topic

by Joshua Walker

If you replace a win9x advapi32.dll with a winNT advapi32.dll, do you gain the extra security features? I'm guessing no... -Joshua

Dec. 31, 2003

Re: GetModuleFileName mysteries

by Alexandre Julliard

"Ralf Juengling" <juenglin(a)cse.ogi.edu> writes: > But what is the reason for having GetModuleFileName return the system > dir for "builtin DLLs"? Because we don't know the real path, and even if we did there is no guarantee that it is accessible from a Windows drive. > Also, why does it behave differently for the two programs, as I reported > in my initial posting; is one of the two cases exhibiting a bug? Because in one case you used a .exe.so and in the other a .dll.so, they behave slightly differently. It's not really a bug, just a side effect of the fact that you can load a .exe.so by specifying its path explicitly, which you cannot do for builtin dlls. This could be changed, but there hasn't been any real need for that yet. -- Alexandre Julliard julliard(a)winehq.com

Dec. 31, 2003

PATCH - winebrowser

by Chris Morgan

Has Rein's fix for mozilla and Ivan's additional browsers. Tried to clean the script up a little bit, could probably still use some work but I'm no script guru. Chris * tools/winebrowser, tools/wineinstall, tools/Makefile.in, winedefault.reg Chris Morgan <cmorgan(a)alum.wpi.edu> Add HKEY_LOCAL_MACHINE\software\classes\http\shell\open\command key and value. Winebrowser script. Makefile changes to install/remove script. Wineinstall should create a simlink from windows/winebrowser.exe to the location of winebrowser on the machine.

Dec. 30, 2003

Re: Add support for some other MCI_ commands and implement mciSendCommandW

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > @@ -84,7 +84,16 @@ BOOL VFWAPIV MCIWndRegisterClass(HINSTAN > { > WNDCLASSW wc; > > - wc.style = CS_VREDRAW | CS_HREDRAW | CS_DBLCLKS | CS_OWNDC; > + /* Since we are going to register a class belonging to MSVFW32 > + * and later we will create windows with a different hInstance > + * CS_GLOBALCLASS is needed. And because the second attempt > + * to register a global class will fail we need to test whether > + * the class was already registered. > + */ > + if (GetClassInfoW(MSVFW32_hModule, mciWndClassW, &wc)) > + return TRUE; > + This is not thread-safe; if you need to know why the class creation failed you should check the last error returned from RegisterClassW. -- Alexandre Julliard julliard(a)winehq.com

Dec. 30, 2003

Re: Allow regsvr32 to register multiple DLLs at once

by Alexandre Julliard

Mike Hearn <mike(a)theoretic.com> writes: > When you just get the urge to reregister your entire windows/system > directory... > > Mike Hearn <mike(a)theoretic.com> > Allow regsvr32 to register multiple DLLs even if some fail regsvr32 is a standard Windows program, we shouldn't invent new options that don't exist on Windows. -- Alexandre Julliard julliard(a)winehq.com

Dec. 30, 2003

Re: Key exist query in registry

by Zimler Attila

Dimitrie O. Paun wrote: >>I call RefreshListView() but the key doesn't appear in >>the list. Should we do some insert to the listview? Or >>this could be a bug? >> >> > >Hold on, are you inserting a key or a value? Values appear >in the listview, keys in the treeview. > I'm trying to insert a key. Sorry for the incovenience, I mean the treeview object as you guessed. > But I don't think >there is a treeview refresh just yet, so it's a bit trickier. Maybe we should first handle values, it's easier, >we can worry about keys after that... > > > Should I then post my patch on how to insert a new key? And later we do the treeview refresh? Attila

Dec. 30, 2003

Re: option to ignore primary selection

by Alexandre Julliard

Ulrich Czekalla <ulrich.czekalla(a)utoronto.ca> writes: > Makes sense to me. I modified the patch to turn it on by default. IMO you should also invert the option (and rename it to something like "UsePrimary"). It's confusing to have to set an option to false to enable a feature. -- Alexandre Julliard julliard(a)winehq.com

Dec. 30, 2003

Re: PATCH: dlls/winmm/wineoss/audio.c

by Alexandre Julliard

Gerald Pfeifer <gerald(a)pfeifer.com> writes: > Tests by a FreeBSD user and discussions with one of the FreeBSD sound > maintainers confirmed that this is the right fix for that platform. > > I'm not sure whether you want to make this change in general, for all > platforms, so for now I have embedded it in an #if(n)def. I think we should do that on all platforms, yes. And you probably want to fix OSS_WaveInInit too. -- Alexandre Julliard julliard(a)winehq.com

Dec. 30, 2003

Re: Better fix for the GetTempFileName problem

by Alexandre Julliard

Mike Hearn <mike(a)theoretic.com> writes: > Index: files/file.c > =================================================================== > RCS file: /home/wine/wine/files/file.c,v > retrieving revision 1.197 > diff -u -r1.197 file.c > --- files/file.c 15 Dec 2003 20:15:20 -0000 1.197 > +++ files/file.c 25 Dec 2003 19:10:35 -0000 > @@ -922,7 +922,7 @@ > p = buffer + strlenW(buffer); > > /* add a \, if there isn't one and path is more than just the drive letter ... */ > - if ( !((strlenW(buffer) == 2) && (buffer[1] == ':')) > + if ( ((strlenW(buffer) == 2) && (buffer[1] == ':')) > && ((p == buffer) || (p[-1] != '\\'))) *p++ = '\\'; This is clearly not what was intended here, you'll need to investigate this some more (and write a test case). -- Alexandre Julliard julliard(a)winehq.com

Dec. 30, 2003

Re: Simple arguments check

by Alexandre Julliard

Mike Hearn <mike(a)theoretic.com> writes: > Index: dlls/shell32/pidl.c > =================================================================== > RCS file: /home/wine/wine/dlls/shell32/pidl.c,v > retrieving revision 1.94 > diff -u -r1.94 pidl.c > --- dlls/shell32/pidl.c 4 Nov 2003 04:21:01 -0000 1.94 > +++ dlls/shell32/pidl.c 25 Dec 2003 19:32:48 -0000 > @@ -1234,10 +1234,19 @@ > LPSHELLFOLDER shellfolder; > > TRACE_(shell)("(pidl=%p,%p)\n",pidl,pszPath); > - pdump(pidl); > > - if (!pidl) return FALSE; > + if (!pidl) { > + ERR_(shell)("argument check failed: pidl == null\n"); > + return FALSE; > + } > + > + if (!pszPath) { > + ERR_(shell)("argument check failed: pszPath == null\n"); > + return FALSE; > + } The ERRs are useless. If Windows does a NULL check, then we should do one too, without any error message; if Windows doesn't, then we shouldn't check at all. -- Alexandre Julliard julliard(a)winehq.com

Dec. 30, 2003