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

Re: advapi32.dll: Reduce Registry access to MAXIMUM_ALLOWED wherever possible

by Rob Shearman

2009/11/27 Paul Chitescu <paulc(a)voip.null.ro>: > Changelog: > advapi32.dll: Reduce Registry access to MAXIMUM_ALLOWED wherever possible > > Makes read operation succeed on read/only Registry keys. Needs tests to show that this behaviour matches that on Windows. You should be able to achieve this by setting an appropriate security descriptor on the registry key before calling the function you are changing. However, the change to get_special_root_hkey looks fine to me. The rest of your patch isn't easy to review because you haven't generated the diff with the "-p" option. -- Rob Shearman

Nov. 28, 2009

Re: Wine programs - replicating bad design/bugs

by Jerome Leclanche

The issue with notepad is, the search menu is completely different in Windows notepad (AFAIK it's in Edit and there's no search menu). Fair enough for 18622. J. Leclanche / Adys On Sat, Nov 28, 2009 at 6:20 PM, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: > Jerome Leclanche wrote: >> http://bugs.winehq.org/show_bug.cgi?id=20844 > IMHO this could be done, however this will be a "hidden feature". You can't > add that to the menu - it will break programs that "script" notepad (yes > there are programs like that). > >> ** http://bugs.winehq.org/show_bug.cgi?id=18622 > This error coming from API layer, not regedit. Windows' registry API is > case-insensitive and does not allow that. As well as wineserver handles > registry as case-insensitive. Altering API means breaking programs. > > Vitaliy. > >

Nov. 28, 2009

Re: Corrections for signal handlers

by Markus Elfring

> And don't ask me to actually think about what I'm doing, I am still open for further discussions. > it's too hard to figure out how to print a string and a number without using printf(). This data display (e. g. for the input command and line number) is generally not a problem. But the situation is different in the context of a signal handler because of the limited set of async-signal-safe functions. Regards, Markus

Nov. 28, 2009

Re: Corrections for signal handlers

by Vitaliy Margolen

Don't CC wine-patches. Markus Elfring wrote: >> Original printed more useful information. >> Just dropping it in sake of "correctness" is wrong. >> You'll have to come up with something that prints the same >> or don't touch it. > > I am aware of the desire to get some data for easier program debugging conveniently. > I have got an opposite opinion. I am curious if more software developers would like to care for complete async-signal-safety. > This will not happen at the moment because of conflicting expectations. > I assume that the involved implementation details will be reconsidered some day in the future. So basically you saying: ---------- I don't care what you had in there, and I don't care how useful that information was to you. I care about some highly hypothetical error cases that might never happen in your program but just because theoretically they can happen I'll remove some code that looks wrong. And don't ask me to actually think about what I'm doing, it's too hard to figure out how to print a string and a number without using printf(). So I'll leave that to you to code. ----------- No wonder you receive such a "welcome" from other projects you've tried to "improve" before. Vitaliy.

Nov. 28, 2009

Re: Corrections for signal handlers

by Markus Elfring

> Original printed more useful information. I am aware of the desire to get some data for easier program debugging conveniently. > Just dropping it in sake of "correctness" is wrong. I have got an opposite opinion. I am curious if more software developers would like to care for complete async-signal-safety. > You'll have to come up with something that prints the same This will not happen at the moment because of conflicting expectations. > or don't touch it. I assume that the involved implementation details will be reconsidered some day in the future. Regards, Markus

Nov. 28, 2009

Re: Corrections for signal handlers

by Vitaliy Margolen

Markus Elfring wrote: > Hello, > > Some signal handler implementations are also affected by technical details that are described in an article by Justin Pincar. > https://www.securecoding.cert.org/confluence/display/seccode/SIG30-C.+Call+… > Your code looks even worse then your arguments for "correct" codding practices. > -static int watchdog; > +static sig_atomic_t watchdog; Don't do this, you've been told to leave it alone. > - fprintf( stderr, "wineserver crashed, please enable coredumps (ulimit -c unlimited) and restart.\n"); > + char const message[] = "wineserver crashed, please enable coredumps (ulimit -c unlimited) and restart.\n"; Should be "static const char" in that exact order. > + > + (void) write(STDERR_FILENO, message, sizeof(message) - 1); What's "(void)" doing here? Yes we do ignore returned states here and in 10000s or other places. Don't do that. > + (void) fsync(STDERR_FILENO); Why do you need sync here? > abort(); > --- a/tools/wmc/wmc.c Wine fix per program please. You'll have to split this into 3 separate patches. > static void segvhandler(int sig) > { > -<----->fprintf(stderr, "\n%s:%d: Oops, segment violation\n", input_name, line_number); > -<----->fflush(stdout); > -<----->fflush(stderr); > + char const message[] = "\nOops, segment violation\n"; Same as above - should be "static const char" in that exact order. > + > + (void) write(STDERR_FILENO, message, sizeof(message) - 1); > + (void) fsync(STDOUT_FILENO); > + (void) fsync(STDERR_FILENO); Remove bogus "(void)". > <----->abort(); > } Original printed more useful information. Just dropping it in sake of "correctness" is wrong. You'll have to come up with something that prints the same or don't touch it. Original used tabs (8-spaces) your patch uses 4-space indentation. Either keep the file's formatting or stick to 4-space indentation but DO NOT mix and match both inside one function. Same applies to tools/wrc/wrc.c Vitaliy.

Nov. 28, 2009

Re: Wine programs - replicating bad design/bugs

by Vitaliy Margolen

Jerome Leclanche wrote: > http://bugs.winehq.org/show_bug.cgi?id=20844 IMHO this could be done, however this will be a "hidden feature". You can't add that to the menu - it will break programs that "script" notepad (yes there are programs like that). > ** http://bugs.winehq.org/show_bug.cgi?id=18622 This error coming from API layer, not regedit. Windows' registry API is case-insensitive and does not allow that. As well as wineserver handles registry as case-insensitive. Altering API means breaking programs. Vitaliy.

Nov. 28, 2009

re: Corrections for signal handlers

by Dan Kegel

