February 2009 - Wine-devel - list.winehq.org

re: WINEGATE.DLL: Wine gateway to native Unix libraries
by Dan Kegel 18 Feb '09

18 Feb '09

Very interesting. I'd been suggesting to ISVs that they create a single winelib dll and conditionally load that if present, but winegate.dll might be an appealing alternative. I don't think this really brings up any security considerations but it is a reminder that Windows programs under Wine have access to the entire Linux system just like Linux programs do. btw nice name, but it pulls up 7 million hits for me, not sure what you mean by "google doesn't reveal any other uses of the name". - Dan

8 17

Re: ntdll: Replace malloc() with RtlAllocateHeap()
by Rob Shearman 18 Feb '09

18 Feb '09

2009/2/17 Andrew Talbot <andrew.talbot(a)talbotville.com>: > Changelog: > ntdll: Replace malloc() with RtlAllocateHeap(). > > diff --git a/dlls/ntdll/server.c b/dlls/ntdll/server.c > index 145540f..0cade3f 100644 > --- a/dlls/ntdll/server.c > +++ b/dlls/ntdll/server.c > @@ -743,13 +743,13 @@ static void setup_config_dir(void) > struct stat st; > char *tmp_dir; > > - if (!(tmp_dir = malloc( p + 1 - config_dir ))) fatal_error( "out of memory\n" ); > + if (!(tmp_dir = RtlAllocateHeap( GetProcessHeap(), 0, p + 1 - config_dir ))) fatal_error( "out of memory\n" ); > memcpy( tmp_dir, config_dir, p - config_dir ); > tmp_dir[p - config_dir] = 0; > if (!stat( tmp_dir, &st ) && st.st_uid != getuid()) > fatal_error( "'%s' is not owned by you, refusing to create a configuration directory there\n", > tmp_dir ); > - free( tmp_dir ); > + RtlFreeHeap( GetProcessHeap(), 0, tmp_dir ); > } I'd be surprised if this worked, since setup_config_dir is called very early in the ntdll execution sequence, and RtlAllocateHeap itself will depend on server calls (NtAllocateVirtualMemory, NtCreateMutex, etc.) that depend on the server having started (i.e. after this function having already executed). -- Rob Shearman

1 0

Re: winetest: Annotate xmalloc() and xrealloc() with allocation size attribute.
by Steven Edwards 18 Feb '09

18 Feb '09

On Tue, Feb 17, 2009 at 12:51 PM, Francois Gouget <fgouget(a)free.fr> wrote: > --- > > I moved them after the windows.h include though in practice the needed > winnt.h has already been included by the time we include winetest.h. So > maybe windows.h should be nuked altogether... Conversely maybe using windows.h usage should be fixed and used more often. Wine is an oddball when it comes to win32 program with the excessive lengths it goes to, to avoid using windows.h. I am starting to think even avoiding it internally like we do causes more harm than good as far as being source compatible with MSVC. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

3 6

Re: [02/12] fusion: Add tests for the IAssemblyEnum interface.
by Alexandre Julliard 18 Feb '09

18 Feb '09

Hans Leidekker <hans(a)codeweavers.com> writes: > Some tests in James' original patch failed here, which I have fixed. I still see failures: ../../../tools/runtest -q -P wine -M fusion.dll -T ../../.. -p fusion_test.exe.so asmenum.c && touch asmenum.ok asmenum.c:430: Test failed: Expected "wine, Version=1.0.1.2, Culture=neutral, PublicKeyToken=123456789abcdef0" or "wine, Version=1.0.1.2, Culture=neutral, PublicKeyToken=16a3fcd171e93a8d", got "wine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=16a3fcd171e93a8d" asmenum.c:573: Test failed: Expected "wine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=16a3fcd171e93a8d", got "wine, Version=1.0.1.2, Culture=neutral, PublicKeyToken=123456789abcdef0" asmenum.c:586: Test failed: Expected "wine, Version=1.0.1.2, Culture=neutral, PublicKeyToken=123456789abcdef0" or "wine, Version=1.0.1.2, Culture=neutral, PublicKeyToken=16a3fcd171e93a8d", got "wine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=16a3fcd171e93a8d" make[2]: *** [asmenum.ok] Error 3 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [5/6]wininet: handle cookie expiration
by Alexandre Julliard 18 Feb '09

18 Feb '09

