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

Re: kernel32: Partially implement GetGeoInfo()

by Nikolay Sivov

On 07/08/2014 04:49 AM, Dmitry Timoshkov wrote: > Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > >>> Some of this info already exists in the locale data under dlls/kernel32/nls >>> and returned by GetLocaleInfo(), probably it would be a good idea to add >>> missing geo data there as well (auto-generate from the public source) and >>> use it from inside of GetGeoInfo(). >> This patch implements geotypes that don't belong to nls, meaning they >> don't depend on locale. >> Other types like friendly name and country name as localized, and I'll >> plan to add them to nls files. > Wouldn't it be easier to just map geo id to locale id instead of creating > a completely separate data set? That way mapping between locale and geo > info would look something like this: > > GEO_ISO2 -> LOCALE_SISO3166CTRYNAME > GEO_ISO3 -> LOCALE_SABBREVCTRYNAME Well, you don't have locale info for all supported locations. > GEO_RFC1766 -> LOCALE_SISO639LANGNAME (mlang uses this mapping) This one doesn't work like that, it's synthesized from location and specified langid. > GEO_FRIENDLYNAME -> something appropriate > GEO_OFFICIALNAME -> something appropriate > What's appropriate for that is to add ~300*2 localized strings for each locale Wine supports, and that's where we need nls files. We also need to support the rest of types, like GEO_LATITUDE/LONGITUDE and GET_ISO_UN_NUMBER. Both are mapped by location id, so even if it'd be possible to reuse something we already have (and I don't think it is) we still need a mapping table for the rest of supported data.

July 7, 2014

Re: kernel32: Partially implement GetGeoInfo()

by Dmitry Timoshkov

Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > > Some of this info already exists in the locale data under dlls/kernel32/nls > > and returned by GetLocaleInfo(), probably it would be a good idea to add > > missing geo data there as well (auto-generate from the public source) and > > use it from inside of GetGeoInfo(). > This patch implements geotypes that don't belong to nls, meaning they > don't depend on locale. > Other types like friendly name and country name as localized, and I'll > plan to add them to nls files. Wouldn't it be easier to just map geo id to locale id instead of creating a completely separate data set? That way mapping between locale and geo info would look something like this: GEO_ISO2 -> LOCALE_SISO3166CTRYNAME GEO_ISO3 -> LOCALE_SABBREVCTRYNAME GEO_RFC1766 -> LOCALE_SISO639LANGNAME (mlang uses this mapping) GEO_LCID -> mapped lcid GEO_FRIENDLYNAME -> something appropriate GEO_OFFICIALNAME -> something appropriate -- Dmitry.

July 7, 2014

Re: Wine development questions

by Vincent Povirk

This would've been more appropriate on wine-users. > - If a patch/commit has a bad impact for users why not remove it, especially > if a possible solution is not accepted? Reverting it would break whatever that patch was supposed to fix. > -This summer sale i bought Tomb Raider 2013 on steam just to find the game > playable only with a patch on bugzilla. Is it only a case of the patch not > having come through the correct channels.Can it be accepted ? Its not a > single case. Which bug and patch are you referring to?

July 7, 2014

Wine development questions

by Rui Caridade

Hello all, Some software i use has been negatively affected by some patches, namely Ken's work on WGL My question's are: - If a patch/commit has a bad impact for users why not remove it, especially if a possible solution is not accepted? -This summer sale i bought Tomb Raider 2013 on steam just to find the game playable only with a patch on bugzilla. Is it only a case of the patch not having come through the correct channels.Can it be accepted ? Its not a single case. All the best everyone.

July 7, 2014

Re: kernel32: Partially implement GetGeoInfo()

by Alexandre Julliard

Nikolay Sivov <nsivov(a)codeweavers.com> writes: > -INT WINAPI GetGeoInfoW(GEOID GeoId, GEOTYPE GeoType, LPWSTR lpGeoData, > - int cchData, LANGID language) > +struct geoinfo_t { > + char iso2A[3]; > + char iso3A[4]; > + WCHAR iso2W[3]; > + WCHAR iso3W[4]; > + INT uncode; > +}; Surely you don't need both A and W versions of every string. -- Alexandre Julliard julliard(a)winehq.org

July 7, 2014

Re: [PATCH 3/4] ddraw/tests: Add tests for lost P8 primaries.

by Alexandre Julliard

Stefan Dösinger <stefan(a)codeweavers.com> writes: > The explicit request of DDSCAPS_VIDEOMEMORY is needed to work around two > bugs in Wine's ddraw that are not the concern of this test: If neither > SYSTEMMEMORY nor VIDEOMEMORY are requested we use SYSTEMMEMORY for P8 > surfaces because check_device_format fails. The next patch addresses > this. The second problem is that we do not lose system memory surfaces > on SetCooperativeLevel even though we should. (We should at least lose > primaries. I haven't checked offscreen or texture surfaces.) > > I don't feel strongly about having this test included. I'm happy with > just sending it as a documentation that SetCooperativeLevel does not > have to restore the palette. If the DDSCAPS_VIDEOMEMORY is considered > ugly, or the fix in the next patch wrong just ignore the patches. I do > not know any game that depends on the behavior tested here or the > behavior changed in the next patch. > --- > dlls/ddraw/tests/ddraw1.c | 141 +++++++++++++++++++++++++++++++++++++++++++ > dlls/ddraw/tests/ddraw2.c | 141 +++++++++++++++++++++++++++++++++++++++++++ > dlls/ddraw/tests/ddraw4.c | 141 +++++++++++++++++++++++++++++++++++++++++++ > dlls/ddraw/tests/ddraw7.c | 150 ++++++++++++++++++++++++++++++++++++++++++++++ > 4 files changed, 573 insertions(+) It doesn't work here: ../../../tools/runtest -q -P wine -T ../../.. -M ddraw.dll -p ddraw_test.exe.so ddraw1 && touch ddraw1.ok ddraw1.c:5694: Test failed: Got unexpected hr 0. ddraw1.c:5696: Test failed: Got unexpected hr 0. -- Alexandre Julliard julliard(a)winehq.org

