- wine-devel - winehq.org

Re: msvcp90/tests: Skip tests on missing functions
by Piotr Caban 07 Aug '13

07 Aug '13

On 08/06/13 23:00, André Hentschel wrote: > @@ -749,6 +749,13 @@ static BOOL init(void) > > SET(p_basic_istream_char_read_uint64, > "??5?$basic_istream@DU?$char_traits@D@std@@@std@@QAEAAV01@AA_K@Z"); > + > + if (!p_basic_istream_char_read_uint64) > + { > + skip("_basic_istream_char_read_uint64 not found, skipping tests\n"); > + return FALSE; > + } Why are you skipping the tests instead of properly initializing functions pointers on ARM?

2 1

Request to add wow64 keyword to bugzilla
by Rosanne DiMesio 07 Aug '13

07 Aug '13

Can wow64 be added as a keyword to bugzilla? I know we already have win64 as a keyword, but that's being used for both 64 bit apps and 32 bit apps in a 64 bit wineprefix. I'm interested in being able to track the latter, as it's hitting increasing numbers of users. -- Rosanne DiMesio <dimesio(a)earthlink.net>

2 1

Re: [PATCH] typo fixes (https://github.com/vlajos/misspell_fixer)
by Frédéric Delanoy 07 Aug '13

07 Aug '13

On Mon, Aug 5, 2013 at 9:41 PM, Veres Lajos <vlajos(a)gmail.com> wrote: > > Signed-off-by: Veres Lajos <vlajos(a)gmail.com> > --- > dlls/comctl32/tests/trackbar.c | 2 +- > documentation/ChangeLog.ALPHA | 80 ++++++++++++++++++++-------------------- > documentation/ChangeLog.BETA | 44 +++++++++++----------- > documentation/ChangeLog.OLD | 24 ++++++------ > tools/winebuild/utils.c | 2 +- > 5 files changed, 76 insertions(+), 76 deletions(-) The "documentation/ChangeLog.*" files have been removed so the patch won't apply. Frédéric Delanoy

1 0

Re: msvcrt: strncpy doesn't compliant C standard (try 2)
by Frédéric Delanoy 07 Aug '13

07 Aug '13

On Tue, Aug 6, 2013 at 10:44 PM, Álvaro Nieto <alvaro.nieto(a)gmail.com> wrote: > Remove strlen and implement some tests You should probably add tests for when the source string is not null-terminated. Frédéric Delanoy

1 0

Re: msvcp90/tests: Skip tests on missing functions
by Marvin 06 Aug '13

06 Aug '13

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 http://testbot.winehq.org/JobDetails.pl?Key=26628 Your paranoid android. === WXPX64 (32 bit misc) === No test summary line found === WXPX64 (32 bit ios) === No test summary line found

1 0

Re: msvcr90/tests: Skip when _type_info_name_internal_method is not found
by Marvin 06 Aug '13

06 Aug '13

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 http://testbot.winehq.org/JobDetails.pl?Key=26627 Your paranoid android. === WXPX64 (32 bit msvcr90) === No test summary line found

1 0

Re: ws2_32/tests: Fix a comment
by Juan Lang 06 Aug '13

06 Aug '13

Hi Andre, - /* this is a io heavy test, do it at the end so the kernel doesn't start dropping packets */ + /* this is a heavy io test, do it at the end so the kernel doesn't start dropping packets */ To my eyes, this isn't an improvement. A slight improvement might be "this is a io-heavy test", or "this is an io-heavy test", but I'm not sure it's enough of an improvement to bother. --Juan

1 0

Re: msvcrt: strncpy doesn't compliant C standard
by Nikolay Sivov 06 Aug '13

06 Aug '13

On 8/6/2013 11:09, Álvaro Nieto wrote: > This patch solves [Bug 34211]. The implementation of strncpy function > doesn't compliant with C standard [1]. Also Microsoft Visual Studio > C/C++ compiler is ok with the standard [2]. > > Extract from msdn; > > "The strncpy function copies the initial count characters of strSource > to strDest and returns strDest. If count is less than or equal to the > length of strSource, a null character is not appended automatically to > the copied string. If count is greater than the length of strSource, > the destination string is padded with null characters up to length > count. The behavior of strncpy is undefined if the source and > destination strings overlap." > > [1] http://pubs.opengroup.org/onlinepubs/009695399/functions/strncpy.html > [2] http://msdn.microsoft.com/en-us/library/vstudio/xdsywd25.aspx This needs tests.

1 0

Fwd: [AppDB] Submitted test data deleted
by Ken Sharp 05 Aug '13

05 Aug '13

Deleting test results because the Wine version is old? What the Hell is the plan there? -------- Original Message -------- Subject: [AppDB] Submitted test data deleted Date: Mon, 05 Aug 2013 15:48:43 -0500 From: AppDB <appdb-noreply(a)winehq.org> Reply-To: AppDB <appdb-noreply(a)winehq.org> To: appdb-noreply(a)winehq.org Submitted test data deleted ------------------------------------------------------- The test report you submitted for 'Microsoft Access 2007' has been deleted. The action was performed by Joerg Schiermeier Reasons given Old wine - deprecated. Best regards. The AppDB team http://appdb.winehq.org/ If you don't want to receive any other e-mail, please change your preferences: http://appdb.winehq.org/preferences.php

1 0

wine mannual is wrong?
by 中川祥 05 Aug '13

05 Aug '13

I'm interpretering wine.man. I found it says"this requires X11 to run". But the newest ver. does not require X11,does it?

3 2

Draft: improve IMC/IMCC related functions
by Qian Hong 05 Aug '13

05 Aug '13

Hello, This is a follow up of http://www.winehq.org/pipermail/wine-devel/2013-July/100459.html ( [PATCH] imm32: Fixed crashing in ImmGetIMCCSize. ) I believe the attached patchset is the correct fix for the Office crashing bug, how ever, I'm looking for a more graceful way to improve ImmCreateContext and other IMC functions, I appreciate to any feedback on the patches especially Patch 6/6. My tests show that Windows return a HGLOBAL hmem for ImmCreateIMCC() as the returned HIMCC, so it is easy to re-implement ImmCreateIMCC in a graceful way. However, Windows return a magic number for ImmCreateContext, (for instance, have a look at 000B01D9 in the test show in https://testbot.winehq.org/JobDetails.pl?Key=26619&log_207=1#k207) I have no idea how that magic number comes, while I understand there is no need to re-implement ImmCreateContext in the same way as Windows does, I'm still interesting in a more beautiful implementation like my ImmCreateIMCC reached, get rid of casting InputContextData to HIMC if possible. Thanks in advance for any suggestions! If there is no better way, I'll send this series to wine-patches. -- Regards, Qian Hong - http://www.winehq.org

1 0

Re: inputscope.idl: Imported from mingw-w64.
by Ken Sharp 05 Aug '13

05 Aug '13

On 05/08/13 12:14, Jacek Caban wrote: > + * No warranty is given; refer to the file DISCLAIMER.PD within this package. It's a minor point but this may be a bit confusing given the file doesn't exist.

1 0

Re: msvcrt: invoke invalid_handler in _wcscpy_s
by Piotr Caban 05 Aug '13

05 Aug '13

On 08/02/13 20:08, Daniel Lehman wrote: > + if(!MSVCRT_CHECK_PMT(wcDest)) > + { > + *MSVCRT__errno() = MSVCRT_EINVAL; > return MSVCRT_EINVAL; > + } The MSVCRT_CHECK_PMT macro sets the errno value. There's also MSVCRT_CHECK_PMT_ERR macro if you need to set different error.

1 0

po: Add English (Philippines) resource
by Ken Sharp 05 Aug '13

05 Aug '13

Hi everyone, Would anyone mind looking at the attached patch? It adds the English (Philippines) resource by linking (or copying) the English (US) resource. See http://bugs.winehq.org/show_bug.cgi?id=23124 Actually, the attached version links to fr.po (French) to make testing much easier. The final won't do that. It's explained in the bug. I have tested this successfully in Linux only. I wanted to test others but: Cygwin 1.7.22: creates its own "symlink" but no translations are built at all. Compilation is basically broken. PC-BSD 9.1: complains about gettext although the config.log seems to complain about gm4. I gave up. OpenIndiana: can't seem to find its own packages. Gave up. Debian kFreeBSD: all sorts of problems in VBox. Might try again later. So clearly I've had no luck on other platforms. If anyone else could quickly test it, that would be great! Thanks to Austin and François for the help thus far. Of course, all feedback welcome. TIA, Ken

2 3

Wiki RFC: Redirects, swarm tactics, etc.
by Kyle Auble 05 Aug '13

05 Aug '13

So I've finished with pretty much all of the edits I had in mind for the wiki, but before I ride off into the sunset for a while, I wanted to toss out a few ideas. 1. Do we want some kind of guideline on redirects for the wiki? Some stable "interface" pages to the main site might be good, but beyond that, I think minimizing redirects makes sense in this use case. 2. There's still a lot of old/missing content on the wiki, and much of it requres a good sense of where the code is at. Also, it might be too overwhelming for one person to work in depth on more than a few pages at this point. I feel like a semi-coordinated swarm of editing might be the best bet for further improvements. I was picturing a table of all relevant pages, then people could adopt one or two to work on, then strike/delete a record once that page is finished. Any thoughts? 3. There are actually a few more fixes to the theme code at the head of my bitbucket repo (and also branches for 2 different Moinmoin upgrade paths). I'm cool with keeping the theme code for the near future; if and when we move it onto WineHQ's git server though, just let me know so I can note that I'm not upstream anymore. 4. Finally, spammers... they keep coming... and they're getting smarter. We can mostly stalemate them with the regex filter, but it blocks legit edits too sometimes (in very annoying fashion). In fact, I think there are a few of them that have learned to turn the filter against us by completely wiping pages with false positives so we can't revert the page. Are there any relatively easy things we could do to cut the spam? I don't know, but it's possible the newer version of Moinmoin has more potent anti-spam tools. -Kyle

5 5

help [Abount Sql2005 and WMI]
by Jing Li 04 Aug '13

04 Aug '13

Hi, all: I have met a problem when installing sql2005, and it seems related to some WMI problems. As WMI has just been implemented in wine-1.6 ( right? ), I want to know in what degree it has been implemented.By the way is there anyone succeed in install of it? Thanks. Appreciate your kind help.

2 1

Vacation
by Alexandre Julliard 02 Aug '13

02 Aug '13

Folks, I'll be on vacation for the next 10 days, so you'll have to live without commits for a while... -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [docs] wineusr: Assorted formatting & tagging fixes (try 2)
by Alexandre Julliard 02 Aug '13

02 Aug '13

Frédéric Delanoy <frederic.delanoy(a)gmail.com> writes: > @@ -710,17 +714,18 @@ Path="c:\windows;c:\windows\system;e:\;e:\test;f:\" > choose between several edition modes: > <itemizedlist> > <listitem> > - <para> > - Emacs: the same keybindings as under > - emacs are available. For example, Ctrl-A > - will bring the cursor to the beginning > - of the edition line. See your emacs > - manual for the details of the commands. > - </para> > + <para> > + <literal>Emacs</literal>: the same keybindings as under > + <command>emacs</command> are available. For example, > + <keycombo><keycap>Ctrl</keycap><keycap>A</keycap></keycombo> > + will bring the cursor to the beginning > + of the edition line. See your <command>emacs</command> > + manual for the details of the commands. > + </para> Please avoid messing up the indentation. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: gdi32: Avoid a crash by loading AppKit before using Core Text if might use the Mac driver.
by Alexandre Julliard 02 Aug '13

02 Aug '13

Ken Thomases <ken(a)codeweavers.com> writes: > + /* If the Mac driver might be used, then load AppKit now before using the Core Text API. > + Otherwise, AppKit crashes on Mac OS X 10.7+ because CTFontDescriptor isn't toll-free > + bridged to NSCTFontDescriptor. That bridging is only set up if AppKit has been loaded > + when CTFontDescriptor is first used. */ > + /* @@ Wine registry key: HKCU\Software\Wine\Drivers */ > + if (!RegOpenKeyA(HKEY_CURRENT_USER, "Software\\Wine\\Drivers", &hkey)) > + { > + char buffer[MAX_PATH]; > + DWORD type, count = sizeof(buffer); > + > + if (!RegQueryValueExA(hkey, "Graphics", 0, &type, (LPBYTE) buffer, &count)) > + { > + char *name = buffer; > + > + usingMacDriver = FALSE; > + while (name) > + { > + char *next = strchr(name, ','); > + if (next) *next++ = 0; > + > + if (!strcmp(name, "mac")) > + { > + usingMacDriver = TRUE; > + break; > + } > + > + name = next; > + } > + } > + > + RegCloseKey(hkey); > + } That's ugly. freetype.c has no business knowing about the details of the graphics driver. -- Alexandre Julliard julliard(a)winehq.org

2 5

Re: riched20: Make ITextDocument stub reusable for ITextServices (try 4)
by Alexandre Julliard 02 Aug '13

02 Aug '13

Caibin Chen <tigersoldi(a)gmail.com> writes: > diff --git a/dlls/riched20/tomimpl.h b/dlls/riched20/tomimpl.h > new file mode 100644 > index 0000000..886c3a8 > --- /dev/null > +++ b/dlls/riched20/tomimpl.h > @@ -0,0 +1,59 @@ > +/* > + * RichEdit - TOM interfaces implementations > + * > + * Copyright 2013 by Caibin Chen > + * > + * This library is free software; you can redistribute it and/or > + * modify it under the terms of the GNU Lesser General Public > + * License as published by the Free Software Foundation; either > + * version 2.1 of the License, or (at your option) any later version. > + * > + * This library is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public > + * License along with this library; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA > + */ > + > +#ifndef __RICHOLE_H > +#define __RICHOLE_H > + > +#include <tom.h> > + > +#include "editstr.h" > + > +typedef struct ITextDocumentImpl ITextDocumentImpl; > +typedef struct ITextSelectionImpl ITextSelectionImpl; > + > +/* ITextDocument */ > + > +struct ITextDocumentImpl { > + ITextDocument ITextDocument_iface; > + IUnknown *outer_unk; > + ME_TextEditor *editor; > + ITextSelectionImpl *txtSel; > +}; You shouldn't need a new header either. Particularly since implementation details shouldn't be global. > +/** > + * Create an ITextDocumentImpl object, which acts as an inner object of COM aggression. I'm sure writing COM code can make you feel aggressive, but that's not the right term ;-) > + * > + * The ITextDocumentImpl object will delegate all of its IUnknown calls to the specified > + * {@code outer_unk}. > + * > + * @param outer_unk The outer objects that creates and delegates ITextDocument > + * method calls to the created ITextDocumentImpl. > + * @param editor The editor implementation. > + * > + * @return An ITextDocumentImpl object that should be destroyed with > + * {@code ITextDocumentImpl_destroy} > + */ Please don't use that sort of documentation markup. Besides, things like parameters and return should be obvious from the code, you shouldn't have to add documentation for this, especially not for internal functions. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: xmllite: Improve attribute value parsing
by Alexandre Julliard 02 Aug '13

02 Aug '13

Nikolay Sivov <nsivov(a)codeweavers.com> writes: > +static void reader_normalize_space(xmlreader *reader, WCHAR *ptr) > +{ > + encoded_buffer *buffer = &reader->input->buffer->utf16; > + > + if (!is_wchar_space(*ptr)) return; > + > + if (*ptr == '\r' && *ptr == '\n') That's not going to happen very often... -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] oleaut32: ERR on 32bit typelibs on 64bit
by Alexandre Julliard 02 Aug '13

02 Aug '13

Marcus Meissner <meissner(a)suse.de> writes: > Triggered by the Novell Groupwise installer currently, > from the ISBE64W.exe Installshield Helper program. > > The typelib is contained directly in ISBE64W.exe itself :/ > > Basically if we encounter this case the program will crash > anyway (but with random backtrace), so output an ERR(). That looks like it's just hiding the problem. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: d3dx9 [patch 1/2]: Implement D3DXCreatePolygon
by Matteo Bruni 02 Aug '13

02 Aug '13

2013/8/1 Nozomi Kodama <nozomi.kodama(a)yahoo.com>: > + vertices = HeapAlloc(GetProcessHeap(), 0, 2 * (sides + 1) * sizeof(D3DXVECTOR3)); + if (!vertices) + { + TRACE("Not memory enough for vertex buffer\n"); + polygon->lpVtbl->Release(polygon); + return E_OUTOFMEMORY; + } + + hr = polygon->lpVtbl->LockVertexBuffer(polygon, D3DLOCK_DISCARD, (VOID **)&vertices); Why are you allocating memory and immediately dropping track of it? Recheck how ID3DXMesh::LockVertexBuffer works. Also I'm having a deja-vu here, this patch looks suspiciously similar (up to having this same issue) to one I've already reviewed in the past.

2 1

appwiz: Correct Wine Mono installer title in several languages
by Ken Sharp 02 Aug '13

02 Aug '13

Hi Alexandre, http://source.winehq.org/patches/data/97460 should be correct but would I be right in assuming you would rather have the changes made along with the next string for each language?

2 4

Re: [PATCH 4/5] d3dx9/tests: Add ID3DXConstantTable struct test.
by Matteo Bruni 02 Aug '13

02 Aug '13

2013/7/24 Rico Schüller <kgbricola(a)web.de>: > --- > dlls/d3dx9_36/tests/shader.c | 308 > +++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 308 insertions(+) > This is okay, but as a followup can you add some tests with mixed-type structs? Something like: struct { float f; int i; bool b; }; If you have already written tests of this kind, I'd like to know what does the compiler do in this case :)

2 6

Re: [1/2] ntdll: Implement NtQueryEvent
by Alexandre Julliard 02 Aug '13

02 Aug '13

Andrew Cook <ariscop(a)gmail.com> writes: > diff --git a/dlls/ntdll/tests/Makefile.in b/dlls/ntdll/tests/Makefile.in > index 10d6674..a44b880 100644 > --- a/dlls/ntdll/tests/Makefile.in > +++ b/dlls/ntdll/tests/Makefile.in > @@ -7,6 +7,7 @@ C_SRCS = \ > directory.c \ > env.c \ > error.c \ > + event.c \ > exception.c \ > file.c \ > generated.c \ Please don't add a new file for just a couple of tests, merge this into an existing file. -- Alexandre Julliard julliard(a)winehq.org

1 0

jscript FTBFS in Cygwin 1.7.22
by Ken Sharp 02 Aug '13

02 Aug '13

Probably better to post this here rather than the forums: http://forum.winehq.org/viewtopic.php?f=2&t=19501 "Not sure if this is a Wine bug (as usual) so I'd rather put this here than to open a new bug. On Cygwin 1.7.22 the compilation stops at jscript, apparently a conflict in the declaration of dtoa. $ make ccache cc -c -I/home/ken/wine-git/dlls/jscript -I. -I/home/ken/wine-git/include -I../../include -D__WINESRC__ -D_REENTRANT -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wwrite-strings -Wpointer-arith -Wlogical-op -gdwarf-2 -gstrict-dwarf -fno-omit-frame-pointer -g -O0 -D_WIN32 -o jscript_main.o /home/ken/wine-git/dlls/jscript/jscript_main.c ccache cc -c -I/home/ken/wine-git/dlls/jscript -I. -I/home/ken/wine-git/include -I../../include -D__WINESRC__ -D_REENTRANT -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wwrite-strings -Wpointer-arith -Wlogical-op -gdwarf-2 -gstrict-dwarf -fno-omit-frame-pointer -g -O0 -D_WIN32 -o lex.o /home/ken/wine-git/dlls/jscript/lex.c ccache cc -c -I/home/ken/wine-git/dlls/jscript -I. -I/home/ken/wine-git/include -I../../include -D__WINESRC__ -D_REENTRANT -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wwrite-strings -Wpointer-arith -Wlogical-op -gdwarf-2 -gstrict-dwarf -fno-omit-frame-pointer -g -O0 -D_WIN32 -o number.o /home/ken/wine-git/dlls/jscript/number.c /home/ken/wine-git/dlls/jscript/number.c:57:20: error: conflicting types for ‘dtoa’ In file included from /home/ken/wine-git/include/wine/port.h:47:0, from /home/ken/wine-git/dlls/jscript/number.c:20: /usr/include/stdlib.h:161:35: note: previous declaration of ‘dtoa’ was here Makefile:199: recipe for target `number.o' failed make: *** [number.o] Error 1 dlls/jscript/number.c: static inline void dtoa(double d, WCHAR *buf, int size, int *dec_point) /usr/include/stdlib.h: char * _EXFUN(dtoa,(double, int, int, int *, int*, char**));"

1 0

Re: ntdll: Implement compatible FindActCtxSectionString() for window class section (try3)
by Alexandre Julliard 02 Aug '13

02 Aug '13

Nikolay Sivov <nsivov(a)codeweavers.com> writes: > @@ -1031,6 +1105,17 @@ static BOOL parse_window_class_elem(xmlbuf_t* xmlbuf, struct dll_redirect* dll) > > if (!(entity->u.class.name = xmlstrdupW(&content))) return FALSE; > > + /* each class entry needs index, data and string data */ > + acl->actctx->wndclass_section_len += sizeof(struct wndclass_index); > + acl->actctx->wndclass_section_len += sizeof(struct wndclass_redirect_data); > + /* original name is stored separately */ > + acl->actctx->wndclass_section_len += aligned_string_len((content.len+1)*sizeof(WCHAR)); > + /* versioned name and module name are stored one after another */ > + len = get_assembly_version(assembly, NULL) + content.len + 2 /* null terminator and '!' separator */; > + len += strlenW(dll->name) + 1; > + acl->actctx->wndclass_section_len += aligned_string_len(len*sizeof(WCHAR)); > + acl->actctx->wndclass_count++; > + It would be better to do this at the time you build the structure. The parser shouldn't need to worry about this. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: po: Add English (Canada) resource [Take 2]
by Ken Sharp 02 Aug '13

02 Aug '13

Please disregard this patch. I missed a couple of words and with those corrected en_CA.po becomes identical to en.po (except that "serialisation" is fuzzy) and Wine defaults to that anyway for Canadian English. Will re-submit if there are any changes (just noticed -able/-eable). Will keep an eye on the English translations. On 30/07/13 22:37, Ken Sharp wrote: > - Re-based to latest git > - Removed all the fuzzies thanks to http://www.etymonline.com/index.php > > Turns out all the -ise/-ize words used in Wine are of Latin origin anyway. > > > -------- Original Message -------- > Subject: po: Add English (Canada) resource > Date: Mon, 22 Jul 2013 19:28:51 +0100 > From: Ken Sharp <kennybobs(a)o2.co.uk> > To: wine-patches(a)winehq.org > > Canadian English follows some British/French rules but not others. > > I have left some of the -ise/-ize words fuzzy because: > > "the etymological convention that verbs derived from Greek roots are > spelled with -ize and those from Latin with -ise is preserved in that > practice." > http://en.wikipedia.org/wiki/Canadian_english#Spelling_and_dictionaries > > I tried looking for the origins of the words and I couldn't get any. The > non-fuzzies are correct. > > With British, US and Canadian I believe all the English variations (used > in Wine) are covered, except Philippines (follows US rules). > > >

1 1

Re: reg.exe: Add query function
by Nikolay Sivov 02 Aug '13

02 Aug '13

On 8/1/2013 17:44, Hugh McMaster wrote: > This patch builds significantly on the query function stub in programs/reg.exe. The patch includes recursion for subkeys. > > Some examples of usage: > > wine reg.exe query "HKCU" > wine reg.exe query "HKCU\Console" > wine reg.exe query "HKCU\Console" /v "ScreenSize" > wine reg.exe query "HKCU\Software" /s > > --- > programs/reg/reg.c | 232 +++++++++++++++++++++++++++++++++++++++++++++++++--- > 1 file changed, 221 insertions(+), 11 deletions(-) > > +static LPVOID WINAPI mem_alloc(size_t size) > +{ > + return HeapAlloc(GetProcessHeap(), 0, size); > +} > + > +static void WINAPI mem_free(LPVOID mem) > +{ > + HeapFree(GetProcessHeap(), 0, mem); > +} Why WINAPI? It's better to follow naming from existing module, there's plenty of them with similar helpers. > + case REG_SZ: > + case REG_MULTI_SZ: > + case REG_EXPAND_SZ: No tabs please. > +static void reg_output_subkey(LPWSTR key_name, LPWSTR subkeyName) > +{ > + reg_printfW(formatSW, key_name); > + > + if (subkeyName > 0) > + { > + reg_printfW(formatSW, slashW); > + reg_printfW(formatSW, subkeyName); > + reg_printfW(formatSW, newlineW); > + } > +} Comparison looks a bit odd. Also why do you need to break it down to three printf calls instead of one? > + p = strchrW(key_name,'\\'); > + if (!p) > + { > + p = 0; > + } > + else p++; I'm not sure what this is supposed to do. > + case REG_BINARY: > + case REG_NONE: > + pValue = value; > + for (i=0; i<valueSize; i++, pValue++) > + reg_printfW(formatXW, *pValue); > + break; There's no need for separate variable here nor for incrementing pointer.

2 3

Clang warns on "wrong" header guard in "config.h"
by Charles Davis 02 Aug '13

02 Aug '13

Hi, I've been building Wine with Clang, and it (apparently, unlike GCC) produces warnings like this: ../../include/config.h:4:9: warning: 'WINE_CROSSTEST' is used as a header guard here, followed by #define of a different macro [-Wheader-guard] #ifndef WINE_CROSSTEST ^~~~~~~~~~~~~~ ../../include/config.h:5:9: note: '__WINE_CONFIG_H' is defined here; did you mean 'WINE_CROSSTEST'? #define __WINE_CONFIG_H ^~~~~~~~~~~~~~~ WINE_CROSSTEST I tracked this down to these three lines in configure.ac: AH_TOP([#ifndef WINE_CROSSTEST #define __WINE_CONFIG_H]) AH_BOTTOM([#endif /* WINE_CROSSTEST */]) These lines generate what Clang thinks is the header guard for the "config.h" header, but we know that it isn't--that header AFAICT has never had an include guard, and __WINE_CONFIG_H is just there to indicate that it's been included. Should we change the __WINE_CONFIG_H macro to be a real header guard instead, or (as I'll admit it has been in the past) is Clang broken here? I'd imagine you guys don't want to rig configure to add -Wno-header-guard to CFLAGS if you can help it. I will point out that lots of these warnings are generated when building with Clang, because (for obvious reasons) this particular header is included all over the place. It makes it harder to see real warnings (like the ones that caused AJ not to commit my last two patches). And please don't tell me to use GCC instead. I suspect that GCC might pick up a similar warning--there's been lots of cross pollination going on between GCC and Clang, so we might have to deal with this sooner or later--and I'd prefer sooner. (I know the commit that added the WINE_CROSSTEST checks is from over 3 years ago, but this warning was only added recently to Clang, which is why I'm only bringing this up now.) Chip

