wine-devel August 2010

wine-devel@winehq.org

110 participants
338 discussions

Re: [3/5] msi/tests: Skip SourceDir tests on win9x.
by testbot＠testbot.winehq.org 18 Aug '10

18 Aug '10

1 0

Re: [2/5] msi/tests: Use HKEY_CURRENT_USER instead of HKEY_LOCAL_MACHINE for registry tests.
by testbot＠testbot.winehq.org 18 Aug '10

18 Aug '10

1 0

Re: [1/5] msi/tests: Fix some WoW64 test failures.
by testbot＠testbot.winehq.org 18 Aug '10

18 Aug '10

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=4525 Your paranoid android. === W7PROX64 (32 bit package) === package.c:8329: Test failed: Expected "C:\Program Files\VMware\VMware Tools\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\", got "C:\Program Files (x86)\VMware\VMware Tools\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\" === W7PROX64 (64 bit package) === package.c:8366: Test failed: Expected "C:\winetest\FileName1", got "" package.c:8377: Test failed: Expected "C:\winetest\", got "" package.c:8388: Test failed: Expected "C:\winetest\", got "" package.c:8438: Test failed: Expected "C:\winetest\FileName3.dll", got "" package.c:8449: Test failed: Expected "C:\winetest\FileName5.dll", got "" package.c:8458: Test failed: Expected "C:\", got "" package.c:8464: Test failed: Expected "C:\winetest\", got "" package.c:8485: Test failed: Expected "C:\winetest\FileName1", got "" package.c:8494: Test failed: Expected "C:\winetest\FileName1", got ""

1 0

kernel32/tests: GetVolumeInformationA X: succeeds iff drive's default dir is root. (try 2)
by Joerg-Cyril.Hoehle＠t-systems.com 18 Aug '10

18 Aug '10

Hi, what happened to this patch? It's still marked new. Is the discovery too surprising? (Maybe it's the wrong time to ask with AJ still on vacation) Is it not robust enough (lacking testing with network drives)? It explains bugs #20887 and #23355. It may explain intermittent failures in test.winehq/kernel/volume.ok, as success depends on where the test was launched from. >Tests pass on w95,w98,w2k,xp,7. I forgot to add "without skipping the one relevant section", i.e. when started from another drive than C: Of course I invite people here to also perform the test on native. Regards, Jörg Höhle

2 2

Re: wldap32: Fix handling of zero timeout value in ldap_search_extW.
by testbot＠testbot.winehq.org 18 Aug '10

18 Aug '10

1 0

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

re: winex11.drv: Fix uninitialised values. (valgrind) (try 2)
by Dan Kegel 17 Aug '10

17 Aug '10

That's for http://bugs.winehq.org/show_bug.cgi?id=20335 , right? Alexandre's reply to that was "It sounds like it's hashing padding bytes. Probably should be reported to the X.org folks." X is old code, and I don't think anyone has cleaned it up for valgrind yet. That's why I use suppression files like http://winezeug.googlecode.com/svn/trunk/valgrind/valgrind-suppressions which contain blanket suppressions like { bogus_X11_1 Memcheck:Param write(buf) obj:* obj:/usr/lib*/libX11.so.6.2.0 } { bogus_X11_2 Memcheck:Param write(buf) obj:* obj:* obj:/usr/lib*/libX11.so.6.2.0 }

2 1

Re: Should we expect Liberation fonts to be installed?
by Scott Ritchie 17 Aug '10

17 Aug '10

On 08/08/2010 06:56 AM, James McKenzie wrote: > Scott Ritchie wrote: >> I was looking through our fairly large collection of open font bugs and >> realized that things might be a lot simpler if we took some opinionated >> positions and just declared certain fonts to be dependencies and >> expected all packagers to provide them. >> >> This is similar to bundling our own Tahoma, except much less work. >> > This might work for Linux, but these fonts are not installed on any > MacOSX version that I'm aware of. This might break Wine useage for > Macs. It might also break it for Solaris as well. > > James McKenzie > It should only break in a way that makes it as bad as it currently is. Thanks, Scott Ritchie

4 5

Re: kernel32: add stub for SetFileValidData
by Alexandre Julliard 17 Aug '10

17 Aug '10