July 7, 2014

Re: kernel32: Partially implement GetGeoInfo()

by Nikolay Sivov

On 07/07/2014 06:58 AM, Dmitry Timoshkov wrote: > Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > >> [0001-kernel32-Partially-implement-GetGeoInfo.patch text/x-patch (32.2KB)] > Some of this info already exists in the locale data under dlls/kernel32/nls > and returned by GetLocaleInfo(), probably it would be a good idea to add > missing geo data there as well (auto-generate from the public source) and > use it from inside of GetGeoInfo(). This patch implements geotypes that don't belong to nls, meaning they don't depend on locale. Other types like friendly name and country name as localized, and I'll plan to add them to nls files.

July 7, 2014

Re: [1/6] ntdll: refactor NTDLL_create_struct_sd and NTDLL_free_struct_sd so that other modules are able to use them

by Michael Stefaniuc

On 07/07/2014 03:38 PM, Joris van der Wel wrote: > I dislike duplicating code... > An alternative would be to put the entire function in a header file, > I've seen examples of other functions that are placed in one, in wine. > This would introduce around 70 lines to some .h file. Perhaps along > with the other headers for the server protocol?, > NTDLL_create_struct_sd is part of the client to server serialization > after all... Or in a header of ntdll? > > What do you suggest? I hate duplicated code too but sometimes you gotta do what you gotta do... Duplicating code is considered the less ugly solution in Wine in a lot of situations. > > On Mon, Jul 7, 2014 at 12:13 PM, Alexandre Julliard <julliard(a)winehq.org> wrote: >> Joris van der Wel <joris(a)jorisvanderwel.com> writes: >> >>> So should I instead copy paste those 2 functions into kernel32 (with >>> NTDLL renamed to KERNEL32)? >> >> Possibly, though there may be better ways to do that. bye michael

July 7, 2014

Re: [PATCH 4/4] ddraw: Test if P8 primaries can be converted to RGB.

by Henri Verbeet

On 7 July 2014 15:26, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > The drawable format is a winex11.drv / winemac.drv internal thing. In a sense, but wined3d picks it in context_create() / context_choose_pixel_format(). That's also where WINED3DFMT_P8_UINT is overridden to WINED3DFMT_B8G8R8A8_UNORM. >> So I think the fix for this would need to be in >> wined3d_check_device_format(), or its utility functions. > I don't think so. Wined3d_check_device_format doesn't know what ddraw > is going to do with the source surface. What if e.g. the application > tries to create a YUY2 offscreen surface in P8 mode? > Does it really matter what ddraw is going to do with it, beyond what's passed in through usage / resource_type? In principle I see no reason why wined3d shouldn't allow offscreen YUY2 surfaces in P8 mode. > I'm open to the argument that blits between converted surfaces with > the same format should be reported as supposed. In some cases, yes, but when e.g. stretching is involved that's not necessarily true either.

July 7, 2014

Re: [1/6] ntdll: refactor NTDLL_create_struct_sd and NTDLL_free_struct_sd so that other modules are able to use them

by Joris van der Wel

I dislike duplicating code... An alternative would be to put the entire function in a header file, I've seen examples of other functions that are placed in one, in wine. This would introduce around 70 lines to some .h file. Perhaps along with the other headers for the server protocol?, NTDLL_create_struct_sd is part of the client to server serialization after all... Or in a header of ntdll? What do you suggest? On Mon, Jul 7, 2014 at 12:13 PM, Alexandre Julliard <julliard(a)winehq.org> wrote: > Joris van der Wel <joris(a)jorisvanderwel.com> writes: > >> So should I instead copy paste those 2 functions into kernel32 (with >> NTDLL renamed to KERNEL32)? > > Possibly, though there may be better ways to do that. > > -- > Alexandre Julliard > julliard(a)winehq.org

July 7, 2014