I'm not sure this change does what you think: - fflush(stdout); ... + (void) fsync(STDOUT_FILENO); The real problem with your change is that *we don't care* whether the output of wineserver is garbled, because it is low priority debugging information, and I've never seen it garbled in practice. In short, it's not worth the time reviewing the patch. So while we appreciate your effort to improve the correctness of Wine's code, we would prefer it if you chose a more useful target. Also, Wine's patch review system is reputation-based. Your best avenue for getting pedantic corrections accepted is to get some pragmatic improvements accepted first. You might then be able to use some of your earned karma points on your favorite bikeshed problem. - Dan

Nov. 28, 2009

Re: Whitespace cleanups

by Jerome Leclanche

I was just working on shell32/shlview.c: ShellView_OnNotify. There is so much mixing between tabs, spaces, different indent levels, trailing whitespace and what not that the code is properly unreadable. git-blame is one thing, but when it goes as far as almost preventing a developer to make changes... J. Leclanche / Adys On Fri, Nov 27, 2009 at 7:27 AM, Ken Thomases <ken(a)codeweavers.com> wrote: > On Nov 26, 2009, at 10:15 AM, Francois Gouget wrote: > >> On Wed, 25 Nov 2009, Ken Thomases wrote: >> [...] >>> >>> One important reason to avoid whitespace-only changes is it makes >>> git-blame essentially useless for finding the real source of >>> functional changes >> >> Such changes don't make git-blame useless. They just make it a bit >> harder to use. >> >> Let's say your 'git-blame dlls/mshtml/tests/dom.c' leads you to commit >> 1e4412d7 which, by looking at it, you decide is a false positive. Then >> you do: >> >> $ git cat-file -p 1e4412d7 >> tree ea3b2e117b383ade8afc7cc9bf534c48faf891c7 >> parent 44f520a5b6f2bd6ec6da8793177711e57bda9c72 >> author Francois Gouget <fgouget(a)free.fr> 1258539107 +0100 >> committer Alexandre Julliard <julliard(a)winehq.org> 1258553736 +0100 >> >> mshtml/tests: Add a trailing '\n' to ok() calls. >> >> Then you run git-blame again: >> >> git blame 44f520a5 dlls/mshtml/tests/dom.c >> >> And continue the analysis until you find the right culprit. > > Um, it's just easier to add a caret ('^') to the commit ID. > > git blame 1e4412d7^ dlls/mshtml/tests/dom.c > > I'm well aware of this technique, but if it doesn't make git-blame useless, > it makes it a hell of a lot less useful, especially if whitespace-only > changes become non-rare. I wasn't aware of and haven't tried Kai's > suggestion of using the -w switch. > > -Ken > > > >

Nov. 28, 2009

Wine programs - replicating bad design/bugs

by Jerome Leclanche

Ok, posting here to get a broader feedback on the issue. Recently, another bug* was closed about an enhancement to a wine program - a minor feature not present on Windows. This is an issue I've seen brought up before, and which I've brought up myself**. As far as the win32 api goes, I can totally agree on dysfunctions that need to be replicated. However I find this unnecessary for the wine programs (notepad, wordpad, regedit, any or more). The idea behind bug 20844 was to have a better integration with the desktop, where Shift-F3 is a common keybind for "Search previous...". The only problem with this kind of mindset is "where should we stop with new features?". IMHO, the issue behind the two bugs linked below is only a matter of better integration, better design. I can also understand how some developers' goal is to close bugs, sometimes disregarding the fact there is a problem to deal with before then. * http://bugs.winehq.org/show_bug.cgi?id=20844 ** http://bugs.winehq.org/show_bug.cgi?id=18622 J. Leclanche PS. In bug 18622, I'm not talking about a case-insensitive registry, but for the key being actually renamed.

Nov. 28, 2009

Re: dlls/kernel32/path.c: Fix return values for UNC pathnames in GetLongPathNameW

by Paul Vriens

On 11/24/2009 02:41 PM, Alexandre Hardy wrote: > The MSDN: > http://msdn.microsoft.com/en-us/library/aa364980(VS.85).aspx > states that GetLongPathNameW returns the length of the string > required to hold the pathname if the buffer is too small to hold > the path. In the case where the buffer is too small, the filename > should not be stored in the buffer. > > This ensures that the buffer is not written to (for UNC pathnames) > if the buffer is not large enought to store the path. > > Kind regards > Alexandre > Hi Alexandre, Patches should go to wine-patches unless your asking for some guidance or comments. This one should also be accompanied with some tests. -- Cheers, Paul.

Nov. 28, 2009

Re: New winetricks 20091125: new verbs ie7, alsa, fbo, pbuffer, ...

by Louis Lenders

Dan Kegel <dank <at> kegel.com> writes: > > Pie's in the oven, time for another winetricks release. > Could it be possible to "fix" mdac as well? Because of wine now having a more or less stubbed oledb32.dll, apps that need mdac don't run properly anymore. Simple solution is to set oledb32 to native, before the mdac installer is started, (and leave it to native afterwards) Could that be added to winetricks?

Nov. 27, 2009

Re: comctl32: Implementation the WM_GETTEXT processing of datetime control

by Nikolay Sivov

Ilya Shpigor wrote: > +static INT > +DATETIME_GetText (DATETIME_INFO *infoPtr, INT count, LPWSTR dst) > +{ > + WCHAR buf[80]; > + int i; > + > + if(!count) return 0; > + > + dst[0] = 0; > + for (i = 0; i < infoPtr->nrFields; i++) > + { > + DATETIME_ReturnTxt(infoPtr, i, buf, sizeof(buf)/sizeof(buf[0])); > + if ((strlenW(dst) + strlenW(buf)) <= count) > + strcatW(dst, buf); > + else break; > + } > + return strlenW(dst); > +} > I don't think it's a right way. You probably should use window text instead updating it on every change, see how GetWindowText is implemented. > @@ -674,6 +675,10 @@ static void test_wm_set_get_text(void) > ret = SendMessage(hWnd, WM_GETTEXT, sizeof(buff), (LPARAM)buff); > ok(strcmp(buff, a_str) != 0, "Expected text not to change, got %s\n", buff); > > + GetSystemTime(&stime); > + sprintf(time, "%d.%d.%d", stime.wDay, stime.wMonth, stime.wYear); > + ok(!strcmp(buff, time), "Expected %s, got %s\n", time, buff); > + > DestroyWindow(hWnd); > } > Test is definitely wrong. You can't expect DD.MMMM.YYYY pattern here, it's locale dependent.

Nov. 27, 2009

windows shutdown process

