August 2010 - Wine-Devel - list.winehq.org

Re: [PATCH 2/3] winex11.drv: set global key state

by Rafał Miłecki

Hi Alexandre, W dniu 11 września 2009 13:22 użytkownik Alexandre Julliard <julliard(a)winehq.org> napisał: > 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. It's prehistoric thread already, but issue still isn't solved. I wanted to rework that old patch but I noticed set_key_state was already changed and it doesn't change single key state, but instead sets whole array at every call. This was I can not use set_key_state handler to update my "global_keystate" array, as I have no idea which key actually has been changed. Do you see some nice solution for this problem? -- Rafał

Aug. 16, 2010

Re: [4/6] ipconfig: Partially implement basic adapter information output.

by Andrew Nguyen

On 08/16/2010 01:24 PM, Juan Lang wrote: > Hi Andrew, > + static const WCHAR ethernetW[] = {'E','t','h','e','r','n','e','t',0}; > + static const WCHAR unknownW[] = {'U','n','k','n','o','w','n',0}; > shouldn't these be resources instead? > --Juan Hmm, I suppose they probably should be. I was being "lazy", but I can make it happen.

Aug. 16, 2010

Re: [PATCH 1/5] d3d10: Fix d3dcommon.h inclusion.

by James Mckenzie

Henri Verbeet <hverbeet(a)gmail.com> wrote: >Sent: Aug 16, 2010 11:06 AM >To: Rico Schüller <kgbricola(a)web.de> >Cc: wine-devel(a)winehq.org >Subject: Re: [PATCH 1/5] d3d10: Fix d3dcommon.h inclusion. > >2010/8/16 Rico Schüller <kgbricola(a)web.de>: >> Yes, this replaces the earlier patch series. I thought this was clear from >> the discussion for try 2. >> >At the very least it's obvious that the other series isn't going to >happen. Whether this series replaces it or is independent doesn't >matter a whole lot at that point. > If the other series is cancelled, it would be nice to state so as well. This conserves AJ's time and efforts. This has happened to me (I found that my code was seriously broken.) James McKenzie

Aug. 16, 2010

Re: [4/6] ipconfig: Partially implement basic adapter information output.

by Juan Lang

Hi Andrew, + static const WCHAR ethernetW[] = {'E','t','h','e','r','n','e','t',0}; + static const WCHAR unknownW[] = {'U','n','k','n','o','w','n',0}; shouldn't these be resources instead? --Juan

Aug. 16, 2010

WineAPI structure plans

by Max TenEyck Woodbury