Aric Stewart <aric(a)codeweavers.com> writes: > + LPCWSTR ptr,ptr2; > + SYSTEMTIME tm; > + int i; > + > + memset(&tm,0,sizeof(tm)); > + > + ptr = expiry; > + for (i = 0; i < 7; i++) > + { > + if (strncmpiW(day[i],ptr,3)==0) > + { > + tm.wDayOfWeek = i; > + break; > + } > + } > + ptr += 5; > + tm.wDay = strtolW(ptr,(LPWSTR*)&ptr2,10); > + ptr = ptr2+1; You should handle the various possible parsing errors, not just assume that you have a well-formatted string. -- Alexandre Julliard julliard(a)winehq.org

3 2

Re: oleaut32(2/3): Implement VarDecFix
by Dmitry Timoshkov 18 Feb '09

18 Feb '09

"Juan Lang" <juan.lang(a)gmail.com> wrote: > + hr = VarR8FromDec((DECIMAL *)pDecIn, &dbl); According to PSDK VarR8FromDec() takes a const pointer to the 1st parameter, to it should be fixed instead of casting const out. Same for VarDecInt() patch. -- Dmitry.

1 0

Re: kernel32: add tests for recasing files
by Dmitry Timoshkov 18 Feb '09

18 Feb '09

"Austin English" <austinenglish(a)gmail.com> wrote: > + /* create a temporary file */ > + uUnique = GetTempFileNameA(tempdir, "pfx", 0, source); > + ok(uUnique != 0, "GetTempFileNameA error %d\n", GetLastError()); > + > + /* get the same filename as above with upper case > + prefix and without creating any file */ > + ret = GetTempFileNameA(tempdir, "PFX", uUnique, dest); > + ok(ret != 0, "GetTempFileNameA error %d\n", GetLastError()); > + > + /* MoveFile should be able to change the case of the letters */ > + ret = MoveFileA(source, dest); > + todo_wine { > + ok(ret, "MoveFileA: failed, error %d\n", GetLastError()); > + } The comment above about expected MoveFile behaviour is incorrect since the test doesn't test what it implies. What most likely happens is that MoveFile should be a noop if source and destination file names are the same, and in that case 'MoveFileA(source, source);' is enough to test. -- Dmitry.

1 0

Re: advapi32: GetNamedSecurityInfoExA Stub
by Dmitry Timoshkov 18 Feb '09

18 Feb '09

"Paul Bryan Roberts" <pbronline-wine(a)yahoo.co.uk> wrote: > I guess this stub falls in to the 'not obviously correct' category. > > I could do with some feedback on what might be an acceptable patch. It appears that GetNamedSecurityInfoExA signature doesn't match the MSDN/PSDK one. Also it's a common practice to simultaneously add both A and W versions, and add prototypes to an appropriate .h file. -- Dmitry.

3 5

Re: kernel32: Free profile before reloading
by Michael Karcher 17 Feb '09

17 Feb '09

Am Dienstag, den 17.02.2009, 09:19 +0100 schrieb Michael Karcher: > Should fix bug #17050 Doesn't do. Please ignore.

1 0

Re: GSoC 2009 coming up
by Kai Blin 17 Feb '09

17 Feb '09

On Tuesday 17 February 2009 04:41:11 Brian Vincent wrote: > On Sat, Feb 14, 2009 at 2:39 AM, Kai Blin <kai.blin(a)gmail.com> wrote: > > We should also investigate possible changes to the requirements (weekly > > reports to the mailing list come to mind). Maarten, any comments? > > My gut instinct was weekly reports would be a bad idea for students - of > course they're just going to procrastinate until the last month and then do > all the work at once. Yes, Kai, I realize you were the exception to that > rule. That's not going to work anyway. There's a mid-term evaluation you're going to get failed at if you didn't produce anything until the mid-term. :) > Then my second thought was: "Hey, if this was the real world their manager > would certainly be expecting progress reports. Therefore mentors should > too." And, it makes for simple updates to include for WWN issues. I > think it'd be interesting to weekly or bi-weekly reports, but I think > mentors will need to apply a little tactful pressure in order to get the > status report updates. My biggest motivation for requiring weekly status updates is that in the past years I had a hard time following the GSoC projects I was not involved with directly. At WorldForge, we required weekly reports to the mentor at first and then decided that the weekly reports should go to the developer mailing list. That kept everybody informed what was going on. Also, if the weekly reports don't only include "that's what I did last week" but also "this is my plan for the next week", students can get early feedback if whatever they're planning to do next looks like a bad idea to some other developer. It also helps integrating the students in the community, as they're not only talking to their mentor. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

2 1