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

Re: revert of a6c07ffba4b2b37d01affb4c39f032bb5f8d34bf
by Francois Gouget Feb. 20, 2009

Feb. 20, 2009

A little bit of explanation would be nice... -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ La terre est une bêta...

2 3

Re: fusion/tests: Do not use a fixed path to the assembly
by Nicolas Le Cam Feb. 19, 2009

Feb. 19, 2009

2009/2/20 Detlef Riekenberg <wine.dev(a)web.de>: > James: A fixed path is broken by design. > > This fix the remaining failure on w2k. > > The asmcache has more failures on win9x, but a fix for that > failures conflict with the patchset from Hans. > > > -- > > By by ... Detlef > > > > Hi Detlef, I've already sent a similar patch, see http://www.winehq.org/pipermail/wine-patches/2009-February/069647.html

1 0

Re: [13/13] fusion: Add tests for the IAssemblyEnum interface.
by Paul Vriens Feb. 19, 2009

Feb. 19, 2009

Hans Leidekker wrote: > -Hans > > > ------------------------------------------------------------------------ > > Hi Hans, These tests crash on Vista with .NET 3.5 (not sure about other platforms/.NET versions yet). The enum_gac_assemblies function relies on the fact that ffd.cFileName contains 2 underscores. On Vista however I see some assemblies with a different format for the cFileName like: 6.0.0.0_en_31bf3856ad364e35 This explains the (first) crash as we dereference a pointer. So doing something like this fixes that piece: else if (depth == 1) { - ptr = strstr(ffd.cFileName, "__"); + CHAR version[MAX_PATH]; + + lstrcpyA(version, ffd.cFileName); + ptr = strstr(version, "_"); *ptr = '\0'; - ptr += 2; + ptr = strrchr(ffd.cFileName, '_'); + ptr += 1; sprintf(buf, "Version=%s, Culture=neutral, PublicKeyToken=%s", - ffd.cFileName, ptr); + version, ptr); This seems to work fine but than it crashes again while trying to free the memory "HeapFree(GetProcessHeap(), 0, asmname->data);" in test_enumerate. Just ignoring those HeapFree's doesn't fix it as we crash again later on. -- Cheers, Paul.

2 3

Re: [4/5] dxgi: Convert DXGI_FORMAT values to WINED3DFORMAT values.
by Stefan Dösinger Feb. 19, 2009

Feb. 19, 2009

Am Donnerstag, 19. Februar 2009 17:03:37 schrieb Henri Verbeet: I haven't looked at all the different formats yet, just a general question: Why did you choose to keep the WINED3D formats and not use the DXGI formats in wined3d? I'm not saying that there's anything wrong with that, I'm just curious what lead to that decision. I was inclined to do it the other way around, mostly because of the generic and specific(ie SINT, UINT, SRGB) formats in DXGI.

2 1

Re: msctf/tests: Don't import uuid library cause it could break crosstest
by Austin English Feb. 19, 2009

Feb. 19, 2009