by Vincent Povirk

In order to find the correct fix for bug 18753, I've been examining the shutdown process on Windows. I have written a program that logs the messages sent to it, and I've run it on Windows 7. What I found was that a shutdown produces the following sequence of events: * We get a 0x3b message. DefWindowProc sends a WM_QUERYENDSESSION message. We return 1, allowing the session to end. * We get another 0x3b message, which leads to a WM_ENDSESSION. * Nothing else happens, but for some reason the program exits. I added a trace after the message loop returns to see if the program gets a WM_QUIT. It doesn't. Apparently, my test program was killed. I tried changing the window proc so that it loops infinitely when it gets WM_ENDSESSION. Windows 7 sees this as "blocking shutdown". (Naturally, it responds the same way if I return 0 from WM_QUERYENDSESSION.) This leads me to believe that Windows 7, when shutting down, immediately kills any process that returns from a WM_ENDSESSION message. Does that seem sane? I've posted my test program (source code and .exe file) at http://madewokherd.nfshost.com/msgtest.zip, and I'd like to hear if other Windows versions behave the same way Windows 7 does. -- Vincent Povirk

Nov. 27, 2009

Re: Commit 05c788ac6f464b75c2a55c847a91d3a79261ca8e causes tooltip functions in e-Sword to stop functioning

by Austin English

On Fri, Nov 27, 2009 at 8:42 AM, James McKenzie <jjmckenzie51(a)earthlink.net> wrote: > Nikolay Sivov wrote: >> James McKenzie wrote: >>> All >>> >>> Commit 05c788ac6f464b75c2a55c847a91d3a79261ca8e richedit: Used ITextHost >>> methods to avoid using window handle directly caused the tooltips popups >>> to stop functioning in e-Sword. >>> >>> Has this been corrected in later Wine releases? I am at wine-1.1.14 >>> with integrating the EM_FORMATRANGE patch. >>> >>> Thank you. >>> >>> James McKenzie >>> >> Did you file a bug report got that? >> >> > Nikolay: > > I don't want to file a bug report if it is already fixed. I'll continue > to work forward and see if the bug still exists. If it does, the report > goes in. You should check that yourself in git before e-mailing everyone in wine-devel about it... -- -Austin

Nov. 27, 2009

Re: Commit 05c788ac6f464b75c2a55c847a91d3a79261ca8e causes tooltip functions in e-Sword to stop functioning

by Michael Stefaniuc

James, James McKenzie wrote: > Nikolay Sivov wrote: >> James McKenzie wrote: >>> Commit 05c788ac6f464b75c2a55c847a91d3a79261ca8e richedit: Used ITextHost >>> methods to avoid using window handle directly caused the tooltips popups >>> to stop functioning in e-Sword. >>> >>> Has this been corrected in later Wine releases? I am at wine-1.1.14 >>> with integrating the EM_FORMATRANGE patch. >>> >>> Thank you. >>> >>> James McKenzie >>> >> Did you file a bug report got that? >> >> > Nikolay: > > I don't want to file a bug report if it is already fixed. I'll continue > to work forward and see if the bug still exists. If it does, the report > goes in. wine-1.1.14 is pretty old. There are 109 commits since then that touch riched20; see the output of the below command for the details: git log wine-1.1.14..origin dlls/riched20/ bye michael

Nov. 27, 2009

Re: Commit 05c788ac6f464b75c2a55c847a91d3a79261ca8e causes tooltip functions in e-Sword to stop functioning

by James McKenzie

Nikolay Sivov wrote: > James McKenzie wrote: >> All >> >> Commit 05c788ac6f464b75c2a55c847a91d3a79261ca8e richedit: Used ITextHost >> methods to avoid using window handle directly caused the tooltips popups >> to stop functioning in e-Sword. >> >> Has this been corrected in later Wine releases? I am at wine-1.1.14 >> with integrating the EM_FORMATRANGE patch. >> >> Thank you. >> >> James McKenzie >> > Did you file a bug report got that? > > Nikolay: I don't want to file a bug report if it is already fixed. I'll continue to work forward and see if the bug still exists. If it does, the report goes in. James McKenzie

Nov. 27, 2009

Re: Commit 05c788ac6f464b75c2a55c847a91d3a79261ca8e causes tooltip functions in e-Sword to stop functioning

by Nikolay Sivov

James McKenzie wrote: > All > > Commit 05c788ac6f464b75c2a55c847a91d3a79261ca8e richedit: Used ITextHost > methods to avoid using window handle directly caused the tooltips popups > to stop functioning in e-Sword. > > Has this been corrected in later Wine releases? I am at wine-1.1.14 > with integrating the EM_FORMATRANGE patch. > > Thank you. > > James McKenzie > Did you file a bug report got that?

Nov. 27, 2009

Commit 05c788ac6f464b75c2a55c847a91d3a79261ca8e causes tooltip functions in e-Sword to stop functioning

by James McKenzie

All Commit 05c788ac6f464b75c2a55c847a91d3a79261ca8e richedit: Used ITextHost methods to avoid using window handle directly caused the tooltips popups to stop functioning in e-Sword. Has this been corrected in later Wine releases? I am at wine-1.1.14 with integrating the EM_FORMATRANGE patch. Thank you. James McKenzie

Nov. 27, 2009

Re: [4/4] ntdll: partially support HEAP_DISABLE_COALESCE_ON_FREE, allows us to detect use-after-free

by Dan Kegel

Don't apply this one yet, just found a problem with it. On Tue, Nov 24, 2009 at 6:20 PM, Dan Kegel <dank(a)kegel.com> wrote: > This adds something like support for > HEAP_DISABLE_COALESCE_ON_FREE. > If the GlobalFlags registry entry has the > 200000 bit set, freed blocks are set > aside for a while rather than immediately > being released for reuse. This allows > us to poison them and check for use-after-free > or double-free errors, and report them as heap corruption. > > If you're running Valgrind, you get an immediate error > and stack trace for any of these heap corruption events, > which was the motivation for the patch series. > But the patches are useful even without valgrind. > > The number of blocks kept out of circulation is > 5000 by default, but can be set via an environment > variable. It ought to have a limit on number of bytes, > too, but this seemed enough for the moment. >

Nov. 27, 2009

Re: Whitespace cleanups

by Ken Thomases

On Nov 26, 2009, at 10:15 AM, Francois Gouget wrote: > On Wed, 25 Nov 2009, Ken Thomases wrote: > [...] >> One important reason to avoid whitespace-only changes is it makes >> git-blame essentially useless for finding the real source of >> functional changes. > > Such changes don't make git-blame useless. They just make it a bit > harder to use. > > Let's say your 'git-blame dlls/mshtml/tests/dom.c' leads you to commit > 1e4412d7 which, by looking at it, you decide is a false positive. Then > you do: > > $ git cat-file -p 1e4412d7 > tree ea3b2e117b383ade8afc7cc9bf534c48faf891c7 > parent 44f520a5b6f2bd6ec6da8793177711e57bda9c72 > author Francois Gouget <fgouget(a)free.fr> 1258539107 +0100 > committer Alexandre Julliard <julliard(a)winehq.org> 1258553736 +0100 > > mshtml/tests: Add a trailing '\n' to ok() calls. > > Then you run git-blame again: > > git blame 44f520a5 dlls/mshtml/tests/dom.c > > And continue the analysis until you find the right culprit. Um, it's just easier to add a caret ('^') to the commit ID. git blame 1e4412d7^ dlls/mshtml/tests/dom.c I'm well aware of this technique, but if it doesn't make git-blame useless, it makes it a hell of a lot less useful, especially if whitespace-only changes become non-rare. I wasn't aware of and haven't tried Kai's suggestion of using the -w switch. -Ken

Nov. 27, 2009

Re: [PATCH] kernel32: Respect the LANG environment variable on Mac OS.

by Ken Thomases

On Nov 26, 2009, at 12:31 AM, Vitaliy Margolen wrote: > Ken Thomases wrote: >> Setting LC_ALL would achieve that, plus override the various other >> locale >> categories. Set LANG is the wrong approach, in my opinion. > > However this is not the way Wine works on all other platforms. Sure it is, if you consider the user preferences to be setting the LC_* variables. On Linux, if the LC_* variables are set, then setting LANG does nothing. LANG is, always and everywhere, a fallback, not an override. This is true for how Wine works on Linux and Mac OS X and everywhere else. I see no inconsistency. On Nov 26, 2009, at 12:58 AM, Dmitry Timoshkov wrote: > "Ken Thomases" <ken(a)codeweavers.com> wrote: > >> If you as a user want to override the language that Wine displays, >> you can set LC_MESSAGES in your environment rather than LANG. >> Setting LC_ALL would achieve that, plus override the various other >> locale categories. Set LANG is the wrong approach, in my opinion. > > In the most cases what user wants is not just change the UI language > (which setting the LC_MESSAGES does) but also change the locale (i.e. > input/output code page), that's where LANG should be used. No, that's where setting LC_ALL should be used. > LC_MESSAGES hack adds more confusion IMO than really helps. Except that the vast, vast majority of Mac users will never touch (or even think about) the LANG or LC_* variables. For them, the current code does the right thing, even for the case where their preferred language is set to something other than their formats region. Letting LANG override their system settings would produce incorrect results for those users and force them to think about and use LANG or LC_ALL where they otherwise wouldn't. I see no upside at all to changing LANG into an override where that's not how it functions in any other context. Regards, Ken

Nov. 27, 2009

Re: New valgrind results, this time with overrun checks and lots of new errors.

by Dan Kegel

On Fri, Nov 20, 2009 at 9:02 AM, Nikolay Sivov <bunglehead(a)gmail.com> wrote: > Dan Kegel wrote: >> http://kegel.com/wine/valgrind/logs/2009-11-18-21.51/diff-comctl32_tab.txt >> http://kegel.com/wine/valgrind/logs/2009-11-18-21.51/vg-comctl32_tab.txt >> show a more inscrutable error: >> Invalid write of size 4 >> at TAB_SetCurSel (tab.c:255) >> by TAB_WindowProc (tab.c:3367) >>... > This shouldn't be a case for today git - see commit > 3371ba9f73367572693589905ed57af87b747b54. > > And thanks a lot for these test results, I'm waiting for automated daily > runs a lot... Here's the next run: http://kegel.com/wine/valgrind/logs/2009-11-26-06.08/vg-comctl32_header.txt Conditional jump or move depends on uninitialised value(s) at winetest_vok (test.h:306) by winetest_ok (test.h:331) by test_hds_nosizing (header.c:1303) by func_header (header.c:1869) by run_test (test.h:535) by main (test.h:585) Uninitialised value was created by a stack allocation at test_hds_nosizing (header.c:1261) Conditional jump or move depends on uninitialised value(s) at HEADER_IsItemFixed (header.c:226) by HEADER_InternalHitTest (header.c:674) by HEADER_HitTest (header.c:1292) by HEADER_WindowProc (header.c:2065) by ??? (library.h:159) by call_window_proc (winproc.c:469) by WINPROC_CallProcAtoW (winproc.c:1023) by CallWindowProcA (winproc.c:2299) by header_subclass_proc (header.c:415) by ??? (library.h:159) by call_window_proc (winproc.c:469) by WINPROC_call_window (winproc.c:2223) by call_window_proc (message.c:1635) by send_message (message.c:2482) by SendMessageA (message.c:2627) by test_hds_nosizing (header.c:1328) by func_header (header.c:1869) by run_test (test.h:535) by main (test.h:585) Uninitialised value was created by a stack allocation at test_hds_nosizing (header.c:1261)

Nov. 26, 2009

Re: Garmin watches and USB

by Stefan Leichter

Am Tuesday 24 November 2009 22:38:53 schrieb Chris Teague: > > I'm trying to figure out exactly what the installer is looking for to > see if the dongle is present. I get a "You must connect your USB ANT > Stick.." message in a dialogbox, and a Retry button. I thought it was > checking for the presence of a new COM port or maybe something in the > Windows device tree? > I think your problem is here: 001c:Call setupapi.SetupDiGetClassDevsW(00488150,00000000,00000000,00000012) ret=00401ef5 001c:Call advapi32.RegOpenKeyExW(80000002,7d92a160 L"System\\CurrentControlSet\\Control\\DeviceClasses",00000000,00020019,0033ef18) ret=7d906628 001c:Ret advapi32.RegOpenKeyExW() retval=00000002 ret=7d906628 001c:Ret setupapi.SetupDiGetClassDevsW() retval=00196458 ret=00401ef5 001c:Call setupapi.SetupDiEnumDeviceInterfaces(00196458,00000000,00488150,00000000,0033f29c) ret=00401f16 001c:Ret setupapi.SetupDiEnumDeviceInterfaces() retval=00000000 ret=00401f16 0

Nov. 26, 2009

Re: kernel32.dll: Reduce Registry access to KEY_READ or MAXIMUM_ALLOWED wherever possible

by Charles Davis

Maarten Lankhorst wrote: > Paul Chitescu schreef: >> Changelog: >> kernel32.dll: Reduce Registry access to KEY_READ or >> MAXIMUM_ALLOWED wherever possible >> >> In many places reading the Registry is enough to work even when write >> access is denied. >> > Your patches cannot be applied with -Np1, consider using git for sending > patches, rather than diffing them :) > > Uhh... he doesn't use git. He made a big deal about this when I told him to upgrade after his .cvsignore patch didn't get in. Chip

Nov. 26, 2009

Re: kernel32.dll: Reduce Registry access to KEY_READ or MAXIMUM_ALLOWED wherever possible

by Maarten Lankhorst

Paul Chitescu schreef: > Changelog: > kernel32.dll: Reduce Registry access to KEY_READ or MAXIMUM_ALLOWED wherever > possible > > In many places reading the Registry is enough to work even when write access > is denied. > Your patches cannot be applied with -Np1, consider using git for sending patches, rather than diffing them :)

Nov. 26, 2009

Re: [PATCH] server: Add primitive support for setting and getting the security descriptor of files based on their Unix permissions.

by Ben Peddell

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4 Oct 2007, Rob Shearman submitted the patch "server: Add primitive support for setting and getting the security descriptor of files based on their Unix permissions.", which calculated the owner permissions solely based on the grant/deny permissions for the owner's SID. On 17 Oct 2007, in bug #10067, "Daniel" reported a bug about FAT32 support being broken in 0.9.47 (which included the above patch) On 21 Oct 2007, Rob Shearman submitted the patch "server: Fix file_set_sd to handle NULL DACLs.", which added support for setting permissions from NULL ACLs. On 21 Nov 2007, Rob Shearman submitted the patch "server: Add primitive support for setting and getting the security descriptor of files based on their Unix permissions.", which added the world permissions to the owner permissions. On 10 Mar 2009, in bug #17672, Nathan Lineback reported a bug about wine incorrectly setting permissions when installing Oracle DB. On 17 Mar 2009, in bug #17776, Richard Hendrikse reported a bug about FAT32 support being broken. On 5 Aug 2009, in bug #19588, Ken Sharp reported that wine was setting the wrong permissions in some cases. On 10 Nov 2009, in bug #20643, Marshall Davis reported that wine was removing owner permissions when World of Warcraft was giving only the users group permission to access the World of Warcraft directory. On 17 Nov 2009, I posted an initial patch here to take the permissions of the groups the user is a member of when calculating the UNIX mode. Rob Shearman replied: > While I agree that there is a problem that needs to be fixed, I'm not > sure this is the right approach. I think you need to take a step back > and consider the meanings of the different SIDs in a token by default > and how they map wine running inside the Unix permissions model. Later on 17 Nov 2009, I revised the patch to only look at the user's groups if the user was the owner of the file. If permissions should be revoked from a user when (1) they are the owner of the file, (2) they are not a trustee in the file's security descriptor, and (3) they are removed from all groups in the file's security descriptor, then there needs to be some other way of storing the owner of the file and the security descriptor in the filesystem (such as POSIX ACLs), and the owner in the security descriptor cannot be the UNIX owner of the file, as the UNIX owner permissions cannot be overridden by POSIX ACLs. In the meantime, the owner of the file cannot access the file when they are not a trustee in the security descriptor, even if token_access_check says they should be able to access the file. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksO/KUACgkQTHDAI68NsunTzwCfVdptQ8sFkFr42r2KOJjvbE2p U7YAoIGowA5ncsgts+p+twCxNDrEedKd =knqg -----END PGP SIGNATURE-----

Nov. 26, 2009

Re: Ctrl/Shift don't autorepeat

by Nikolay Sivov

F Capela wrote: > On Thursday 26 November 2009 11:27:24 am Nikolay Sivov wrote: > >> Dmitry Timoshkov wrote: >> >>> "Nikolay Sivov" <bunglehead(a)gmail.com> wrote: >>> >>> >>>> I've noticed some problems with keyboard input while testing my >>>> favorite Listview control code. >>>> The problem is that Ctrl/Shift don't fire WM_KEYDOWNs properly: they >>>> don't trigger autorepeat. >>>> >>>> Is it a known input processing problem? >>>> >>> http://bugs.winehq.org/show_bug.cgi?id=18296 ? >>> >> Actually, no. I don't have unneeded keyups, the problem is that function >> keys don't autorepeat while letter keys >> do it properly. >> > > Have you tested to see if those keys are auto-repeating under linux (i.e., try to run xev and see if they are repeating)? AFAIK they don't usually autorepeat in Linux, and Wine does not simulate autorepeating; if it's not autorepeating under Linux, it will not autorepeat in Wine. > You're right. There's no autorepeat running my system, so Wine is ok here. Thanks for your answer. No questions. > > Fábio Oliveira Schmidt Capela > darkwalker_(a)yahoo.com >

Nov. 26, 2009

Re: Ctrl/Shift don't autorepeat

by F Capela

On Thursday 26 November 2009 11:27:24 am Nikolay Sivov wrote: > Dmitry Timoshkov wrote: > > "Nikolay Sivov" <bunglehead(a)gmail.com> wrote: > > > >> I've noticed some problems with keyboard input while testing my > >> favorite Listview control code. > >> The problem is that Ctrl/Shift don't fire WM_KEYDOWNs properly: they > >> don't trigger autorepeat. > >> > >> Is it a known input processing problem? > > > > http://bugs.winehq.org/show_bug.cgi?id=18296 ? > Actually, no. I don't have unneeded keyups, the problem is that function > keys don't autorepeat while letter keys > do it properly. Have you tested to see if those keys are auto-repeating under linux (i.e., try to run xev and see if they are repeating)? AFAIK they don't usually autorepeat in Linux, and Wine does not simulate autorepeating; if it's not autorepeating under Linux, it will not autorepeat in Wine. Fábio Oliveira Schmidt Capela darkwalker_(a)yahoo.com

Nov. 26, 2009

Re: Whitespace cleanups

by Francois Gouget

On Wed, 25 Nov 2009, Ken Thomases wrote: [...] > One important reason to avoid whitespace-only changes is it makes > git-blame essentially useless for finding the real source of > functional changes. Such changes don't make git-blame useless. They just make it a bit harder to use. Let's say your 'git-blame dlls/mshtml/tests/dom.c' leads you to commit 1e4412d7 which, by looking at it, you decide is a false positive. Then you do: $ git cat-file -p 1e4412d7 tree ea3b2e117b383ade8afc7cc9bf534c48faf891c7 parent 44f520a5b6f2bd6ec6da8793177711e57bda9c72 author Francois Gouget <fgouget(a)free.fr> 1258539107 +0100 committer Alexandre Julliard <julliard(a)winehq.org> 1258553736 +0100 mshtml/tests: Add a trailing '\n' to ok() calls. Then you run git-blame again: git blame 44f520a5 dlls/mshtml/tests/dom.c And continue the analysis until you find the right culprit. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ I haven't lost my mind, it's backed up on tape around here somewhere...

Nov. 26, 2009

Re: Ctrl/Shift don't autorepeat

by Nikolay Sivov

Paul Chitescu wrote: > On Thursday 26 November 2009 11:27:24 am Nikolay Sivov wrote: > >> Dmitry Timoshkov wrote: >> >>> "Nikolay Sivov" <bunglehead(a)gmail.com> wrote: >>> >>> >>>> I've noticed some problems with keyboard input while testing my >>>> favorite Listview control code. >>>> The problem is that Ctrl/Shift don't fire WM_KEYDOWNs properly: they >>>> don't trigger autorepeat. >>>> >>>> Is it a known input processing problem? >>>> >>> http://bugs.winehq.org/show_bug.cgi?id=18296 ? >>> >> Actually, no. I don't have unneeded keyups, the problem is that function >> keys don't autorepeat while letter keys >> do it properly. >> > > Are you using an USB keyboard? Can you experiment on a computer with PS/2 > keyboard? > > I ask because USB HID doesn't provide autorepeat, that is emulated in kernel. > Besides, modifier keys (there can be maximum 8 of them) are treated > differently by HID keyboard spec. > I'm using PS/2 through vmware running Lenny.

Nov. 26, 2009

Re: Ctrl/Shift don't autorepeat

by Paul Chitescu

On Thursday 26 November 2009 11:27:24 am Nikolay Sivov wrote: > Dmitry Timoshkov wrote: > > "Nikolay Sivov" <bunglehead(a)gmail.com> wrote: > > > >> I've noticed some problems with keyboard input while testing my > >> favorite Listview control code. > >> The problem is that Ctrl/Shift don't fire WM_KEYDOWNs properly: they > >> don't trigger autorepeat. > >> > >> Is it a known input processing problem? > > > > http://bugs.winehq.org/show_bug.cgi?id=18296 ? > Actually, no. I don't have unneeded keyups, the problem is that function > keys don't autorepeat while letter keys > do it properly. Are you using an USB keyboard? Can you experiment on a computer with PS/2 keyboard? I ask because USB HID doesn't provide autorepeat, that is emulated in kernel. Besides, modifier keys (there can be maximum 8 of them) are treated differently by HID keyboard spec.

Nov. 26, 2009

Re: Ctrl/Shift don't autorepeat

by Nikolay Sivov

Dmitry Timoshkov wrote: > "Nikolay Sivov" <bunglehead(a)gmail.com> wrote: > >> I've noticed some problems with keyboard input while testing my >> favorite Listview control code. >> The problem is that Ctrl/Shift don't fire WM_KEYDOWNs properly: they >> don't trigger autorepeat. >> >> Is it a known input processing problem? > > http://bugs.winehq.org/show_bug.cgi?id=18296 ? Actually, no. I don't have unneeded keyups, the problem is that function keys don't autorepeat while letter keys do it properly.

Nov. 26, 2009

Re: Ctrl/Shift don't autorepeat

by Dmitry Timoshkov

"Nikolay Sivov" <bunglehead(a)gmail.com> wrote: > I've noticed some problems with keyboard input while testing my favorite > Listview control code. > The problem is that Ctrl/Shift don't fire WM_KEYDOWNs properly: they > don't trigger autorepeat. > > Is it a known input processing problem? http://bugs.winehq.org/show_bug.cgi?id=18296 ? -- Dmitry.

Nov. 26, 2009

Ctrl/Shift don't autorepeat

by Nikolay Sivov

Hi, guys. I've noticed some problems with keyboard input while testing my favorite Listview control code. The problem is that Ctrl/Shift don't fire WM_KEYDOWNs properly: they don't trigger autorepeat. Is it a known input processing problem? P.S. Alt key is different cause it generates WM_SYSKEYDOWN which isn't supported by control yet.

Nov. 26, 2009

Re: [PATCH] kernel32: Respect the LANG environment variable on Mac OS.

by Dmitry Timoshkov

"Ken Thomases" <ken(a)codeweavers.com> wrote: > If you as a user want to override the language that Wine displays, > you can set LC_MESSAGES in your environment rather than LANG. > Setting LC_ALL would achieve that, plus override the various other > locale categories. Set LANG is the wrong approach, in my opinion. In the most cases what user wants is not just change the UI language (which setting the LC_MESSAGES does) but also change the locale (i.e. input/output code page), that's where LANG should be used. LC_MESSAGES hack adds more confusion IMO than really helps. -- Dmitry.

Nov. 26, 2009

Re: [PATCH] kernel32: Respect the LANG environment variable on Mac OS.

by Vitaliy Margolen

Ken Thomases wrote: > Setting LC_ALL would achieve that, plus override the various other locale > categories. Set LANG is the wrong approach, in my opinion. However this is not the way Wine works on all other platforms. Keeping everything in sync is more appropriate here. Or modify global Wine behavior. Vitaliy.

Nov. 26, 2009

New winetricks 20091125: new verbs ie7, alsa, fbo, pbuffer, ...

by Dan Kegel