2 1

Re: [PATCH] d3dx9_36: Implement ID3DXEffect_FindNextValidTechnique + add tests.
by Rico Schüller 02 Aug '13

02 Aug '13

On 02.08.2013 00:03, Christian Costa wrote: > + technique = (D3DXHANDLE)0xdeadbeef; > + hr = effect->lpVtbl->FindNextValidTechnique(effect, technique1, &technique); > + ok(hr == D3D_OK, "FindNextValidTechnique failed, got %#x, expected %#x\n", hr, D3D_OK); > + ok(technique == technique2, "Technique returned %p, expected %p\n", technique, technique2); > + > + technique = (D3DXHANDLE)0xdeadbeef; > + hr = effect->lpVtbl->FindNextValidTechnique(effect, technique2, &technique); > + ok(hr == S_FALSE, "FindNextValidTechnique, got %#x, expected %#x\n", hr, S_FALSE); Looks fine to me, but I found one minor issue. I'd write "FindNextValidTechnique failed, ..." as in the line above. Cheers Rico

1 0

Re: [11/11] apphelp: Add tests.
by Marvin 01 Aug '13

01 Aug '13

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 http://testbot.winehq.org/JobDetails.pl?Key=26579 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

gdi32: Don't let the gdi32 driver allocate memory in the dplayx region.
by Alexei Svitkine 01 Aug '13