I think I have a usable structure for the pages on the WineAPI wiki which I am about to lay before you, but first a discussion of the project name... ---- I understand that some people do not particularly approve of the name I have given this project. It is on Sourceforge and a short relevant name was needed. Much of the information to be presented is specific to Wine and will be based on the contents of the Wine repository. The name reflects that dependence. Other projects may want to use the information presented. They are welcome to do so as far as I am concerned. They may also wish to present information specific to their projects. That is an excellent idea and I will help where I can, but I have two reservations: First, I am unlikely to be familiar with the structure of other projects; I will not be able to maintain those contributions. Someone from the other projects will have to take responsibility for maintaining those contributions and coordinate with the members of the project from Wine. Second, where there are differences between the projects, and the other projects are invited to provide their information but not at the expense of the Wine information. I also included a reference to 'API'. More than just the API will be covered, but the API will definitely be included. While Wine is intended to provide an interface functionally equivalent to the Microsoft products, it will differ from their interface in small ways. One of the most important differences will be that this API is open and *not* particularly designed to promote Microsoft's products. References to the Microsoft documentation will be included, but infringement of Microsoft's copyrights is *not* intended and will be corrected as quickly as it can be verified. The project name can be changed if really necessary, but requests to change it should be constructive with an emphasis on how the new name meets the projects needs. ---- There are two major types of information that will be presented. One type of information is annotation, opinion, discussion, description and so on. This will be managed by people. Another type of information is technical and is tied directly to the contents of the Wine project (and other projects when the details have been worked out). My intention is to write scripts that extract and report this kind of information. This information will change as Wine changes. It will be difficult for the scripts to work around the human generated content. To allow the two major kinds of information to mix, they will be kept on separate pages. Specifically, the editable information will be kept on what MediaWiki calls 'sub-pages'. The places where sub-pages are included will be controlled by the scripts. The script writers will need to be informed of where these inclusions should be placed. Also, to keep the number of 'red-links' under control, The scripts will generate initial versions of the sub-pages. Some structure is needed to make the scripts work and to allow people to check the scripts. For that reason, all script generated pages will start with a comment describing the main script responsible for generating the page along with revision information for the script and script components. The comment will also identify the revision of the repository used to generate the page. (Note, the revision information will be for the last time the page content has to be changed, and will not be updated unless the page content, and not the revision information, is changed. Some structure will also be needed for sub-pages and will be set up in the generated initial versions of those pages. That structure consists of a link back to the article that included the sub-page, markings that the page is editable and at least one section header to serve as a handle to enable easy editing of the sub-page. -Max

Aug. 16, 2010

Re: [PATCH 1/5] d3d10: Fix d3dcommon.h inclusion.

by Henri Verbeet

2010/8/16 Rico Schüller <kgbricola(a)web.de>: > Yes, this replaces the earlier patch series. I thought this was clear from > the discussion for try 2. > At the very least it's obvious that the other series isn't going to happen. Whether this series replaces it or is independent doesn't matter a whole lot at that point.

Aug. 16, 2010

Re: [PATCH 1/5] d3d10: Fix d3dcommon.h inclusion.

by James Mckenzie

Rico Schüller <kgbricola(a)web.de> wrote: >Sent: Aug 16, 2010 10:21 AM >To: wine-devel(a)winehq.org >Subject: Re: [PATCH 1/5] d3d10: Fix d3dcommon.h inclusion. > >Am 15.08.2010 18:26, schrieb James McKenzie: >> Rico Schüller wrote: >>> Hi, >>> >>> this patch series implements the ID3DBlob interface. This time the >>> interface is implemented in the d3dcompiler_43.dll. The function >>> D3D10CreateBlob from d3d10 is forwarded to the D3DCreateBlob function >>> in the d3dcompiler_43.dll. >> >> Does this replace the ten patch series you submitted on 8/11? This is >> not clear here. >> >Yes, this replaces the earlier patch series. I thought this was clear >from the discussion for try 2. > I've learned the hard way to never assume anything and to document everything. If something can be misunderstood it will and will in the most damaging manner. James McKenzie James McKenzie

Aug. 16, 2010

Re: [PATCH 1/5] d3d10: Fix d3dcommon.h inclusion.

by Rico Schüller

Am 15.08.2010 18:26, schrieb James McKenzie: > Rico Schüller wrote: >> Hi, >> >> this patch series implements the ID3DBlob interface. This time the >> interface is implemented in the d3dcompiler_43.dll. The function >> D3D10CreateBlob from d3d10 is forwarded to the D3DCreateBlob function >> in the d3dcompiler_43.dll. > > Does this replace the ten patch series you submitted on 8/11? This is > not clear here. > > James McKenzie > > > Yes, this replaces the earlier patch series. I thought this was clear from the discussion for try 2. Cheers Rico

Aug. 16, 2010

RE: Wine users with a CD-ROM drive, please test

by Ge van Geldorp

> From: Joerg Hoehle > > There's no mention of win95/98 in the attachment so I assume these > were not included, or was that because there was no error? Right, they were not included. I ran into some problems trying to attach the .iso to those VMs and gave up. Win9x should die :-). Ge.

Aug. 16, 2010

Wine users with a CD-ROM drive, please test

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, Greg Geldorp wrote: >I ran mcicda_test from TestBot job 4436 on the TestBot VMs, with a >data .iso connected as CD-ROM. Thank you very much for your excellent support. It's good to have such tests executed on a broad range of OS prior to submission. There's no mention of win95/98 in the attachment so I assume these were not included, or was that because there was no error? Don't worry, I don't need further tests from w9x (or others). >On NT4, Win2000, XP, W2K3 >mcicda.c:397: Test failed: STATUS position: MCIERR_HARDWARE IMHO this shows that a vmware machine has a different timing than native with a real CD-ROM. There's already a comment in the tests about: Status position -> ok Sleep 2seconds Status position -> MCIERR_HARDWARE Your vmware boxes appear to deliver the latter immediately ;) I'll add a broken() to account for this. >On NT4, Win2000: >mcicda.c:318: Test failed: resume without play: 0=NOERROR Weird, since a real w2k machine with a data only CD returns MCIERR_HARDWARE. Adding a broken() here would annoy me as it would shadow every successful return from any other machine (with a real CD). Let's see what test.winrhq.org will reveal when I'll submit the tests. Thanks to all you people who contributed test results, Jörg Höhle

Aug. 16, 2010

Re: [3/3] wined3d: Remove isInDraw hack from context_setup_target.

by Stefan Dösinger

Am 16.08.2010 um 13:58 schrieb Henri Verbeet: > On 16 August 2010 13:25, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: >> It is conceptually wrong and actually broken too (as the comment there >> said). Just remove the hack now and properly fix any regression >> that may come up later by explicitely acquiring the right context where >> needed (so, in surface_internal_preload and its callees). > Note that isInDraw is mildly awful in itself, and we should probably > get rid of it eventually. In most places where it's used it's probably > an artifact of the old context management, but that needs to be > checked. Vertex buffer preloads are a problem. Between two draw calls the stateblock may be in an invalid state(e.g. a stream referenced by the vdecl is still set to NULL), so it may be unsafe for VB_PreLoad to attempt to find out which vertex attrib types are in the buffer. Now that mechanism has changed a while ago too. Nowadys the VBO code uses the cached strided data from the device, rather than parsing it on its own. There are also some places where isInDraw is used to avoid redundant "give me a context, any render target, any state" context_acquire calls.

Aug. 16, 2010

Re: [3/3] wined3d: Remove isInDraw hack from context_setup_target.

by Henri Verbeet

On 16 August 2010 13:25, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > It is conceptually wrong and actually broken too (as the comment there > said). Just remove the hack now and properly fix any regression > that may come up later by explicitely acquiring the right context where > needed (so, in surface_internal_preload and its callees). Note that isInDraw is mildly awful in itself, and we should probably get rid of it eventually. In most places where it's used it's probably an artifact of the old context management, but that needs to be checked.

Aug. 16, 2010

Re: [1/3] wined3d: Call set_render_offscreen at the end of context_setup_target.

by Henri Verbeet

I'm ok with this, but for future reference, if the change isn't entirely obvious a small comment is usually appropriate.

Aug. 16, 2010

Re: [PATCH 2/2] jscript: Throw TypeError in in_eval.

by testbot＠testbot.winehq.org

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 http://testbot.winehq.org/JobDetails.pl?Key=4470 Your paranoid android. === W98SE (32 bit) === No test summary line found === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found

Aug. 16, 2010

Re: urlmon: Return failures from progress callback

by Jacek Caban

Hi Juan, On 8/4/10 11:44 PM, Juan Lang wrote: > Partial fix for bug 21032. > --Juan if(!This->callback) - return; + return E_POINTER; This doesn't seem right. It's fine to call URLDownloadToFile without callback AFAIR. Thanks, Jacek

Aug. 16, 2010

Re: [PATCH 1/2] jscript: Throw TypeError in instanceof_expression_eval.

by testbot＠testbot.winehq.org

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 http://testbot.winehq.org/JobDetails.pl?Key=4469 Your paranoid android. === W98SE (32 bit) === No test summary line found === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found

Aug. 16, 2010

Re: Some statistics about the 1.0->1.2 development cycle

by Francois Gouget

On Sun, 15 Aug 2010, Marcus Meissner wrote: [...] > Similar for me ... "marcus(a)jet.franken.de" is my private account and means > private work. > > (The meissner(a)suse.de account is however for work I have done on SUSE time.) Same split here: fgouget(a)codeweavers.com patches were for work and fgouget(a)free.fr are for personal stuff. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ May your Tongue stick to the Roof of your Mouth with the Force of a Thousand Caramels.

Aug. 16, 2010

Re: [PATCH 1/1] d3dx9: Add tests for FVF <-> declaration conversion.

by Henri Verbeet

This is for the most part just a copy of the corresponding d3d9 test, so I guess it should work, but it also contains most of the flaws from that test, like e.g. returning E_FAIL from a function returning int. There's probably room for improvement in the test setup itself as well.

Aug. 16, 2010

kernel32/tests: GetVolumeInformationA X: succeeds iff drive's default dir is root. (try 2)

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, Greg Geldorp wrote: >I ... ran the test, >In short: everything passes. This is excellent news. Hopefully somebody will jump in and write code for kernel32/volume.c that satisfies the tests and get fame for fixing bug #23355 and help #20887. I'm nominating the bugfix for 1.2.1 Regards, Jörg Höhle.

Aug. 16, 2010

Re: comctl32: Simplify is_textT by omitting isW.

by Gerald Pfeifer

On Mon, 10 May 2010, Nikolay Sivov wrote: >> -static inline BOOL is_textT(LPCWSTR text, BOOL isW) >> +static inline BOOL is_textT(LPCWSTR text) >> > There's no reason to keep this helper then. It's better to rename > is_textW() to is_text() and remove is_textT(). Excellent idea. I'll submit a patch to the extent in a minute (and sorry that this has taken three months). Gerald

Aug. 15, 2010

Re: Some statistics about the 1.0->1.2 development cycle

by Wolfram Sang

> you'll have to reassign my patches to the "(None)" category. While I do Will do, of course. Also for all the other requests I get/got. > for that; even my trips to the WineConfs are payed out of my own pocket. Sounds familiar ;) Regards, Wolfram

Aug. 15, 2010

Re: Some statistics about the 1.0->1.2 development cycle

by Wolfram Sang

> But just for accuracy, I'm a frenchman. Ah, now I remember what I wanted to add to the README :) I did not change anything in the built-in country-detection which is still quite experimental, even upstream. Please just ignore it. I once thought about removing it, might do so later on. Thanks, Wolfram

Aug. 15, 2010

Re: Some statistics about the 1.0->1.2 development cycle

by GOUJON Alexandre

Rather interesting , thanks ! But just for accuracy, I'm a frenchman.

Aug. 15, 2010

Re: Some statistics about the 1.0->1.2 development cycle

by Henri Verbeet

On 15 August 2010 19:28, Marcus Meissner <marcus(a)jet.franken.de> wrote: > Similar for me ... "marcus(a)jet.franken.de" is my private account and means > private work. > Similar split for me, although the amount of patches from hverbeet(a)gmail.com after 1.0 is probably trivial.

Aug. 15, 2010

Re: Some statistics about the 1.0->1.2 development cycle

by Marcus Meissner

On Sun, Aug 15, 2010 at 07:13:12PM +0200, Michael Stefaniuc wrote: > Hello Wolfram, > > On 08/15/2010 05:42 PM, Wolfram Sang wrote: >> I am going to speak about my "getting into wine development" at FrosCon >> (near Bonn/Germany) next weekend. During preparation, I was interested >> in some numbers, so I roughly modified 'kps' (kernel patch statistics) >> for wine. The outcome for the 1.0->1.2 cycle can be found here, if >> somebody is interested (just make sure you read the README first): >> >> http://www.the-dreams.de/wine/winekpsstats10-12.tar.gz >> >> So far, not too surprising IMHO, although I probably missed a number of >> people. I am open for comments, if there are some. > you'll have to reassign my patches to the "(None)" category. While I do > work for Red Hat I'm working there as a network engineer, not as a > developer. Wine is pure hobby for me and Red Hat doesn't pay me a cent for > that; even my trips to the WineConfs are payed out of my own pocket. Similar for me ... "marcus(a)jet.franken.de" is my private account and means private work. (The meissner(a)suse.de account is however for work I have done on SUSE time.) Ciao, Marcus

Aug. 15, 2010