Austin English <austinenglish(a)gmail.com> writes: > @@ -1001,6 +1001,16 @@ error: > } > > /*********************************************************************** > + * SetFileValidData (KERNEL32.@) > + */ > +BOOL WINAPI SetFileValidData( HANDLE hFile, LONGLONG ValidDataLength ) > +{ > + FIXME("stub: %p, %llu\n", hFile, ValidDataLength); You can't use %ll formats. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: user32, GetUserObjectInformation implementation with index=UOI_USER_SID (try2, resend)
by Alexandre Julliard 17 Aug '10

17 Aug '10

Wolfgang Schwotzer <wolfgang.schwotzer(a)gmx.net> writes: > New patch after rebase. > Always checks return values. > Tested with Polar Protrainer 5, updater.exe > From dcb91595b33513f8df2cf4d439221d3143c8fac1 Mon Sep 17 00:00:00 2001 > From: Wolfgang Schwotzer <wolfgang.schwotzer(a)gmx.net> > Date: Sat, 24 Jul 2010 17:12:05 +0200 > Subject: GetUserObjectInformation UOI_USER_SID (try 2) This should be retrieved from the server, based on the object security token or something along those lines. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: shdocvw: Remove useless menu separator
by Octavian Voicu 17 Aug '10

17 Aug '10

Not sure if it's useless. I thing it's intended to separate the static part of the menu (Add to favorites) from the dynamically generated list of favorite items that follows (which isn't implemented yet). Octavian

3 2

Re: [PATCH 1/4] msvcp90: Added allocator<char> 64-bit exports
by Alexandre Julliard 17 Aug '10

17 Aug '10

Piotr Caban <piotr(a)codeweavers.com> writes: > @@ -35,6 +35,12 @@ char* __stdcall MSVCP_allocator_char_address(void *this, char *ptr) > return ptr; > } > > +/* ?address@?$allocator@D@std@@QEBAPEADAEAD@Z */ > +char* __cdecl MSVCP64_allocator_char_address(void *this, char *ptr) > +{ > + return MSVCP_allocator_char_address(this, ptr); > +} > + stdcall and cdecl are equivalent on 64-bit, so you don't need the extra wrappers. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: avifil32: Fix EditStreamSetInfo wine checks [try 2]
by Alexandre Julliard 17 Aug '10

17 Aug '10

Alexandre Goujon <ale.goujon(a)gmail.com> writes: > +#define TEST_SETINFO_(m) \ > + hres = EditStreamSetInfo(stream, &info, sizeof(AVISTREAMINFO) ); \ > + ok( hres == 0, "got 0x%08X, expected 0\n", hres); \ > + hres = AVIStreamInfo(stream, &info2, sizeof(AVISTREAMINFO) ); \ > + ok( hres == 0, "got 0x%08X, expected 0\n", hres); \ > + ok( info2.m == info.m, "EditStreamSetInfo did not update "#m" parameter\n" ); > + > +#define TEST_SETINFO(m) \ > + info.m++; \ > + TEST_SETINFO_(m); \ > + \ > + info.m = 0; \ > + TEST_SETINFO_(m); Please avoid that sort of macros. Add a helper function if necessary, or just spell things out explicitly. -- Alexandre Julliard julliard(a)winehq.org

1 0

iPod synced with iTunes v7.6!
by Russ Mannex 17 Aug '10

17 Aug '10

Hello Maarten! I read your post on the WineHQ site. I was wondering if you know whether I am attempting something that simply will not work yet. I am running iTunes 7.7.1 on Wine 1.1.42. These are running on Ubuntu 10.04. iTunes is not showing my iPod. I have tried setting an autodetect drive E: to /media/IPOD, but iTunes seems to not see it there. Any help will be greatly appreciated, even if the answer is "will not work." Thanks. -- Russ Mannex Russ(a)Mannex.com

3 2

Re: [PATCH 1/5] wined3d: separate driver info from GPU info
by Henri Verbeet 17 Aug '10

17 Aug '10

On 17 August 2010 03:52, Roderick Colenbrander <thunderbird2k(a)gmail.com> wrote: > --- > dlls/wined3d/directx.c | 276 +++++++++++++++++++++------------------ > dlls/wined3d/wined3d_private.h | 14 ++ > 2 files changed, 163 insertions(+), 127 deletions(-) > This will return inconsistent driver version numbers for Vista, Win7 and 95/98/NT4.

1 0

Re: [2/2] gdiplus: Implement multi-frame image loading.
by testbot＠testbot.winehq.org 17 Aug '10

17 Aug '10

1 0

Re: [4/6] ipconfig: Partially implement basic adapter information output.
by Juan Lang 16 Aug '10

16 Aug '10

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

2 1

Re: [PATCH 1/5] d3d10: Fix d3dcommon.h inclusion.
by James Mckenzie 16 Aug '10

16 Aug '10

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

1 0

WineAPI structure plans
by Max TenEyck Woodbury 16 Aug '10

16 Aug '10

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

1 0

Re: [PATCH 1/5] d3d10: Fix d3dcommon.h inclusion.
by James McKenzie 16 Aug '10

16 Aug '10

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

3 2

Re: [PATCH 1/5] d3d10: Fix d3dcommon.h inclusion.
by James Mckenzie 16 Aug '10

16 Aug '10

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

1 0

RE: Wine users with a CD-ROM drive, please test
by Ge van Geldorp 16 Aug '10

16 Aug '10

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

1 0

RE: Wine users with a CD-ROM drive, please test
by Greg Geldorp 16 Aug '10

16 Aug '10

Hi Joerg, > From: Joerg Hoehle > > I found out that some machines ignore > set c audio all off > which was in the testsuite, while others react to it and even > update the system preferences volume mixer control if > it happens to be open. > > I don't know whether that difference depends on the HW (CD-ROM > driver) or the OS. You can find it out by posting your results here. > > I'm now using > set c audio all on > (which should be the default) > such that all users running the testsuite get to hear something. > > https://testbot.winehq.org/JobDetails.pl?Key=4434 > mcicda.c:612: Test failed: STOP all returned MCIERR_HARDWARE > (I fixed that, but not yet on testbot). I ran mcicda_test from TestBot job 4436 on the TestBot VMs, with a data .iso connected as CD-ROM. Full results in attachment. In short: On NT4, Win2000: mcicda.c:318: Test failed: resume without play: 0=NOERROR On NT4, Win2000, XP, W2K3 mcicda.c:397: Test failed: STATUS position: MCIERR_HARDWARE Ge.

2 1

Re: [3/3] wined3d: Remove isInDraw hack from context_setup_target.
by Henri Verbeet 16 Aug '10

16 Aug '10

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.

2 1

Re: [1/3] wined3d: Call set_render_offscreen at the end of context_setup_target.
by Henri Verbeet 16 Aug '10

16 Aug '10

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

1 0

← Newer
1
...
6
7
8
9
10
11
12
13
14
Older →

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