September 2015 - Wine-Devel

d3d8/9 swapchain flip

by Stefan Dösinger

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

Sept. 4, 2015

Re: Prep for Wineconf - testing

by Bruno Jesus

On Fri, Sep 4, 2015 at 11:58 PM, Jeremy White <jwhite(a)codeweavers.com> wrote: >> Attaching a 15 USD smart card reader to any of them and making it work >> in Windows would make winscard support get alive in Wine. Inserting >> any old credit card with chip (very common at least in Brazil) or any >> other 1 USD contact card would make all kinds of tests work. A sample >> reader that also should be supported by pcsclite is at [1] >> >> [1] http://www.amazon.com/HID-Global-Corporation-R30210015-1-OMNIKEY/dp/B003BKV… > > Just to clarify - it wouldn't be attaching just one reader, right? If > we have 4 test systems, then ideally, we'd attach 4 of these readers, so > that all the machines would test identically, right? Thanks for the reply, I was thinking about an overly simple solution where we could have a single reader connected to a physical machine and somehow exposed to a single virtual machine which would run XP or Windows 7. My virtualization knowledge is limited to vmware player so all I know is to right click and attach the usb reader, sorry =) The differences between XP and after XP for the main winscard functions are minimal so I don't think we need more than one reader to do it but certainly it wouldn't hurt. As for the reader brand/model the only important thing is to ensure the reader is PC/SC compatible, because some may be proprietary driver driven or simplified card ID to HID converters. Best wishes, Bruno

Sept. 4, 2015

Re: Prep for Wineconf - testing

by Jeremy White

On 09/03/2015 09:55 AM, Bruno Jesus wrote: > On Thu, Sep 3, 2015 at 9:55 PM, Jeremy White <jwhite(a)codeweavers.com> wrote: >> Hardware is cheap, particularly if we don't need beefy machines, as the >> expected load is lower. >> >> ... >> >> That sound right? And would a pair of i5s with fast hard drives and 8G >> of RAM do the trick? > > Since sending email is free and the worst that can happen is getting a > no as answer I would like to give an idea. > > Attaching a 15 USD smart card reader to any of them and making it work > in Windows would make winscard support get alive in Wine. Inserting > any old credit card with chip (very common at least in Brazil) or any > other 1 USD contact card would make all kinds of tests work. A sample > reader that also should be supported by pcsclite is at [1] > > [1] http://www.amazon.com/HID-Global-Corporation-R30210015-1-OMNIKEY/dp/B003BKV… Just to clarify - it wouldn't be attaching just one reader, right? If we have 4 test systems, then ideally, we'd attach 4 of these readers, so that all the machines would test identically, right? And we would need to add a kvm option to attach this device when we started kvm, but that shouldn't be hard. Cheers, Jeremy

Sept. 4, 2015

Re: wineps.drv: Add glyph names for PostScript Format 1 glyphs (try 2).

by Erich E. Hoover

On Fri, Sep 4, 2015 at 3:29 AM, Huw Davies <huw(a)codeweavers.com> wrote: > ... > You can test the 'custom' glyph names by starting notepad, selecting > Tahoma and typing a Euro sign for example. And no, it doesn't work. > The length of the pascal strings is stored as a BYTE not a USHORT. Sorry I didn't think of that on my own, I'll go ahead and fix and test that. > Also, you need to add some checks that you don't read past for end > of the POST table and that you don't copy more than MAX_G_NAME > chars into the provided name buffer (although this should perhaps be > changed to a dynamic buffer). I'll adjust the code to truncate to MAX_G_NAME characters, since (at least older versions) of the spec says that 31 characters is the max I don't think it makes sense to make a dynamic buffer: http://partners.adobe.com/public/developer/opentype/index_glyph2.html Best, Erich

Sept. 4, 2015

Re: po: German translation: …

by Florian Pelz

Hi, Thanks for the review. On 09/04/2015 02:46 PM, Julian Rüger wrote: >> #: crypt32.rc:105 >> msgid "Unsigned CMC Request" >> -msgstr "Unsignierte CMC Antwort" >> +msgstr "Unsignierte-CMC-Antwort" > > First hyphen is wrong, that's an adjective and a noun. > Of course. Should have noticed this. Actually, "Unsignierte CMC-Anfrage" (instead of "Antwort") would probably be the right translation. > > #: crypt32.rc:110 > msgid "PKCS 7 Signed" > -msgstr "PKCS 7 signiert" > +msgstr "PKCS-7-signiert" > > #: crypt32.rc:111 > msgid "PKCS 7 Enveloped" > -msgstr "PKCS 7 umhüllt" > +msgstr "PKCS-7-umhüllt" > > [... and similar] > > These feel wrong. I'm not sure what would be correct, but I suspect > "PKCS-7, signiert" or "[Umhülltes/Signiertes] PKCS-7" would be correct. > (These are descriptions of file types to open, right?) > I think "PKCS 7 Signed" means "signed using the public key cryptography standard 7", so "PKCS-7-signiert" would be a good translation. These are not file types but "display names" of "object identifiers". Apparently they are used to provide information about parts of cryptographic certificates. > #: crypt32.rc:150 cryptui.rc:134 > msgid "Windows System Component Verification" > -msgstr "Windows System Komponenten Verifizierung" > +msgstr "Windows-System-Komponenten-Verifizierung" > > [... and 2 similar] > > "Windows-Systemkomponentenverifizierung" would be grammatically correct, > I think. It's a freaking long word though... > Yes, this looks better. > > > #: crypt32.rc:160 > msgid "IP security IKE intermediate" > -msgstr "Dazwischenliegende IP Sicherheits-IKE" > +msgstr "Dazwischenliegende IP-Sicherheits-IKE" > > Something like "temporäre" or "Übergangs-..." would better reflect the > meaning. Dazwischenliegend is just wrong. I remember not having anything > better, so I left these alone. Ideas? > I think "intermediate" really means "dazwischenliegend" (i.e. "in between") here. I don't know about IPsec terminology, but the term "intermediate" is frequently used for certificates that are not trusted by themselves but signed by a trusted authority. It might be better to use the English word though. I cannot find anyone using the German "dazwischenliegend" on the Web. > > #: winerror.mc:3536 > msgid "Security package error.\n" > -msgstr "Sicherheitspaket Fehler.\n" > +msgstr "Sicherheitspaket-Fehler.\n" > > "Sicherheitspakets-Fehler"? "Fehler im Sicherheitspaket"? > This does not need an s just like "Paketzusteller" does not need an s. > > #: winerror.mc:3701 > msgid "Not all objects could be exported.\n" > @@ -6844,9 +6844,9 @@ msgstr "" > "Protokollierung und Benutzeroberfläche für die oberen Befehle > anpassen:\n" > "\t/l[*][i|w|e|a|r|u|c|m|o|p|v|][+|!] Protokolldatei\n" > "\t/q{|n|b|r|f|n+|b+|b-}\n" > -"MSI Service registrieren:\n" > +"MSI-Service registrieren:\n" > "\t/y\n" > -"Registrierung des MSI Service aufheben:\n" > +"Registrierung des MSI-Service aufheben:\n" > > While we're at it, this should be "MSI-Dienst", imho. > Yes. > > #: msvidc32.rc:29 > msgid "Wine Video 1 video codec" > -msgstr "Wine Video 1 Video Codec" > +msgstr "Wine-Video-1-Video-Codec" > > "Videocodec" seems to be a word > (https://de.wikipedia.org/wiki/Videocodec ), but I would just say > "Wine-Video-1-Codec". Still feels clumsy somehow... > "Wine-Video-1-Videocodec" looks more readable, yes. I don't like "Wine-Video-1-Codec" because it makes it harder to see that it is a video codec. > > #: shdoclc.rc:28 > msgid "Wine Internet Explorer" > -msgstr "Wine Internet Explorer" > +msgstr "Wine-Internet-Explorer" > > While technically right, this looks "wrong" somehow. Stichwort: > Eigenname? > I don't think Wine Internet Explorer is supposed to be a proper name. Internet Explorer is a proper name. This is the Wine-'Internet Explorer' and because of Durchkopplung this becomes Wine-Internet-Explorer. > -"$d aktuelles Datum $e Escape $g > Zeichen\n" > -"$l < Zeichen $n aktuelles Laufwerk $p aktueller Pfad\n" > +"$d aktuelles Datum $e Escape $g Größerzeichen (>)\n" > +"$l Kleinerzeichen (<) $n aktuelles Laufwerk $p aktueller Pfad\n" > > Nice one! > > > #: ipconfig.rc:49 > msgid "Default gateway" > -msgstr "Standard Gateway" > +msgstr "Standard-Gateway" > > "Standardgateway"? > Maybe. Separating the English part of the word does not look bad though. I don't think this needs changing. > > #: net.rc:37 > msgid "The %1 service is starting.\n" > -msgstr "Der %1 Dienst startet.\n" > +msgstr "Der Dienst %1 startet.\n" > > Why go half-way? ;) > "Der Dienst '%1' startet.\n" > Maybe. It's longer though and less close to English. Then again, the English does not look good either: Z:\home\florian>net start PlugPlay The Plug and Play Service service is starting. Service already running. Microsoft does not have this problem because their PlugPlay is called "Plug and Play" instead of "Plug and Play Service". > #: taskmgr.rc:322 > msgid "System Idle Process" > -msgstr "Leerlauf Prozess" > +msgstr "Leerlauf-Prozess" > > "Leerlaufprozess" (I think it's OK to copy Windows here) > Yes. > > #: winecfg.rc:143 > msgid "Windows registration information" > -msgstr "Windows Registrierungs-Informationen" > +msgstr "Windows-Registrierungs-Informationen" > > "Registrierungsinformationen" > Yes. On 09/04/2015 02:48 PM, Julian Rüger wrote: > Das wurde zwar, soweit ich weiss, mit der neuen Rechtschreibung > geändert, aber einverstanden. Ist höflicher ;) > It didn't change. The 2006 rules say in 2.5 § 65 that "Das Anredepronomen Sie und das entsprechende Possessivpronomen Ihr sowie die zugehörigen flektierten Formen schreibt man groß." Yes, I looked it up ;) . IMO good writing style is more important anyway though. On 09/04/2015 03:00 PM, Julian Rüger wrote: >> #: 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. > Yes, I could not find anything about this comma being optional. I think this type of error occurs frequently. The period at the end should definitely be added to the English .rc files for all programs. At least in regedit in Windows 98, XP and 8.1, the status bars at the bottom all use a period at the end. > #: 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? > Apparently yes, "geparst". The English d is not how Germans pronounce the word; we use a t and we use German grammar when speaking. According to duden.de, the silent e I wanted to keep is lost, similar to "geleast". In summary, I agree with changing "Unsignierte-CMC-Antwort", "Windows-System-Komponenten-Verifizierung", "Dazwischenliegende IP-Sicherheits-IKE", all occurrences of "MSI-Service", "Wine-Video-1-Video-Codec", "Leerlauf-Prozess", "Windows-Registrierungs-Informationen" and "geparset", though sometimes not as you proposed. "Der Dienst %1 startet.\n" should be given these apostrophe quotes in English first I think. The status bar messages "Anwendung beenden. Fragt ob Änderungen zu speichern sind" all need a period at the end in English and German. The missing comma after "Fragt" should be fixed everywhere this type of error occurs. I'll try fixing up some patches. I disagree with changing "PKCS-7-signiert" and similar, "Sicherheitspaket-Fehler.\n", "Wine-Internet-Explorer", "Standard-Gateway". Best regards, Florian

Sept. 4, 2015

Re: [2/2] winhttp: Add custom implementation of IWinHttpRequest::Invoke(DISPID_HTTPREQUEST_OPTION).

by Dmitry Timoshkov

Jacek Caban <jacek(a)codeweavers.com> wrote: > >> On 09/02/15 07:44, Dmitry Timoshkov wrote: > >>> + if (member == DISPID_HTTPREQUEST_OPTION) > >> Why can't we use standard, ITypeInfo-based implementation here? > > The tests (1/2 and existing ones) show that ITypeInfo->Invoke doesn't work > > for a lot of cases when native IWinHttpRequest::Invoke succeeds. In fact, > > after a lot of attempts I failed to force ITypeInfo->Invoke work at all > > under Windows using same code that winhttp request (and many other places > > in Wine) uses to load a typelib from winhttp.dll and forward Invoke to > > ITypeInfo implementation. > > It seems to me that it's a typelib problem. I think that Invoke > implementation can't find how to handle enum arguments. Did you try if > building the typelib with midl helps? My guess is that the typelib > produced by widl is somehow broken. I tried almost all things that can think of like extracting a binary typelib from an XP's winhttp.dll and replacing by it a Wine generated one in the Wine built-in winhttp.dll, extracting with oleview.exe typelib from XP's winhttp.dll and compiling it with widl and idl and using the result again in the Wine built-in dll. After that I've written a test under Windows that does the same as Wine's winhttp's IDispatch implementation: loads a typelib from winhttp.dll, and uses the resulting ITypeInfo for experimenting with ITypeInfo_Invoke: noone of the Invoke calls succeed. So I went to a conclusion that winhttp.dll in Windows most likely uses custom Invoke implementation, especially taking into account that it can successfully handle some invalid flags/args usage demonstrated by the tests. -- Dmitry.

Sept. 4, 2015

Re: po: German translation: Fix grammar errors

by Julian Rüger

> #: 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?

Sept. 4, 2015

Re: [2/2] winhttp: Add custom implementation of IWinHttpRequest::Invoke(DISPID_HTTPREQUEST_OPTION).

by Jacek Caban

Hi Dmitry, On 09/02/15 11:49, Dmitry Timoshkov wrote: > Hi Jacek, > > thanks for the review, I'm sorry for the delay, I wanted to take a closer look at those tests. > Jacek Caban <jacek(a)codeweavers.com> wrote: > >> On 09/02/15 07:44, Dmitry Timoshkov wrote: >>> + if (member == DISPID_HTTPREQUEST_OPTION) >> Why can't we use standard, ITypeInfo-based implementation here? > The tests (1/2 and existing ones) show that ITypeInfo->Invoke doesn't work > for a lot of cases when native IWinHttpRequest::Invoke succeeds. In fact, > after a lot of attempts I failed to force ITypeInfo->Invoke work at all > under Windows using same code that winhttp request (and many other places > in Wine) uses to load a typelib from winhttp.dll and forward Invoke to > ITypeInfo implementation. It seems to me that it's a typelib problem. I think that Invoke implementation can't find how to handle enum arguments. Did you try if building the typelib with midl helps? My guess is that the typelib produced by widl is somehow broken. >>> + { >>> + VARIANT ret_value, option; >>> + UINT err_pos; >>> + >>> + if (!result) result = &ret_value; >>> + if (!arg_err) arg_err = &err_pos; >>> + >>> + VariantInit( &option ); >>> + VariantInit( result ); >>> + >>> + if (flags == DISPATCH_PROPERTYPUT) >>> + { >>> + hr = DispGetParam( params, 0, VT_I4, &option, arg_err ); >>> + if (FAILED(hr)) return hr; >>> + >>> + hr = IWinHttpRequest_put_Option( &request->IWinHttpRequest_iface, V_I4( &option ), params->rgvarg[0] ); >>> + if (FAILED(hr)) >>> + WARN("put_Option(%d) failed: %x\n", V_I4( &option ), hr); >>> + return hr; >>> + } >>> + else if (flags & (DISPATCH_PROPERTYGET | DISPATCH_METHOD)) >>> + { >>> + hr = DispGetParam( params, 0, VT_I4, &option, arg_err ); >>> + if (FAILED(hr)) return hr; >>> + >>> + hr = IWinHttpRequest_get_Option( &request->IWinHttpRequest_iface, V_I4( &option ), result ); >>> + if (FAILED(hr)) >>> + WARN("get_Option(%d) failed: %x\n", V_I4( &option ), hr); >>> + return hr; >>> + } >>> + >>> + return S_OK; >> I don't think silently returning S_OK is right for not handled flags. > Do you have some particular flags in mind? I tried to follow the test results, > although probably the tests don't cover every case. DISPATCH_PROPERTYPUTREF mostly, maybe some invalid combination. Having a FIXME like you did in the other version of the patch looks good to me. Thanks, Jacek

Sept. 4, 2015

Re: po: German translation: Fix hyphenation

by Julian Rüger

Sorry for being late, had a busy week. I realize they are already in, but I have some remarks anyway. I fully agree with most of these. There are some examples of ugly translations in there, though. (Not your fault of course) It would be great if you/we could fix some of these, while we're at it. > #: crypt32.rc:105 > msgid "Unsigned CMC Request" > -msgstr "Unsignierte CMC Antwort" > +msgstr "Unsignierte-CMC-Antwort" First hyphen is wrong, that's an adjective and a noun. #: crypt32.rc:110 msgid "PKCS 7 Signed" -msgstr "PKCS 7 signiert" +msgstr "PKCS-7-signiert" #: crypt32.rc:111 msgid "PKCS 7 Enveloped" -msgstr "PKCS 7 umhüllt" +msgstr "PKCS-7-umhüllt" [... and similar] These feel wrong. I'm not sure what would be correct, but I suspect "PKCS-7, signiert" or "[Umhülltes/Signiertes] PKCS-7" would be correct. (These are descriptions of file types to open, right?) #: crypt32.rc:150 cryptui.rc:134 msgid "Windows System Component Verification" -msgstr "Windows System Komponenten Verifizierung" +msgstr "Windows-System-Komponenten-Verifizierung" [... and 2 similar] "Windows-Systemkomponentenverifizierung" would be grammatically correct, I think. It's a freaking long word though... #: crypt32.rc:160 msgid "IP security IKE intermediate" -msgstr "Dazwischenliegende IP Sicherheits-IKE" +msgstr "Dazwischenliegende IP-Sicherheits-IKE" Something like "temporäre" or "Übergangs-..." would better reflect the meaning. Dazwischenliegend is just wrong. I remember not having anything better, so I left these alone. Ideas? #: winerror.mc:3536 msgid "Security package error.\n" -msgstr "Sicherheitspaket Fehler.\n" +msgstr "Sicherheitspaket-Fehler.\n" "Sicherheitspakets-Fehler"? "Fehler im Sicherheitspaket"? #: winerror.mc:3701 msgid "Not all objects could be exported.\n" @@ -6844,9 +6844,9 @@ msgstr "" "Protokollierung und Benutzeroberfläche für die oberen Befehle anpassen:\n" "\t/l[*][i|w|e|a|r|u|c|m|o|p|v|][+|!] Protokolldatei\n" "\t/q{|n|b|r|f|n+|b+|b-}\n" -"MSI Service registrieren:\n" +"MSI-Service registrieren:\n" "\t/y\n" -"Registrierung des MSI Service aufheben:\n" +"Registrierung des MSI-Service aufheben:\n" While we're at it, this should be "MSI-Dienst", imho. #: msvidc32.rc:29 msgid "Wine Video 1 video codec" -msgstr "Wine Video 1 Video Codec" +msgstr "Wine-Video-1-Video-Codec" "Videocodec" seems to be a word (https://de.wikipedia.org/wiki/Videocodec ), but I would just say "Wine-Video-1-Codec". Still feels clumsy somehow... #: shdoclc.rc:28 msgid "Wine Internet Explorer" -msgstr "Wine Internet Explorer" +msgstr "Wine-Internet-Explorer" While technically right, this looks "wrong" somehow. Stichwort: Eigenname? -"$d aktuelles Datum $e Escape $g > Zeichen\n" -"$l < Zeichen $n aktuelles Laufwerk $p aktueller Pfad\n" +"$d aktuelles Datum $e Escape $g Größerzeichen (>)\n" +"$l Kleinerzeichen (<) $n aktuelles Laufwerk $p aktueller Pfad\n" Nice one! #: ipconfig.rc:49 msgid "Default gateway" -msgstr "Standard Gateway" +msgstr "Standard-Gateway" "Standardgateway"? #: net.rc:37 msgid "The %1 service is starting.\n" -msgstr "Der %1 Dienst startet.\n" +msgstr "Der Dienst %1 startet.\n" Why go half-way? ;) "Der Dienst '%1' startet.\n" #: taskmgr.rc:322 msgid "System Idle Process" -msgstr "Leerlauf Prozess" +msgstr "Leerlauf-Prozess" "Leerlaufprozess" (I think it's OK to copy Windows here) #: winecfg.rc:143 msgid "Windows registration information" -msgstr "Windows Registrierungs-Informationen" +msgstr "Windows-Registrierungs-Informationen" "Registrierungsinformationen"

Sept. 4, 2015

Re: reg: Implement binary data add operation

by Alexandre Julliard

Thomas Faller <tfaller1(a)gmx.de> writes: > No, i don't know an app which needs this. > But this special case is noticed in the reg.exe tests, so I decided to > implement the version check. You shouldn't do a version check. Simply implement the new behavior since the old one is already marked as broken. -- Alexandre Julliard julliard(a)winehq.org

Sept. 4, 2015

Re: Who decides what are good translations war: Update German translation.

by Julian Rüger

Hi all, looks like I'm late to the first translations "flamewar" in my time. :) > "Anwendungsentferner" reminds me at Germans "Trolls" that refuse to use > well known english terms which are solely used in the area of computer > and software. So they are a technical/special terms in German. This is actually the first time someone told me I was translating too much. I've only had the opposite ("too Denglish") before. > The term "Anwendungsentferner" you will find in wine only ... The Gnome or Mate Projects (German translation teams) for example are way more radical with their "no English phrases/terms if at all possible". There are many German phrases you'll only find in Gnome/Mate. I always try to find a good balance, keep a formal yet natural tone that "feels right", use common English terms and try to avoid translations that would make it harder to understand. (see the release announcements for examples of the last bit, no use inventing words for DirectWrite features and friends) To comment on the uninstaller example, I kept "uninstaller" in the error messages (familiar to technical people and the command itself is not translated either) but for the title, "Anwendungsentferner" tells you exactly what it does, even newbies and tech-illiterates. (Btw, I didn't even introduce that term, it was there before I became the main German translator) > People familiar with computers may consider the English "Uninstaller" > more natural. A proper German translation may be better for those not so > familiar. I don't think all this matters very much though. IMO it should > just be left as it is. The ubuntuusers.de wiki already started using the > translated name to refer to the uninstaller. Good point. > More generally, I suppose Wine sticks with the first translation offered > unless there are issues. Wine has been a do-ocracy (regarding translations at least ;) up to this point. I've had many difficult cases where I don't feel really satisfied with a translation even though it was the best thing I could come up with. I very much welcome suggestions. In case we can't agree on something, I like a friendly discussion and consider myself very open to rational arguments. Sorry for the long post, btw.. ;) Have a nice weekend everyone! Julian

Sept. 4, 2015

Re: [PATCH 1/2] reg: simplify root key search

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Thanks, this time the patches apply OK for me. I've told Alexandre that the patches look OK to me, let's see what he says. Cheers, Stefan Am 2015-09-03 um 21:51 schrieb Michel Zou: > Split patch from Jonathan Vollebregt: > https://github.com/jnvsor/wine/commit/ea0e2fc70db6ce4904655ea4a27ee34531d96… > --- > programs/reg/reg.c | 85 +++++++++++++++++++++++++++--------------------------- > 1 file changed, 43 insertions(+), 42 deletions(-) > > diff --git a/programs/reg/reg.c b/programs/reg/reg.c > index 4ec25bc..0f28b63 100644 > --- a/programs/reg/reg.c > +++ b/programs/reg/reg.c > @@ -22,6 +22,32 @@ > > #define ARRAY_SIZE(A) (sizeof(A)/sizeof(*A)) > > +static const WCHAR short_hklm[] = {'H','K','L','M',0}; > +static const WCHAR short_hkcu[] = {'H','K','C','U',0}; > +static const WCHAR short_hkcr[] = {'H','K','C','R',0}; > +static const WCHAR short_hku[] = {'H','K','U',0}; > +static const WCHAR short_hkcc[] = {'H','K','C','C',0}; > +static const WCHAR long_hklm[] = {'H','K','E','Y','_','L','O','C','A','L','_','M','A','C','H','I','N','E',0}; > +static const WCHAR long_hkcu[] = {'H','K','E','Y','_','C','U','R','R','E','N','T','_','U','S','E','R',0}; > +static const WCHAR long_hkcr[] = {'H','K','E','Y','_','C','L','A','S','S','E','S','_','R','O','O','T',0}; > +static const WCHAR long_hku[] = {'H','K','E','Y','_','U','S','E','R','S',0}; > +static const WCHAR long_hkcc[] = {'H','K','E','Y','_','C','U','R','R','E','N','T','_','C','O','N','F','I','G',0}; > + > +static const struct > +{ > + HKEY key; > + const WCHAR *short_name; > + const WCHAR *long_name; > +} > +root_rels[] = > +{ > + {HKEY_LOCAL_MACHINE, short_hklm, long_hklm}, > + {HKEY_CURRENT_USER, short_hkcu, long_hkcu}, > + {HKEY_CLASSES_ROOT, short_hkcr, long_hkcr}, > + {HKEY_USERS, short_hku, long_hku}, > + {HKEY_CURRENT_CONFIG, short_hkcc, long_hkcc}, > +}; > + > static const WCHAR type_none[] = {'R','E','G','_','N','O','N','E',0}; > static const WCHAR type_sz[] = {'R','E','G','_','S','Z',0}; > static const WCHAR type_expand_sz[] = {'R','E','G','_','E','X','P','A','N','D','_','S','Z',0}; > @@ -95,51 +121,26 @@ static int reg_message(int msg) > return reg_printfW(formatW, msg_buffer); > } > > -static int reg_StrCmpNIW(LPCWSTR str, LPCWSTR comp, int len) > +static inline BOOL path_rootname_cmp(const WCHAR *input_path, const WCHAR *rootkey_name) > { > - int i; > + DWORD length = strlenW(rootkey_name); > > - for (i = 0; i < len; i++) > - { > - if (!str[i]) > - { > - len = i + 1; > - break; > - } > - } > - > - return CompareStringW(CP_ACP, NORM_IGNORECASE, str, len, comp, len) - CSTR_EQUAL; > + return (!strncmpiW(input_path, rootkey_name, length) && > + (input_path[length] == 0 || input_path[length] == '\\')); > } > > -static HKEY get_rootkey(LPWSTR key) > +static HKEY path_get_rootkey(const WCHAR *path) > { > - static const WCHAR szHKLM[] = {'H','K','L','M',0}; > - static const WCHAR szHKEY_LOCAL_MACHINE[] = {'H','K','E','Y','_','L','O','C','A','L','_','M','A','C','H','I','N','E',0}; > - static const WCHAR szHKCU[] = {'H','K','C','U',0}; > - static const WCHAR szHKEY_CURRENT_USER[] = {'H','K','E','Y','_','C','U','R','R','E','N','T','_','U','S','E','R',0}; > - static const WCHAR szHKCR[] = {'H','K','C','R',0}; > - static const WCHAR szHKEY_CLASSES_ROOT[] = {'H','K','E','Y','_','C','L','A','S','S','E','S','_','R','O','O','T',0}; > - static const WCHAR szHKU[] = {'H','K','U',0}; > - static const WCHAR szHKEY_USERS[] = {'H','K','E','Y','_','U','S','E','R','S',0}; > - static const WCHAR szHKCC[] = {'H','K','C','C',0}; > - static const WCHAR szHKEY_CURRENT_CONFIG[] = {'H','K','E','Y','_','C','U','R','R','E','N','T','_','C','O','N','F','I','G',0}; > - > - if (!reg_StrCmpNIW(key, szHKLM, 4) || > - !reg_StrCmpNIW(key, szHKEY_LOCAL_MACHINE, 18)) > - return HKEY_LOCAL_MACHINE; > - else if (!reg_StrCmpNIW(key, szHKCU, 4) || > - !reg_StrCmpNIW(key, szHKEY_CURRENT_USER, 17)) > - return HKEY_CURRENT_USER; > - else if (!reg_StrCmpNIW(key, szHKCR, 4) || > - !reg_StrCmpNIW(key, szHKEY_CLASSES_ROOT, 17)) > - return HKEY_CLASSES_ROOT; > - else if (!reg_StrCmpNIW(key, szHKU, 3) || > - !reg_StrCmpNIW(key, szHKEY_USERS, 10)) > - return HKEY_USERS; > - else if (!reg_StrCmpNIW(key, szHKCC, 4) || > - !reg_StrCmpNIW(key, szHKEY_CURRENT_CONFIG, 19)) > - return HKEY_CURRENT_CONFIG; > - else return NULL; > + DWORD i; > + > + for (i = 0; i < ARRAY_SIZE(root_rels); i++) > + { > + if (path_rootname_cmp(path, root_rels[i].short_name) || > + path_rootname_cmp(path, root_rels[i].long_name)) > + return root_rels[i].key; > + } > + > + return NULL; > } > > static DWORD wchar_get_type(const WCHAR *type_name) > @@ -237,7 +238,7 @@ static int reg_add(WCHAR *key_name, WCHAR *value_name, BOOL value_empty, > } > p++; > > - root = get_rootkey(key_name); > + root = path_get_rootkey(key_name); > if (!root) > { > reg_message(STRING_INVALID_KEY); > @@ -307,7 +308,7 @@ static int reg_delete(WCHAR *key_name, WCHAR *value_name, BOOL value_empty, > } > p++; > > - root = get_rootkey(key_name); > + root = path_get_rootkey(key_name); > if (!root) > { > reg_message(STRING_INVALID_KEY); > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJV6XG1AAoJEN0/YqbEcdMwWysP/0BvR0rXG67sd/NC5pPItrVv R2bGZceGH8yJpBuYOxpp2W5p9sCRMfoc2giTXrhmvUwVrutXrUbI9c/SqOlLZL6I YLOObNIo/DI6MxBwGaZ2jKGJKWEW3kzg5qKkJWzPIMg92zfbgtQxiTxhvAvd1xaR MxXLzKt+mhMWjPwyFR3omSFCTkvTguWxnXIVEf2S6TRshJnI0A10vJQUj1AC4dsX ZnHZkuXOAgwzgzmvkEnxbNsgkRzqmXCZaUbapcgJ5TXwwuiLMr4AuPbEcYmdf2g+ CqIYeIUYVtbg3pga/9WFdSki0YaAcJJ7kYTt5lEYRN3/V93W6QsPp/SaUXyx1J1B UOCbuj1UNx8OvRRvmABLrTvgbUQMrjlDXPP9QeNBHe8xQCQ1iV/AJ02DdbLrRleJ a/+CgisljGNzuH6Mu+5bKoKAEyEV3KAF3CIz6dJyBB5KQRY6Rk5AZMhWSQAhkJke ICBh+ITIBWYCsm+NDF+RuYutXhtstxvbewRHmwg4KnF2ouOTtQ2ypV+N2Z9JLNQ8 I25+6YB+1WDuDKYa87MPzbac6DX5IyzIPKiGsvLBngMiUcpfSDj6mgJTS4DkTwSM O+JYL5v8x7TIOmxKLGUfXXnvA+aiZ29/nrlLrZY8QoKLvHvpAxOz/SjUhDZa02IC twXso6DreRFxb4DyflTj =BizJ -----END PGP SIGNATURE-----

Sept. 4, 2015

Re: wineps.drv: Add glyph names for PostScript Format 1 glyphs (try 2).

by Huw Davies

On 3 Sep 2015, at 23:44, Erich E. Hoover wrote: > Based on your feedback, closer reading of the spec, and testing I've > attached a proposed patch series. Unfortunately, I cannot test the > last patch since OrCAD does not appear to allow me to enter characters > outside the standard list. If there's something that you can test the > last patch with then that would be greatly appreciated. You can test the 'custom' glyph names by starting notepad, selecting Tahoma and typing a Euro sign for example. And no, it doesn't work. The length of the pascal strings is stored as a BYTE not a USHORT. Also, you need to add some checks that you don't read past for end of the POST table and that you don't copy more than MAX_G_NAME chars into the provided name buffer (although this should perhaps be changed to a dynamic buffer). Huw.

Sept. 4, 2015

Re: wineps.drv: Add glyph names for PostScript Format 1 glyphs (try 2).

by Erich E. Hoover

Based on your feedback, closer reading of the spec, and testing I've attached a proposed patch series. Unfortunately, I cannot test the last patch since OrCAD does not appear to allow me to enter characters outside the standard list. If there's something that you can test the last patch with then that would be greatly appreciated. Best, Erich

Sept. 3, 2015

RE: [PATCH 1/2] reg: simplify root key search

by Michel Zou

Hi, I thought rich text formatting was causing this, but plain text didn't help. I resubmitted using git send email. M > Subject: Re: [PATCH 1/2] reg: simplify root key search > To: wine-devel(a)winehq.org; xantares09(a)hotmail.com > From: stefandoesinger(a)gmail.com > Date: Thu, 3 Sep 2015 11:57:09 +0200 > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > This patch still fails to apply with the same error: > > stefan(a)retina ~/src/wine $ git am /dev/shm/\[PATCH\ 1_2\]\ reg\:\ > simplify\ root\ key\ search.eml > Applying: reg: simplify root key search > /home/stefan/src/wine/.git/rebase-apply/patch:14: trailing whitespace. > static const WCHAR short_hklm[] = {'H','K','L','M',0}; > /home/stefan/src/wine/.git/rebase-apply/patch:15: trailing whitespace. > static const WCHAR short_hkcu[] = {'H','K','C','U',0}; > /home/stefan/src/wine/.git/rebase-apply/patch:16: trailing whitespace. > static const WCHAR short_hkcr[] = {'H','K','C','R',0}; > /home/stefan/src/wine/.git/rebase-apply/patch:17: trailing whitespace. > static const WCHAR short_hku[] = {'H','K','U',0}; > /home/stefan/src/wine/.git/rebase-apply/patch:18: trailing whitespace. > static const WCHAR short_hkcc[] = {'H','K','C','C',0}; > error: patch failed: programs/reg/reg.c:22 > error: programs/reg/reg.c: patch does not apply > Patch failed at 0001 reg: simplify root key search > The copy of the patch that failed is found in: > /home/stefan/src/wine/.git/rebase-apply/patch > When you have resolved this problem, run "git am --continue". > If you prefer to skip this patch, run "git am --skip" instead. > To restore the original branch and stop patching, run "git am --abort". > > Stefan > Am 2015-08-31 um 22:09 schrieb Michel Zou: > > Split patch from Jonathan Vollebregt: > > https://github.com/jnvsor/wine/commit/ea0e2fc70db6ce4904655ea4a27ee34531d96… > > > > > - --- > > programs/reg/reg.c | 85 > > +++++++++++++++++++++++++++--------------------------- 1 file > > changed, 43 insertions(+), 42 deletions(-) > > > > > > > > > > > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQIcBAEBAgAGBQJV6Bl1AAoJEN0/YqbEcdMwf+sQAI7u19WiDrPOtniTS00sJZeS > mrBSZHvhKlDujZ4iCr4VHyycBzhCmg8peflfgEHRyF9xGx6duy/mzh0JHN3qJFlM > r7zbm9wbhFCaH7i4d1JD2a7l9hthow+N3PuPKWk5ox+T+Pe9HaXTQwxUmgB/6YjR > xXjkHDEc5GtyBeqxpiskw2W92GWubrMrEJmfmlQQSWfcIZjkUM0MmKCEUCibMu3O > bLPOsx1AjD3aQ+S0R50D3s1W1u/yO0tfKa0pGki2pqZRL/72UcbBWNow6F9tZIeD > qXaAgNhvn0rc66nMVb7yc//9nN4oN2prBNtrpCtSCCfSgd/Xh47xoq8g3HQUXjHd > nNbfSuePuNLvNzu5XhNb0yP5cGCZedU8q7cYcPURn376t25xw22daigpdId3kaS0 > KN+gwb2M1PSazPwkjRy94qIX9Kl0NIsJT8dLHZgV0TM7ZrRBy0sa2baqH5jvL+4h > pCn9+Kcuyv5jC7Oj/ewNx+9EIRmUf7wOJvgdNocUqwSyHPf7bJwZOysAm4ltk8pq > A7RA2qiyicANi34Yf1e8zKG1Fv1M/uYwvjc3Sd8jrTpkn0z9mzijll4R+bcThAXA > jdZjA3HTyvoaaENxmKJngb7Xz2o0WBV1WUEjIIUos+md8IV7bCnH0dbCDtE3AQKl > u/eABCeasbpTQJ61px7N > =V5u2 > -----END PGP SIGNATURE-----

Sept. 3, 2015

Re: [4/13](try 3)hidclass.sys: Add USB Descriptor parsing

by Aric Stewart

Cannot believe I missed that myself. try 4 just sent. -aric On 9/3/15 1:08 PM, Andrew Eikum wrote: > Sorry for not noticing this before you resent, but you've got some C++ > style comments in parse_io_feature. > > Andrew > > On Thu, Sep 03, 2015 at 11:19:31AM -0500, Aric Stewart wrote: >> More good comments and changes from Henri Verbeet >> >> --- >> dlls/hidclass.sys/Makefile.in | 1 + >> dlls/hidclass.sys/descriptor.c | 1163 ++++++++++++++++++++++++++++++++++++++++ >> dlls/hidclass.sys/hid.h | 3 + >> dlls/hidclass.sys/pnp.c | 37 ++ >> 4 files changed, 1204 insertions(+) >> create mode 100644 dlls/hidclass.sys/descriptor.c

Sept. 3, 2015

Re: wineps.drv: Add glyph names for PostScript Format 1 glyphs (try 2).

by Nikolay Sivov

On 03.09.2015 21:04, Erich E. Hoover wrote: >> On 03.09.2015 19:36, Erich E. Hoover wrote: >>> ... >> >> Format 1 case looks fine, though I think it's better to reuse existing >> tables if possible for get_standard_glyph_name(). > > It looks like the existing tables are not in the right order, but I > can use the GN_<name> values to make the table. > Right, this way we won't need to duplicate strings at least. > The index we are passed is the glyphNameIndex entry value, so there's > no need to go through the table for those indices. For indices > greater than 257 a "patch 2" would allow you to get the glyph name by > finding the appropriate string in the table. I can happily prepare > such a patch. How so? As I'm reading docs you always have to use glyph index with Format 2 table and only if glyphNameIndex[glyph_index] is <= 257 you should use this glyphNameIndex[glyph_index] value as index value in Format 1. "patch 2" can wait of course. Also Apple docs say that Format 2.5 and Format 4 exist, so probably we can just have a single fixme for all formats we don't support.

Sept. 3, 2015

Re: [4/13](try 3)hidclass.sys: Add USB Descriptor parsing

by Andrew Eikum

Sorry for not noticing this before you resent, but you've got some C++ style comments in parse_io_feature. Andrew On Thu, Sep 03, 2015 at 11:19:31AM -0500, Aric Stewart wrote: > More good comments and changes from Henri Verbeet > > --- > dlls/hidclass.sys/Makefile.in | 1 + > dlls/hidclass.sys/descriptor.c | 1163 ++++++++++++++++++++++++++++++++++++++++ > dlls/hidclass.sys/hid.h | 3 + > dlls/hidclass.sys/pnp.c | 37 ++ > 4 files changed, 1204 insertions(+) > create mode 100644 dlls/hidclass.sys/descriptor.c

Sept. 3, 2015

Re: wineps.drv: Add glyph names for PostScript Format 1 glyphs (try 2).

by Erich E. Hoover

On Thu, Sep 3, 2015 at 11:09 AM, Nikolay Sivov <bunglehead(a)gmail.com> wrote: > On 03.09.2015 19:36, Erich E. Hoover wrote: >> ... > > Format 1 case looks fine, though I think it's better to reuse existing > tables if possible for get_standard_glyph_name(). It looks like the existing tables are not in the right order, but I can use the GN_<name> values to make the table. >> + else if(post_header->format == MAKELONG(0, 2)) >> + { >> + if(index < 258) >> + get_standard_glyph_name(index, name); >> + else >> + FIXME("PostScript Format 2 custom glyph names are currently >> unsupported.\n"); >> + } > > > Format 2 case looks wrong, according to specs you need to use glyphNameIndex > entry value, check it against [0,257] range and if it's in you can use > standard name list. The index we are passed is the glyphNameIndex entry value, so there's no need to go through the table for those indices. For indices greater than 257 a "patch 2" would allow you to get the glyph name by finding the appropriate string in the table. I can happily prepare such a patch. >> + else >> + FIXME("Only standard PostScript Format 1 glyph names are >> currently supported.\n"); > > > I think it's better to make explicit message for Format 3, as it's specified > and could be used by some. And after it generic fixme with unrecognized > format value printed in a message. Will do. Best, Erich

Sept. 3, 2015

Re: wineps.drv: Add glyph names for PostScript Format 1 glyphs (try 2).

by Nikolay Sivov

