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

Re: avifil32: Simplify comparing two unsigned ints (PVS-Studio) (try 2)

by Ken Thomases

On Nov 10, 2014, at 4:56 PM, André Hentschel <nerv(a)dawncrow.de> wrote: > try 2: added the missing +1 thanks to a hint by ken on irc > --- > dlls/avifil32/avifile.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/dlls/avifil32/avifile.c b/dlls/avifil32/avifile.c > index 6295c7b..3d90e20 100644 > --- a/dlls/avifil32/avifile.c > +++ b/dlls/avifil32/avifile.c > @@ -466,9 +466,9 @@ static HRESULT WINAPI IAVIFile_fnDeleteStream(IAVIFile *iface, DWORD fccType, LO > /* ... so delete it now */ > HeapFree(GetProcessHeap(), 0, This->ppStreams[nStream]); > > - if (This->fInfo.dwStreams - nStream > 0) > - memcpy(This->ppStreams + nStream, This->ppStreams + nStream + 1, > - (This->fInfo.dwStreams - nStream) * sizeof(IAVIStreamImpl*)); > + if (nStream < This->fInfo.dwStreams) > + memcpy(&This->ppStreams[nStream], &This->ppStreams[nStream + 1], > + (This->fInfo.dwStreams - nStream) * sizeof(This->ppStreams[0])); > > This->ppStreams[This->fInfo.dwStreams] = NULL; > This->fInfo.dwStreams--; This is a more faithful refactoring of the original logic. However, looking at it some more, it looks like the original logic was wrong. It's removing an entry from the array and shifting the following entries up to fill the gap. There are This->fInfo.dwStreams - nStream entries from the nStream'th one to the end. There are only This->fInfo.dwStreams - (nStream + 1) entries that actually _follow_ the nStream'th one. The original logic read past the end of the array and this logic still does. -Ken

Nov. 10, 2014

Wine Mono 4.5.4 Release

by Vincent Povirk

I have published version 4.5.4 of Wine Mono on sourceforge. Once again, it's been about a year since the last release. I really am trying to make these more frequent, but for various reasons it hasn't worked out that way. Due to some odd behavior in msi (or so I'm assuming, unfortunately I haven't had a chance to investigate in any detail), it is necessary to run 'wine64 msiexec /i wine-mono-4.5.4.msi' to install in a 64-bit prefix. Installing without the wine64 uses the 32-bit version of msiexec which somehow installs it alongside the default Wine Mono install instead of upgrading it. Any testing with .NET software (in particular .NET software that has been known to work before, if anyone knows of such a thing) would be appreciated. The source tarball is at https://sourceforge.net/projects/wine/files/Wine%20Mono/4.5.4/wine-mono-4.5… The binary is at https://sourceforge.net/projects/wine/files/Wine%20Mono/4.5.4/wine-mono-4.5… For developers, the source repository is at https://github.com/madewokherd/wine-mono Changes since 4.5.2: * Removed MonoGame. It was problematic because MG didn't have binary compatibility with XNA as a goal, I didn't have time to update from upstream, and the MS version of XNA was used anyway if it was installed, which it usually is. I may consider including a real XNA binary replacement if one appears, but for now I think it's better to work on making the MS implementation work. * It's no longer necessary to have gmcs installed to build from a tarball. Tarballs now include a build of Monolite for bootstrapping the compiler, which is the same thing the Mono project does with their tarballs. This was to avoid problems with old Mono versions not being able to bootstrap the current compiler. * A -l switch was added to build-winemono.sh, which fetches an official Monolite build and uses that to bootstrap the compiler. This is only useful if you are building from Git and don't have a sufficiently new gmcs to make this work. * The build will now abort if -t is specified and any tests fail to build. * The libmono build now specifies strict Dwarf2 debugging symbols, to keep it compatible with winedbg. * The libmono build now specifies static libgcc, to avoid linking errors on recent mingw. * We now use dllmap configuration to find MonoPosixHelper, which eliminates some diffs from upstream and will remove the need for Wine to mess with the PATH of .NET applications. * Added a Wine-specific implementation of System.Runtime.InteropServices.RuntimeEnvironment.GetRuntimeInterfaceAsObject and GetRuntimeInterfaceAsIntPtr. * Updated Mono to the master branch as of October 31, bringing in many changes including the following: * Fixed use of RVA fields pointing to zeroed static data that isn't physically in the PE file (improves managed C++ compatibility). * Added support for service processes using ServiceBase.Run. * It's now possible to change how debug output is printed via the embedding API, which will make possible a future change to Wine to send the output to the Unix stderr stream. * Beginnings of a System.Management implementation.

Nov. 10, 2014

Re: [PATCH 3/3] mshtml: Added script element readyState and onreadystatechange tests.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=10164 Your paranoid android. === w8 (32 bit script) === script.c:632: Test failed: L"extern_res_script_rs = loaded0,eval,complete1, expected eval,complete1,"

Nov. 10, 2014

Re: [PATCH 1/3] mshtml: Ignore query and hash parts in res protocol handler.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=10163 Your paranoid android. === w2000pro (32 bit protocol) === protocol.c:144: Test failed: expected: 00000000 got: 80070716 protocol.c:255: Test failed: Start failed: 80070716 protocol.c:258: Test failed: expected ReportProgress protocol.c:259: Test failed: expected ReportData protocol.c:280: Test failed: Read failed: 80004005 protocol.c:144: Test failed: expected: 00000000 got: 80070716 protocol.c:255: Test failed: Start failed: 80070716 protocol.c:258: Test failed: expected ReportProgress protocol.c:259: Test failed: expected ReportData protocol.c:280: Test failed: Read failed: 80004005

Nov. 10, 2014

Re: Sourceforge says 1.5.22 is the latest version

by Marcus Meissner

On Mon, Nov 10, 2014 at 08:04:41PM +0900, Alexandre Julliard wrote: > Marcus Meissner <marcus(a)jet.franken.de> writes: > > > On Fri, Nov 07, 2014 at 03:13:54PM -0600, Rosanne DiMesio wrote: > >> Not really sure whose bug this is, but a user just pointed out that > >> http://sourceforge.net/projects/wine/files/Source/ (which the source > >> link at the bottom of our Downloads page leads to) has a line > >> stating "Looking for the latest version? Download > >> wine-1.5.22.tar.bz2 (21.2 MB)." The main project page, > >> http://sourceforge.net/projects/wine/, also has a big green Download > >> button for 1.5.22.tar.bz2. > > > > This is something that can be selected in the upload frontend. > > > > Not sure how Alexandre uploads the tarball. > > It's uploaded from a script with rsync, so I never touch the upload > frontend. If someone knows a way to set the latest version from a script > please let me know... I manually set 1.6.2 as latest release. (Expecting the user that downloads updates to know to look for 1.7.xx) Ciao, Marcus

Nov. 10, 2014

Re: [PATCH v3 03/10] reg: Add system error printing function

by Jonathan Vollebregt

> This seems like a step backwards to me. It would be much better to add the required functionality -- e.g. FormatMessage() -- and fix reg.exe printf-style functions in one go. I'd still have to use reg_print_error as is because it's there to get the error string from standard error codes like ERROR_INVALID_DATA not to actually format the output string (FORMAT_MESSAGE_FROM_SYSTEM vs FORMAT_MESSAGE_FROM_STRING) I like splitting the writing part into output_write (That might come in handy for printing long strings in reg query if we can't find a way to make reg_printfW variable size) Giving reg_message extra arguments is a good idea, but I'm not sure if we're supposed to have format specifiers in LoadString resources. I'm not sure whether having output_vprintf is really an advantage over just calling reg_printf since it uses different format specifiers than printf and basically does the same thing (Minus the variable size issue of course)

Nov. 10, 2014

Re: kernel32: add TRUST_E_NOSIGNATURE resource definition

by Alexandre Julliard

Austin English <austinenglish(a)gmail.com> writes: > @@ -281,8 +281,8 @@ msg : msgid sevfacsym { test_id($1); } bodies { $$ = complete_msg($4, $1); } > ; > > msgid : tMSGID '=' id { > - if($3 & (~0xffff)) > - xyyerror("Message ID value out of range (0x%08x > 0xffff)\n", $3); > + if($3 & (~0xffffffff)) > + xyyerror("Message ID value out of range (0x%08x > 0xffffffff)\n", $3); There shouldn't be any need to change the message compiler, there are severity/facility message options. -- Alexandre Julliard julliard(a)winehq.org

Nov. 10, 2014

Re: [PATCH] reg.exe: Modernise print functions

by Jonathan Vollebregt

Unfortunately if I pass in anything besides a pointer it will segfault. It actually wants a format string "%1!d!" for ints which is hardly compact (Especially since we have to type it out in a WCHAR array) There must be a better way to get the size of the string... On 11/10/2014 01:44 PM, Hugh McMaster wrote: > On Monday, 10 Nov 2014 13:17:56 +0100, Jonathan Vollebregt wrote: >> That was my thought, but it doesn't appear to be parsing printf >> parameters properly: >> >> Sticking this in main: >> >>> static const WCHAR testW[] = {'w','0','o','t','\n','%','s','\n',0}; >>> reg_printfW(testW, deleteW); >> >> Results in the output: >> >>> w0ot >>> s > > At a quick glance, %s should be %1. FormatMessage() accepts numerals. > >

Nov. 10, 2014

RE: [PATCH] reg.exe: Modernise print functions

by Hugh McMaster

On Monday, 10 Nov 2014 13:17:56 +0100, Jonathan Vollebregt wrote: > That was my thought, but it doesn't appear to be parsing printf > parameters properly: > > Sticking this in main: > >> static const WCHAR testW[] = {'w','0','o','t','\n','%','s','\n',0}; >> reg_printfW(testW, deleteW); > > Results in the output: > >> w0ot >> s At a quick glance, %s should be %1. FormatMessage() accepts numerals.

Nov. 10, 2014

Re: [PATCH] reg.exe: Modernise print functions

by Jonathan Vollebregt

That was my thought, but it doesn't appear to be parsing printf parameters properly: Sticking this in main: > static const WCHAR testW[] = {'w','0','o','t','\n','%','s','\n',0}; > reg_printfW(testW, deleteW); Results in the output: > w0ot > s On 11/10/2014 01:10 PM, Hugh McMaster wrote: > On Monday, 10 November 2014, Jonathan Vollebregt wrote: >>> WCHAR msg_buffer[1024]; > >> No easy way to get the expected size and dynamically allocate the output I take it? > >> I looked into it before but besides _vscprintf (In msvcrt, which we're >> not allowed to use) there doesn't seem to be a way to get the expected >> output size besides perhaps growing the buffer over and over again until >> it fits (Which seems inefficient for a simple printing function) > > One possible way would be to avoid using vsnprintfW() and pass everything through to output_vprintf(). > > static void __cdecl reg_printfW(const WCHAR* msg, ...) > { > __ms_va_list va_args; > > __ms_va_start(va_args, msg); > output_vprintf(msg, va_args); > __ms_va_end(va_args); > } > > This would have the advantage of using FormatMessage() to allocate memory. But we would have to replace all format specifiers (four or five?) with their FormatMessage() equivalents. > > static const WCHAR unhandled[] = {'U','n','h','a','n','d','l','e','d',' ','T','y','p','e',' ','0','x','%','x',' ',' ','d','a','t','a',' ','%','s','\n',0}; > > becomes > > static const WCHAR unhandled[] = {'U','n','h','a','n','d','l','e','d',' ','T','y','p','e',' ','0','x','%','1','!','x','!',' ',' ','d','a','t','a',' ','%','2','\n',0}; > > > >

Nov. 10, 2014