01 Aug '13

Don't let the gdi32 driver allocate memory in the dplayx region. Fixes bug: http://bugs.winehq.org/show_bug.cgi?id=34095 The issue is that the dplayx code in wine needs to allocate some memory at a static address (0x50000000) and loading the Mac native gdi driver ends up using that part of the address space. This patch fixes that by reserving that part of memory while the display driver is initialized and releasing it after. --- dlls/gdi32/driver.c | 10 ++++++++++ 1 file changed, 10 insertions(+)

2 5

Re: [PATCH 1/4] d3dx9: Track ID3DXEffect::Begin/End().
by Bruno Jesus 01 Aug '13

01 Aug '13

On Thu, Aug 1, 2013 at 9:14 AM, Rico Schüller <kgbricola(a)web.de> wrote: > --- > dlls/d3dx9_36/effect.c | 13 ++++++++++--- > 1 file changed, 10 insertions(+), 3 deletions(-) > > + if (!This->started) > + return D3D_OK; > + > + This->started = FALSE; > + > + return D3D_OK; Sorry to bother but why not simply force false and using a single return? Best wishes, Bruno

2 1

Re: [PATCH 1/11] apphelp: Add definitions.
by Alexandre Julliard 01 Aug '13

01 Aug '13

Mislav Blazevic <krofnica996(a)gmail.com> writes: > @@ -25,6 +26,209 @@ extern "C" { > > BOOL WINAPI ApphelpCheckShellObject(REFCLSID, BOOL, ULONGLONG *); > > +typedef enum _PATH_TYPE { > + DOS_PATH, > + NT_PATH > +} PATH_TYPE; > + > +typedef struct _DB { > + HANDLE file; > + DWORD size; > + PBYTE data; > +} DB, *PDB; > + > +typedef DWORD TAGID; > +typedef WORD TAG; > + > +#define TAGID_NULL 0x0 > +#define TAGID_ROOT 0x0 > + > +/* The above definition of TAGID_ROOT is used in winapi but doesn't make > + * sense, especially internally, because TAGID represents offset into > + * database data and there is a header at offset 0, NOT a tag. > + * Therfore, this definition should only be used internally. */ > +#define _TAGID_ROOT 0xC If it's internal it shouldn't be in the public header. In fact I don't see any of these definitions in the SDK header. -- Alexandre Julliard julliard(a)winehq.org

1 0

reg.exe: Add query function
by Hugh McMaster 01 Aug '13

01 Aug '13

This patch significantly builds on the query function stub in programs/reg.exe. The patch includes recursion for subkeys. Some examples of usage: wine reg.exe query "HKCU" wine reg.exe query "HKCU\Console" wine reg.exe query "HKCU\Console" /v "ScreenSize" wine reg.exe query "HKCU\Software" /s --- programs/reg/reg.c | 232 +++++++++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 221 insertions(+), 11 deletions(-)

2 2

Re: [PATCH 2/2] ddraw: Fix double to float conversion warnings
by Henri Verbeet 01 Aug '13

01 Aug '13

On 1 August 2013 12:25, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > diff --git a/dlls/ddraw/executebuffer.c b/dlls/ddraw/executebuffer.c > index 2925cfa..5c12272 100644 > --- a/dlls/ddraw/executebuffer.c > +++ b/dlls/ddraw/executebuffer.c > @@ -382,10 +382,10 @@ HRESULT d3d_execute_buffer_execute(struct d3d_execute_buffer *buffer, > dst->u8.tv = src->u8.tv; > > /* Now, the matrix multiplication */ > - dst->u1.sx = (src->u1.x * mat._11) + (src->u2.y * mat._21) + (src->u3.z * mat._31) + (1.0 * mat._41); > - dst->u2.sy = (src->u1.x * mat._12) + (src->u2.y * mat._22) + (src->u3.z * mat._32) + (1.0 * mat._42); > - dst->u3.sz = (src->u1.x * mat._13) + (src->u2.y * mat._23) + (src->u3.z * mat._33) + (1.0 * mat._43); > - dst->u4.rhw = (src->u1.x * mat._14) + (src->u2.y * mat._24) + (src->u3.z * mat._34) + (1.0 * mat._44); > + dst->u1.sx = (src->u1.x * mat._11) + (src->u2.y * mat._21) + (src->u3.z * mat._31) + (1.0f * mat._41); > + dst->u2.sy = (src->u1.x * mat._12) + (src->u2.y * mat._22) + (src->u3.z * mat._32) + (1.0f * mat._42); > + dst->u3.sz = (src->u1.x * mat._13) + (src->u2.y * mat._23) + (src->u3.z * mat._33) + (1.0f * mat._43); > + dst->u4.rhw = (src->u1.x * mat._14) + (src->u2.y * mat._24) + (src->u3.z * mat._34) + (1.0f * mat._44); > I get where the 1.0f comes from, but I think you might as well just remove the multiplication completely. And please get rid of the tabs if you're resending anyway.

1 0

Re: windowscodecs: Workaround libtiff bug when it defines toff_t as 32-bit for 32-bit builds. Take 3.
by Alexandre Julliard 01 Aug '13

01 Aug '13

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > @@ -208,9 +233,22 @@ static TIFF* tiff_open_stream(IStream *stream, const char *mode) > zero.QuadPart = 0; > IStream_Seek(stream, zero, STREAM_SEEK_SET, NULL); > > + /* Workaround for broken libtiff 4.x headers on some 64-bit hosts which > + * define TIFF_UINT64_T/toff_t as 32-bit for 32-bit builds, while they > + * are supposed to be always 64-bit. > + * TIFF_UINT64_T doesn't exist in libtiff 3.x, it was introduced in 4.x. > + */ > +#ifdef TIFF_UINT64_T > + /* libtiff 4.x */ > + return pTIFFClientOpen("<IStream object>", mode, stream, tiff_stream_read, > + tiff_stream_write, (void *)tiff_stream_seek, tiff_stream_close, > + (void *)tiff_stream_size, (void *)tiff_stream_map, (void *)tiff_stream_unmap); > +#else > + /* libtiff 3.x */ > return pTIFFClientOpen("<IStream object>", mode, stream, tiff_stream_read, > - tiff_stream_write, tiff_stream_seek, tiff_stream_close, > - tiff_stream_size, tiff_stream_map, tiff_stream_unmap); > + tiff_stream_write, tiff_stream_seek_v3, tiff_stream_close, > + tiff_stream_size_v3, tiff_stream_map_v3, tiff_stream_unmap_v3); > +#endif Now that you are using ifdefs there's no reason to have two sets of functions. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: oledb32: Add IDataSourceLocator support
by Alistair Leslie-Hughes 01 Aug '13

01 Aug '13

Ignore this patch On 1/08/2013 6:36 PM, Alistair Leslie-Hughes wrote: > Hi, > > > Changelog: > oledb32: Add IDataSourceLocator support > > > Best Regards > Alistair Leslie-Hughes > > >

1 0

Re: Re: apphelp: Implement SdbTagToString.
by Marvin 01 Aug '13

01 Aug '13

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 http://testbot.winehq.org/JobDetails.pl?Key=26567 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

Re: [PATCH 11/11] appelp: Add tests.
by Marvin 31 Jul '13

31 Jul '13

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 http://testbot.winehq.org/JobDetails.pl?Key=26546 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

Re: [PATCH 1/4] riched20: Basic ITextDocument implementation for ITextServices (try 3)
by Alexandre Julliard 31 Jul '13

31 Jul '13

Caibin Chen <tigersoldi(a)gmail.com> writes: > Thanks Jacek for reviewing. This time I send all the changes I have in > 4 patches to make it clear that ReTxtDoc is reused between txtsrv.c > and richole.c > - Suppressed Patch 97331 > - Change log from try 2: > - follow COM naming convention > - move ReTxtDoc definition to header, removed > ReTxtDoc_get_ITextDocument() function > - remove COM aggregation test for ITextDocument, only test > ITextService supports querying for the interface. > > --- > dlls/riched20/Makefile.in | 1 + > dlls/riched20/tests/txtsrv.c | 10 ++ > dlls/riched20/txtdoc.c | 270 +++++++++++++++++++++++++++++++++++++++++++ > dlls/riched20/txtdoc.h | 51 ++++++++ > dlls/riched20/txtsrv.c | 6 + Please avoid adding too many source files. In particular, if you have to add new headers and define objects there, it's a sign that things should be grouped in the same file. That's even more true for ITextDocument that already exists. -- Alexandre Julliard julliard(a)winehq.org

2 4

Re: [PATCH] d3dx9_36: Filter out D3DCompile warning messages that are not present with D3DCompileShader.
by Stefan Dösinger 31 Jul '13

31 Jul '13

Hi, Am 31.07.2013 um 09:10 schrieb Christian Costa <titan.costa(a)gmail.com>: > + if (!(strstr(line_out, "warning X3206:") && strstr(line_out, "implicit truncation of vector type"))) > + line_out += line_size; msvc localizes compiler errors and warnings. Are you sure d3dcompiler.dll doesn't do that? Wrt the parsing code, wouldn't it be nicer to use strtok_r to split the buffer into separate lines? I am not sure that parsing the errors and warnings like that is a good thing, but I don't know d3dx9 and d3dcompiler well enough to give a final judgement on that.

2 2

Re: ws2_32/tests: Test the precedence of parameters while creating a socket in WSASocket()
by Austin English 31 Jul '13

31 Jul '13

On Tue, Jul 30, 2013 at 5:13 PM, Bruno Jesus <00cpxxx(a)gmail.com> wrote: > > You forgot the patch. -- -Austin

3 2

d3dx9: Replace M_PI by its D3DX equivalent
by Nozomi Kodama 31 Jul '13

31 Jul '13

What is the problem with patch: http://source.winehq.org/patches/data/97500 M_PI is never used in D3DX (moreover it is deprecated in C99) Nozomi

2 1

Re: kernel32: Fix parameters checking for GetVolumePathName()
by Alexandre Julliard 31 Jul '13

31 Jul '13

Bruno Jesus <00cpxxx(a)gmail.com> writes: > @@ -1813,6 +1821,8 @@ BOOL WINAPI GetVolumePathNameW(LPCWSTR filename, LPWSTR volumepathname, DWORD bu > volumepathname[3] = 0; > return TRUE; > } > + > + SetLastError(ERROR_FILENAME_EXCED_RANGE); > return FALSE; This doesn't really make sense as a general error. -- Alexandre Julliard julliard(a)winehq.org

1 0

d3dx9: Replace M_PI by its D3DX equivalent
by Nozomi Kodama 31 Jul '13

31 Jul '13

Hello What is the problem with patch http://source.winehq.org/patches/data/97500 M_PI is never used in D3DX. Nozomi

1 0

Re: msxml3: Unescape '&' back to '&' in attribute value
by Marvin 31 Jul '13

31 Jul '13

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 http://testbot.winehq.org/JobDetails.pl?Key=26523 Your paranoid android. === W2KPROSP4 (32 bit saxreader) === saxreader.c:2334: Test failed: len 30 (L" attr_value A & & "), expected 29 ( attr_value A & & ) saxreader.c:2334: Test failed: len 30 (L" attr_value A & & "), expected 29 ( attr_value A & & ) === WXPPROSP2 (32 bit saxreader) === saxreader.c:2334: Test failed: len 30 (L" attr_value A & & "), expected 29 ( attr_value A & & ) saxreader.c:2334: Test failed: len 30 (L" attr_value A & & "), expected 29 ( attr_value A & & ) === WXPX64 (32 bit saxreader) === saxreader.c:2334: Test failed: len 30 (L" attr_value A & & "), expected 29 ( attr_value A & & ) saxreader.c:2334: Test failed: len 30 (L" attr_value A & & "), expected 29 ( attr_value A & & ) === W2K3R2SESP2 (32 bit saxreader) === saxreader.c:2334: Test failed: len 30 (L" attr_value A & & "), expected 29 ( attr_value A & & ) saxreader.c:2334: Test failed: len 30 (L" attr_value A & & "), expected 29 ( attr_value A & & ) === WVISTAX64 (32 bit saxreader) === saxreader.c:2334: Test failed: len 30 (L" attr_value A & & "), expected 29 ( attr_value A & & ) saxreader.c:2334: Test failed: len 30 (L" attr_value A & & "), expected 29 ( attr_value A & & ) saxreader.c:2334: Test failed: len 30 (L" attr_value A & & "), expected 29 ( attr_value A & & ) === W2K8SE (32 bit saxreader) === saxreader.c:2334: Test failed: len 30 (L" attr_value A & & "), expected 29 ( attr_value A & & ) saxreader.c:2334: Test failed: len 30 (L" attr_value A & & "), expected 29 ( attr_value A & & ) saxreader.c:2334: Test failed: len 30 (L" attr_value A & & "), expected 29 ( attr_value A & & ) === W7PROX64 (32 bit saxreader) === saxreader.c:2334: Test failed: len 30 (L" attr_value A & & "), expected 29 ( attr_value A & & ) saxreader.c:2334: Test failed: len 30 (L" attr_value A & & "), expected 29 ( attr_value A & & ) saxreader.c:2334: Test failed: len 30 (L" attr_value A & & "), expected 29 ( attr_value A & & ) === TEST64_W7SP1 (32 bit saxreader) === saxreader.c:2334: Test failed: len 30 (L" attr_value A & & "), expected 29 ( attr_value A & & ) saxreader.c:2334: Test failed: len 30 (L" attr_value A & & "), expected 29 ( attr_value A & & ) saxreader.c:2334: Test failed: len 30 (L" attr_value A & & "), expected 29 ( attr_value A & & ) === WXPX64 (64 bit saxreader) === saxreader.c:2334: Test failed: len 30 (L" attr_value A & & "), expected 29 ( attr_value A & & ) saxreader.c:2334: Test failed: len 30 (L" attr_value A & & "), expected 29 ( attr_value A & & ) === WVISTAX64 (64 bit saxreader) === saxreader.c:2334: Test failed: len 30 (L" attr_value A & & "), expected 29 ( attr_value A & & ) saxreader.c:2334: Test failed: len 30 (L" attr_value A & & "), expected 29 ( attr_value A & & ) saxreader.c:2334: Test failed: len 30 (L" attr_value A & & "), expected 29 ( attr_value A & & ) === W7PROX64 (64 bit saxreader) === saxreader.c:2334: Test failed: len 30 (L" attr_value A & & "), expected 29 ( attr_value A & & ) saxreader.c:2334: Test failed: len 30 (L" attr_value A & & "), expected 29 ( attr_value A & & ) saxreader.c:2334: Test failed: len 30 (L" attr_value A & & "), expected 29 ( attr_value A & & ) === TEST64_W7SP1 (64 bit saxreader) === saxreader.c:2334: Test failed: len 30 (L" attr_value A & & "), expected 29 ( attr_value A & & ) saxreader.c:2334: Test failed: len 30 (L" attr_value A & & "), expected 29 ( attr_value A & & ) saxreader.c:2334: Test failed: len 30 (L" attr_value A & & "), expected 29 ( attr_value A & & )

1 0

Re: kernel32/tests: Improve GetVolumePathNameA tests
by Bruno Jesus 30 Jul '13

30 Jul '13

Please ignore this patch, I understand that as is it will not be commited. On Tue, Jul 30, 2013 at 3:30 AM, Bruno Jesus <00cpxxx(a)gmail.com> wrote: > Erich Hoover contacted me about a patch he sent months ago related to > GetVolumePathNameA. He developed a better test infrastructure using a > for loop instead of multiple repetitions of test lines. This patch > will make it easier for him to rebase and send his tests and function > implementation later. > > I used the same approach from [1] by decomposing the "todo_wine" in > winetest_start_todo("wine") and winetest_end_todo("wine"). > > http://source.winehq.org/source/programs/cmd/tests/batch.c#L292 -- universe* god::bigbang (void); //and then it all began...

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel