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

Re: [2/2] msi: Implement MSIRUNMODE_MAINTENANCE and MSIRUNMODE_REBOOTATEND for MsiGetMode.
by James Hawkins 18 Feb '10

18 Feb '10

On Thu, Feb 18, 2010 at 3:47 AM, Hans Leidekker <hans(a)codeweavers.com> wrote: > --- > dlls/msi/install.c | 12 +++++++++++- > dlls/msi/tests/automation.c | 4 ++-- > 2 files changed, 13 insertions(+), 3 deletions(-) > > diff --git a/dlls/msi/install.c b/dlls/msi/install.c > index 7a71867..6e19863 100644 > --- a/dlls/msi/install.c > +++ b/dlls/msi/install.c > @@ -661,6 +661,8 @@ BOOL WINAPI MsiGetMode(MSIHANDLE hInstall, MSIRUNMODE iRunMode) > MSIPACKAGE *package; > BOOL r = FALSE; > > + TRACE("%d %d\n", hInstall, iRunMode); > + > package = msihandle2msiinfo(hInstall, MSIHANDLETYPE_PACKAGE); > if (!package) > { > @@ -706,8 +708,16 @@ BOOL WINAPI MsiGetMode(MSIHANDLE hInstall, MSIRUNMODE iRunMode) > r = package->commit_action_running; > break; > > + case MSIRUNMODE_MAINTENANCE: > + r = msi_get_property_int( package, szInstalled, 0 ) != 0; > + break; > + > + case MSIRUNMODE_REBOOTATEND: > + r = package->need_reboot; > + break; > + > default: > - FIXME("%d %d\n", hInstall, iRunMode); > + FIXME("unimplemented run mode\n"); > r = TRUE; > } > It's nice to see which run mode we're not handling by quickly looking at the FIXME. Any reason you removed this? Keep in mind most general user logs won't have +msi logging, if any. -- James Hawkins

2 1

Re: comctl32: listview should accept both unicode and ansi notifications.
by Nikolay Sivov 18 Feb '10

18 Feb '10

On 2/18/2010 15:46, Dmitry Timoshkov wrote: > Listview receives notifications not only from built-in header control, > but also from custom or subclassed application controls, there is no > need to assert(0) on application input, printing a FIXME is the maximum > we can do on an unknown input. > > The question actually is how does it react on it. Your test only check for return value and most likely doesn't use this conversion path (I'm not sure). The this is so strict probably was that we set notification format when header query for it, and we expect proper codes after that. Anyway change looks a bit confusing cause logically we shouldn't convert to ansi if we have ansi already. > Added test case passes under XP, but listview in Wine intentionally > crashes itself on an absolutely valid input. > Yes, FIXME is ok here.

1 0

Re: [cmd] Don't change case of the batch filename
by Alexandre Julliard 18 Feb '10

18 Feb '10

