wine-devel March 2010

wine-devel@winehq.org

102 participants
263 discussions

Re: [PATCH] winedbg: gdb proxy mode: support qAttached packet
by Eric Pouech 30 Aug '10

30 Aug '10

Paul Bolle a écrit : > Add support for the qAttached packet. Main benefit is that if gdb was > attached to a debuggee and it quits it will now ask if it should detach > from the debuggee instead of asking whether the debuggee should be > killed. (It still will ask whether the debuggee should be killed if it > launched the debuggee itself). > > Signed-off-by: Paul Bolle <pebolle(a)tiscali.nl> > --- > Would it be better to add a new member to gdbctx instead of using a > separate variable (qAttached_reply)? > yes, inclusion in gdbctx is preferred (and storage should rather be an integer rather than a string pointer) A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

2 1

Re: [PATCH 2/3] winex11.drv: set global key state
by Alexandre Julliard 18 Aug '10

18 Aug '10

Rafał Miłecki <zajec5(a)gmail.com> writes: > @@ -1250,6 +1250,21 @@ void X11DRV_send_keyboard_input( WORD wVk, WORD wScan, DWORD event_flags, DWORD > key_state_table[wVkStripped] = key_state_table[wVkL] | key_state_table[wVkR]; > } > > + SERVER_START_REQ( set_global_key_state ) > + { > + req->key = wVk; > + req->state = key_state_table[wVk]; > + wine_server_call( req ); > + } > + SERVER_END_REQ; > + SERVER_START_REQ( set_global_key_state ) > + { > + req->key = wVkStripped; > + req->state = key_state_table[wVkStripped]; > + wine_server_call( req ); > + } > + SERVER_END_REQ; > + You don't want to add 2 extra server calls for every key, especially since the server already receives the necessary information through the key event. -- Alexandre Julliard julliard(a)winehq.org

3 2

TRACE () documentation
by James McKenzie 04 Jul '10

04 Jul '10

All: Is there documentation anywhere on how to use the TRACE command? I am trying to print out the contents of a UNICODE string using this commnd. Thank you. James McKenzie

4 8

Re: Sudden increase of Valgrind errors
by Dan Kegel 14 May '10

14 May '10

Two things: I moved to karmic (and now more modules are enabled, since it comes with new-enough libraries), and I updated valgrind. I haven't had time to dig in to the differences. The suppressions file also needs updating for karmic. On Feb 28, 2010 5:43 AM, "Paul Vriens" <paul.vriens.wine(a)gmail.com> wrote: Hi Dan, As of Feb-25 there is a sudden increase in Valgrind errors reported at http://kegel.com/wine/valgrind/logs. The errors are in loads of modules which make me believe something generic has changed (there are also errors in modules that haven't been touched in a while). Any idea? -- Cheers, Paul.

2 2

LinuxTag Berlin - call for projects
by Jan Gerrit Möltgen 06 May '10

06 May '10

Hello together, I'm not sure, if this is the right place for my question, but I thought it's better than the user-list. The LinuxTag in Berlin makes a call for projects ( http://wiki.linuxtag.org/w/fp:Call_for_Projects ) and in my oppinion Wine should be represented there. Has somebody already submitted an application? If yes, I would like to support, otherwise I'd like to submit an application and would be happy about every helping hand. Greetings, Jan Gerrit -- Dipl.-Wirt.-Inf. Jan Gerrit Möltgen . . . . . .gerrit.moeltgen(a)itomig.de ITOMIG GmbH . . . . . . . . . . . . . . . . . . Tel.: +49 7031 389 25 06 Otto-Lilienthal-Str. 36 . . . . . . . . . . . . . . http://www.itomig.de D-71034 Böblingen . . . . . . . . . . . . . . . http://www.itomig.de/fr Geschäftsführer: David Gümbel . . . . . HRB 728519 Amtsgericht Stuttgart Sitz der Gesellschaft: Böblingen . . . . . . . . . . . . . . . . . . . .

3 5

Re: [1/2] dlls/crypt32: implement PFXImportCertStore()
by Juan Lang 03 May '10

03 May '10

Hi Phillippe, this attempt looks pretty incomplete. First off: + ret = pPKCS12_verify_mac(pkcs12, password, len); + if (ret == 0) + ERR_(crypt)("failed to verify pkcs12 {%p} with password \"%s\" using func {%p}\n", pkcs12, password, pPKCS12_verify_mac); + else + TRACE_(crypt)("verified pkcs12 {%p} with password \"%s\" using func {%p}\n", pkcs12, password, pPKCS12_verify_mac); You accept the PKCS12 file even if the password is incorrect. This is clearly wrong. + /* extract private key and certificate */ + ret = pPKCS12_parse(pkcs12, password, &pkey, &cert, NULL); You don't support more than a single certificate in the PKCS12 file. This may be fine for the majority of uses, but at least a warning indicating more certificates are present would be helpful. Also, a PKCS12 file can contain more than just certificates, and the tests ought at least to check this. For example, what about a PKCS12 file with a CRL in it? OpenSSL also supports at least a couple of attributes associated with the certificates. From the man page for PKCS12_parse: The friendlyName and localKeyID attributes (if present) on each certificate will be stored in the alias and keyid attributes of the X509 structure. The Crypto API also supports setting such attributes, and if you aren't going to support these, at least the tests should cover them (and marked todo_wine) so we know they're still not done. More questions: + const WCHAR storeName[] = {'S', 't', 'o', 'r', 'e', ' ', 'N', 'a', 'm', 'e', 0}; + store = CertOpenStore(CERT_STORE_PROV_MEMORY, 0, (HCRYPTPROV)NULL, CERT_STORE_CREATE_NEW_FLAG, storeName); What's the purpose of the store name? Does the native implementation do this? If not, it can be omitted. If so, the tests should check it. Thanks, --Juan

2 5

re: Remove NoAppDBEntry keyword?
by Dan Kegel 24 Apr '10

24 Apr '10

Jerome Leclanche wrote: > Austin English <austinenglish at gmail.com> wrote: >> Anyone opposed to removing that keyword? > > +1 on removing it. > It would be nice to have a bugzilla filter to replace it, too. > > Are we keeping "tasklist" and "tasklet" keywords as well? theres > barely a dozen very old bugs for both of them. I think it'd be fine to remove noappdbentry, tasklist, and tasklet. If there are no objections by next weekend, let's go ahead and do it. - Dan

4 4

Re: usbhub.sys: add stubbed usbhub.sys
by Alexandre Julliard 14 Apr '10

14 Apr '10

Damjan Jovanovic <damjan.jov(a)gmail.com> writes: > Changelog: > * usbhub.sys: add stubbed usbhub.sys What is this going to be useful for? -- Alexandre Julliard julliard(a)winehq.org

3 12

[GSoC] IUri Implementations
by Thomas Mullaly 08 Apr '10

08 Apr '10

Hi, my name is Thomas Mullaly and I am a undergraduate in the Computer Science department at Kent State University and I would very much like to participate in this years GSoC. I saw under your project ideas page that the IUri API still needs implemented and I thought that this would be a good project for me, but, before I submit a proposal on it I have a few questions about the project itself. Firstly, on the project page it says that the main goal is to have the IUri interface and CreateUri function implemented, but, on MSDN they also have functions and interfaces for creating/manipulating IUriBuilder's and I was wondering if these were also part of the project goals. If not can they be or would this be to ambitious to have finished by the end of the summer. Secondly (more of a design question), I see that the Uri structure and functions are already stubbed out in the "dlls/urlmon/uri.c" file and I was thinking for my implementation I would add another BSTR* member to the Uri struct, which will point to the encoded version of the URI (which will be generated during the CreateUri() call). Since most of the functions that interact with the IUri return components of the URI (e.g. scheme, host, query, etc.) I was thinking about adding more data members to the Uri struct which store the location in the encoded Uri string where each component exists (or -1 if it does not exist) and by doing this the runtimes of the IUri functions will be reduced since the function will already know where to look inside the encoded string for the component it needs. A drawback to this design is that each Uri struct will be bloated with a decent amount of ints which may or may not be used depending on the type of the URI that the IUri represents. The second approach I was thinking of is to not store any locations inside the Uri struct and to compute them on the fly every time the IUri is queried for one of its components, this would result in a smaller memory footprint of the Uri structure but will increase the runtimes of all the functions that access the URI. I was wondering if anyone might have suggestions for which way they think might be better. Any input will be greatly appreciated! -Thomas Mullaly

3 6

[PATCH 1/5] winmm: Improve MCI's Sysinfo command.
by Joerg-Cyril.Hoehle＠t-systems.com 06 Apr '10

06 Apr '10

Hi, Eric Pouech wrote: >did you test the 16 => 32 bit conversion for the MCI_ALL_DEVICE ? Which ones do you have in mind? There are tests involving MCI_ALL_DEVICE_ID that pass on both win9x and later (also in patch #5). I wrote a few more MCI tests privately. Generally, I added (UINT16) casts in Wine when I saw test failures on Win9x platforms, then kept doing so (i.e. I'm not sure I've tested SYSINFO with a 0000FFFF deviceID on Win9x in particular or whether I simply use that pattern everywhere now after having been burnt once). There are a few patches already in git that fix a few MCI_ALL_DEVICE_ID here and there, but as you wrote yourself in the TODO header long ago, support for it is incomplete. Making "close all", "play all" etc. work is on my private TODO list, but I never started working on this particular item. >actually, I'd say it belongs to the 16=>32 mci message mapper, not in >generic 32bit code Do you mean dlls/mmsystem.dll16? I never looked at it but I don't think that's the correct place, see below. Do you mean the A/W (un)mapping? That's distinct, because it deals with string conversions only, as the name suggests, and it does not mogrify dwParam1. Current test results suggest that MCI_ALL_DEVICE_ID is not only a 16/32 issue -- at least when I equate 16 with MS-Windows 3.x -- Have a look at the mciGetDeviceID("all") test case, which returns a 16bit FFFF on Win9x, not FFFFFFFF. Therefore I believe Wine must be prepared for receiving 0000FFFF as ALL_ID from old Win9X apps or drivers -- possibly regardless of them using the A or W function entry points. Of course, a single (or few) central place(s) to convert wDeviceID=(MCIDEVICEID)(WORD)wDeviceID or wDeviceID= wDeviceID==0xFFFF ? MCI_DEVICE_ALL_ID : wDeviceID is a nice idea. That could be a distinct patch. I'm convinced this handle is truly a 16 bit entity, even after it has been upgraded to a UINT/DWORD type at some time in the past. Still, SYSINFO is a special case, as it receives a device ID not only as function argument but also in its PARMS structure. Regards, Jörg Höhle.

2 4

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel March 2010