wine-devel September 2015

wine-devel@winehq.org

73 participants
180 discussions

Re: configure.ac: Fix breakage caused by -Werror=unused-variable
by Alexandre Julliard 08 Sep '15

08 Sep '15

Daniel Santos <daniel.santos(a)pobox.com> writes: > When configuring with CFLAGS="-Wunused-variable -Werror", the configure > test for HAVE_PNG_SET_EXPAND_GRAY_1_2_4_TO_8 fails with unused variable. Running configure with -Werror is not a good idea. Is there a particular reason why you need this? -- Alexandre Julliard julliard(a)winehq.org

2 3

Re: ntdll: wrap getdirentries around getdents on NetBSD
by Ken Thomases 07 Sep '15

07 Sep '15

On Sep 7, 2015, at 2:40 AM, Austin English <austinenglish(a)gmail.com> wrote: > For https://bugs.winehq.org/show_bug.cgi?id=18166 getdirentries() is only used if USE_GETDENTS is not defined. USE_GETDENTS is defined at the top of the file in the #ifdef linux block that your patch is right after. So, why not just #define USE_GETDENTS for NetBSD, too? No need for a wrapper. -Ken

1 0

Re: [PATCH 1/3] wineps.drv: Add support for PostScript Format 1 glyph names.
by Huw Davies 07 Sep '15

07 Sep '15

On Fri, Sep 04, 2015 at 10:28:50PM -0600, Erich E. Hoover wrote: > + size = GetFontData(hdc, MS_MAKE_TAG('p','o','s','t'), 0, NULL, 0); > + if(size == 0 || size == GDI_ERROR) > + return; Here you'll want to check that size >= sizeof(*post_header). In the 2nd patch you don't check that this size includes numberOfGlyphs. In the 3rd patch the size checks are repeated three times, it should be possible to simplify that. Huw.

1 0

Re: WS2_32: Proper WSACleanup implementation using wineserver help (try 2)
by Bruno Jesus 06 Sep '15

06 Sep '15

