September 2014 - Wine-devel

Re: (resend)[3/6]dwrite: Implement GetInformationalStrings
by Alexandre Julliard 05 Sep '14

05 Sep '14

Aric Stewart <aric(a)codeweavers.com> writes: > @@ -53,6 +54,8 @@ struct dwrite_font_data { > DWRITE_FONT_SIMULATIONS simulations; > DWRITE_FONT_METRICS metrics; > > + IDWriteLocalizedStrings *info_strings[23]; Where does this 23 come from? -- Alexandre Julliard julliard(a)winehq.org

2 3

Re: [3/6]dwrite: Implement GetInformationalStrings
by Alexandre Julliard 05 Sep '14

05 Sep '14

Aric Stewart <aric(a)codeweavers.com> writes: > read strings from OpenType 'name' table opentype.c: In function ‘get_name_font_table_data’: opentype.c:470:12: error: variable ‘format’ set but not used [-Werror=unused-but-set-variable] -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: dpnet: Stub interface IDirectPlay8LobbyClient (try 4 - resend)
by Alexandre Julliard 05 Sep '14

05 Sep '14

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: > Hi, > Moved to be client.c. > Flags are printed as 0x%08x. > > Putting the tests in with client.c doesn't make much sense, since > they wont share code. Creating a new file for a 10-line test makes even less sense. Maybe at some point it will be big enough to have its own file, but for now please avoid creating new files when not necessary. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: configure: Fix detection of ncurses library on Archlinux.
by Alexandre Julliard 04 Sep '14

04 Sep '14

Sebastian Lackner <sebastian(a)fds-team.de> writes: > On Archlinux the libncurses library is just an ASCII text file > containing "INPUT(-lncursesw)" to force the linker to use libncursesw > instead. AC_LINK_IFELSE succeeds, but afterwards, when > WINE_CHECK_SONAME tries to figure out the name it fails because it > doesn't recognize libncursesw.so as the same library. Using a regexp > as pattern is the easiest solution to fix this. That doesn't do the right thing on Mac OS: #define SONAME_LIBNCURSES " /sw/lib/ncurses/libncurses.5.dylib (compatibility version 5.0.0, current version 5.0.0)" -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 1/5] widl: Introduce an "aggregate_return" function attribute.
by Alexandre Julliard 04 Sep '14

04 Sep '14

Henri Verbeet <hverbeet(a)codeweavers.com> writes: > For MSVC style handling of aggregate return values. This probably doesn't make > anyone particularly happy; I'm open to suggestions. It may be possible to do > this without an attribute, based on the function declaration, but then we'd > have to figure out how MSVC decides when to use registers and when to use the > stack for the return value. The attribute is certainly ugly. Also it seems to me you are doing this the wrong way around; you don't want to add a return parameter, you want to avoid one. Check how div() is handled. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: (resend/renumber)[6/14]dwrite: code to add fonts to a fontfamily
by Alexandre Julliard 04 Sep '14

04 Sep '14

Aric Stewart <aric(a)codeweavers.com> writes: > @@ -968,6 +968,28 @@ static const IDWriteFontFamilyVtbl fontfamilyvtbl = { > dwritefontfamily_GetMatchingFonts > }; > > +static HRESULT fontfamily_AddFont(struct dwrite_fontfamily *family, IDWriteFont *font) > +{ > + struct dwrite_font *font_data = impl_from_IDWriteFont(font); > + > + if (family->font_count + 1 >= family->alloc) > + { > + struct dwrite_font_data **new_list; > + UINT32 new_alloc; > + new_alloc = family->alloc * 2; > + new_list = heap_realloc(family->fonts, sizeof(*family->fonts) * new_alloc); > + if (!new_list) > + return E_OUTOFMEMORY; > + family->fonts = new_list; > + family->alloc = new_alloc; > + } > + > + family->fonts[family->font_count] = font_data->data; > + InterlockedIncrement(&font_data->data->ref); > + family->font_count++; > + return S_OK; > +} Please don't add dead code. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH] ddrawex: Don't leak surfaces.
by Henri Verbeet 04 Sep '14

04 Sep '14

On 4 September 2014 13:18, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > dds_get_outer AddRefs the inner surface when it creates the wrapper > surface. The wrapper releases only one reference when it is destroyed, > leaking one of the two. AddRefing in dds_get_outer makes sense because > this is also used by e.g. GetAttachedSurface, where it creates a new > wrapper for surfaces ddrawex didn't know about yet. > > Whether native ddrawex.dll properly handles GetAttachedSurfaces and > friends is an open question. We already know it doesn't properly handle > IDirectDraw4::GetSurfaceFromDC, even though the equivalent ddraw3 method > works. On a related note, I think it's unfortunate that dds_get_outer() creates a wrapper surface with refcount 1 if it doesn't exist yet, but doesn't AddRef() existing interfaces when returning them. That means the caller effectively needs to know if the wrapper already exists or not in order to do proper refcounting.

1 0

[PATCH 1/4] reg.exe: Add path_get_key() to remove boilerplate
by Hugh McMaster 04 Sep '14

04 Sep '14

On Wed, 3 Sep 2014 14:54:44 +0200, Jonathan Vollebregt wrote: > + if (path[0] == '\\') > + { > + path++; > + } > + if (path[0] == '\\') > + { > + reg_message(STRING_NO_REMOTE); > + return NULL; > + } This would be valid if the path was something like \\remote-machine\HKLM. But if the first if block was true and the second block was false, the registry path is invalid. Windows does not accept registry paths such as \HKLM. In summary: True + True = valid path, but not supported in Wine. True + False = invalid path False + True = impossible False + False = valid path The original check was better: if (key_name[0] == '\\' && key_name[1] == '\\') { reg_message(STRING_NO_REMOTE); return 1; } It was also unclear why you perform the path[0] == '\\' check in path_get_key() and path_get_rootkey_name(). One common check should be enough. The original version of this patch did this (now superseded). But I see you made some changes around the reg_delete() function.

2 1

Re: [5/17]dwrite: Shift to using localized string for family name
by Nikolay Sivov 04 Sep '14

04 Sep '14

> +HRESULT clone_localizedstring(IDWriteLocalizedStrings *iface, IDWriteLocalizedStrings **strings) This looks unnecessary, as you can do create_localizedstrings() and a series of add_localizedstring() after.

2 2

Re: (resend/renumber)[4/14]dwrite: implement a list of font data for IDWriteFontFamily
by Alexandre Julliard 03 Sep '14

03 Sep '14

Aric Stewart <aric(a)codeweavers.com> writes: > @@ -1121,6 +1188,24 @@ static void get_font_properties(struct dwrite_font *font, HDC hdc) > } > } > > +static HRESULT create_font_from_data(struct dwrite_font_data *data, IDWriteFont **font) > +{ > + HRESULT hr; > + struct dwrite_font *This; > + > + hr = create_font_base(font); > + if (FAILED(hr)) > + return hr; > + > + This = impl_from_IDWriteFont(*font); > + > + heap_free(This->data); > + This->data = data; > + InterlockedIncrement(&This->data->ref); > + > + return S_OK; > +} That looks unnecessarily complicated. Why allocate and initialize the data only to immediately replace it? -- Alexandre Julliard julliard(a)winehq.org

2 2