Pie's in the oven, time for another winetricks release. Changes in this version: Add experimental dotnet35 verb Add IE7 verb. Based on a patch by Hans Leidekker. Add verbs alsa, audioio, coreaudio, esound, jack, nas, oss to override sound driver Add verbs backbuffer, fbo, pbuffer for setting offscreen rendering buffer Don't crash winecfg if native comctl32 is used Fix gecko to work with wine-1.1.33. Make vc2003toolkit and psdk2003 verbs run on windows On cleanup, remove $WINETRICKS_TMP, not just the files in it Sorted command menu Update Firefox to 3.5.5 Update mpc to latest version, move the exe to Program Files and add it to %PATH% Online as always at http://kegel.com/wine/winetricks or http://winezeug.googlecode.com (Bug reports to the issue tracker at the above URL, please.) Thanks to Austin English, Erik Inge Bolsoe, and Hans Leidekker. This message posted in gmail (basic mode) in ie7 in wine.

Nov. 25, 2009

Re: My script for doing testing

by Steven Edwards

On Wed, Nov 25, 2009 at 5:48 PM, Austin English <austinenglish(a)gmail.com> wrote: > Sure, that would be an option if the system has e-mail configured, but > since I use webmail, I went with the 'sit and wait' method. For other > projects that script would obviously need a different strategy (though > I don't other projects are running winetest.exe daily ;-)). Having the private vncserver or Xnest session is more important than the polling method. You should be able to turn your script in to a proper service without much trouble, the following psudo-init script is a snippet of the serivce I wrote. start() { echo -n $"winecis spam" /usr/bin/vncserver -geometry 1152x900 -depth 16 :$DISPLAY >> /var/log/vncserver.log 2>&1 doaustinswinecismagic RETVAL=$? echo [ $RETVAL = 0 ] return $RETVAL } stop() {..} restart() {..} etc,etc... -- 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

Nov. 25, 2009

Re: My script for doing testing

by Nicolas Le Cam

2009/11/25 Austin English <austinenglish(a)gmail.com>: > On Wed, Nov 25, 2009 at 4:45 PM, Marcus Meissner <marcus(a)jet.franken.de> wrote: >> On Wed, Nov 25, 2009 at 05:21:30PM -0500, Steven Edwards wrote: >>> On Wed, Nov 25, 2009 at 12:08 PM, Austin English >>> <austinenglish(a)gmail.com> wrote: >>> > The other neat thing is that it will run git fetch in a loop every 30 >>> > minutes (again, overridable), so that you can run it in the morning >>> > while waiting for AJ to commit. Once commits are made to the git >>> > master branch (but not stable), the script will kick into motion. >>> >>> It would be nice to dummy email account subscribed to the commit >>> messages that it could poll to trigger the checkout, build, test >>> cycle. >>> >>> To make a Continuous Integration Service around it it should run as a >>> background process under another user out of init in a Xnest/VNC >>> session. I am thinking something like a winecis user which would run >>> these scripts, fetch and the Xnest session as a service we could call >>> winecis. >>> >>> I did something similar recently for a stupid java service that had to >>> have an interactive gui. >> >> As AJ is pushing just once a day you can also run your fetch script >> once a day... Perhaps triggered by a commit mail. > > Sure, that would be an option if the system has e-mail configured, but > since I use webmail, I went with the 'sit and wait' method. For other > projects that script would obviously need a different strategy (though > I don't other projects are running winetest.exe daily ;-)). > > -- > -Austin > > > You could watch http://test.winehq.org/builds/ to see if there is any update (a push is followed by a test build). -- Nicolas Le Cam

Nov. 25, 2009

Re: My script for doing testing

by Austin English

On Wed, Nov 25, 2009 at 4:45 PM, Marcus Meissner <marcus(a)jet.franken.de> wrote: > On Wed, Nov 25, 2009 at 05:21:30PM -0500, Steven Edwards wrote: >> On Wed, Nov 25, 2009 at 12:08 PM, Austin English >> <austinenglish(a)gmail.com> wrote: >> > The other neat thing is that it will run git fetch in a loop every 30 >> > minutes (again, overridable), so that you can run it in the morning >> > while waiting for AJ to commit. Once commits are made to the git >> > master branch (but not stable), the script will kick into motion. >> >> It would be nice to dummy email account subscribed to the commit >> messages that it could poll to trigger the checkout, build, test >> cycle. >> >> To make a Continuous Integration Service around it it should run as a >> background process under another user out of init in a Xnest/VNC >> session. I am thinking something like a winecis user which would run >> these scripts, fetch and the Xnest session as a service we could call >> winecis. >> >> I did something similar recently for a stupid java service that had to >> have an interactive gui. > > As AJ is pushing just once a day you can also run your fetch script > once a day... Perhaps triggered by a commit mail. Sure, that would be an option if the system has e-mail configured, but since I use webmail, I went with the 'sit and wait' method. For other projects that script would obviously need a different strategy (though I don't other projects are running winetest.exe daily ;-)). -- -Austin

Nov. 25, 2009

Re: My script for doing testing

by Marcus Meissner

On Wed, Nov 25, 2009 at 05:21:30PM -0500, Steven Edwards wrote: > On Wed, Nov 25, 2009 at 12:08 PM, Austin English > <austinenglish(a)gmail.com> wrote: > > The other neat thing is that it will run git fetch in a loop every 30 > > minutes (again, overridable), so that you can run it in the morning > > while waiting for AJ to commit. Once commits are made to the git > > master branch (but not stable), the script will kick into motion. > > It would be nice to dummy email account subscribed to the commit > messages that it could poll to trigger the checkout, build, test > cycle. > > To make a Continuous Integration Service around it it should run as a > background process under another user out of init in a Xnest/VNC > session. I am thinking something like a winecis user which would run > these scripts, fetch and the Xnest session as a service we could call > winecis. > > I did something similar recently for a stupid java service that had to > have an interactive gui. As AJ is pushing just once a day you can also run your fetch script once a day... Perhaps triggered by a commit mail. Ciao, Marcus

Nov. 25, 2009

Re: My script for doing testing

by Avery Pennarun

On Wed, Nov 25, 2009 at 5:24 PM, Steven Edwards <winehacker(a)gmail.com> wrote: >> To make a Continuous Integration Service around it it should run as a >> background process under another user out of init in a Xnest/VNC >> session. I am thinking something like a winecis user which would run >> these scripts, fetch and the Xnest session as a service we could call >> winecis. >> >> I did something similar recently for a stupid java service that had to >> have an interactive gui. > > Thinking about it a bit more, I guess the email thing is kind of > redundant since git can poll more often. I guess it really depends on > how many build agents you want to have hanging out hammering git. To > you want them to hammer git or hammer your mail server? Checking git every few minutes for new revisions costs basically zero, in the event that there are no new revisions. BTW, gitbuilder can do this sort of thing for you. It also provides an rss feed of build results. Avery

Nov. 25, 2009

Re: My script for doing testing

by Steven Edwards

On Wed, Nov 25, 2009 at 5:21 PM, Steven Edwards <winehacker(a)gmail.com> wrote: > It would be nice to dummy email account subscribed to the commit > messages that it could poll to trigger the checkout, build, test > cycle. > > To make a Continuous Integration Service around it it should run as a > background process under another user out of init in a Xnest/VNC > session. I am thinking something like a winecis user which would run > these scripts, fetch and the Xnest session as a service we could call > winecis. > > I did something similar recently for a stupid java service that had to > have an interactive gui. Thinking about it a bit more, I guess the email thing is kind of redundant since git can poll more often. I guess it really depends on how many build agents you want to have hanging out hammering git. To you want them to hammer git or hammer your mail server? -- 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

Nov. 25, 2009

Re: My script for doing testing

by Steven Edwards

On Wed, Nov 25, 2009 at 12:08 PM, Austin English <austinenglish(a)gmail.com> wrote: > The other neat thing is that it will run git fetch in a loop every 30 > minutes (again, overridable), so that you can run it in the morning > while waiting for AJ to commit. Once commits are made to the git > master branch (but not stable), the script will kick into motion. It would be nice to dummy email account subscribed to the commit messages that it could poll to trigger the checkout, build, test cycle. To make a Continuous Integration Service around it it should run as a background process under another user out of init in a Xnest/VNC session. I am thinking something like a winecis user which would run these scripts, fetch and the Xnest session as a service we could call winecis. I did something similar recently for a stupid java service that had to have an interactive gui. -- 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

Nov. 25, 2009

Re: openal32: Add alBufferSubDataEXT

by Chris Robinson

I'm not sure it's very appropriate to add this yet, since the extension isn't finalized. Until it's finalized, there could be changes that modify the API calls (I don't expect changes, but it's best to err on the side of caution, I think). The alBufferDataStatic patch is fine, though.

Nov. 25, 2009

Re: Whitespace cleanups

by Kai Blin

On Wednesday 25 November 2009 19:02:08 Ken Thomases wrote: > On Nov 25, 2009, at 11:13 AM, Nate Gallaher wrote: > > Ken Thomases wrote: > >> One important reason to avoid whitespace-only changes is it makes > >> git-blame essentially useless for finding the real source of functional > >> changes. > > > > But is that really important? git-bisect would put you on the other side > > of any whitespace changes, and a prudent bug-hunter should be referring > > to the commit logs anyway. > > Who says git-blame is only useful on occasions when it makes sense to > git-bisect? Or that one is hunting bugs. > > I often use git-blame precisely to figure out which commit log I need to be > looking at to understand why the code is the way it is. I see something in > the code which is done in a way I don't understand/expect. I git-blame to > see what commit introduced the code in that form. I get a commit ID. I > look up the commit to see what it contained, what the log message was, what > commits were around it, etc. There _is_ a -w option to git-blame that ignores whitespace, though. Adding two characters (possibly via an alias) is a small price to pay for non-braindead formatting imho. 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.

Nov. 25, 2009

Re: Fixing the kernel32:actctx tests on Vista+

by Jacek Caban

Paul Vriens wrote: > On 11/25/2009 05:39 PM, Jacek Caban wrote: >> Hi Paul, >> >> Paul Vriens wrote: >>> Hi Jacek, >>> >>> You are the original author of these tests. Is there any reason the >>> "test3.manifest" name is reused? >>> >>> The tests currently crash (intermittently on some) on Vista+ and with >>> the attached patch things seem to get better. I'm just renaming one of >>> the manifest files so there are no duplicates in these tests. >> >> I don't remember much about these tests, but looking at the code I don't >> see any reason to reuse the name, so your patch looks good for me. > > Well, it was 2007 ;) > > Btw. another patch (see attached patch2) works as well and is > basically the same thing that Ge did back in September to these same > tests. > > So both work fine. Any favors for one over the other? Both seem good for me. I think that a new file name is slightly better, because it feels safer than cheating cache mechanisms. Jacek

Nov. 25, 2009

Re: Fixing the kernel32:actctx tests on Vista+

by Paul Vriens

On 11/25/2009 05:39 PM, Jacek Caban wrote: > Hi Paul, > > Paul Vriens wrote: >> Hi Jacek, >> >> You are the original author of these tests. Is there any reason the >> "test3.manifest" name is reused? >> >> The tests currently crash (intermittently on some) on Vista+ and with >> the attached patch things seem to get better. I'm just renaming one of >> the manifest files so there are no duplicates in these tests. > > I don't remember much about these tests, but looking at the code I don't > see any reason to reuse the name, so your patch looks good for me. Well, it was 2007 ;) Btw. another patch (see attached patch2) works as well and is basically the same thing that Ge did back in September to these same tests. So both work fine. Any favors for one over the other? -- Cheers, Paul.

Nov. 25, 2009

Re: Whitespace cleanups

by Ken Thomases

On Nov 25, 2009, at 11:13 AM, Nate Gallaher wrote: > Ken Thomases wrote: >> One important reason to avoid whitespace-only changes is it makes git-blame essentially useless for finding the real source of functional changes. >> > > But is that really important? git-bisect would put you on the other side of any whitespace changes, and a prudent bug-hunter should be referring to the commit logs anyway. Who says git-blame is only useful on occasions when it makes sense to git-bisect? Or that one is hunting bugs. I often use git-blame precisely to figure out which commit log I need to be looking at to understand why the code is the way it is. I see something in the code which is done in a way I don't understand/expect. I git-blame to see what commit introduced the code in that form. I get a commit ID. I look up the commit to see what it contained, what the log message was, what commits were around it, etc. How would git-bisect be helpful in that case? > There should be a path to eventual codebase sanity, no matter how slow. I think you're going to be disappointed. :-/ -Ken

Nov. 25, 2009