On Thu, Feb 19, 2009 at 9:21 AM, Nikolay Sivov <bunglehead(a)gmail.com> wrote: > Changelog: > - Don't import uuid library cause it could break crosstest > > >From 26890998dc20bd31c2d23b8b59dfaf664ca98dc0 Mon Sep 17 00:00:00 2001 > From: Nikolay Sivov <bunglehead(a)gmail.com> > Date: Thu, 19 Feb 2009 10:20:32 -0500 > Subject: Don't import uuid library cause it could break crosstest > > --- > dlls/msctf/tests/Makefile.in | 2 +- > dlls/msctf/tests/inputprocessor.c | 1 + > 2 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/dlls/msctf/tests/Makefile.in b/dlls/msctf/tests/Makefile.in > index 669f5a1..0d7aba8 100644 > --- a/dlls/msctf/tests/Makefile.in > +++ b/dlls/msctf/tests/Makefile.in > @@ -3,7 +3,7 @@ TOPOBJDIR = ../../.. > SRCDIR = @srcdir@ > VPATH = @srcdir@ > TESTDLL = msctf.dll > -IMPORTS = uuid ole32 user32 kernel32 > +IMPORTS = ole32 user32 kernel32 > > CTESTS = \ > inputprocessor.c > diff --git a/dlls/msctf/tests/inputprocessor.c b/dlls/msctf/tests/inputprocessor.c > index 200a0d4..2e71eec 100644 > --- a/dlls/msctf/tests/inputprocessor.c > +++ b/dlls/msctf/tests/inputprocessor.c > @@ -33,6 +33,7 @@ static ITfInputProcessorProfiles* g_ipp; > static LANGID gLangid; > > DEFINE_GUID(CLSID_FakeService, 0xEDE1A7AD,0x66DE,0x47E0,0xB6,0x20,0x3E,0x92,0xF8,0x24,0x6B,0xF3); > +DEFINE_GUID(CLSID_TF_InputProcessorProfiles, 0x33c53a50,0xf456,0x4884,0xb0,0x49,0x85,0xfd,0x64,0x3e,0xcf,0xed); > > static HRESULT initialize(void) > { > -- > 1.5.6.5 > > > > > AJ beat you to it: http://source.winehq.org/git/wine.git/?a=commitdiff;h=cd656fa7f68bc86f78be2… -- -Austin

2 1

Re: msctf/tests: Don't import uuid library cause it could break crosstest
by Paul Vriens Feb. 19, 2009

Feb. 19, 2009

Nikolay Sivov wrote: > Changelog: > - Don't import uuid library cause it could break crosstest > >>From 26890998dc20bd31c2d23b8b59dfaf664ca98dc0 Mon Sep 17 00:00:00 2001 > From: Nikolay Sivov <bunglehead(a)gmail.com> > Date: Thu, 19 Feb 2009 10:20:32 -0500 > Subject: Don't import uuid library cause it could break crosstest > > --- > dlls/msctf/tests/Makefile.in | 2 +- > dlls/msctf/tests/inputprocessor.c | 1 + > 2 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/dlls/msctf/tests/Makefile.in b/dlls/msctf/tests/Makefile.in > index 669f5a1..0d7aba8 100644 > --- a/dlls/msctf/tests/Makefile.in > +++ b/dlls/msctf/tests/Makefile.in > @@ -3,7 +3,7 @@ TOPOBJDIR = ../../.. > SRCDIR = @srcdir@ > VPATH = @srcdir@ > TESTDLL = msctf.dll > -IMPORTS = uuid ole32 user32 kernel32 > +IMPORTS = ole32 user32 kernel32 > > CTESTS = \ > inputprocessor.c > diff --git a/dlls/msctf/tests/inputprocessor.c b/dlls/msctf/tests/inputprocessor.c > index 200a0d4..2e71eec 100644 > --- a/dlls/msctf/tests/inputprocessor.c > +++ b/dlls/msctf/tests/inputprocessor.c > @@ -33,6 +33,7 @@ static ITfInputProcessorProfiles* g_ipp; > static LANGID gLangid; > > DEFINE_GUID(CLSID_FakeService, 0xEDE1A7AD,0x66DE,0x47E0,0xB6,0x20,0x3E,0x92,0xF8,0x24,0x6B,0xF3); > +DEFINE_GUID(CLSID_TF_InputProcessorProfiles, 0x33c53a50,0xf456,0x4884,0xb0,0x49,0x85,0xfd,0x64,0x3e,0xcf,0xed); > > static HRESULT initialize(void) > { Hi Already fixed in Git: http://source.winehq.org/git/wine.git/?a=commit;h=cd656fa7f68bc86f78be21c67… -- Cheers, Paul.

1 0

Re: msctf crosstest build failed
by Nicolas Le Cam Feb. 19, 2009

Feb. 19, 2009

2009/2/19 Nikolay Sivov <bunglehead(a)gmail.com>: > Nicolas Le Cam wrote: >> >> 2009/2/18 Nikolay Sivov <bunglehead(a)gmail.com>: >> >>> >>> Building today crosstests I've got: >>> >>> i586-mingw32msvc-gcc -c -I. -I. -I../../../include -I../../../include >>> -g -O2 -o inputprocessor.cross.o inputprocessor.c >>> i586-mingw32msvc-gcc -c -I. -I. -I../../../include -I../../../include >>> -g -O2 -o testlist.cross.o testlist.c >>> i586-mingw32msvc-gcc inputprocessor.cross.o testlist.cross.o -o >>> msctf_crosstest.exe -L../../../dlls -L../../../dlls/uuid >>> -L../../../dlls/ole32 -L../../../dlls/user32 -L../../../dlls/kernel32 >>> -luuid -lole32 -luser32 -lkernel32 >>> inputprocessor.cross.o: In function `initialize': >>> /home/mrlarch/wine-git/dlls/msctf/tests/inputprocessor.c:41: undefined >>> reference to `_CLSID_TF_InputProcessorProfiles' >>> collect2: ld returned 1 exit status >>> make[2]: *** [msctf_crosstest.exe] Error 1 >>> make[2]: Leaving directory `/home/mrlarch/wine-git/dlls/msctf/tests' >>> make[1]: *** [msctf/tests/__crosstest__] Error 2 >>> make[1]: Leaving directory `/home/mrlarch/wine-git/dlls' >>> make: *** [dlls/__crosstest__] Error 2 >>> >>> This outputs after: >>> make clean >>> ./configure >>> make depend && make >>> make crosstest >>> >>> What seems to be a problem? >>> >>> >>> >>> >> >> Same here. Can't find a solution. >> Perhaps it's because libuuid exports the CLSID as >> CLSID_TF_InputProcessorProfiles instead of >> _CLSID_TF_InputProcessorProfiles but I don't know how to fix. >> > > It's normal, is a kind of naming convention, don't know how to call it > right, but it's ok. >> >> Does building it with winegcc instead of ar / ranlib could fix the problem >> ? >> > > Native test builds without any problem. What do you mean? > As I checked uuid isn't imported anywhere else in test suite, inline guid > definitions used instead. > So if nobody knows why this happens I propose to patch msctf/tests not to > use uuid. > Now I'm setting up a system with rather fresh Lenny, so you could send this > patch. > > Just found that Alexandre committed something related to that last year. It seems to be a problem with MingW, see [1]. I will send a fix this evening. [1] http://source.winehq.org/git/wine.git/?a=commit;h=79c64acc7b5f9f9de07592fec…

2 1

msctf crosstest build failed
by Nikolay Sivov Feb. 19, 2009

Feb. 19, 2009

Building today crosstests I've got: i586-mingw32msvc-gcc -c -I. -I. -I../../../include -I../../../include -g -O2 -o inputprocessor.cross.o inputprocessor.c i586-mingw32msvc-gcc -c -I. -I. -I../../../include -I../../../include -g -O2 -o testlist.cross.o testlist.c i586-mingw32msvc-gcc inputprocessor.cross.o testlist.cross.o -o msctf_crosstest.exe -L../../../dlls -L../../../dlls/uuid -L../../../dlls/ole32 -L../../../dlls/user32 -L../../../dlls/kernel32 -luuid -lole32 -luser32 -lkernel32 inputprocessor.cross.o: In function `initialize': /home/mrlarch/wine-git/dlls/msctf/tests/inputprocessor.c:41: undefined reference to `_CLSID_TF_InputProcessorProfiles' collect2: ld returned 1 exit status make[2]: *** [msctf_crosstest.exe] Error 1 make[2]: Leaving directory `/home/mrlarch/wine-git/dlls/msctf/tests' make[1]: *** [msctf/tests/__crosstest__] Error 2 make[1]: Leaving directory `/home/mrlarch/wine-git/dlls' make: *** [dlls/__crosstest__] Error 2 This outputs after: make clean ./configure make depend && make make crosstest What seems to be a problem?

3 4

Need help on couple of patches
by Igor Tarasov Feb. 18, 2009

Feb. 18, 2009

Hello! I've written 2 patches, and I need advice on both of them. First one is here: http://www.winehq.org/pipermail/wine-patches/2009-February/069463.html It's a single-line patch that adds forwarding notification that was omitted in wine code. This fix looks pretty simple, but it included lots of reading/testing/debugging, and here is what I came with. And as I told there it fixes one wine bugzilla bug. But as I see, it was not comitted, so I am asking for advice: what could I do in order to make it go through? Another patch is here: http://bugs.winehq.org/show_bug.cgi?id=12701 The patch adresses 3 problems that all together fix that bug. My question there was if I should send it in one patch or in several. But it seems that no one have noticed that post. Any help and advice is appreciated. Thanks.

5 10

Re: [8/9] setupapi: implement SetupPromptForDiskA by wrapping around W version
by Juan Lang Feb. 18, 2009

Feb. 18, 2009

Hi Ricardo, + DialogTitleW = MultiByteToUnicode(DialogTitle, CP_UTF8); You should be using CP_ACP here, not CP_UTF8. Same applies to remaining character conversions. In fact, you could use strdupAtoW instead. --Juan

2 1

Wine & viruses
by Martin Hinner Feb. 18, 2009

Feb. 18, 2009

Hi, I will start one more hot discussion. Sorry if it was discussed earlier, I am not regular reader of this mailing-list. I tried to search google, found several discussions, but no real result: http://www.linux.com/feature/42031 http://www.vnunet.com/vnunet/news/2116150/linux-experts-wine-virus https://bugs.launchpad.net/ubuntu/+source/wine/+bug/256880 wine-devel mailing list google results The problem is that some (almost all?) distributions simply execute .exe file when you click on it. I was amazed when testing JTAGTest on Linux! This is in my opinion quite big issue as ordinary users do not have problem clicking on "New folder.exe" on their flashdisk etc. It's good that wine is so compatible that it runs even viruses, but I think there should be some (optional) protection. The biggest problem seem to be removable media, in many distributions mounted under /mnt or /media. Please think about this twice before writing "problem is in Microsoft not in Wine", "it's not a bug but feature", etc. It's too childish IMO. - What about creating a configurable list of directories, where wine would first ask if you really want to execute the program? It would be up to distribution what is set-up by default. - It's long time I have been interested in viruses, but I think that 90% of most common virus infected/trojan .exe files can be pretty easily identified. Almost every modern virus is trying to connect to the internet either by opening socket or using few standard DLL functions. What about adding some checks to Wine that would check the calling function code sample against some small database to see if this is a virus and ask user? Or adding some "API" functions to allow someone to write such program? I have done quite a lot of work with PE loading and code modification and I think it could be moved to level when it works without crashing anything. I understand, that none of this is system solution. But are anti-viruses system solution? They solve real world problem. Regarding API I have mentioned above I mean some hookdll() function that would re-direct GetProcAddress() or PE loader for defined functions, i.e.: http://www.codeguru.com/cpp/w-p/dll/hooking/article.php/c3639 http://www.codeguru.com/cpp/w-p/dll/hooking/article.php/c127 Obviously this would have to be global for wine (libwine.so?), not as a PE exported API function. Pre-loaded "antivirus" would be able to hook Winsock functions + some other important stuff and then check if the binary code is not on the list. Martin

9 13

Re: [1/9] setupapi: add header information for SetupPromptForDisk
by Juan Lang Feb. 18, 2009

Feb. 18, 2009

Hi Ricardo, > dlls/setupapi/setupapi_private.h | 11 +++++++++++ > include/setupapi.h | 14 +++++++++----- I'd suggest you have the changes to setupapi.h as one patch on their own. The changes to setupapi_private.h can be combined with the changes to the .rc file (patch 2 in your series), along with your patch to create the new dialog.c file (patch 3 in your series), and your patch to create a do-nothing dialog (patch 4 in your series.) In this way, each patch has a single functional change. If you do it as I suggest, patch 1 will change the public header file. Patch 2 will introduce a new dialog. The remaning patches seem split appropriately, so you'd end up with a 7 patch series. --Juan

1 0

Re: Wine64 - msvcrt dll test fix
by Ricardo Filipe Feb. 18, 2009

Feb. 18, 2009

this was commited already today. :) http://source.winehq.org/git/wine.git/?a=shortlog 2009/2/18 Juan M. Navarro <juan.m.navarro(a)gmail.com> > Resending as plain text. > > Thanks, > Juan > > On Tue, Feb 17, 2009 at 12:19 PM, Juan M. Navarro > <juan.m.navarro(a)gmail.com> wrote: > > Hello all! > > > > This is my first patch ever, and first open source contribution ever. > > > > The strlen function returns a size_t that represents an unsigned int in > > 32-bit environments, and an unsigned long in 64-bit environments. The > strlen > > function call has been changed to an lstrlen function call, which always > > returns an integer. > > > > I am a grad student at UCLA that has just started working on porting Wine > to > > 64-bit environments. > > > > I attest to not having seen any Microsoft source, or dissasembling > > Microsoft's DLL's. > > > > Thanks, > > > > Juan > > > >

1 0

Re: Status of USB driver support?
by emiliano esposito Feb. 18, 2009

Feb. 18, 2009

Alexander Morozov wrote: >> If that USB Key is not of a supportable kind, then I apologize for >> asking. >> > > I think you should try. > Thanks. I tried this way: git clone git://source.winehq.org/git/wine.git ~/wine-git git-am 0001... git-am 0002... ./tools/wineinstall When launching a Wine application, I get some errors, I think this is the important one: err:winedevice:ServiceMain driver L"Usbhub" failed to load I have installed the Key driver but not yet added the registry keys. Should I do that or something else first? Thanks.

1 0

Status of USB driver support?
by Dan Kegel Feb. 18, 2009

Feb. 18, 2009

Is http://wiki.winehq.org/USB up to date? I could have sworn that Alexander Morozov had submitted a new version of his patch, but I can't find it.

5 7

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

Feb. 18, 2009

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 Feb. 18, 2009

Feb. 18, 2009

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 Feb. 18, 2009

Feb. 18, 2009

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 Feb. 18, 2009

Feb. 18, 2009

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 Feb. 18, 2009

Feb. 18, 2009

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 Feb. 17, 2009

Feb. 17, 2009

"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 Feb. 17, 2009

Feb. 17, 2009

"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 Feb. 17, 2009

Feb. 17, 2009

"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 Feb. 17, 2009

Feb. 17, 2009

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 Feb. 17, 2009

Feb. 17, 2009

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