On Sun, Aug 30, 2015 at 11:04 PM, Matt Durgavich <mattdurgavich(a)gmail.com> wrote: > Fixes some tests and also bug 32910 > > From 6b34d1b9f6cfa491a26b9c36e395c3b180b5ceea Mon Sep 17 00:00:00 2001 > From: Matt <matt(a)wymzee.com> > Date: Thu, 27 Aug 2015 23:43:59 -0400 > Subject: [PATCH] WS2_32: Proper WSACleanup implementation using wineserver > help I see the patch is pending and I can think of a few new issues. First two minor issues that are not related which are the DLL name in uppercase in the email subject and the patch has 5 whitespace issues (whitespace after the end of a line). The main issue is that it does not seem to work as we expect it does. And that is proved by the need of adding those new todo lines in the send() and closesocket() calls. For example in the closesocket call: 2977 fd = get_sock_fd(s, FILE_READ_DATA, NULL); 2978 if (fd >= 0) 2979 { ... Despite being closed in the server the get_sock_fd still succeeds in the DLL returning a no longer valid handle. It looks like some out of sync problem with the ntdll cache. Need someone else to help with that because I have no idea how to improve the patch. Best wishes, Bruno

1 0

Re: Who decides what are good translations war: Update German translation.
by Hin-Tak Leung 06 Sep '15

06 Sep '15

------------------------------ On Sat, Sep 5, 2015 7:10 AM BST Alex Henrie wrote: >2015-09-02 7:47 GMT-06:00 Thomas Kaltenbrunner <tkaltenbrunner(a)opc.de>: >> BTW. Who decides what are good translations? > >My German is terrible, so I will not attempt to comment on specific >German translations. However, I'd like to point out that I used >Windows as a reference to translate Wine into Catalan. I did not copy >translations word-for-word, but I noticed that Windows consistently >used some very specific terminology that is less common in Linux. The >list I came up with was: > >byte -> byte >default -> per defecte >font size -> cos de lletra >front (of window stack) -> primer terme >graph -> gràfic >handle -> identificador >item -> element >move -> desplaçar >pool -> agrupació >prompt -> indicador >set -> definir >settings -> opcions, configuració >suppress -> reprimir >use -> utilitzar > >Windows also had some grossly horrible translations, like "tancar" for >"shut down". I ignored those. My point though is that if you are >having a hard time deciding which German word is appropriate for Wine, >I would give a lot of consideration to which German word Windows uses. > >-Alex > > That's perhaps the most relevant response in this thread - remember, the stated aim of wine is to be bug-for-bug compatible with windows. Wine does not try to be a 'better' windows. There is no 'good' translations, but just what localised windows does. Different from localised windows is a flaw, even if it is arguably 'better'. one might choose to have a flaw occasionally, but a flaw it is, if it is different from localised windows.

5 5

Re: [PATCH] shell32: Fix SHFileOperation(FO_MOVE) on non-exist files.
by Marvin 06 Sep '15

06 Sep '15

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=16527 Your paranoid android. === wvistau64 (32 bit shlfileop) === shlfileop.c:818: Test failed: Expected ERROR_CANCELLED or DE_DIFFDIR === wvistau64 (64 bit shlfileop) === shlfileop.c:818: Test failed: Expected ERROR_CANCELLED or DE_DIFFDIR

1 0

Re: po: Update German translation.
by Florian Pelz 05 Sep '15

05 Sep '15

Sorry for sending to the wrong list. On 08/28/2015 03:03 PM, Florian Pelz wrote: > On 08/28/2015 02:35 PM, Julian Rüger wrote: >> +"Wine Anwendungsentferner\n" > > This needs a hyphen ("Wine-Anwendungsentferner\n"). >

4 10

Re: po: German translation: Fix grammar errors
by Julian Rüger 04 Sep '15

04 Sep '15

> #: oleview.rc:110 > msgid "Quit the application. Prompts to save changes" > -msgstr "Anwendung beenden. Frag ob Änderungen zu speichern sind" > +msgstr "Anwendung beenden. Fragt ob Änderungen zu speichern sind" "Fragt, ob ..." There should really be a full stop at the as well. Generally, you're right in not adding it when it's not there in the original, but I wonder why it was left out. Maybe we should add it to both. #: wineconsole.rc:44 msgid "wineconsole: Couldn't parse event id\n" -msgstr "wineconsole: Ereignis-ID konnte nicht geparsed werden\n" +msgstr "wineconsole: Ereignis-ID konnte nicht geparset werden\n" I'm never sure what to do in these cases. Correct German grammar would be "geparst", but that looks just awful... My personal preference is the pretty, but grammatically wrong English ending. I guess my OCD has to live with the pain ;) Let's use the correct case. Agreed?

2 2

d3d8/9 swapchain flip
by Stefan Dösinger 04 Sep '15

04 Sep '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Henri, I'm sending my current swapchain flipping patches for you to look at in case you have any comments. A few notes: *) It doesn't involve the front buffer yet, it only cycles through the back buffers. Patch 8 has a few comments about that. *) The first interesting patch is patch 4. I am updating the wined3d_surface pointers in each d3d9_surface in the swapchain and adjust the d3d9 surface's parents. *) The other interesting parts are patch 7 and 8. If a view is created for a swapchain texture I'm storing the swapchain + buffer index in the view. When the view is used the texture is fetched from the swapchain. Alternatively I could maintain a list of views that are created for each texture and modify the views in present. With the current way we don't have to worry about how many views there are, but it makes looking up the actual texture slightly more expensive. So far this is only implemented for render target views, but the same approach should work for shader resource views. Before sending this I'm going to remove the back buffer type from the wined3d interface. It's not used anywhere according to MSDN, and none of the stereo hacks out there (occulus rift, ati quad buffer, nvidia 3d vision) use it. Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJV6dE/AAoJEN0/YqbEcdMwZQ4P+weZy8ymZAp8pHgMztjuQRIC dUXaVO3hhoj6l6q/a2l27VDPnON81FBUADHG/Mk00MNOi0K/7IlHvKW5cEx54hV6 HsmRdtq1Kp9HLhgDTGJqy2yMhg9K9ugg5+u0ouQUxxxFdhDxhwlwDlfOGQvUkXL8 +SqAM5lB6wnDxVQ5OOlip2yJDEXYimL2e6QQOXaRpyWnciKUqd9Rs1RrFObLCnBK OC7rGpkCg0jmI6cKCsNEUrA+3ihz+zl+E7XU+W/g454oGTO3dKRI68iqrfN1wNB5 JfOzwIyHIdHTZOuuXZ+66Z8qqSxx8XcvyjEiKuN/bnvVCjGB+zLnqi10sKHD8yJv 2FE9AKFb6Kwyty9zLw2AMC/8Ch/Fh0s75TzhDm0cywORDwx94ApSDCF0R+ryQ+h8 QYhTpj187lQum1Egmti7PlHQRVCDv+sblyssdGvwDIYqmyfSoBARCILO08bKSGsd 9teITH2yfYYiChbf05n1aDzYyTwNRf52/p7xSHtfzaSR/U7G/tO7nvpXUuQjoPso je87AM2WJk0JSlfifCUn6qQ4j+aXLftUzzvqPSNRTmhw4uuO7Y1cxg7kp0ORwpC7 nEFrR/AaPJyGg/Hcy69LsNwokv/qlT1FgFrhnZrI2Rauop3dt4rZQSou2id2fo+J OQG8vE6dUux/GGHPIPIk =W1o8 -----END PGP SIGNATURE-----

1 0

Re: wineps.drv: Add glyph names for PostScript Format 1 glyphs (try 2).
by Nikolay Sivov 04 Sep '15

04 Sep '15

> +void get_glyph_name(HDC hdc, UINT flags, WORD index, char *name) > { > - /* FIXME */ > + BOOL bIsGlyphIndex = ((flags & ETO_GLYPH_INDEX) == 0); > + > + if (bIsGlyphIndex && index < 258) This is essentially the same as it was on try 1. I still think we shouldn't rely on glyph indices mapped to some specific code range, I don't see any documentation that says it should be mapped like that. I think what we want is to map from WCHAR string to such glyph names directly, and that's why ETO_GLYPH_INDEX case is important - if you get index array initially you fallback to generic glyph names, if you got string then for codepoints that have defined glyphs in your names array you use those, for the rest of codepoints fallback again to generic name. This way we could also extend this lookup when it's decided how to deal with licensed glyph list data.

3 8

Jump to page:

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 September 2015