On 03.09.2015 19:36, Erich E. Hoover wrote: > On Thu, Sep 3, 2015 at 1:37 AM, Huw Davies <huw(a)codeweavers.com> wrote: >> On Thu, Sep 03, 2015 at 06:59:56AM +0300, Nikolay Sivov wrote: >>> 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. >> >> Note that we already have many of the glyph names in >> PSDRV_AGLbyUV[] and friends (see wineps.drv/data/agl.[ch]). >> > > Ok, I've done some more research on this and it looks like what we > should do is pull up the 'post' table and use the standard glyph names > if the table is in format 1 or 2 (and index is < 258). If the table > is in format 2 there's also the possibility of custom names in > addition to the standard names. In later formats the layout of the > table changes somewhat. I think we don't have to always depend on particular 'post', because we generate new font essentially from selected font data, so it might be preferable to use predictable names from tables Huw mentioned. Font 'post' data could still be useful in case of ETO_GLYPH_INDEX when we don't WCHAR string, in this case you can indeed do 'post' name lookup so we don't have to make assumptions about particular index layout. > > Based on this information I've attached a version of the patch that > checks the format and returns the standard glyphs if the format is > "correct". I'm not sure if ETO_GLYPH_INDEX is relevant to this, as it > appears that the glyph indices are always in terms of the "mac" > ordering. Do you have an application that generates an example of > this? I also found a draft version of ISO/IEC CD 14496-22 that says > that Format 2 is required for fonts used on Windows, though I think > it's in our best interest to support all the formats our users care > about. > Regarding patch itself: > + if(post_header->format == MAKELONG(0, 1)) > + { > + if(index < 258) > + get_standard_glyph_name(index, name); > + else > + WARN("Font uses PostScript Format 1, but non-standard glyph (%d) requested.\n", index); > + } Format 1 case looks fine, though I think it's better to reuse existing tables if possible for get_standard_glyph_name(). > + else if(post_header->format == MAKELONG(0, 2)) > + { > + if(index < 258) > + get_standard_glyph_name(index, name); > + else > + FIXME("PostScript Format 2 custom glyph names are currently unsupported.\n"); > + } Format 2 case looks wrong, according to specs you need to use glyphNameIndex entry value, check it against [0,257] range and if it's in you can use standard name list. > + else > + FIXME("Only standard PostScript Format 1 glyph names are currently supported.\n"); I think it's better to make explicit message for Format 3, as it's specified and could be used by some. And after it generic fixme with unrecognized format value printed in a message. > Best, > Erich >

Sept. 3, 2015

Re: PATCH: widl: implement move-if-changed logic

by Jacek Caban

Hi Marcus, On 09/03/15 13:07, Marcus Meissner wrote: > From d8df64a7261bc0febcdd48d4ed818dc1f36f3471 Mon Sep 17 00:00:00 2001 > From: Marcus Meissner <meissner(a)suse.de> > Date: Thu, 3 Sep 2015 12:11:13 +0200 > Subject: [PATCH] widl: implement a move-if-changed logic > > This avoids unnecessary rebuilds if the generated code by widl > does not change. While I like the idea and it would often save a bug chunk of build time, I don't think it would work well with make. If you don't touch output file, then following make invocation will execute widl again, which is undesired. Thanks, Jacek

Sept. 3, 2015

Re: wineps.drv: Add glyph names for PostScript Format 1 glyphs (try 2).

by Erich E. Hoover

On Thu, Sep 3, 2015 at 1:37 AM, Huw Davies <huw(a)codeweavers.com> wrote: > On Thu, Sep 03, 2015 at 06:59:56AM +0300, Nikolay Sivov wrote: >> 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. > > Note that we already have many of the glyph names in > PSDRV_AGLbyUV[] and friends (see wineps.drv/data/agl.[ch]). > Ok, I've done some more research on this and it looks like what we should do is pull up the 'post' table and use the standard glyph names if the table is in format 1 or 2 (and index is < 258). If the table is in format 2 there's also the possibility of custom names in addition to the standard names. In later formats the layout of the table changes somewhat. Based on this information I've attached a version of the patch that checks the format and returns the standard glyphs if the format is "correct". I'm not sure if ETO_GLYPH_INDEX is relevant to this, as it appears that the glyph indices are always in terms of the "mac" ordering. Do you have an application that generates an example of this? I also found a draft version of ISO/IEC CD 14496-22 that says that Format 2 is required for fonts used on Windows, though I think it's in our best interest to support all the formats our users care about. Best, Erich

Sept. 3, 2015

Re: reg: Implement binary data add operation

by Thomas Faller

No, i don't know an app which needs this. But this special case is noticed in the reg.exe tests, so I decided to implement the version check. Kind Regards Thomas Am 03.09.2015 um 10:55 schrieb Alexandre Julliard: > Thomas Faller <tfaller1(a)gmx.de> writes: > >> +static inline BOOL is_xp_or_older(void) >> +{ >> + DWORD version = GetVersion(); >> + if(version < 0x80000000){ >> + /* compare major */ >> + return (DWORD)(LOBYTE(LOWORD(version))) < 6; >> + } >> + return TRUE; >> +} > Do you actually have an app that depends on such a version check? >

Sept. 3, 2015

Re: Prep for Wineconf - testing

by Aaryaman Vasishta

Well, I have an old 2009 MBP with a Nvidia GPU I don't use anymore. It uses the old core 2 duo chip so not sure if it might be as useful as the new ones with i5's out there.. On Thu, Sep 3, 2015 at 8:28 PM, Jeremy White <jwhite(a)codeweavers.com> wrote: > > Yes, two extra boxes should maintain the old status-quo. > > > > > >> That sound right? And would a pair of i5s with fast hard drives and 8G > >> of RAM do the trick? > > > > One aspect that I think is important is to ensure that the processor > > support the virtualization instructions. For Intel that's VT-x and VT-d > > and Intel tends to turn these features on and off at random across their > > processor range. So before buying a processor I'd recommend checking it > > out on http://ark.intel.com/. > > And no special graphics hardware, right, so Intel built in video is > sufficient? > > If so, Newman, can you order up a pair of boxes (and a new UPS) that > meet the criteria? Ideally, if we can get them online a little before > Wineconf, we can work based on those results. > > Cheers, > > Jeremy > > p.s. And then anyone want to volunteer to help Francois? That sounds > like it would be even more valuable... > > >

Sept. 3, 2015

Re: Prep for Wineconf - testing

by Jeremy White

> Yes, two extra boxes should maintain the old status-quo. > > >> That sound right? And would a pair of i5s with fast hard drives and 8G >> of RAM do the trick? > > One aspect that I think is important is to ensure that the processor > support the virtualization instructions. For Intel that's VT-x and VT-d > and Intel tends to turn these features on and off at random across their > processor range. So before buying a processor I'd recommend checking it > out on http://ark.intel.com/. And no special graphics hardware, right, so Intel built in video is sufficient? If so, Newman, can you order up a pair of boxes (and a new UPS) that meet the criteria? Ideally, if we can get them online a little before Wineconf, we can work based on those results. Cheers, Jeremy p.s. And then anyone want to volunteer to help Francois? That sounds like it would be even more valuable...

Sept. 3, 2015

Re: Prep for Wineconf - testing

by Bruno Jesus

On Thu, Sep 3, 2015 at 9:55 PM, Jeremy White <jwhite(a)codeweavers.com> wrote: > Hardware is cheap, particularly if we don't need beefy machines, as the > expected load is lower. > > ... > > That sound right? And would a pair of i5s with fast hard drives and 8G > of RAM do the trick? Since sending email is free and the worst that can happen is getting a no as answer I would like to give an idea. Attaching a 15 USD smart card reader to any of them and making it work in Windows would make winscard support get alive in Wine. Inserting any old credit card with chip (very common at least in Brazil) or any other 1 USD contact card would make all kinds of tests work. A sample reader that also should be supported by pcsclite is at [1] [1] http://www.amazon.com/HID-Global-Corporation-R30210015-1-OMNIKEY/dp/B003BKV… Best wishes, Bruno

Sept. 3, 2015

Re: Prep for Wineconf - testing

by Francois Gouget

On Thu, 3 Sep 2015, Jeremy White wrote: [...] > How many boxes should we buy? If I read Francois's notes on the default > configuration, it seems like the pipe was originally '3', which implies > two more boxes should do it. Yes, two extra boxes should maintain the old status-quo. > That sound right? And would a pair of i5s with fast hard drives and 8G > of RAM do the trick? One aspect that I think is important is to ensure that the processor support the virtualization instructions. For Intel that's VT-x and VT-d and Intel tends to turn these features on and off at random across their processor range. So before buying a processor I'd recommend checking it out on http://ark.intel.com/. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ "Lotto: A tax on people who are bad at math." -- unknown "Windows: Microsoft's tax on computer illiterates." -- WE7U

Sept. 3, 2015

Re: Prep for Wineconf - testing

by Francois Gouget

On Thu, 3 Sep 2015, Huw Davies wrote: [...] > Early indications are that this does indeed help > See: > http://test.winehq.org/data/tests/msi:action.html > (ignore the XP failures, they're not testbot's) [...] > and: > http://test.winehq.org/data/tests/gdi32:font.html [...] > I don't think it's entirely surprising given the long revert > times we're seeing. On the contrary I find that surprising. My understanding is that the MSI tests are I/O bound. But given the long revert times, reverts are not doing much I/O at all so they should not interfere that much with the tests. However based on some times I looked at this recently the QEmu process spins its heels, seemingly doign nothing. That means it keeps a core fully occupied. But given that the VM hosts have at least 4 cores each that should still not slow down the MSI tests much given that they only have access to two cores anyway. > It seems to me that adding more hardware (to have fewer VMs per host) > is the pragmatic way forward. It would also help to have more people contributing to the TestBot. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ I haven't lost my mind, it's backed up on tape around here somewhere...

Sept. 3, 2015

Re: Idea of fixing SHFileOperation(FO_MOVE)

by Bruno Jesus

On Thu, Sep 3, 2015 at 10:17 PM, Zhenbo Li <litimetal(a)gmail.com> wrote: > Hi Bruno, > > Thanks for your comments. > > 2015-09-03 16:04 GMT+08:00 Bruno Jesus <00cpxxx(a)gmail.com>: >> >> Hi, I dislike the idea of removing tests because they are obsolete but that >> is just my opinion. At least I like to keep winsock running in NT4. >> > Do you know how I can get the test result in NT4? I have no idea about that. Not really, I run tests manually. I don't think you should bother about that. >> What I have done in patches that reached similar issues is to detect the OS >> using a specific test that you are sure differs between OS and then use >> if/else to separate the tests. This reduces the amount of broken required, >> broken can be a vilain sometimes because it does not specify which OS is >> failing. > > How about this soultion? > ok(retval == value1 || broken(retval == value2) || broken(retval == value3) ...) > switch(retval) > { > case value1:... > case value2:... > case value3:... > } > > In this way, we can find the difference between OSs. What I was thinking was more simple like: retval = test_with_known_os_difference(); if(retval = VISTA_RESULT) { //all >= vista tests } else { //all xp + old broken tests } Others may have different opinion, this is just the way I do =)

Sept. 3, 2015

Re: Idea of fixing SHFileOperation(FO_MOVE)

by Zhenbo Li

Hi Bruno, Thanks for your comments. 2015-09-03 16:04 GMT+08:00 Bruno Jesus <00cpxxx(a)gmail.com>: > > Hi, I dislike the idea of removing tests because they are obsolete but that > is just my opinion. At least I like to keep winsock running in NT4. > Do you know how I can get the test result in NT4? I have no idea about that. > What I have done in patches that reached similar issues is to detect the OS > using a specific test that you are sure differs between OS and then use > if/else to separate the tests. This reduces the amount of broken required, > broken can be a vilain sometimes because it does not specify which OS is > failing. How about this soultion? ok(retval == value1 || broken(retval == value2) || broken(retval == value3) ...) switch(retval) { case value1:... case value2:... case value3:... } In this way, we can find the difference between OSs. -- Have a nice day! Zhenbo Li

Sept. 3, 2015

Re: Prep for Wineconf - testing

by Jeremy White

> It seems to me that adding more hardware (to have fewer > VMs per host) is the pragmatic way forward. Sure, we can > argue that the long revert times are crazy and should be fixed, > but nobody is going to do this anytime soon. Of course > somebody has to setup the said new hardware and reconfigure > testbot to use it, but hopefully that's something we know how to do. Hardware is cheap, particularly if we don't need beefy machines, as the expected load is lower. How many boxes should we buy? If I read Francois's notes on the default configuration, it seems like the pipe was originally '3', which implies two more boxes should do it. That sound right? And would a pair of i5s with fast hard drives and 8G of RAM do the trick? Cheers, Jeremy

Sept. 3, 2015

Re: quartz: Simplify a loop and make the code more robust

by Bruno Jesus

On Thu, Sep 3, 2015 at 9:06 PM, Bruno Jesus <00cpxxx(a)gmail.com> wrote: > Sorry, ignore this patch. Current quartz behavior is wrong and should be fixed instead of reinforced.

Sept. 3, 2015

Re: [4/13](resend)hidclass.sys: Add USB Descriptor parsing

by Henri Verbeet

On 3 September 2015 at 14:09, Aric Stewart <aric(a)codeweavers.com> wrote: >> Here and elsewhere, there's a lot of magic numbers. Do these have >> names in the standard? Could you make up names for them? TAG_INPUT or >> something. Or is it more useful to have the raw numbers? > > All these magic number have defined tags as per the USB spec. I was really hoping to find a nice header file where they where all defined but while there are a lot of document describing them and tools to turn the tags into numbers there was not clean header file. I chose to keep the numbers as numbers to avoid a lot of #defines. But that was just a personal choice. You could use an enum, of course. > +static const char* feature_string[] = You probably meant to write "static const char * const feature_string[] =" here. (And probably in some other places where you have arrays of string pointers.) > + return wine_dbg_sprintf("[%x - %x]", caps->u.Range.UsageMin, caps->u.Range.UsageMax); You almost never want to use plain "%x". (E.g., does "20" mean 32 or 20?) Use either "%#x or 0x%08x. > +int parse_descriptor(BYTE *descriptor, INT index, INT length, INT *feature_index, INT *collection_index, struct collection *collection, struct caps *caps, struct list *features) > +{ > + int i; > + for (i = index; i < length;) Unless "index" can legitimitely be < 0, it should be unsigned. I think the applies to most cases where you're using signed types. > + data->dwFeatureReportCount ++; That's a really unconventional way to format this.

Sept. 3, 2015

Re: [8/13](resend)hidclass.sys: Add a processing thread for HID devices

by Aric Stewart