Paul Vriens <paul.vriens.wine(a)gmail.com> writes: > diff --git a/programs/cmd/batch.c b/programs/cmd/batch.c > index 28744d4..6cb732c 100644 > --- a/programs/cmd/batch.c > +++ b/programs/cmd/batch.c > @@ -91,7 +91,7 @@ void WCMD_batch (WCHAR *file, WCHAR *command, int called, WCHAR *startLabel, HAN > prev_context = context; > context = LocalAlloc (LMEM_FIXED, sizeof (BATCH_CONTEXT)); > context -> h = h; > - context->batchfileW = WCMD_strdupW(string); > + context->batchfileW = WCMD_strdupW(file); That whole function is broken, it should not be lowering the string in the first place. It does this in order to use strstrW, but that's not the right way to check the extension anyway. In any case the test environment needs to be comparing paths in a case-insensitive way, it doesn't make sense to require exact case. -- Alexandre Julliard julliard(a)winehq.org

2 4

Re: [cmd] Don't change case of the batch filename
by Paul Vriens 18 Feb '10

18 Feb '10

On 02/18/2010 02:35 PM, Paul Vriens wrote: > Hi, > > This should fix the test failures for Wine (on test.winehq.org) > > Not sure how to write a (simple) test for this. The test is there in > fact but it will only show up on test.winehq.org or when doing a "make > batch.ok" from a directory with an uppercase letter in the path. > > Maybe we should create an uppercase directory in %TEMP% and run our > tests from there instead of the current directory? > > Changelog > Don't change case of the batch filename > Ignore this one. Needs more thought. -- Cheers, Paul.

1 0

Re: [PATCH 5/5] cmd: rename reference file from .out to .exp to avoid clash with gnu make builtin rule
by Paul Vriens 18 Feb '10

18 Feb '10

On 02/16/2010 10:08 PM, Dan Kegel wrote: > Without this, editing the .cmd file and then running make would > cause make to overwrite the .out file with a copy of the .cmd file! > Evidently '.out' is not appropriate as a suffix for a nongenerated > source file. The arbitrarily-chosen .exp suffix works better > (if anyone asks, it stands for 'expected output'). > --- > programs/cmd/tests/batch.c | 4 ++-- > programs/cmd/tests/rsrc.rc | 4 ++-- > programs/cmd/tests/test_builtins.cmd.exp | 18 ++++++++++++++++++ > programs/cmd/tests/test_builtins.cmd.out | 18 ------------------ > 4 files changed, 22 insertions(+), 22 deletions(-) > create mode 100644 programs/cmd/tests/test_builtins.cmd.exp > delete mode 100644 programs/cmd/tests/test_builtins.cmd.out > > Hi Dan, These last changes introduce several test failures on some W2K, XP and W2K3 boxes but on all Wine ones: http://test.winehq.org/data/tests/cmd.exe:batch.html One thing I've noticed is that the succeeding ones run 12 tests whereas the failing ones run 14 tests. Could you have a look? -- Cheers, Paul.

1 3

Re: [PATCH] wined3d: Split comments in separate line to avoid buffer overflow when traces are enabled (try 2)
by Henri Verbeet 18 Feb '10

18 Feb '10

On 17 February 2010 17:54, Christian Costa <titan.costa(a)wanadoo.fr> wrote: > + if (TRACE_ON(d3d_shader)) > + { > + int size = strlen(comment) + 1; > + char* str = (char*)HeapAlloc(GetProcessHeap(), 0, size); > + int i = 0; > + char* line = str; > + memcpy(str, comment, size); > + DPRINTF("//"); > + while (i < size) > + { > + /* Find end of line */ > + while ((str[i] != 0) && (str[i] != 0x0a)) > + i++; > + /* Terminate line and remove preceding 0x0d if any */ > + if (i && (str[i-1] == 0x0d)) > + str[i-1] = 0; > + else > + str[i] = 0; > + /* Display line and prepare next line */ > + DPRINTF("%s\n", debugstr_an(line, strlen(line))); > + i++; > + line = str + i; > + } > + } This code has several obvious issues.

2 1

Re: tools/wine.inf: Add a symlink for WindowsNT.CurrentVersion.Print.Printers
by Alexandre Julliard 17 Feb '10

17 Feb '10

Detlef Riekenberg <wine.dev(a)web.de> writes: > @@ -905,6 +905,7 @@ HKLM,%CurrentVersionNT%\Ports,"COM1:",2,"9600,n,8,1" > HKLM,%CurrentVersionNT%\Ports,"COM2:",2,"9600,n,8,1" > HKLM,%CurrentVersionNT%\Ports,"COM3:",2,"9600,n,8,1" > HKLM,%CurrentVersionNT%\Ports,"COM4:",2,"9600,n,8,1" > +HKLM,%CurrentVersionNT%\Print\Printers,"SymbolicLinkValue",0x60000,"\Registry\Machine\%Control%\Print\Printers" It looks like it should be the other way around. -- Alexandre Julliard julliard(a)winehq.org

2 2

re: Status of Patchwatcher
by Dan Kegel 17 Feb '10

17 Feb '10

Seth Shelnutt wrote: > I am wondering what that status of patchwatcher is? It's waiting around for somebody to have time to start it up again. It's ugly code, written in shell and perl, which scares most people off. One has to wonder whether it shouldn't be done over again using buildbot, just to avoid scaring people. But it could live on in its present form given time and attention. Another problem is that the code for watching for patch series is fragile. We might conceivably move to driving it from a web submission form like WineTestBot uses, that would solve that. (I've been focusing my precious Wine time on the daily valgrind runs. It would be cool to run those tests on Patchwatcher; that was the whole goal of patchwatcher, actually. I think to do it fast enough we'd have to take a shortcut, like only valgrind the tests most obviously related to the change.) > I saw the ideals for converting UnitTestSuit and wpkg scripts to Appinstall. I > definitely think this is a good idea and needed; however I was thinking that > linking patchwatcher and appinstall testing would be even more beneficial. You're referring to http://wiki.winehq.org/SummerOfCode#head-6e93309cf25ab1bb55e35698562cac148d… and http://wiki.winehq.org/UnitTestSuites A daily run of appinstall is probably sufficient. Austin does that already. The main downside is that the results aren't tied in to test.winehq.org. It'd be really great to invoke lots of wpkg installs from inside Appinstall, and file bugs for whatever that turns up. (And fix them, maybe.) UnitTestSuites is a bit more programmer-oriented. I'd recommend that if you're interested in becoming a developer. Grinding through and automating builds for a few open source apps on wine would probably teach you a lot. - Dan

4 3

compiling for 64bit: types and format strings
by Joerg-Cyril.Hoehle＠t-systems.com 17 Feb '10

17 Feb '10

Hi, While I have no 64bit system, I recently submitted a compilation job to WTB and saw dozens of warnings unknown to me so far, mostly about printf format strings. The reason for the warnings is that WTB compiles in 64 bit mode, while I only know 32bit systems. Is there anything us 32bit users can do to prevent such warnings or shall we patiently wait until AJ checks in 64bit fixes? (BTW, thank you for the recent winmm one). Or compile every patch on WTB first? More specifically, regarding format strings, I'm unsure whether it's actually possible to find %d/%ld formats that work on both systems for all types one comes across (UINT, MMRESULT etc.) What's the receipe? Thank you, Jörg Höhle

3 2

Re: [PATCH] wined3d: Split comments in separate line to avoid buffer overflow when traces are enabled
by Henri Verbeet 17 Feb '10

17 Feb '10

On 17 February 2010 11:47, Christian Costa <titan.costa(a)wanadoo.fr> wrote: > It should use debugstr_an() in the first place. You could have a go at splitting it into separate lines if needed after that, but I can't think of a whole lot of cases where the comments are really useful.

3 3