>> + >> +static DWORD CALLBACK hid_device_thread(void *args) >> +{ >> + DEVICE_OBJECT *device = (DEVICE_OBJECT*)args; >> + >> + IRP *irp; >> + IO_STATUS_BLOCK irp_status; >> + IO_STACK_LOCATION *irpsp; >> + DWORD rc; >> + HANDLE events[2]; >> + NTSTATUS ntrc; >> + >> + BASE_DEVICE_EXTENSION *ext = device->DeviceExtension; >> + events[0] = CreateEventA(NULL, FALSE, FALSE, NULL); >> + events[1] = ext->halt_event; >> + >> + if (ext->information.Polled) >> + { >> + while(1) >> + { >> + HID_XFER_PACKET *packet; >> + ResetEvent(events[0]); >> + >> + packet = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(*packet) + ext->preparseData->caps.InputReportByteLength); >> + packet->reportBufferLen = ext->preparseData->caps.InputReportByteLength; >> + packet->reportBuffer = ((BYTE*)packet) + sizeof(*packet); >> + packet->reportId = 0; >> + >> + irp = IoBuildDeviceIoControlRequest(IOCTL_HID_GET_INPUT_REPORT, >> + device, NULL, 0, packet, sizeof(packet), TRUE, events[0], >> + &irp_status); >> + >> + irpsp = IoGetNextIrpStackLocation(irp); >> + irpsp->CompletionRoutine = read_Completion; >> + irpsp->Control = SL_INVOKE_ON_SUCCESS | SL_INVOKE_ON_ERROR; >> + >> + ntrc = IoCallDriver(device, irp); >> + >> + if (ntrc == STATUS_PENDING) >> + rc = WaitForMultipleObjects(2, events, FALSE, INFINITE); >> + >> + if (irp->IoStatus.u.Status == STATUS_SUCCESS) >> + { >> + RingBuffer_Write(ext->ring_buffer, packet); > > I'm not opposed to what you have here, but a get-buffer/commit-buffer > model would avoid an allocation and a memcpy. Although this would > complicate simultaneous writes, if that's a concern. > Part of the trickiness here is that the the packet gets 'consumed' by the IoCallDriver/IoCompleteRequest process. It needs to be a stack pointer. So I end up having to allocate it on the stack and then copy the result out of it. -aric

Sept. 3, 2015

Re: [7/13](resend)hidclass.sys: Implement IRP_MJ_READ for HID Devices

by Aric Stewart

On 9/2/15 7:12 PM, Vincent Povirk wrote: > On Wed, Sep 2, 2015 at 3:34 PM, Andrew Eikum <aeikum(a)codeweavers.com> wrote: >> Is it necessary to make a copy of the data in the ring buffer? Seems >> like returning a raw pointer would be more efficient. I flipped >> through the rest of the patch sequence and all uses of RingBuffer_Read >> seemed to be read-only. > > We have to hold the critical section while reading the data to prevent > another thread from writing to it (RingBuffer_Write added in next > patch). > > This doesn't mean we have to copy it, but the alternative is to > require readers to "lock" when reading and "unlock" when finished with > the data. And I don't know if it's a good idea to call > IoCompleteRequest while holding a mutex. > Yeah, I did not want to have to worry about holding a lock during processing, which mean basically i was copying the data out either on the RingBuffer_Read or locking, doing a read, then copying and unlocking anyway. -aric

Sept. 3, 2015

Re: [4/13](resend)hidclass.sys: Add USB Descriptor parsing

by Aric Stewart

Thanks for the review: On 9/2/15 1:53 PM, Andrew Eikum wrote: > A couple small notes inline below. > >> + bSize = (bSize == 3) ? 4 : bSize; >> + if (bType == 0x03 && bTag == 0x0F && bSize == 2 && i + 2 < length) >> + { >> + /* Long data items: Should be unused */ >> + ERR("Long Data Item, should be unused\n"); > > This confused me. Is this a malformed report from the HID or something > Wine doesn't yet support? It is in the spec but my reading I found statements that it was an option that was unused. So I wanted to highlight it if it was found but did not need to handle it. > > >> + if (bType == 0x00) >> + { >> + struct feature *feature; >> + switch(bTag) >> + { >> + case 0x08: > > Here and elsewhere, there's a lot of magic numbers. Do these have > names in the standard? Could you make up names for them? TAG_INPUT or > something. Or is it more useful to have the raw numbers? All these magic number have defined tags as per the USB spec. I was really hoping to find a nice header file where they where all defined but while there are a lot of document describing them and tools to turn the tags into numbers there was not clean header file. I chose to keep the numbers as numbers to avoid a lot of #defines. But that was just a personal choice. USB Report Descriptors are almost always written in a format like: 0x05, 0x01, // USAGE_PAGE (Generic Desktop) 0x09, 0x05, // USAGE (Game Pad) 0xa1, 0x01, // COLLECTION (Application) 0xa1, 0x00, // COLLECTION (Physical) 0x85, 0x01, // REPORT_ID (1) ... Where the hex values are the actual values in the report and the comments have the human readable meanings. Other comments are being integrated and the patch resent thanks again! -aric

Sept. 3, 2015

Re: [PATCH 5/6] wined3d: Return a texture from the swapchain resource creation callback.

by Henri Verbeet

On 3 September 2015 at 12:52, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > @@ -3034,32 +3034,29 @@ static HRESULT CDECL device_parent_volume_created(struct wined3d_device_parent * > return D3D_OK; > } > > -static HRESULT CDECL device_parent_create_swapchain_surface(struct wined3d_device_parent *device_parent, > - void *container_parent, const struct wined3d_resource_desc *desc, struct wined3d_surface **surface) > +static HRESULT CDECL device_parent_create_swapchain_texture(struct wined3d_device_parent *device_parent, > + void *container_parent, const struct wined3d_resource_desc *desc, struct wined3d_texture **texture) > { > struct d3d8_device *device = device_from_device_parent(device_parent); > struct wined3d_resource_desc texture_desc; > + struct wined3d_surface *surface; > struct d3d8_surface *d3d_surface; > - struct wined3d_texture *texture; > HRESULT hr; > > - TRACE("device_parent %p, container_parent %p, desc %p, surface %p.\n", > - device_parent, container_parent, desc, surface); > + TRACE("device_parent %p, container_parent %p, desc %p, texture %p.\n", > + device_parent, container_parent, desc, texture); > > texture_desc = *desc; > texture_desc.resource_type = WINED3D_RTYPE_TEXTURE; Now that you're creating a texture, you don't need to change the resource type anymore. You should just be able to pass "desc" to wined3d_texture_create(). > - *surface = wined3d_surface_from_resource(wined3d_texture_get_sub_resource(texture, 0)); > - wined3d_surface_incref(*surface); > - wined3d_texture_decref(texture); > - > - d3d_surface = wined3d_surface_get_parent(*surface); > + surface = wined3d_surface_from_resource(wined3d_texture_get_sub_resource(*texture, 0)); > + d3d_surface = wined3d_surface_get_parent(surface); wined3d_resource_get_parent(). > diff --git a/dlls/wined3d/device.c b/dlls/wined3d/device.c > index 765af0d..d50cd84 100644 > --- a/dlls/wined3d/device.c > +++ b/dlls/wined3d/device.c > @@ -4685,32 +4685,37 @@ HRESULT CDECL wined3d_device_reset(struct wined3d_device *device, > } > if (swapchain->desc.enable_auto_depth_stencil) > { > - struct wined3d_resource_desc surface_desc; > - struct wined3d_surface *surface; > + struct wined3d_resource_desc texture_desc; > + struct wined3d_texture *texture; > + struct wined3d_rendertarget_view_desc view_desc; > > TRACE("Creating the depth stencil buffer\n"); > > - surface_desc.resource_type = WINED3D_RTYPE_SURFACE; > - surface_desc.format = swapchain->desc.auto_depth_stencil_format; > - surface_desc.multisample_type = swapchain->desc.multisample_type; > - surface_desc.multisample_quality = swapchain->desc.multisample_quality; > - surface_desc.usage = WINED3DUSAGE_DEPTHSTENCIL; > - surface_desc.pool = WINED3D_POOL_DEFAULT; > - surface_desc.width = swapchain->desc.backbuffer_width; > - surface_desc.height = swapchain->desc.backbuffer_height; > - surface_desc.depth = 1; > - surface_desc.size = 0; > - > - if (FAILED(hr = device->device_parent->ops->create_swapchain_surface(device->device_parent, > - device->device_parent, &surface_desc, &surface))) > + texture_desc.resource_type = WINED3D_RTYPE_SURFACE; This looks wrong. It probably works anyway because you overwrite the resource type in the create_swapchain_texture() implementations.

Sept. 3, 2015

Re: [PATCH 1/2] reg: simplify root key search

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, This patch still fails to apply with the same error: stefan(a)retina ~/src/wine $ git am /dev/shm/\[PATCH\ 1_2\]\ reg\:\ simplify\ root\ key\ search.eml Applying: reg: simplify root key search /home/stefan/src/wine/.git/rebase-apply/patch:14: trailing whitespace. static const WCHAR short_hklm[] = {'H','K','L','M',0}; /home/stefan/src/wine/.git/rebase-apply/patch:15: trailing whitespace. static const WCHAR short_hkcu[] = {'H','K','C','U',0}; /home/stefan/src/wine/.git/rebase-apply/patch:16: trailing whitespace. static const WCHAR short_hkcr[] = {'H','K','C','R',0}; /home/stefan/src/wine/.git/rebase-apply/patch:17: trailing whitespace. static const WCHAR short_hku[] = {'H','K','U',0}; /home/stefan/src/wine/.git/rebase-apply/patch:18: trailing whitespace. static const WCHAR short_hkcc[] = {'H','K','C','C',0}; error: patch failed: programs/reg/reg.c:22 error: programs/reg/reg.c: patch does not apply Patch failed at 0001 reg: simplify root key search The copy of the patch that failed is found in: /home/stefan/src/wine/.git/rebase-apply/patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". Stefan Am 2015-08-31 um 22:09 schrieb Michel Zou: > Split patch from Jonathan Vollebregt: > https://github.com/jnvsor/wine/commit/ea0e2fc70db6ce4904655ea4a27ee34531d96… > > - --- > programs/reg/reg.c | 85 > +++++++++++++++++++++++++++--------------------------- 1 file > changed, 43 insertions(+), 42 deletions(-) > > > > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJV6Bl1AAoJEN0/YqbEcdMwf+sQAI7u19WiDrPOtniTS00sJZeS mrBSZHvhKlDujZ4iCr4VHyycBzhCmg8peflfgEHRyF9xGx6duy/mzh0JHN3qJFlM r7zbm9wbhFCaH7i4d1JD2a7l9hthow+N3PuPKWk5ox+T+Pe9HaXTQwxUmgB/6YjR xXjkHDEc5GtyBeqxpiskw2W92GWubrMrEJmfmlQQSWfcIZjkUM0MmKCEUCibMu3O bLPOsx1AjD3aQ+S0R50D3s1W1u/yO0tfKa0pGki2pqZRL/72UcbBWNow6F9tZIeD qXaAgNhvn0rc66nMVb7yc//9nN4oN2prBNtrpCtSCCfSgd/Xh47xoq8g3HQUXjHd nNbfSuePuNLvNzu5XhNb0yP5cGCZedU8q7cYcPURn376t25xw22daigpdId3kaS0 KN+gwb2M1PSazPwkjRy94qIX9Kl0NIsJT8dLHZgV0TM7ZrRBy0sa2baqH5jvL+4h pCn9+Kcuyv5jC7Oj/ewNx+9EIRmUf7wOJvgdNocUqwSyHPf7bJwZOysAm4ltk8pq A7RA2qiyicANi34Yf1e8zKG1Fv1M/uYwvjc3Sd8jrTpkn0z9mzijll4R+bcThAXA jdZjA3HTyvoaaENxmKJngb7Xz2o0WBV1WUEjIIUos+md8IV7bCnH0dbCDtE3AQKl u/eABCeasbpTQJ61px7N =V5u2 -----END PGP SIGNATURE-----

Sept. 3, 2015

Re: Prep for Wineconf - testing

by Huw Davies

On 1 Sep 2015, at 06:14, Alexandre Julliard wrote: > Francois Gouget <fgouget(a)free.fr> writes: > >> But it's possible the settings on the winehq.org server are different. >> Only Alexandre has access to that machine. If so, then I guess the >> experiment would call for trying the following settings: >> >> $MaxRevertingVMs = 1; >> $MaxRevertsWhileRunningVMs = 0; >> $MaxActiveVMs = 1; >> >> I'm a bit skeptical that it would make much of a difference. > > OK I changed it, let me know how it goes. Early indications are that this does indeed help See: http://test.winehq.org/data/tests/msi:action.html (ignore the XP failures, they're not testbot's) and: http://test.winehq.org/data/tests/gdi32:font.html I don't think it's entirely surprising given the long revert times we're seeing. It seems to me that adding more hardware (to have fewer VMs per host) is the pragmatic way forward. Sure, we can argue that the long revert times are crazy and should be fixed, but nobody is going to do this anytime soon. Of course somebody has to setup the said new hardware and reconfigure testbot to use it, but hopefully that's something we know how to do. Huw.

Sept. 3, 2015

Re: reg: Implement binary data add operation

by Alexandre Julliard

Thomas Faller <tfaller1(a)gmx.de> writes: > +static inline BOOL is_xp_or_older(void) > +{ > + DWORD version = GetVersion(); > + if(version < 0x80000000){ > + /* compare major */ > + return (DWORD)(LOBYTE(LOWORD(version))) < 6; > + } > + return TRUE; > +} Do you actually have an app that depends on such a version check? -- Alexandre Julliard julliard(a)winehq.org

Sept. 3, 2015

Re: Idea of fixing SHFileOperation(FO_MOVE)

by Bruno Jesus

On Thursday, September 3, 2015, Zhenbo Li <litimetal(a)gmail.com> wrote: > Hello, > > As I'm working on bug 25207, I found that previous test code > (test_move() in shlfileop.c) had some disadvantages > > 1. Duplicate tests > 2. Legacy test code (for Win98 or NT4) > 3. Lack of test for Vista or later Windows Versions > > As more applications are depending on the new behaviours introduced in > Vista, IMHO, we should focus on Vista's new behaviour. So I rewrote > test_move() to remove code for win98, mark xp behaviour as broken, and > expect Vista's behaviour. My next step is to re-implement FO_MOVE > operation of SHFileOperation to fix bug 25207. > > Any suggestion for this? Hi, I dislike the idea of removing tests because they are obsolete but that is just my opinion. At least I like to keep winsock running in NT4. What I have done in patches that reached similar issues is to detect the OS using a specific test that you are sure differs between OS and then use if/else to separate the tests. This reduces the amount of broken required, broken can be a vilain sometimes because it does not specify which OS is failing. Best wishes, Bruno

Sept. 3, 2015

Re: wineps.drv: Add glyph names for PostScript Format 1 glyphs (try 2).

by Huw Davies

On Thu, Sep 03, 2015 at 06:59:56AM +0300, Nikolay Sivov wrote: > 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. Note that we already have many of the glyph names in PSDRV_AGLbyUV[] and friends (see wineps.drv/data/agl.[ch]). Huw.

Sept. 3, 2015

Idea of fixing SHFileOperation(FO_MOVE)

by Zhenbo Li

Hello, As I'm working on bug 25207, I found that previous test code (test_move() in shlfileop.c) had some disadvantages 1. Duplicate tests 2. Legacy test code (for Win98 or NT4) 3. Lack of test for Vista or later Windows Versions As more applications are depending on the new behaviours introduced in Vista, IMHO, we should focus on Vista's new behaviour. So I rewrote test_move() to remove code for win98, mark xp behaviour as broken, and expect Vista's behaviour. My next step is to re-implement FO_MOVE operation of SHFileOperation to fix bug 25207. Any suggestion for this? Thank you. -- Have a nice day! Zhenbo Li

Sept. 3, 2015

Re: wineps.drv: Add glyph names for PostScript Format 1 glyphs (try 2).

by Nikolay Sivov

> +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.

Sept. 3, 2015

Re: [7/13](resend)hidclass.sys: Implement IRP_MJ_READ for HID Devices

by Vincent Povirk

On Wed, Sep 2, 2015 at 3:34 PM, Andrew Eikum <aeikum(a)codeweavers.com> wrote: > Is it necessary to make a copy of the data in the ring buffer? Seems > like returning a raw pointer would be more efficient. I flipped > through the rest of the patch sequence and all uses of RingBuffer_Read > seemed to be read-only. We have to hold the critical section while reading the data to prevent another thread from writing to it (RingBuffer_Write added in next patch). This doesn't mean we have to copy it, but the alternative is to require readers to "lock" when reading and "unlock" when finished with the data. And I don't know if it's a good idea to call IoCompleteRequest while holding a mutex.

Sept. 3, 2015

Re: [8/13](resend)hidclass.sys: Add a processing thread for HID devices

by Andrew Eikum

On Wed, Sep 02, 2015 at 07:02:18AM -0500, Aric Stewart wrote: > --- > dlls/hidclass.sys/buffer.c | 21 ++++++ > dlls/hidclass.sys/device.c | 175 +++++++++++++++++++++++++++++++++++++++++++++ > dlls/hidclass.sys/hid.h | 2 + > dlls/hidclass.sys/pnp.c | 2 + > 4 files changed, 200 insertions(+) > > > diff --git a/dlls/hidclass.sys/buffer.c b/dlls/hidclass.sys/buffer.c > index 6f09393..94e3372 100644 > --- a/dlls/hidclass.sys/buffer.c > +++ b/dlls/hidclass.sys/buffer.c > @@ -140,3 +140,24 @@ void RingBuffer_RemovePointer(struct ReportRingBuffer *ring, UINT index) > ring->pointers[index] = 0xffffffff; > LeaveCriticalSection(&ring->lock); > } > + > +void RingBuffer_Write(struct ReportRingBuffer *ring, void *data) > +{ > + UINT i; > + > + EnterCriticalSection(&ring->lock); > + memcpy(&ring->buffer[ring->end * ring->buffer_size], data, ring->buffer_size); > + ring->end++; > + if (ring->end == ring->size) > + ring->end = 0; > + if (ring->start == ring->end) > + { > + ring->start++; > + if (ring->start == ring->size) > + ring->start = 0; > + } > + for (i = 0; i < ring->pointer_alloc; i++) > + if (ring->pointers[i] == ring->end) > + ring->pointers[i] = ring->start; > + LeaveCriticalSection(&ring->lock); > +} > diff --git a/dlls/hidclass.sys/device.c b/dlls/hidclass.sys/device.c > index 326c994..e09a96c 100644 > --- a/dlls/hidclass.sys/device.c > +++ b/dlls/hidclass.sys/device.c > @@ -198,6 +198,181 @@ void HID_DeleteDevice(HID_MINIDRIVER_REGISTRATION *driver, DEVICE_OBJECT *device > IoDeleteDevice(device); > } > > +static void HID_Device_processQueue(DEVICE_OBJECT *device) > +{ > + LIST_ENTRY *entry; > + IRP *irp; > + BASE_DEVICE_EXTENSION *ext = device->DeviceExtension; > + UINT buffer_size = RingBuffer_GetBufferSize(ext->ring_buffer); > + HID_XFER_PACKET *packet; > + > + packet = HeapAlloc(GetProcessHeap(), 0, buffer_size); > + > + entry = RemoveHeadList(&ext->irp_queue); > + while(entry != &ext->irp_queue) > + { > + int ptr; > + irp = CONTAINING_RECORD(entry, IRP, Tail.Overlay.ListEntry); > + ptr = (int)irp->Tail.Overlay.OriginalFileObject->FsContext; > + > + buffer_size = RingBuffer_GetBufferSize(ext->ring_buffer); > + RingBuffer_Read(ext->ring_buffer, ptr, packet, &buffer_size); > + if (buffer_size) > + { > + IO_STACK_LOCATION *irpsp = IoGetCurrentIrpStackLocation(irp); > + TRACE_(hid_report)("Processing Request (%i)\n",ptr); > + if (irpsp->Parameters.Read.Length >= packet->reportBufferLen) > + { > + memcpy(irp->AssociatedIrp.SystemBuffer, packet->reportBuffer, packet->reportBufferLen); > + irp->IoStatus.Information = packet->reportBufferLen; > + irp->IoStatus.u.Status = STATUS_SUCCESS; > + } > + else > + { > + irp->IoStatus.Information = 0; > + irp->IoStatus.u.Status = STATUS_BUFFER_OVERFLOW; > + } > + } > + else > + { > + irp->IoStatus.Information = 0; > + irp->IoStatus.u.Status = STATUS_UNSUCCESSFUL; > + } > + IoCompleteRequest( irp, IO_NO_INCREMENT ); > + entry = RemoveHeadList(&ext->irp_queue); > + } > + HeapFree(GetProcessHeap(), 0, packet); > +} > + > +static NTSTATUS WINAPI read_Completion(DEVICE_OBJECT *deviceObject, IRP *irp, void *context ) > +{ > + SetEvent(irp->UserEvent); > + return STATUS_MORE_PROCESSING_REQUIRED; > +} > + > +static DWORD CALLBACK hid_device_thread(void *args) > +{ > + DEVICE_OBJECT *device = (DEVICE_OBJECT*)args; > + > + IRP *irp; > + IO_STATUS_BLOCK irp_status; > + IO_STACK_LOCATION *irpsp; > + DWORD rc; > + HANDLE events[2]; > + NTSTATUS ntrc; > + > + BASE_DEVICE_EXTENSION *ext = device->DeviceExtension; > + events[0] = CreateEventA(NULL, FALSE, FALSE, NULL); > + events[1] = ext->halt_event; > + > + if (ext->information.Polled) > + { > + while(1) > + { > + HID_XFER_PACKET *packet; > + ResetEvent(events[0]); > + > + packet = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(*packet) + ext->preparseData->caps.InputReportByteLength); > + packet->reportBufferLen = ext->preparseData->caps.InputReportByteLength; > + packet->reportBuffer = ((BYTE*)packet) + sizeof(*packet); > + packet->reportId = 0; > + > + irp = IoBuildDeviceIoControlRequest(IOCTL_HID_GET_INPUT_REPORT, > + device, NULL, 0, packet, sizeof(packet), TRUE, events[0], > + &irp_status); > + > + irpsp = IoGetNextIrpStackLocation(irp); > + irpsp->CompletionRoutine = read_Completion; > + irpsp->Control = SL_INVOKE_ON_SUCCESS | SL_INVOKE_ON_ERROR; > + > + ntrc = IoCallDriver(device, irp); > + > + if (ntrc == STATUS_PENDING) > + rc = WaitForMultipleObjects(2, events, FALSE, INFINITE); > + > + if (irp->IoStatus.u.Status == STATUS_SUCCESS) > + { > + RingBuffer_Write(ext->ring_buffer, packet); I'm not opposed to what you have here, but a get-buffer/commit-buffer model would avoid an allocation and a memcpy. Although this would complicate simultaneous writes, if that's a concern.

Sept. 2, 2015

Re: [7/13](resend)hidclass.sys: Implement IRP_MJ_READ for HID Devices

by Andrew Eikum

On Wed, Sep 02, 2015 at 07:02:11AM -0500, Aric Stewart wrote: > diff --git a/dlls/hidclass.sys/buffer.c b/dlls/hidclass.sys/buffer.c > index 2561235..6f09393 100644 > --- a/dlls/hidclass.sys/buffer.c > +++ b/dlls/hidclass.sys/buffer.c > @@ -80,6 +80,39 @@ void RingBuffer_Destroy(struct ReportRingBuffer *ring) > HeapFree(GetProcessHeap(), 0, ring); > } > > +UINT RingBuffer_GetBufferSize(struct ReportRingBuffer *ring) > +{ > + return ring->buffer_size; > +} > + > +void RingBuffer_Read(struct ReportRingBuffer *ring, UINT index, void *output, UINT *size) > +{ > + void *ret = NULL; > + > + EnterCriticalSection(&ring->lock); > + if (index >= ring->pointer_alloc || ring->pointers[index] == 0xffffffff) > + { > + LeaveCriticalSection(&ring->lock); > + *size = 0; > + return; > + } > + if (ring->pointers[index] == ring->end) > + { > + LeaveCriticalSection(&ring->lock); > + *size = 0; > + } > + else > + { > + ret = &ring->buffer[ring->pointers[index] * ring->buffer_size]; > + memcpy(output, ret, ring->buffer_size); Is it necessary to make a copy of the data in the ring buffer? Seems like returning a raw pointer would be more efficient. I flipped through the rest of the patch sequence and all uses of RingBuffer_Read seemed to be read-only. > + ring->pointers[index]++; > + if (ring->pointers[index] == ring->size) > + ring->pointers[index] = 0; > + LeaveCriticalSection(&ring->lock); > + *size = ring->buffer_size; > + } > +} > + > UINT RingBuffer_AddPointer(struct ReportRingBuffer *ring) > { > UINT idx; > diff --git a/dlls/hidclass.sys/device.c b/dlls/hidclass.sys/device.c > index a6660db..326c994 100644 > --- a/dlls/hidclass.sys/device.c > +++ b/dlls/hidclass.sys/device.c > @@ -36,6 +36,7 @@ > #include "devguid.h" > > WINE_DEFAULT_DEBUG_CHANNEL(hid); > +WINE_DECLARE_DEBUG_CHANNEL(hid_report); > > static const WCHAR device_name_fmtW[] = {'\\','D','e','v','i','c','e', > '\\','H','I','D','#','%','p','&','%','p',0}; > @@ -353,6 +354,48 @@ NTSTATUS WINAPI HID_Device_ioctl(DEVICE_OBJECT *device, IRP *irp) > return rc; > } > > +NTSTATUS WINAPI HID_Device_read(DEVICE_OBJECT *device, IRP *irp) > +{ > + HID_XFER_PACKET *packet; > + BASE_DEVICE_EXTENSION *ext = device->DeviceExtension; > + UINT buffer_size = RingBuffer_GetBufferSize(ext->ring_buffer); > + NTSTATUS rc = STATUS_SUCCESS; > + int ptr = -1; > + > + packet = HeapAlloc(GetProcessHeap(), 0, buffer_size); > + ptr = (int)irp->Tail.Overlay.OriginalFileObject->FsContext; > + > + irp->IoStatus.Information = 0; > + RingBuffer_Read(ext->ring_buffer, ptr, packet, &buffer_size); > + > + if (buffer_size) > + { > + IO_STACK_LOCATION *irpsp = IoGetCurrentIrpStackLocation( irp ); > + TRACE_(hid_report)("Got Packet %p %i\n", packet->reportBuffer, packet->reportBufferLen); > + if (irpsp->Parameters.Read.Length >= packet->reportBufferLen) > + { > + memcpy(irp->AssociatedIrp.SystemBuffer, packet->reportBuffer, packet->reportBufferLen); > + irp->IoStatus.Information = packet->reportBufferLen; > + irp->IoStatus.u.Status = STATUS_SUCCESS; > + } > + else > + { > + irp->IoStatus.Information = 0; > + irp->IoStatus.u.Status = STATUS_BUFFER_OVERFLOW; > + } > + IoCompleteRequest( irp, IO_NO_INCREMENT ); > + } > + else > + { > + TRACE_(hid_report)("Queue irp\n"); > + InsertTailList(&ext->irp_queue, &irp->Tail.Overlay.ListEntry); > + rc = STATUS_PENDING; > + } > + HeapFree(GetProcessHeap(), 0, packet); > + > + return rc; > +} > + > NTSTATUS WINAPI HID_Device_create(DEVICE_OBJECT *device, IRP *irp) > { > BASE_DEVICE_EXTENSION *ext = device->DeviceExtension; > diff --git a/dlls/hidclass.sys/hid.h b/dlls/hidclass.sys/hid.h > index c9bc338..34ec241 100644 > --- a/dlls/hidclass.sys/hid.h > +++ b/dlls/hidclass.sys/hid.h > @@ -58,6 +58,8 @@ typedef struct _BASE_DEVICE_EXTENSTION { > > UINT RingBuffer_AddPointer(struct ReportRingBuffer *buffer) DECLSPEC_HIDDEN; > void RingBuffer_RemovePointer(struct ReportRingBuffer *ring, UINT index) DECLSPEC_HIDDEN; > +void RingBuffer_Read(struct ReportRingBuffer *buffer, UINT index, void *output, UINT *size) DECLSPEC_HIDDEN; > +UINT RingBuffer_GetBufferSize(struct ReportRingBuffer *buffer) DECLSPEC_HIDDEN; > void RingBuffer_Destroy(struct ReportRingBuffer *buffer) DECLSPEC_HIDDEN; > struct ReportRingBuffer* RingBuffer_Create(UINT buffer_size) DECLSPEC_HIDDEN; > > @@ -81,6 +83,7 @@ NTSTATUS HID_LinkDevice(DEVICE_OBJECT *device, LPCWSTR serial, LPCWSTR index) DE > void HID_DeleteDevice(HID_MINIDRIVER_REGISTRATION *driver, DEVICE_OBJECT *device) DECLSPEC_HIDDEN; > > NTSTATUS WINAPI HID_Device_ioctl(DEVICE_OBJECT *device, IRP *irp) DECLSPEC_HIDDEN; > +NTSTATUS WINAPI HID_Device_read(DEVICE_OBJECT *device, IRP *irp) DECLSPEC_HIDDEN; > NTSTATUS WINAPI HID_Device_create(DEVICE_OBJECT *device, IRP *irp) DECLSPEC_HIDDEN; > NTSTATUS WINAPI HID_Device_close(DEVICE_OBJECT *device, IRP *irp) DECLSPEC_HIDDEN; > > diff --git a/dlls/hidclass.sys/main.c b/dlls/hidclass.sys/main.c > index 1e0e802..4be4409 100644 > --- a/dlls/hidclass.sys/main.c > +++ b/dlls/hidclass.sys/main.c > @@ -69,6 +69,7 @@ NTSTATUS WINAPI HidRegisterMinidriver(HID_MINIDRIVER_REGISTRATION *registration) > registration->DriverObject->DriverUnload = UnloadDriver; > > registration->DriverObject->MajorFunction[IRP_MJ_DEVICE_CONTROL] = HID_Device_ioctl; > + registration->DriverObject->MajorFunction[IRP_MJ_READ] = HID_Device_read; > registration->DriverObject->MajorFunction[IRP_MJ_CREATE] = HID_Device_create; > registration->DriverObject->MajorFunction[IRP_MJ_CLOSE] = HID_Device_close; > > >

Sept. 2, 2015

Re: [2/4] user32: Add test case for DeferWindowPos() with invalid HWND (try 2)

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=16475 Your paranoid android. === w8 (32 bit win) === win.c:3417: Test failed: hwnd 000300F6 message 0118

Sept. 2, 2015

Re: [4/13](resend)hidclass.sys: Add USB Descriptor parsing

by Andrew Eikum

A couple small notes inline below. On Wed, Sep 02, 2015 at 07:01:51AM -0500, Aric Stewart wrote: > diff --git a/dlls/hidclass.sys/Makefile.in b/dlls/hidclass.sys/Makefile.in > index 8ed51e6..6e79486 100644 > --- a/dlls/hidclass.sys/Makefile.in > +++ b/dlls/hidclass.sys/Makefile.in > @@ -5,6 +5,7 @@ DELAYIMPORTS = setupapi hid > > C_SRCS = \ > buffer.c \ > + descriptor.c \ > device.c \ > main.c \ > pnp.c > diff --git a/dlls/hidclass.sys/descriptor.c b/dlls/hidclass.sys/descriptor.c > new file mode 100644 > index 0000000..c277dec > --- /dev/null > +++ b/dlls/hidclass.sys/descriptor.c > @@ -0,0 +1,1106 @@ > +/* > + * HID descriptor parsing > + * > + * Copyright (C) 2015 Aric Stewart > + * > + * 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 > + */ > + > +#include "config.h" > + > +#include <stdarg.h> > +#include <stdlib.h> > +#define NONAMELESSUNION > +#include "hid.h" > + > +#include "wine/debug.h" > +#include "wine/list.h" > + > +WINE_DEFAULT_DEBUG_CHANNEL(hid); > + > +#define USAGE_MAX 10 > + > +static const char* feature_string[] = > + { "Input", "Output", "Feature" }; > + > +struct caps { > + USAGE UsagePage; > + LONG LogicalMin; > + LONG LogicalMax; > + LONG PhysicalMin; > + LONG PhysicalMax; > + ULONG UnitsExp; > + ULONG Units; > + USHORT BitSize; > + UCHAR ReportID; > + USHORT ReportCount; > + > + BOOLEAN IsRange; > + BOOLEAN IsStringRange; > + BOOLEAN IsDesignatorRange; > + int usage_count; > + union { > + struct { > + USAGE UsageMin; > + USAGE UsageMax; > + USHORT StringMin; > + USHORT StringMax; > + USHORT DesignatorMin; > + USHORT DesignatorMax; > + } Range; > + struct { > + USAGE Usage[USAGE_MAX]; > + USAGE Reserved1; > + USHORT StringIndex; > + USHORT Reserved2; > + USHORT DesignatorIndex; > + USHORT Reserved3; > + } NotRange; > + } DUMMYUNIONNAME; > + > + int Delim; > +}; > + > +struct feature { > + struct list entry; > + struct list col_entry; > + struct caps caps; > + > + HIDP_REPORT_TYPE type; > + BOOLEAN isData; > + BOOLEAN isArray; > + BOOLEAN IsAbsolute; > + BOOLEAN Wrap; > + BOOLEAN Linear; > + BOOLEAN prefState; > + BOOLEAN HasNull; > + BOOLEAN Volatile; > + BOOLEAN BitField; > + > + int index; > + struct collection *collection; > +}; > + > +static const char* collection_string[] = { > + "Physical", > + "Application", > + "Logical", > + "Report", > + "Named Array", > + "Usage Switch", > + "Usage Modifier", > +}; > + > +struct collection { > + struct list entry; > + struct caps caps; > + int index; > + int type; > + struct collection *parent; > + struct list features; > + struct list collections; > +}; > + > +static const char* debugstr_usages(struct caps *caps) > +{ > + if (!caps->IsRange) > + { > + static char out[30]; > + int i; > + strcpy(out, "[ "); > + for (i = 0; i < caps->usage_count; i++) > + strcat(out, wine_dbg_sprintf("%x ", caps->u.NotRange.Usage[i])); > + strcat(out,"]"); > + return out; > + } > + else > + return wine_dbg_sprintf("[%x - %x]", caps->u.Range.UsageMin, caps->u.Range.UsageMax); > +} > + > +static const char* debugstr_stringindex(struct caps *caps) > +{ > + if (!caps->IsStringRange) > + return wine_dbg_sprintf("%i", caps->u.NotRange.StringIndex); > + else > + return wine_dbg_sprintf("[%i - %i]", caps->u.Range.StringMin, caps->u.Range.StringMax); > +} > + > +static const char* debugstr_designatorindex(struct caps *caps) > +{ > + if (!caps->IsDesignatorRange) > + return wine_dbg_sprintf("%i", caps->u.NotRange.DesignatorIndex); > + else > + return wine_dbg_sprintf("[%i - %i]", caps->u.Range.DesignatorMin, caps->u.Range.DesignatorMax); > +} > + > +static const char* debugstr_caps(struct caps *caps) > +{ > + if (!caps) > + return ""; > + return wine_dbg_sprintf("(UsagePage %x; LogicalMin %i; LogicalMax %i; PhysicalMin %i; PhysicalMax %i; UnitsExp %i; Units %i; BitSize %i; ReportID %i; ReportCount %i; Usage %s; StringIndex %s; DesignatorIndex %s; Delim %i;)", > + caps->UsagePage, > + caps->LogicalMin, > + caps->LogicalMax, > + caps->PhysicalMin, > + caps->PhysicalMax, > + caps->UnitsExp, > + caps->Units, > + caps->BitSize, > + caps->ReportID, > + caps->ReportCount, > + debugstr_usages(caps), > + debugstr_stringindex(caps), > + debugstr_designatorindex(caps), > + caps->Delim); > +} > + > +static void debug_feature(struct feature *feature) > +{ > + if (!feature) > + return; > + TRACE("[\n\t type %s [%i]; %s; %s; %s; %s; %s; %s; %s; %s; %s\n\t %s\n]\n", > + feature_string[feature->type], > + feature->index, > + (feature->isData)?"Data":"Const", > + (feature->isArray)?"Array":"Var", > + (feature->IsAbsolute)?"Abs":"Rel", > + (feature->Wrap)?"Wrap":"NoWrap", > + (feature->Linear)?"Linear":"NonLinear", > + (feature->prefState)?"PrefStat":"NoPrefState", > + (feature->HasNull)?"HasNull":"NoNull", > + (feature->Volatile)?"Volatile":"NonVolatile", > + (feature->BitField)?"BitField":"Buffered", > + debugstr_caps(&feature->caps)); > +} > + > +static void debug_collection(struct collection *collection) > +{ > + struct feature *fentry; > + struct collection *centry; > + if (TRACE_ON(hid)) > + { > + TRACE("{ %s[%i], %p, %i features, %i collections\n\t %s\n", collection_string[collection->type], collection->index, collection->parent, list_count(&collection->features), list_count(&collection->collections), debugstr_caps(&collection->caps)); > + LIST_FOR_EACH_ENTRY(fentry, &collection->features, struct feature, col_entry) > + debug_feature(fentry); > + LIST_FOR_EACH_ENTRY(centry, &collection->collections, struct collection, entry) > + debug_collection(centry); > + TRACE("}\n"); > + } > +} > + > +static void debug_print_button_cap(const CHAR * type, WINE_HID_ELEMENT *wine_element) > +{ > + if (!wine_element->caps.button.IsRange) > + TRACE("%s Button: %x/%04x: ReportId %i, startBit %i/1\n" , type, > + wine_element->caps.button.UsagePage, > + wine_element->caps.button.u.NotRange.Usage, > + wine_element->caps.value.ReportID, > + wine_element->valueStartBit); > + else > + TRACE("%s Button: %x/[%04x-%04x]: ReportId %i, startBit %i/%i\n" ,type, > + wine_element->caps.button.UsagePage, > + wine_element->caps.button.u.Range.UsageMin, > + wine_element->caps.button.u.Range.UsageMax, > + wine_element->caps.value.ReportID, > + wine_element->valueStartBit, > + wine_element->bitCount); > +} > + > +static void debug_print_value_cap(const CHAR * type, WINE_HID_ELEMENT *wine_element) > +{ > + TRACE("%s Value: %x/%x: ReportId %i, IsAbsolute %i, HasNull %i, " > + "Bit Size %i, ReportCount %i, UnitsExp %i, Units %i, " > + "LogicalMin %i, Logical Max %i, PhysicalMin %i, " > + "PhysicalMax %i -- StartBit %i/%i\n", type, > + wine_element->caps.value.UsagePage, > + wine_element->caps.value.u.NotRange.Usage, > + wine_element->caps.value.ReportID, > + wine_element->caps.value.IsAbsolute, > + wine_element->caps.value.HasNull, > + wine_element->caps.value.BitSize, > + wine_element->caps.value.ReportCount, > + wine_element->caps.value.UnitsExp, > + wine_element->caps.value.Units, > + wine_element->caps.value.LogicalMin, > + wine_element->caps.value.LogicalMax, > + wine_element->caps.value.PhysicalMin, > + wine_element->caps.value.PhysicalMax, > + wine_element->valueStartBit, > + wine_element->bitCount); > +} > + > +static void debug_print_element(const CHAR* type, WINE_HID_ELEMENT *wine_element) > +{ > + if (wine_element->ElementType == ButtonElement) > + debug_print_button_cap(type, wine_element); > + else if (wine_element->ElementType == ValueElement) > + debug_print_value_cap(type, wine_element); > + else > + TRACE("%s: UNKNOWN\n", type); > +} > + > +static void debug_print_report(const char* type, WINE_HID_REPORT *report) > +{ > + int i; > + TRACE("%s REPORT:\n" > + "\tReportID: %i\n" > + "\tdwSize: %i\n" > + "\telementCount: %i\n", > + type, > + report->reportID, > + report->dwSize, > + report->elementCount); > + for (i = 0; i < report->elementCount; i++) > + debug_print_element(type, &report->Elements[i]); > +} > + > +static void debug_print_preparsed(WINE_HIDP_PREPARSED_DATA *data) > +{ > + int i; > + WINE_HID_REPORT *r; > + if (TRACE_ON(hid)) > + { > + TRACE("PREPARSED Data:\n" > + "\tdwSize: %i\n" > + "\tCaps:\n" > + "\t\tUsage: %i\n" > + "\t\tUsagePage: %i\n" > + "\t\tInputReportByteLength: %i\n" > + "\t\tOutputReportByteLength: %i\n" > + "\t\tFeatureReportByteLength: %i\n" > + "\t\tNumberLinkCollectionNodes: %i\n" > + "\t\tNumberInputButtonCaps: %i\n" > + "\t\tNumberInputValueCaps: %i\n" > + "\t\tNumberInputDataIndices: %i\n" > + "\t\tNumberOutputButtonCaps: %i\n" > + "\t\tNumberOutputValueCaps: %i\n" > + "\t\tNumberOutputDataIndices: %i\n" > + "\t\tNumberFeatureButtonCaps: %i\n" > + "\t\tNumberFeatureValueCaps: %i\n" > + "\t\tNumberFeatureDataIndices: %i\n" > + "\tdwInputReportCount: %i\n" > + "\tdwOutputReportCount: %i\n" > + "\tdwFeatureReportCount: %i\n" > + "\tdwOutputReportOffset: %i\n" > + "\tdwFeatureReportOffset: %i\n", > + data->dwSize, > + data->caps.Usage, > + data->caps.UsagePage, > + data->caps.InputReportByteLength, > + data->caps.OutputReportByteLength, > + data->caps.FeatureReportByteLength, > + data->caps.NumberLinkCollectionNodes, > + data->caps.NumberInputButtonCaps, > + data->caps.NumberInputValueCaps, > + data->caps.NumberInputDataIndices, > + data->caps.NumberOutputButtonCaps, > + data->caps.NumberOutputValueCaps, > + data->caps.NumberOutputDataIndices, > + data->caps.NumberFeatureButtonCaps, > + data->caps.NumberFeatureValueCaps, > + data->caps.NumberFeatureDataIndices, > + data->dwInputReportCount, > + data->dwOutputReportCount, > + data->dwFeatureReportCount, > + data->dwOutputReportOffset, > + data->dwFeatureReportOffset); > + > + r = HID_INPUT_REPORTS(data); > + for (i = 0; i < data->dwInputReportCount; i++) > + { > + debug_print_report("INPUT", r); > + r = HID_NEXT_REPORT(data, r); > + } > + r = HID_OUTPUT_REPORTS(data); > + for (i = 0; i < data->dwOutputReportCount; i++) > + { > + debug_print_report("OUTPUT", r); > + r = HID_NEXT_REPORT(data, r); > + } > + r = HID_FEATURE_REPORTS(data); > + for (i = 0; i < data->dwFeatureReportCount; i++) > + { > + debug_print_report("FEATURE", r); > + r = HID_NEXT_REPORT(data, r); > + } > + } > +} > + > +static int getValue(int bsize, int source) > +{ > + int mask = 0xff; > + int negative = 0x80; > + int outofrange = 0x100; > + int value; > + int i; > + > + if (bsize == 4) > + return source; > + > + for (i = 1; i < bsize; i++) > + { > + mask = (mask<<8) + 0xff; > + negative = (negative<<8); > + outofrange = (outofrange<<8); > + } > + value = (source&mask); > + if (value&negative) > + value = -1 * (outofrange - value); > + return value; > +} > + > +void parse_io_feature(int bSize, int itemVal, int bTag, int *feature_index, struct feature *feature) > +{ > + if (bSize <= 0) > + { > + return; > + } > + else > + { > + if ((itemVal & 0x01) == 0) > + feature->isData = TRUE; > + else > + feature->isData = FALSE; //Const > + if ((itemVal & 0x02) == 0) > + feature->isArray= TRUE; > + else > + feature->isArray= TRUE; //Var > + if ((itemVal & 0x04) == 0) > + feature->IsAbsolute = TRUE; > + else > + feature->IsAbsolute = FALSE; //Rel > + if ((itemVal & 0x08) == 0) > + feature->Wrap = FALSE; > + else > + feature->Wrap = TRUE; > + if ((itemVal & 0x10) == 0) > + feature->Linear = TRUE; > + else > + feature->Linear = FALSE; > + if ((itemVal & 0x20) == 0) > + feature->prefState = TRUE; > + else > + feature->prefState = FALSE; > + if ((itemVal & 0x40) == 0) > + feature->HasNull = FALSE; > + else > + feature->HasNull = TRUE; > + > + if (bTag != 0x08) > + { > + if ((itemVal & 0x80) == 0) > + feature->Volatile = FALSE; > + else > + feature->Volatile = TRUE; > + } > + if (bSize > 1) > + { > + if ((itemVal & 0x100) == 0) > + feature->BitField = TRUE; > + else > + feature->BitField = FALSE; //Buffered Bytes > + } > + feature->index = *feature_index; > + *feature_index = *feature_index + 1; > + } > +} > + > +void parse_collection(int bSize, int itemVal, struct collection *collection) > +{ > + if (bSize <= 0) > + return; > + else > + { > + collection->type = itemVal; > + > + if (itemVal >= 0x07 && itemVal <= 0x7F) { > + ERR(" (Reserved %x )\n", itemVal); > + } > + else if (itemVal >= 0x80 && itemVal <= 0xFF) { > + ERR(" (Vendor Defined %x )\n", itemVal); > + } > + } > +} > + > +static void new_caps(struct caps *caps) > +{ > + caps->IsRange = 0; > + caps->IsStringRange = 0; > + caps->IsDesignatorRange = 0; > + caps->usage_count = 0; > +} > + > +int parse_descriptor(BYTE *descriptor, INT index, INT length, INT *feature_index, INT *collection_index, struct collection *collection, struct caps *caps, struct list *features) > +{ > + int i; > + for (i = index; i < length;) > + { > + BYTE b0 = descriptor[i++]; > + int bSize = b0 & 0x03; > + int bType = (b0 >> 2) & 0x03; > + int bTag = (b0 >> 4) & 0x0F; > + > + bSize = (bSize == 3) ? 4 : bSize; > + if (bType == 0x03 && bTag == 0x0F && bSize == 2 && i + 2 < length) > + { > + /* Long data items: Should be unused */ > + ERR("Long Data Item, should be unused\n"); This confused me. Is this a malformed report from the HID or something Wine doesn't yet support? > + } > + else > + { > + int bSizeActual = 0; > + int itemVal = 0; > + int j; > + > + for (j = 0; j < bSize; j++) > + { > + if (i + j < length) > + { > + itemVal += descriptor[i + j] << (8 * j); > + bSizeActual++; > + } > + } > + TRACE(" %x[%i], type %i , tag %i, size %i, val %i\n",b0,i-1,bType, bTag, bSize, itemVal ); > + > + if (bType == 0x00) > + { > + struct feature *feature; > + switch(bTag) > + { > + case 0x08: Here and elsewhere, there's a lot of magic numbers. Do these have names in the standard? Could you make up names for them? TAG_INPUT or something. Or is it more useful to have the raw numbers? > + feature = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(*feature)); > + list_add_tail(&collection->features, &feature->col_entry); > + list_add_tail(features, &feature->entry); > + feature->type = HidP_Input; > + parse_io_feature(bSize, itemVal, bTag, feature_index, feature); > + feature->caps = *caps; > + feature->collection = collection; > + new_caps(caps); > + break; > + case 0x09: > + feature = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(*feature)); > + list_add_tail(&collection->features, &feature->col_entry); > + list_add_tail(features, &feature->entry); > + feature->type = HidP_Output; > + parse_io_feature(bSize, itemVal, bTag, feature_index, feature); > + feature->caps = *caps; > + feature->collection = collection; > + new_caps(caps); > + break; > + case 0x0B: > + feature = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(*feature)); > + list_add_tail(&collection->features, &feature->col_entry); > + list_add_tail(features, &feature->entry); > + feature->type = HidP_Feature; > + parse_io_feature(bSize, itemVal, bTag, feature_index, feature); > + feature->caps = *caps; > + feature->collection = collection; > + new_caps(caps); > + break; > + case 0x0A: Here, the cases are in a different order. That wouldn't matter with symbols, but it struck me with the raw numbers. > + { > + struct collection *subcollection = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(struct collection)); > + list_add_tail(&collection->collections, &subcollection->entry); > + subcollection->parent = collection; > + /* Only set our collection once... > + We do not properly handle composite devices yet. */ > + if (*collection_index == 0) > + collection->caps = *caps; > + subcollection->caps = *caps; > + subcollection->index = *collection_index; > + *collection_index = *collection_index + 1; > + list_init(&subcollection->features); > + list_init(&subcollection->collections); > + new_caps(caps); > + > + parse_collection(bSize, itemVal, subcollection); > + > + i = parse_descriptor(descriptor, i+1, length, feature_index, collection_index, subcollection, caps, features); > + continue; > + } > + case 0x0C: > + return i; > + default: > + ERR("Unknown Tag\n"); Would it be useful to print the tag value here? > + } > + } > + else if (bType == 0x01) > + { > + switch(bTag) > + { > + case 0x00: > + caps->UsagePage = getValue(bSize, itemVal); > + break; > + case 0x01: > + caps->LogicalMin = getValue(bSize, itemVal); > + break; > + case 0x02: > + caps->LogicalMax = getValue(bSize, itemVal); > + break; > + case 0x03: > + caps->PhysicalMin = getValue(bSize, itemVal); > + break; > + case 0x04: > + caps->PhysicalMax = getValue(bSize, itemVal); > + break; > + case 0x05: > + caps->UnitsExp = getValue(bSize, itemVal); > + break; > + case 0x06: > + caps->Units = getValue(bSize, itemVal); > + break; > + case 0x07: > + caps->BitSize = getValue(bSize, itemVal); > + break; > + case 0x08: > + caps->ReportID = getValue(bSize, itemVal); > + break; > + case 0x09: > + caps->ReportCount = getValue(bSize, itemVal); > + break; > + case 0x0A: > + ERR("Push\n"); > + break; > + case 0x0B: > + ERR("Pop\n"); > + break; Are these invalid messages from the HID device, or things wine doesn't yet support? Should they be FIXMEs? > + default: > + ERR("Unknown (bTag: %x, bType: %x)\n", bTag, bType); > + } > + } > + else if (bType == 0x02) > + { > + switch(bTag) > + { > + case 0x00: > + if (caps->usage_count >= USAGE_MAX) > + FIXME("More than %i individual usages defined\n",USAGE_MAX); > + else > + { > + caps->u.NotRange.Usage[caps->usage_count++] = getValue(bSize, itemVal); > + caps->IsRange = FALSE; > + } > + break; > + case 0x01: > + caps->usage_count = 1; > + caps->u.Range.UsageMin = getValue(bSize, itemVal); > + caps->IsRange = TRUE; > + break; > + case 0x02: > + caps->usage_count = 1; > + caps->u.Range.UsageMax = getValue(bSize, itemVal); > + caps->IsRange = TRUE; > + break; > + case 0x03: > + caps->u.NotRange.DesignatorIndex = getValue(bSize, itemVal); > + caps->IsDesignatorRange = FALSE; > + break; > + case 0x04: > + caps->u.Range.DesignatorMin = getValue(bSize, itemVal); > + caps->IsDesignatorRange = TRUE; > + break; > + case 0x05: > + caps->u.Range.DesignatorMax = getValue(bSize, itemVal); > + caps->IsDesignatorRange = TRUE; > + break; > + case 0x07: > + caps->u.NotRange.StringIndex = getValue(bSize, itemVal); > + caps->IsStringRange = FALSE; > + break; > + case 0x08: > + caps->u.Range.StringMin = getValue(bSize, itemVal); > + caps->IsStringRange = TRUE; > + break; > + case 0x09: > + caps->u.Range.StringMax = getValue(bSize, itemVal); > + caps->IsStringRange = TRUE; > + break; > + case 0x0A: > + caps->Delim = getValue(bSize, itemVal); > + break; > + default: > + ERR("Unknown (bTag: %x, bType: %x)\n", bTag, bType); > + } > + } > + else > + ERR("Unknown (bTag: %x, bType: %x)\n", bTag, bType); > + > + i += bSize; > + } > + } > + return i; > +} > + > +static inline void new_report(WINE_HID_REPORT *wine_report, struct feature* feature) > +{ > + wine_report->reportID = feature->caps.ReportID; > + wine_report->dwSize = sizeof(*wine_report) - sizeof(WINE_HID_ELEMENT); > + wine_report->elementCount = 0; > +} > + > +static void build_elements(WINE_HID_REPORT *wine_report, struct feature* feature, DWORD *bitOffset) > +{ > + int i; > + > + if (!feature->isData) > + { > + *bitOffset = *bitOffset + (feature->caps.BitSize * feature->caps.ReportCount); > + return; > + } > + > + for (i = 0; i < feature->caps.usage_count; i++) > + { > + WINE_HID_ELEMENT *wine_element = &wine_report->Elements[wine_report->elementCount]; > + > + wine_element->valueStartBit = *bitOffset; > + if (feature->caps.UsagePage == HID_USAGE_PAGE_BUTTON) > + { > + wine_element->ElementType = ButtonElement; > + wine_element->caps.button.UsagePage = feature->caps.UsagePage; > + wine_element->caps.button.ReportID = feature->caps.ReportID; > + wine_element->caps.button.BitField = feature->BitField; > + wine_element->caps.button.IsRange = feature->caps.IsRange; > + wine_element->caps.button.IsStringRange = feature->caps.IsStringRange; > + wine_element->caps.button.IsDesignatorRange = feature->caps.IsDesignatorRange; > + wine_element->caps.button.IsAbsolute = feature->IsAbsolute; > + if (wine_element->caps.button.IsRange) > + { > + wine_element->bitCount = (feature->caps.u.Range.UsageMax - feature->caps.u.Range.UsageMin) + 1; > + *bitOffset = *bitOffset + wine_element->bitCount; > + wine_element->caps.button.u.Range.UsageMin = feature->caps.u.Range.UsageMin; > + wine_element->caps.button.u.Range.UsageMax = feature->caps.u.Range.UsageMax; > + wine_element->caps.button.u.Range.StringMin = feature->caps.u.Range.StringMin; > + wine_element->caps.button.u.Range.StringMax = feature->caps.u.Range.StringMax; > + wine_element->caps.button.u.Range.DesignatorMin = feature->caps.u.Range.DesignatorMin; > + wine_element->caps.button.u.Range.DesignatorMax = feature->caps.u.Range.DesignatorMax; > + } > + else > + { > + *bitOffset = *bitOffset + 1; > + wine_element->bitCount = 1; > + wine_element->caps.button.u.NotRange.Usage = feature->caps.u.NotRange.Usage[i]; > + wine_element->caps.button.u.NotRange.StringIndex = feature->caps.u.NotRange.StringIndex; > + wine_element->caps.button.u.NotRange.DesignatorIndex = feature->caps.u.NotRange.DesignatorIndex; > + } > + } > + else > + { > + wine_element->ElementType = ValueElement; > + wine_element->caps.value.UsagePage = feature->caps.UsagePage; > + wine_element->caps.value.ReportID = feature->caps.ReportID; > + wine_element->caps.value.BitField = feature->BitField; > + wine_element->caps.value.IsRange = feature->caps.IsRange; > + wine_element->caps.value.IsStringRange = feature->caps.IsStringRange; > + wine_element->caps.value.IsDesignatorRange = feature->caps.IsDesignatorRange; > + wine_element->caps.value.IsAbsolute = feature->IsAbsolute; > + wine_element->caps.value.HasNull = feature->HasNull; > + wine_element->caps.value.BitSize = feature->caps.BitSize; > + if (feature->caps.usage_count > 1) > + wine_element->caps.value.ReportCount = 1; > + else > + wine_element->caps.value.ReportCount = feature->caps.ReportCount; > + wine_element->bitCount = (feature->caps.BitSize * wine_element->caps.value.ReportCount); > + *bitOffset = *bitOffset + wine_element->bitCount; > + wine_element->caps.value.UnitsExp = feature->caps.UnitsExp; > + wine_element->caps.value.Units = feature->caps.Units; > + wine_element->caps.value.LogicalMin = feature->caps.LogicalMin; > + wine_element->caps.value.LogicalMax = feature->caps.LogicalMax; > + wine_element->caps.value.PhysicalMin = feature->caps.PhysicalMin; > + wine_element->caps.value.PhysicalMax = feature->caps.PhysicalMax; > + if (wine_element->caps.value.IsRange) > + { > + wine_element->caps.value.u.Range.UsageMin = feature->caps.u.Range.UsageMin; > + wine_element->caps.value.u.Range.UsageMax = feature->caps.u.Range.UsageMax; > + wine_element->caps.value.u.Range.StringMin = feature->caps.u.Range.StringMin; > + wine_element->caps.value.u.Range.StringMax = feature->caps.u.Range.StringMax; > + wine_element->caps.value.u.Range.DesignatorMin = feature->caps.u.Range.DesignatorMin; > + wine_element->caps.value.u.Range.DesignatorMax = feature->caps.u.Range.DesignatorMax; > + } > + else > + { > + wine_element->caps.value.u.NotRange.Usage = feature->caps.u.NotRange.Usage[i]; > + wine_element->caps.value.u.NotRange.StringIndex = feature->caps.u.NotRange.StringIndex; > + wine_element->caps.value.u.NotRange.DesignatorIndex = feature->caps.u.NotRange.DesignatorIndex; > + } > + } > + > + wine_report->elementCount++; > + } > +} > + > +static void count_elements(struct feature* feature, USHORT *buttons, USHORT *values) > +{ > + if (feature->caps.UsagePage == HID_USAGE_PAGE_BUTTON) > + { > + if (feature->caps.IsRange) > + *buttons = *buttons + 1; > + else > + *buttons = *buttons + feature->caps.usage_count; > + } > + else > + { > + if (feature->caps.IsRange) > + *values = *values + 1; > + else > + *values = *values + feature->caps.usage_count; > + } > +} > + > +WINE_HIDP_PREPARSED_DATA* build_PreparseData( > + struct feature **features, int feature_count, > + struct feature **input_features, int i_count, > + struct feature **output_features, int o_count, > + struct feature **feature_features, int f_count, > + struct collection *base_collection) > +{ > + WINE_HIDP_PREPARSED_DATA *data; > + WINE_HID_REPORT *wine_report = NULL; > + DWORD bitOffset, bitLength; > + int report_count = 1; > + int i; > + int element_count; > + int size = 0; > + > + if (features[0]->caps.ReportID != 0) > + { > + int *report_ids; > + int cnt = max(i_count, o_count); > + cnt = max(cnt, f_count); > + report_ids = HeapAlloc(GetProcessHeap(), 0 , sizeof(*report_ids) * cnt); > + > + if (i_count) > + { > + report_ids[0] = input_features[0]->caps.ReportID; > + for (i = 1; i < i_count; i++) > + { > + int j; > + int found = FALSE; > + for (j = 0; !found && j < i_count; j++) > + { > + if (report_ids[j] == input_features[i]->caps.ReportID) > + found = TRUE; > + } > + if (!found) > + { > + report_ids[report_count] = input_features[i]->caps.ReportID; > + report_count++; > + } > + } > + } > + if (o_count) > + { > + report_count++; > + report_ids[0] = output_features[0]->caps.ReportID; > + for (i = 1; i < o_count; i++) > + { > + int j; > + int found = FALSE; > + for (j = 0; !found && j < o_count; j++) > + { > + if (report_ids[j] == output_features[i]->caps.ReportID) > + found = TRUE; > + } > + if (!found) > + { > + report_ids[report_count] = output_features[i]->caps.ReportID; > + report_count++; > + } > + } > + } > + if (f_count) > + { > + report_count++; > + report_ids[0] = feature_features[0]->caps.ReportID; > + for (i = 1; i < f_count; i++) > + { > + int j; > + int found = FALSE; > + for (j = 0; !found && j < f_count; j++) > + { > + if (report_ids[j] == feature_features[i]->caps.ReportID) > + found = TRUE; > + } > + if (!found) > + { > + report_ids[report_count] = feature_features[i]->caps.ReportID; > + report_count++; > + } > + } > + } > + HeapFree(GetProcessHeap(), 0, report_ids); > + } > + else > + { > + if (o_count) report_count++; > + if (f_count) report_count++; > + } > + > + element_count = 0; > + for (i = 0; i < feature_count; i++) > + element_count += features[i]->caps.usage_count; > + > + size = sizeof(WINE_HIDP_PREPARSED_DATA) + > + (element_count * sizeof(WINE_HID_ELEMENT)) + > + (report_count * sizeof(WINE_HID_REPORT)); > + > + TRACE("%i reports %i elements -> size %i\n",report_count, element_count, size); > + > + data = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, size); > + data->magic = HID_MAGIC; > + data->dwSize = size; > + data->caps.Usage = base_collection->caps.u.NotRange.Usage[0]; > + data->caps.UsagePage = base_collection->caps.UsagePage; > + > + wine_report = data->InputReports; > + if (i_count) > + { > + bitLength = 0; > + new_report(wine_report, input_features[0]); > + data->dwInputReportCount ++; > + > + if (input_features[0]->caps.ReportID != 0) > + bitOffset = 8; > + else > + bitOffset = 0; > + > + for (i = 0; i < i_count; i++) > + { > + if (input_features[i]->caps.ReportID != wine_report->reportID) > + { > + wine_report->dwSize += (sizeof(WINE_HID_ELEMENT) * wine_report->elementCount); > + wine_report = (WINE_HID_REPORT*)(((BYTE*)wine_report)+wine_report->dwSize); > + new_report(wine_report, input_features[i]); > + data->dwInputReportCount ++; > + bitLength = max(bitOffset, bitLength); > + if (input_features[i]->caps.ReportID != 0) > + bitOffset = 8; > + else > + bitOffset = 0; > + } > + build_elements(wine_report, input_features[i], &bitOffset); > + count_elements(input_features[i], &data->caps.NumberInputButtonCaps, > + &data->caps.NumberInputValueCaps); > + } > + wine_report->dwSize += (sizeof(WINE_HID_ELEMENT) * wine_report->elementCount); > + bitLength = max(bitOffset, bitLength); > + data->caps.InputReportByteLength = ((bitLength + 7) & ~7)/8; > + } > + > + if (o_count) > + { > + bitLength = 0; > + wine_report = (WINE_HID_REPORT*)(((BYTE*)wine_report)+wine_report->dwSize); > + data->dwOutputReportOffset = (BYTE*)wine_report - (BYTE*)data->InputReports; > + new_report(wine_report, output_features[0]); > + data->dwOutputReportCount ++; > + if (output_features[0]->caps.ReportID != 0) > + bitOffset = 8; > + else > + bitOffset = 0; > + > + for (i = 0; i < o_count; i++) > + { > + if (output_features[i]->caps.ReportID != wine_report->reportID) > + { > + wine_report->dwSize += (sizeof(WINE_HID_ELEMENT) * wine_report->elementCount); > + wine_report = (WINE_HID_REPORT*)(((BYTE*)wine_report)+wine_report->dwSize); > + new_report(wine_report, output_features[i]); > + data->dwOutputReportCount ++; > + bitLength = max(bitOffset, bitLength); > + if (output_features[0]->caps.ReportID != 0) > + bitOffset = 8; > + else > + bitOffset = 0; > + } > + build_elements(wine_report, output_features[i], &bitOffset); > + count_elements(output_features[i], &data->caps.NumberOutputButtonCaps, > + &data->caps.NumberOutputValueCaps); > + } > + wine_report->dwSize += (sizeof(WINE_HID_ELEMENT) * wine_report->elementCount); > + bitLength = max(bitOffset, bitLength); > + data->caps.OutputReportByteLength = ((bitLength + 7) & ~7)/8; > + } > + > + if (f_count) > + { > + bitLength = 0; > + wine_report = (WINE_HID_REPORT*)(((BYTE*)wine_report)+wine_report->dwSize); > + data->dwFeatureReportOffset = (BYTE*)wine_report - (BYTE*)data->InputReports; > + new_report(wine_report, feature_features[0]); > + data->dwFeatureReportCount ++; > + if (feature_features[0]->caps.ReportID != 0) > + bitOffset = 8; > + else > + bitOffset = 0; > + > + for (i = 0; i < f_count; i++) > + { > + if (feature_features[i]->caps.ReportID != wine_report->reportID) > + { > + wine_report->dwSize += (sizeof(WINE_HID_ELEMENT) * wine_report->elementCount); > + wine_report = (WINE_HID_REPORT*)((BYTE*)wine_report)+wine_report->dwSize; > + new_report(wine_report, feature_features[i]); > + data->dwFeatureReportCount ++; > + bitLength = max(bitOffset, bitLength); > + if (feature_features[0]->caps.ReportID != 0) > + bitOffset = 8; > + else > + bitOffset = 0; > + } > + build_elements(wine_report, feature_features[i], &bitOffset); > + count_elements(feature_features[i], &data->caps.NumberFeatureButtonCaps, > + &data->caps.NumberFeatureValueCaps); > + } > + bitLength = max(bitOffset, bitLength); > + data->caps.FeatureReportByteLength = ((bitLength + 7) & ~7)/8; > + } > + > + return data; > +} > + > +static void free_collection(struct collection *collection) > +{ > + struct feature *fentry, *fnext; > + struct collection *centry, *cnext; > + LIST_FOR_EACH_ENTRY_SAFE(centry, cnext, &collection->collections, struct collection, entry) > + { > + list_remove(&centry->entry); > + free_collection(centry); > + } > + LIST_FOR_EACH_ENTRY_SAFE(fentry, fnext, &collection->features, struct feature, col_entry) > + { > + list_remove(&fentry->col_entry); > + HeapFree(GetProcessHeap(), 0, fentry); > + } > + HeapFree(GetProcessHeap(), 0, collection); > +} > + > +static int compare_reports(const void *a, const void* b) > +{ > + struct feature *f1 = *(struct feature **)a; > + struct feature *f2 = *(struct feature **)b; > + int c = (f1->caps.ReportID - f2->caps.ReportID); > + if (c) return c; > + return (f1->index - f2->index); > +} > + > +WINE_HIDP_PREPARSED_DATA* ParseDescriptor(BYTE *descriptor, INT length) > +{ > + WINE_HIDP_PREPARSED_DATA *data = NULL; > + struct collection *base; > + struct caps caps; > + > + struct list features; > + > + int feature_count = 0; > + int cidx; > + > + if (TRACE_ON(hid)) > + { > + TRACE("Descriptor[%i]: ", length); > + for (cidx = 0; cidx < length; cidx++) > + TRACE("%x ",descriptor[cidx]); > + TRACE("\n"); > + } > + > + list_init(&features); > + > + base = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(*base)); > + base->index = 1; > + list_init(&base->features); > + list_init(&base->collections); > + memset(&caps, 0, sizeof(caps)); > + > + cidx = 0; > + parse_descriptor(descriptor, 0, length, &feature_count, &cidx, base, &caps, &features); > + > + debug_collection(base); > + > + cidx = 2; > + if (feature_count) > + { > + struct feature *entry; > + struct feature** sorted_features; > + struct feature** input_features; > + struct feature** output_features; > + struct feature** feature_features; > + int i_count, o_count, f_count; > + int i; > + > + i_count = o_count = f_count = 0; > + > + sorted_features = HeapAlloc(GetProcessHeap(), 0, sizeof(*sorted_features) * feature_count); > + input_features = HeapAlloc(GetProcessHeap(), 0, sizeof(*input_features) * feature_count); > + output_features = HeapAlloc(GetProcessHeap(), 0, sizeof(*output_features) * feature_count); > + feature_features = HeapAlloc(GetProcessHeap(), 0, sizeof(*feature_features) * feature_count); > + > + i = 0; > + LIST_FOR_EACH_ENTRY(entry, &features, struct feature, entry) > + sorted_features[i++] = entry; > + > + /* Sort features base on report if there are multiple reports */ > + if (sorted_features[0]->caps.ReportID != 0) > + qsort(sorted_features, feature_count, sizeof(struct feature*), compare_reports); > + > + for (i = 0; i < feature_count; i++) > + { > + switch (sorted_features[i]->type) > + { > + case HidP_Input: > + input_features[i_count] = sorted_features[i]; > + i_count++; > + break; > + case HidP_Output: > + output_features[o_count] = sorted_features[i]; > + o_count++; > + break; > + case HidP_Feature: > + feature_features[f_count] = sorted_features[i]; > + f_count++; > + break; > + default: > + ERR("Unknown type %i\n",sorted_features[i]->type); > + } > + } > + > + if (TRACE_ON(hid)) > + { > + TRACE("DUMP FEATURES:\n"); > + TRACE("----INPUT----\n"); > + for (cidx = 0; cidx < i_count; cidx++) > + debug_feature(input_features[cidx]); > + TRACE("----OUTPUT----\n"); > + for (cidx = 0; cidx < o_count; cidx++) > + debug_feature(output_features[cidx]); > + TRACE("----FEATURE----\n"); > + for (cidx = 0; cidx < f_count; cidx++) > + debug_feature(feature_features[cidx]); > + } > + > + data = build_PreparseData(sorted_features, feature_count, input_features, i_count, output_features, o_count, feature_features, f_count, base); > + > + debug_print_preparsed(data); > + > + HeapFree(GetProcessHeap(), 0, sorted_features); > + HeapFree(GetProcessHeap(), 0, input_features); > + HeapFree(GetProcessHeap(), 0, output_features); > + HeapFree(GetProcessHeap(), 0, feature_features); > + } > + > + free_collection(base); > + /* We do not have to free the list as free_collection does all the work */ > + > + return data; > +} > diff --git a/dlls/hidclass.sys/hid.h b/dlls/hidclass.sys/hid.h > index 8f9e56f..c8cee69 100644 > --- a/dlls/hidclass.sys/hid.h > +++ b/dlls/hidclass.sys/hid.h > @@ -81,3 +81,6 @@ void HID_DeleteDevice(HID_MINIDRIVER_REGISTRATION *driver, DEVICE_OBJECT *device > /* Pseudo-Plug and Play support*/ > NTSTATUS WINAPI PNP_AddDevice(DRIVER_OBJECT *driver, void* native) DECLSPEC_HIDDEN; > void PNP_CleanupPNP() DECLSPEC_HIDDEN; > + > +/* Parsing HID Report Descriptors into preparsed data */ > +WINE_HIDP_PREPARSED_DATA* ParseDescriptor(BYTE *descriptor, INT length) DECLSPEC_HIDDEN; > diff --git a/dlls/hidclass.sys/pnp.c b/dlls/hidclass.sys/pnp.c > index ca85cb7..5694b8a 100644 > --- a/dlls/hidclass.sys/pnp.c > +++ b/dlls/hidclass.sys/pnp.c > @@ -53,6 +53,9 @@ NTSTATUS WINAPI PNP_AddDevice(DRIVER_OBJECT *driver, void *native) > DWORD index = HID_STRING_ID_ISERIALNUMBER; > NATIVE_DEVICE *tracked_device, *ptr; > INT interface_index = 1; > + HID_DESCRIPTOR descriptor; > + BYTE *reportDescriptor; > + INT i; > > static const WCHAR ig_fmtW[] = {'I','G','_','%','i',0}; > static const WCHAR im_fmtW[] = {'I','M','_','%','i',0}; > @@ -104,6 +107,40 @@ NTSTATUS WINAPI PNP_AddDevice(DRIVER_OBJECT *driver, void *native) > > list_add_tail(&tracked_devices, &tracked_device->entry); > > + status = call_minidriver(IOCTL_HID_GET_DEVICE_DESCRIPTOR, device, NULL, 0, > + &descriptor, sizeof(descriptor)); > + if (status != STATUS_SUCCESS) > + { > + ERR("Cannot get Device Descriptor(%x)\n",status); > + HID_DeleteDevice(&minidriver->minidriver, device); > + return status; > + } > + for (i = 0; i < descriptor.bNumDescriptors; i++) > + if (descriptor.DescriptorList[i].bReportType == HID_REPORT_DESCRIPTOR_TYPE) > + break; > + > + if (i >= descriptor.bNumDescriptors) > + { > + ERR("No Report Descriptor found in reply\n"); > + HID_DeleteDevice(&minidriver->minidriver, device); > + return status; > + } > + > + reportDescriptor = HeapAlloc(GetProcessHeap(), 0, descriptor.DescriptorList[i].wReportLength); > + status = call_minidriver(IOCTL_HID_GET_REPORT_DESCRIPTOR, device, NULL, 0, > + reportDescriptor, descriptor.DescriptorList[i].wReportLength); > + if (status != STATUS_SUCCESS) > + { > + ERR("Cannot get Report Descriptor(%x)\n",status); > + HID_DeleteDevice(&minidriver->minidriver, device); > + HeapFree(GetProcessHeap(), 0, reportDescriptor); > + return status; > + } > + > + ext->preparseData = ParseDescriptor(reportDescriptor, descriptor.DescriptorList[0].wReportLength); > + ext->information.DescriptorSize = ext->preparseData->dwSize; > + HeapFree(GetProcessHeap(), 0, reportDescriptor); > + > status = call_minidriver(IOCTL_HID_GET_STRING, device, > (void*)index, sizeof(DWORD), serial, sizeof(serial)); > > >

Sept. 2, 2015

Re: [1/4] user32: Add test case for basic {Begin, , End}DeferWindowPos() (try 2)

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=16474 Your paranoid android. === w7u (32 bit win) === win.c:3297: Test failed: hwnd 00060134 message 0200 win.c:3299: Test failed: message 0100 available

Sept. 2, 2015

Re: [PATCH 2/2] ole32: Catch crashes in stub object destructors when destroying stub manager.

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=16468 Your paranoid android. === w8 (32 bit marshal) === marshal.c:3390: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3391: Test failed: info->dwServerPid was 0x5ac instead of 0xfc4 marshal.c:3407: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3408: Test failed: info->dwServerPid was 0x5ac instead of 0xfc4 marshal.c:3445: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3446: Test failed: info->dwServerPid was 0x5ac instead of 0xfc4 marshal.c:3463: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3464: Test failed: info->dwServerPid was 0x5ac instead of 0xfc4 marshal.c:3427: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3428: Test failed: info->dwServerPid was 0x5ac instead of 0xfc4 marshal.c:3390: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3391: Test failed: info->dwServerPid was 0x5ac instead of 0xfc4 marshal.c:3407: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3408: Test failed: info->dwServerPid was 0x5ac instead of 0xfc4 marshal.c:3445: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3446: Test failed: info->dwServerPid was 0x5ac instead of 0xfc4 marshal.c:3463: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3464: Test failed: info->dwServerPid was 0x5ac instead of 0xfc4 marshal.c:3427: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3428: Test failed: info->dwServerPid was 0x5ac instead of 0xfc4 marshal.c:3390: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3391: Test failed: info->dwServerPid was 0x5ac instead of 0xfc4 marshal.c:3407: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3408: Test failed: info->dwServerPid was 0x5ac instead of 0xfc4 marshal.c:3445: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3446: Test failed: info->dwServerPid was 0x5ac instead of 0xfc4 marshal.c:3463: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3464: Test failed: info->dwServerPid was 0x5ac instead of 0xfc4 marshal.c:3427: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3428: Test failed: info->dwServerPid was 0x5ac instead of 0xfc4

Sept. 2, 2015

po: German Translation of "Paging"

by Florian Pelz

Hi, The Wine Task Manager shows "Paged" and "Nonpaged" Kernel memory. The German translation refers to this as "Ausgelagert" (in English: "swapped out") and "Nicht ausgelagert" ("not swapped out"). This matches Microsoft's translation as used in my German copy of Windows XP. However, I believe "ausgelagert" is the wrong word. Am I correct in that paged memory is not necessarily swapped out? If yes, should Wine stick with Microsoft's mistranslation or should "ausgelagert" be changed to something like "gepaget"? Regards, Florian

Sept. 2, 2015

Re: Who decides what are good translations war: Update German translation.

by Florian Pelz

Hi, On 09/02/2015 03:47 PM, Thomas Kaltenbrunner wrote: > BTW. Who decides what are good translations? > > "Anwendungsentferner" reminds me at Germans "Trolls" that refuse to use > well known english terms which are solely used in the area of computer > and software. So they are a technical/special terms in German. > > The term "Anwendungsentferner" you will find in wine only ... > > Eine Anwendung entfernt man mit Hilfe des Uninstallers oder der > Deinstallationssoftware/dem Deinstallationsprogramm. > People familiar with computers may consider the English "Uninstaller" more natural. A proper German translation may be better for those not so familiar. I don't think all this matters very much though. IMO it should just be left as it is. The ubuntuusers.de wiki already started using the translated name to refer to the uninstaller. More generally, I suppose Wine sticks with the first translation offered unless there are issues. Regards, Florian

Sept. 2, 2015

Re: [PATCH 1/2] ole32: Quote executable name in CreateProcess call.

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=16467 Your paranoid android. === w8 (32 bit marshal) === marshal.c:3315: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3316: Test failed: info->dwServerPid was 0x920 instead of 0xfd4 marshal.c:3332: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3333: Test failed: info->dwServerPid was 0x920 instead of 0xfd4 marshal.c:3370: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3371: Test failed: info->dwServerPid was 0x920 instead of 0xfd4 marshal.c:3388: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3389: Test failed: info->dwServerPid was 0x920 instead of 0xfd4 marshal.c:3352: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3353: Test failed: info->dwServerPid was 0x920 instead of 0xfd4 marshal.c:3315: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3316: Test failed: info->dwServerPid was 0x920 instead of 0xfd4 marshal.c:3332: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3333: Test failed: info->dwServerPid was 0x920 instead of 0xfd4 marshal.c:3370: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3371: Test failed: info->dwServerPid was 0x920 instead of 0xfd4 marshal.c:3388: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3389: Test failed: info->dwServerPid was 0x920 instead of 0xfd4 marshal.c:3352: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3353: Test failed: info->dwServerPid was 0x920 instead of 0xfd4 marshal.c:3315: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3316: Test failed: info->dwServerPid was 0x920 instead of 0xfd4 marshal.c:3332: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3333: Test failed: info->dwServerPid was 0x920 instead of 0xfd4 marshal.c:3370: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3371: Test failed: info->dwServerPid was 0x920 instead of 0xfd4 marshal.c:3388: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3389: Test failed: info->dwServerPid was 0x920 instead of 0xfd4 marshal.c:3352: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3353: Test failed: info->dwServerPid was 0x920 instead of 0xfd4

Sept. 2, 2015

Who decides what are good translations war: Update German translation.

by Thomas Kaltenbrunner

BTW. Who decides what are good translations? "Anwendungsentferner" reminds me at Germans "Trolls" that refuse to use well known english terms which are solely used in the area of computer and software. So they are a technical/special terms in German. The term "Anwendungsentferner" you will find in wine only ... Eine Anwendung entfernt man mit Hilfe des Uninstallers oder der Deinstallationssoftware/dem Deinstallationsprogramm. Viele Grüße Thomas Kaltenbrunner Am 31.08.2015 um 15:04 schrieb Julian Rüger: > You're welcome to whip up a patch that fixes these cases. ;) > > It's never wrong to be thorough and precise, but the most important > thing is consistency, imho. > > (Feel free to ask me off-list if you run into trouble.) > > Best, > Julian > > Am Montag, den 31.08.2015, 13:29 +0200 schrieb Florian Pelz: >> Hi, >> >> On 08/31/2015 12:05 PM, Julian Rüger wrote: >>> Hi Florian, >>> >>> I omitted the hyphen on purpose (for consistency). >>> There are a few other instances of "Wine foo" without hyphen, and even: >>> >>> #: uninstaller.rc:29 >>> msgid "Wine Application Uninstaller" >>> msgstr "Wine Anwendungsentferner" >>> >>> I think this is a kind of 50-50 case, where it's okay either way. >>> >> According to [1], omitting the hyphen is incorrect as per the official >> spelling. That said, this part of the official orthography has never >> quite caught on. I don't know if Wine cares about following official >> orthography. >> >> (Sorry that nit-picking is my only contribution to Wine so far. I hope >> I'll have time to do more in the future. So far I'm mostly lurking.) >> >> Best regards, >> Florian >> >> [1] https://de.wikipedia.org/wiki/Leerzeichen_in_Komposita > > > OPC® cardsystems GmbH - Trier -- +49 651 8408 0 +49 151 52628082 Skype: tj-opc GF: Torsten Hülsmann, Dipl.-Ing. (FH) Klaus Dieter Schömer AG Wittlich HRB-Nr.: 3903 Save bytes and energy! - Please don't append useless lengthy texts or graphics.

Sept. 2, 2015

Re: po: Update German translation.

by Florian Pelz

Hi, Sorry for the delayed response. On 08/31/2015 03:04 PM, Julian Rüger wrote: > You're welcome to whip up a patch that fixes these cases. ;) > > It's never wrong to be thorough and precise, but the most important > thing is consistency, imho. > Yes, I agree. I read through the po file and fixed any issues I found. The translation looks rather carefully done btw. Still I found some mistakes other than hyphenation as well. I'll send a patch series soon. > (Feel free to ask me off-list if you run into trouble.) > Thanks for the offer. I hope the way I send the patch is right as it is, but I'd appreciate a review / comments. Regards, Florian

Sept. 2, 2015

Re: wineps.drv: Add glyph names for PostScript Format 1 glyphs.

by Huw Davies

On 1 Sep 2015, at 21:38, Nikolay Sivov wrote: > On 01.09.2015 22:05, Erich E. Hoover wrote: >> On Tue, Sep 1, 2015 at 11:57 AM, Nikolay Sivov <bunglehead(a)gmail.com> wrote: >>> ... >>> get_glyph_name() operates on glyph index, and ttf/otf formats are free to >>> map codepoints to any index, so mapping you implemented will only work in >>> case when currently selected font has 'post' table in Format 1. >> >> Some of the documentation I ran across said that indices 0 through 257 >> are reserved for the standard glyphs even in later formats. However, >> it's entirely possible that the information I found is incorrect. > > Looks like freetype for example only provides names if 'post' table is present, and for index in [0,257] static strings are used no matter what 'post' format is. > > According to this https://www.microsoft.com/typography/otspec/recom.htm, it's required to have first 4 indices fixed to specific chars. 'cmap' requirements section talks about format 4 and 12 that should have same code to glyph mappings within a given font. Also they mention 'Macintosh cmap' (in other words platform == 1/encoding == 0) that strictly follows mapping scheme from Type 1 it seems (that you used). So if you don't provide this platform/encoding pair you presumably don't have to follow this scheme. After reading all this I don't see any explicit documented guide for that, my impression is that people are free to map it in any way. > > Huw, what's your opinion on all that? Yes, we can only really do this for for non-ETO_GLYPH_INDEX case. Huw.

Sept. 2, 2015

Re: [2/2] winhttp: Add custom implementation of IWinHttpRequest::Invoke(DISPID_HTTPREQUEST_OPTION).

by Dmitry Timoshkov

Hi Jacek, thanks for the review, Jacek Caban <jacek(a)codeweavers.com> wrote: > On 09/02/15 07:44, Dmitry Timoshkov wrote: > > + if (member == DISPID_HTTPREQUEST_OPTION) > > Why can't we use standard, ITypeInfo-based implementation here? The tests (1/2 and existing ones) show that ITypeInfo->Invoke doesn't work for a lot of cases when native IWinHttpRequest::Invoke succeeds. In fact, after a lot of attempts I failed to force ITypeInfo->Invoke work at all under Windows using same code that winhttp request (and many other places in Wine) uses to load a typelib from winhttp.dll and forward Invoke to ITypeInfo implementation. > > + { > > + VARIANT ret_value, option; > > + UINT err_pos; > > + > > + if (!result) result = &ret_value; > > + if (!arg_err) arg_err = &err_pos; > > + > > + VariantInit( &option ); > > + VariantInit( result ); > > + > > + if (flags == DISPATCH_PROPERTYPUT) > > + { > > + hr = DispGetParam( params, 0, VT_I4, &option, arg_err ); > > + if (FAILED(hr)) return hr; > > + > > + hr = IWinHttpRequest_put_Option( &request->IWinHttpRequest_iface, V_I4( &option ), params->rgvarg[0] ); > > + if (FAILED(hr)) > > + WARN("put_Option(%d) failed: %x\n", V_I4( &option ), hr); > > + return hr; > > + } > > + else if (flags & (DISPATCH_PROPERTYGET | DISPATCH_METHOD)) > > + { > > + hr = DispGetParam( params, 0, VT_I4, &option, arg_err ); > > + if (FAILED(hr)) return hr; > > + > > + hr = IWinHttpRequest_get_Option( &request->IWinHttpRequest_iface, V_I4( &option ), result ); > > + if (FAILED(hr)) > > + WARN("get_Option(%d) failed: %x\n", V_I4( &option ), hr); > > + return hr; > > + } > > + > > + return S_OK; > > I don't think silently returning S_OK is right for not handled flags. Do you have some particular flags in mind? I tried to follow the test results, although probably the tests don't cover every case. -- Dmitry.

Sept. 2, 2015

Re: [2/13]hidclass.sys: Add Plug-and-play and AddDevice

by Alexandre Julliard

Aric Stewart <aric(a)codeweavers.com> writes: > @@ -57,9 +57,18 @@ typedef struct _minidriver > HID_MINIDRIVER_REGISTRATION minidriver; > > PDRIVER_UNLOAD DriverUnload; > + > + void *AddDevice; Please use the correct callback type and remove the corresponding casts. -- Alexandre Julliard julliard(a)winehq.org

Sept. 2, 2015

Re: [2/2] winhttp: Add custom implementation of IWinHttpRequest::Invoke(DISPID_HTTPREQUEST_OPTION).

by Jacek Caban

Hi Dmitry, On 09/02/15 07:44, Dmitry Timoshkov wrote: > + if (member == DISPID_HTTPREQUEST_OPTION) Why can't we use standard, ITypeInfo-based implementation here? > + { > + VARIANT ret_value, option; > + UINT err_pos; > + > + if (!result) result = &ret_value; > + if (!arg_err) arg_err = &err_pos; > + > + VariantInit( &option ); > + VariantInit( result ); > + > + if (flags == DISPATCH_PROPERTYPUT) > + { > + hr = DispGetParam( params, 0, VT_I4, &option, arg_err ); > + if (FAILED(hr)) return hr; > + > + hr = IWinHttpRequest_put_Option( &request->IWinHttpRequest_iface, V_I4( &option ), params->rgvarg[0] ); > + if (FAILED(hr)) > + WARN("put_Option(%d) failed: %x\n", V_I4( &option ), hr); > + return hr; > + } > + else if (flags & (DISPATCH_PROPERTYGET | DISPATCH_METHOD)) > + { > + hr = DispGetParam( params, 0, VT_I4, &option, arg_err ); > + if (FAILED(hr)) return hr; > + > + hr = IWinHttpRequest_get_Option( &request->IWinHttpRequest_iface, V_I4( &option ), result ); > + if (FAILED(hr)) > + WARN("get_Option(%d) failed: %x\n", V_I4( &option ), hr); > + return hr; > + } > + > + return S_OK; I don't think silently returning S_OK is right for not handled flags. Thanks, Jacek

Sept. 2, 2015

Re: oleaut32: Implement CreateTypeLib

by Nikolay Sivov

This is wrong as CreateTypeLib() is supposed to create SLTG typelib. For https://bugs.winehq.org/show_bug.cgi?id=8780 preferred way is to fix vbscript/jscript so you don't have to switch to native. In any case you don't need separate QI call.

Sept. 2, 2015

Re: user32: Hide horizontal Listbox scroll bar if no horizontal extent is set. (try 2)

by Joachim Priesner

Hi, I was wondering about the status of this patch I sent over a month ago. Anything I can do to improve it and get it reviewed? Joachim Am Samstag, 25. Juli 2015 schrieb Joachim Priesner: > According to https://msdn.microsoft.com/en-us/library/ms997541.aspx , a > horizontal scroll bar is shown iff the WS_HSCROLL style is set and > > a) the LBS_MULTICOLUMN style is set and there are too many items or > b) the LBS_MULTICOLUMN style is not set and a horizontal extent is > specified. > > Before this patch, the default scroll info min=0, max=100 would be set > even if no horizontal extent was specified. This led to WS_HSCROLL > list boxes that were less than 100 pixels wide to erroneously have > a horizontal scroll bar. > > Try 2 because I noted a minor formatting error in the first iteration of the patch. > --- > dlls/user32/listbox.c | 20 ++++++++- > dlls/user32/tests/listbox.c | 103 ++++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 122 insertions(+), 1 deletion(-) > > diff --git a/dlls/user32/listbox.c b/dlls/user32/listbox.c > index 2902ac9..f4d890b 100644 > --- a/dlls/user32/listbox.c > +++ b/dlls/user32/listbox.c > @@ -265,7 +265,7 @@ static void LISTBOX_UpdateScroll( LB_DESCR *descr ) > if (descr->style & WS_VSCROLL) > SetScrollInfo( descr->self, SB_VERT, &info, TRUE ); > > - if (descr->style & WS_HSCROLL) > + if ((descr->style & WS_HSCROLL) && descr->horz_extent) > { > info.nPos = descr->horz_pos; > info.nPage = descr->width; > @@ -274,6 +274,20 @@ static void LISTBOX_UpdateScroll( LB_DESCR *descr ) > info.fMask |= SIF_DISABLENOSCROLL; > SetScrollInfo( descr->self, SB_HORZ, &info, TRUE ); > } > + else > + { > + if (descr->style & LBS_DISABLENOSCROLL) > + { > + info.nMin = 0; > + info.nMax = 0; > + info.fMask = SIF_RANGE | SIF_DISABLENOSCROLL; > + SetScrollInfo( descr->self, SB_HORZ, &info, TRUE ); > + } > + else > + { > + ShowScrollBar( descr->self, SB_HORZ, FALSE ); > + } > + } > } > } > > @@ -1248,6 +1262,8 @@ static LRESULT LISTBOX_SetHorizontalExtent( LB_DESCR *descr, INT extent ) > info.nMin = 0; > info.nMax = descr->horz_extent ? descr->horz_extent - 1 : 0; > info.fMask = SIF_RANGE; > + if (descr->style & LBS_DISABLENOSCROLL) > + info.fMask |= SIF_DISABLENOSCROLL; > SetScrollInfo( descr->self, SB_HORZ, &info, TRUE ); > } > if (descr->horz_pos > extent - descr->width) > @@ -2537,6 +2553,8 @@ static BOOL LISTBOX_Create( HWND hwnd, LPHEADCOMBO lphc ) > } > } > > + LISTBOX_UpdateScroll(descr); > + > TRACE("owner: %p, style: %08x, width: %d, height: %d\n", descr->owner, descr->style, descr->width, descr->height); > return TRUE; > } > diff --git a/dlls/user32/tests/listbox.c b/dlls/user32/tests/listbox.c > index 79d18e7..9380457 100644 > --- a/dlls/user32/tests/listbox.c > +++ b/dlls/user32/tests/listbox.c > @@ -1665,7 +1665,10 @@ static void test_extents(void) > ok(br == TRUE, "GetScrollInfo failed\n"); > ok(sinfo.nMin == 0, "got wrong min: %u\n", sinfo.nMin); > ok(sinfo.nMax == 100, "got wrong max: %u\n", sinfo.nMax); > + ok((GetWindowLongA(listbox, GWL_STYLE) & WS_HSCROLL) == 0, > + "List box should not have a horizontal scroll bar\n"); > > + /* horizontal extent < width */ > SendMessageA(listbox, LB_SETHORIZONTALEXTENT, 64, 0); > > res = SendMessageA(listbox, LB_GETHORIZONTALEXTENT, 0, 0); > @@ -1677,6 +1680,23 @@ static void test_extents(void) > ok(br == TRUE, "GetScrollInfo failed\n"); > ok(sinfo.nMin == 0, "got wrong min: %u\n", sinfo.nMin); > ok(sinfo.nMax == 100, "got wrong max: %u\n", sinfo.nMax); > + ok((GetWindowLongA(listbox, GWL_STYLE) & WS_HSCROLL) == 0, > + "List box should not have a horizontal scroll bar\n"); > + > + /* horizontal extent > width */ > + SendMessageA(listbox, LB_SETHORIZONTALEXTENT, 184, 0); > + > + res = SendMessageA(listbox, LB_GETHORIZONTALEXTENT, 0, 0); > + ok(res == 184, "Got wrong horizontal extent: %u\n", res); > + > + sinfo.cbSize = sizeof(sinfo); > + sinfo.fMask = SIF_RANGE; > + br = GetScrollInfo(listbox, SB_HORZ, &sinfo); > + ok(br == TRUE, "GetScrollInfo failed\n"); > + ok(sinfo.nMin == 0, "got wrong min: %u\n", sinfo.nMin); > + ok(sinfo.nMax == 100, "got wrong max: %u\n", sinfo.nMax); > + ok((GetWindowLongA(listbox, GWL_STYLE) & WS_HSCROLL) == 0, > + "List box should not have a horizontal scroll bar\n"); > > DestroyWindow(listbox); > > @@ -1692,7 +1712,71 @@ static void test_extents(void) > ok(br == TRUE, "GetScrollInfo failed\n"); > ok(sinfo.nMin == 0, "got wrong min: %u\n", sinfo.nMin); > ok(sinfo.nMax == 100, "got wrong max: %u\n", sinfo.nMax); > + ok((GetWindowLongA(listbox, GWL_STYLE) & WS_HSCROLL) == 0, > + "List box should not have a horizontal scroll bar\n"); > + > + /* horizontal extent < width */ > + SendMessageA(listbox, LB_SETHORIZONTALEXTENT, 64, 0); > + > + res = SendMessageA(listbox, LB_GETHORIZONTALEXTENT, 0, 0); > + ok(res == 64, "Got wrong horizontal extent: %u\n", res); > + > + sinfo.cbSize = sizeof(sinfo); > + sinfo.fMask = SIF_RANGE; > + br = GetScrollInfo(listbox, SB_HORZ, &sinfo); > + ok(br == TRUE, "GetScrollInfo failed\n"); > + ok(sinfo.nMin == 0, "got wrong min: %u\n", sinfo.nMin); > + ok(sinfo.nMax == 63, "got wrong max: %u\n", sinfo.nMax); > + ok((GetWindowLongA(listbox, GWL_STYLE) & WS_HSCROLL) == 0, > + "List box should not have a horizontal scroll bar\n"); > + > + /* horizontal extent > width */ > + SendMessageA(listbox, LB_SETHORIZONTALEXTENT, 184, 0); > + > + res = SendMessageA(listbox, LB_GETHORIZONTALEXTENT, 0, 0); > + ok(res == 184, "Got wrong horizontal extent: %u\n", res); > + > + sinfo.cbSize = sizeof(sinfo); > + sinfo.fMask = SIF_RANGE; > + br = GetScrollInfo(listbox, SB_HORZ, &sinfo); > + ok(br == TRUE, "GetScrollInfo failed\n"); > + ok(sinfo.nMin == 0, "got wrong min: %u\n", sinfo.nMin); > + ok(sinfo.nMax == 183, "got wrong max: %u\n", sinfo.nMax); > + ok((GetWindowLongA(listbox, GWL_STYLE) & WS_HSCROLL) != 0, > + "List box should have a horizontal scroll bar\n"); > + > + SendMessageA(listbox, LB_SETHORIZONTALEXTENT, 0, 0); > > + res = SendMessageA(listbox, LB_GETHORIZONTALEXTENT, 0, 0); > + ok(res == 0, "Got wrong horizontal extent: %u\n", res); > + > + sinfo.cbSize = sizeof(sinfo); > + sinfo.fMask = SIF_RANGE; > + br = GetScrollInfo(listbox, SB_HORZ, &sinfo); > + ok(br == TRUE, "GetScrollInfo failed\n"); > + ok(sinfo.nMin == 0, "got wrong min: %u\n", sinfo.nMin); > + ok(sinfo.nMax == 0, "got wrong max: %u\n", sinfo.nMax); > + ok((GetWindowLongA(listbox, GWL_STYLE) & WS_HSCROLL) == 0, > + "List box should not have a horizontal scroll bar\n"); > + > + DestroyWindow(listbox); > + > + > + listbox = create_listbox(WS_CHILD | WS_VISIBLE | WS_HSCROLL | LBS_DISABLENOSCROLL, parent); > + > + res = SendMessageA(listbox, LB_GETHORIZONTALEXTENT, 0, 0); > + ok(res == 0, "Got wrong initial horizontal extent: %u\n", res); > + > + sinfo.cbSize = sizeof(sinfo); > + sinfo.fMask = SIF_RANGE; > + br = GetScrollInfo(listbox, SB_HORZ, &sinfo); > + ok(br == TRUE, "GetScrollInfo failed\n"); > + ok(sinfo.nMin == 0, "got wrong min: %u\n", sinfo.nMin); > + ok(sinfo.nMax == 0, "got wrong max: %u\n", sinfo.nMax); > + ok((GetWindowLongA(listbox, GWL_STYLE) & WS_HSCROLL) != 0, > + "List box should have a horizontal scroll bar\n"); > + > + /* horizontal extent < width */ > SendMessageA(listbox, LB_SETHORIZONTALEXTENT, 64, 0); > > res = SendMessageA(listbox, LB_GETHORIZONTALEXTENT, 0, 0); > @@ -1704,6 +1788,23 @@ static void test_extents(void) > ok(br == TRUE, "GetScrollInfo failed\n"); > ok(sinfo.nMin == 0, "got wrong min: %u\n", sinfo.nMin); > ok(sinfo.nMax == 63, "got wrong max: %u\n", sinfo.nMax); > + ok((GetWindowLongA(listbox, GWL_STYLE) & WS_HSCROLL) != 0, > + "List box should have a horizontal scroll bar\n"); > + > + /* horizontal extent > width */ > + SendMessageA(listbox, LB_SETHORIZONTALEXTENT, 184, 0); > + > + res = SendMessageA(listbox, LB_GETHORIZONTALEXTENT, 0, 0); > + ok(res == 184, "Got wrong horizontal extent: %u\n", res); > + > + sinfo.cbSize = sizeof(sinfo); > + sinfo.fMask = SIF_RANGE; > + br = GetScrollInfo(listbox, SB_HORZ, &sinfo); > + ok(br == TRUE, "GetScrollInfo failed\n"); > + ok(sinfo.nMin == 0, "got wrong min: %u\n", sinfo.nMin); > + ok(sinfo.nMax == 183, "got wrong max: %u\n", sinfo.nMax); > + ok((GetWindowLongA(listbox, GWL_STYLE) & WS_HSCROLL) != 0, > + "List box should have a horizontal scroll bar\n"); > > SendMessageA(listbox, LB_SETHORIZONTALEXTENT, 0, 0); > > @@ -1716,6 +1817,8 @@ static void test_extents(void) > ok(br == TRUE, "GetScrollInfo failed\n"); > ok(sinfo.nMin == 0, "got wrong min: %u\n", sinfo.nMin); > ok(sinfo.nMax == 0, "got wrong max: %u\n", sinfo.nMax); > + ok((GetWindowLongA(listbox, GWL_STYLE) & WS_HSCROLL) != 0, > + "List box should have a horizontal scroll bar\n"); > > DestroyWindow(listbox); > >

Sept. 1, 2015

Re: wineps.drv: Add glyph names for PostScript Format 1 glyphs.

by Nikolay Sivov

On 01.09.2015 22:05, Erich E. Hoover wrote: > On Tue, Sep 1, 2015 at 11:57 AM, Nikolay Sivov <bunglehead(a)gmail.com> wrote: >> ... >> get_glyph_name() operates on glyph index, and ttf/otf formats are free to >> map codepoints to any index, so mapping you implemented will only work in >> case when currently selected font has 'post' table in Format 1. > > Some of the documentation I ran across said that indices 0 through 257 > are reserved for the standard glyphs even in later formats. However, > it's entirely possible that the information I found is incorrect. Looks like freetype for example only provides names if 'post' table is present, and for index in [0,257] static strings are used no matter what 'post' format is. According to this https://www.microsoft.com/typography/otspec/recom.htm, it's required to have first 4 indices fixed to specific chars. 'cmap' requirements section talks about format 4 and 12 that should have same code to glyph mappings within a given font. Also they mention 'Macintosh cmap' (in other words platform == 1/encoding == 0) that strictly follows mapping scheme from Type 1 it seems (that you used). So if you don't provide this platform/encoding pair you presumably don't have to follow this scheme. After reading all this I don't see any explicit documented guide for that, my impression is that people are free to map it in any way. Huw, what's your opinion on all that? > >> So if you >> really need adobe glyph name you have to use unicode-value-to-name lookup >> based on [1] probably (comes under Apache 2.0 license, no idea if it's >> usable in Wine). But even that won't always work I think, because we have to >> support ETO_GLYPH_INDEX case too where you have indices as input. >> ... > > I agree that this is better, but I was unable to find a version of > this data that's not Apache 2.0 licensed and it is not clear to me > that we can include Apache 2.0 licensed data. I'm not even sure why > there's a license on such a lookup table, but the fact remains that it > is there. > > Best, > Erich >

Sept. 1, 2015

Re: wineps.drv: Add glyph names for PostScript Format 1 glyphs.

by Erich E. Hoover

On Tue, Sep 1, 2015 at 11:57 AM, Nikolay Sivov <bunglehead(a)gmail.com> wrote: > ... > get_glyph_name() operates on glyph index, and ttf/otf formats are free to > map codepoints to any index, so mapping you implemented will only work in > case when currently selected font has 'post' table in Format 1. Some of the documentation I ran across said that indices 0 through 257 are reserved for the standard glyphs even in later formats. However, it's entirely possible that the information I found is incorrect. > So if you > really need adobe glyph name you have to use unicode-value-to-name lookup > based on [1] probably (comes under Apache 2.0 license, no idea if it's > usable in Wine). But even that won't always work I think, because we have to > support ETO_GLYPH_INDEX case too where you have indices as input. > ... I agree that this is better, but I was unable to find a version of this data that's not Apache 2.0 licensed and it is not clear to me that we can include Apache 2.0 licensed data. I'm not even sure why there's a license on such a lookup table, but the fact remains that it is there. Best, Erich

Sept. 1, 2015

Re: [PATCH] Fix performance problem in debug tracing

by Daniel Santos

On 09/01/2015 07:10 AM, Alexandre Julliard wrote: > Daniel Santos <daniel.santos(a)pobox.com> writes: > >> Currently, if any classes are passed to WINEDEBUG (nb_debug_options > 0) then >> the initial lazy-init call to __wine_dbg_get_channel_flags() never sets the >> flags in the struct __wine_debug_channel in the object file, resulting in all >> 45k trace calls in wine making a function call, running bsearch on >> debug_options with string compare, etc. > Not really. Only the channel that is actually enabled will make repeated > function calls. This is done on purpose so that you can toggle it on and > off for a given process from the task manager. > My apologies for the oversight! I wish I had known about task manager toggle ability before I updated the debug F12 toggle key patch set. I see that this is described in the Developer's Guide, but I didn't find anything in the wiki about it. I guess I'll play with this a little bit and then add some information about this to the wiki page http://wiki.winehq.org/DebugChannels.

Sept. 1, 2015

Re: wineps.drv: Add glyph names for PostScript Format 1 glyphs.

by Nikolay Sivov

On 01.09.2015 19:21, Erich E. Hoover wrote: > + /* These PostScript Format 1 glyph names are stored by glyph index, do not reorder them. */ > + const char *glyph_table[] = { > + ".notdef", > + ".null", > + "nonmarkingreturn", > + "space", I don't think it can work like that for anything except .notdef. If I understand it correctly one of wineps.drv tasks is to generate Type1/Type42 font description from currently selected font, including converting outline data and metrics to proper format, and that selected font could be anything scalable. get_glyph_name() operates on glyph index, and ttf/otf formats are free to map codepoints to any index, so mapping you implemented will only work in case when currently selected font has 'post' table in Format 1. So if you really need adobe glyph name you have to use unicode-value-to-name lookup based on [1] probably (comes under Apache 2.0 license, no idea if it's usable in Wine). But even that won't always work I think, because we have to support ETO_GLYPH_INDEX case too where you have indices as input. [1] https://github.com/adobe-type-tools/agl-aglfn/blob/master/glyphlist.txt

Sept. 1, 2015

Re: [PATCH 3/7] d3d11: Add ID3D11Texture3D interface stub.

by Henri Verbeet

On 1 September 2015 at 18:56, Józef Kucia <joseph.kucia(a)gmail.com> wrote: > IMHO, this is somehow clearer than IUnknown_AddRef((IUnknown > *)*object). On the other hand, it seems suspicious when AddRef() is > called on other interface than the one returned. You're mixing styles a bit. One way is to first assign *out/*object and then have a common IUnknown_AddRef() at the end of QueryInterface(). The advantage is mostly that you're saving some code duplication for the AddRef() and return, although at the cost of introducing a cast. E.g. d3d10_device_inner_QueryInterface(). The other style is to AddRef() with the correct interface and return immediately, e.g. ddraw_surface7_QueryInterface(). I.e., in this case you'd use "ID3D10Texture3D_AddRef(&texture->ID3D10Texture3D_iface);". Note that the "else" is redundant if you return.

Sept. 1, 2015

Re: [PATCH 3/7] d3d11: Add ID3D11Texture3D interface stub.

by Józef Kucia

On Tue, Sep 1, 2015 at 3:53 PM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > On 1 September 2015 at 00:27, Józef Kucia <jkucia(a)codeweavers.com> wrote: >> + else if (IsEqualGUID(riid, &IID_ID3D10Texture3D) >> + || IsEqualGUID(riid, &IID_ID3D10Resource) >> + || IsEqualGUID(riid, &IID_ID3D10DeviceChild)) >> + { >> + IUnknown_AddRef(iface); >> + *object = &texture->ID3D10Texture3D_iface; > For what it's worth, this works here because the d3d10 and d3d11 > interfaces share the reference count, but in general you should > AddRef() the actual interface you're returning. > > IMHO, this is somehow clearer than IUnknown_AddRef((IUnknown *)*object). On the other hand, it seems suspicious when AddRef() is called on other interface than the one returned.

Sept. 1, 2015

Re: [PATCH 3/7] d3d11: Add ID3D11Texture3D interface stub.

by Henri Verbeet

On 1 September 2015 at 00:27, Józef Kucia <jkucia(a)codeweavers.com> wrote: > + else if (IsEqualGUID(riid, &IID_ID3D10Texture3D) > + || IsEqualGUID(riid, &IID_ID3D10Resource) > + || IsEqualGUID(riid, &IID_ID3D10DeviceChild)) > + { > + IUnknown_AddRef(iface); > + *object = &texture->ID3D10Texture3D_iface; For what it's worth, this works here because the d3d10 and d3d11 interfaces share the reference count, but in general you should AddRef() the actual interface you're returning.

Sept. 1, 2015

Re: [PATCH] Fix performance problem in debug tracing

by Alexandre Julliard

Daniel Santos <daniel.santos(a)pobox.com> writes: > Currently, if any classes are passed to WINEDEBUG (nb_debug_options > 0) then > the initial lazy-init call to __wine_dbg_get_channel_flags() never sets the > flags in the struct __wine_debug_channel in the object file, resulting in all > 45k trace calls in wine making a function call, running bsearch on > debug_options with string compare, etc. Not really. Only the channel that is actually enabled will make repeated function calls. This is done on purpose so that you can toggle it on and off for a given process from the task manager. -- Alexandre Julliard julliard(a)winehq.org

Sept. 1, 2015

Re: Prep for Wineconf - testing

by Francois Gouget

On Mon, 31 Aug 2015, Matt Durgavich wrote: > I hack on Wine for Mac. Anything special someone wants? I was the only one to run WineTest on Mac and since I no longer have a Mac the Mac column on the test.winehq.org website remains desperately empty (gone even). So we'd need someone to run WineTest daily on a Mac so we can track what's broken on the Mac compared to Linux. You get bonus points if you run WineTest twice: once with the Mac/Quartz driver and once with the X11 one so we can identify which issues are specific to the Mac driver. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Indifference will certainly be the downfall of mankind, but who cares?

Sept. 1, 2015

Re: Prep for Wineconf - testing

by Alexandre Julliard

Francois Gouget <fgouget(a)free.fr> writes: > But it's possible the settings on the winehq.org server are different. > Only Alexandre has access to that machine. If so, then I guess the > experiment would call for trying the following settings: > > $MaxRevertingVMs = 1; > $MaxRevertsWhileRunningVMs = 0; > $MaxActiveVMs = 1; > > I'm a bit skeptical that it would make much of a difference. OK I changed it, let me know how it goes. -- Alexandre Julliard julliard(a)winehq.org

Sept. 1, 2015

Re: [PATCH 1/2] vcruntime140: Add the new MSVC 2015 compiler specific DLL.

by Alexandre Julliard

Martin Storsjö <martin(a)martin.st> writes: > So unless it's a really simple function, it ends up pulling in most of > the msvcrt internals. > > For the real implementation, I'd guess it uses most things from > ucrtbase, instead of having a separate full crt state within both > DLLs. But I'm not sure I'm ready to take on such a challenge. That's another reason for avoiding it. Since applications will most likely use both, you can't duplicate the implementation. You'll need vcruntime to import ucrtbase somehow. -- Alexandre Julliard julliard(a)winehq.org

Sept. 1, 2015