wine-devel May 2010

wine-devel@winehq.org

115 participants
288 discussions

Re: [PATCH 5/5] server: get rid of sock_try_event
by Alexandre Julliard 13 May '10

13 May '10

Mike Kaplinskiy <mike.kaplinskiy(a)gmail.com> writes: > We *might* need to ignore POLLERR messages for UDP sockets, as the > condition is actually temporary and sock_try_event was hiding this. It doesn't work here: ../../../tools/runtest -q -P wine -M ws2_32.dll -T ../../.. -p ws2_32_test.exe.so sock.c && touch sock.ok sock.c:941: Test failed: some threads have not completed: 102 sock.c:3567: Tests skipped: WSAIoctl failed to get AcceptEx with ret -1 + errno 10045 make: *** [sock.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: urlmon: CreateUri should return E_INVALIDARG for NULL args.
by Paul Vriens 13 May '10

13 May '10

On 05/13/2010 04:49 AM, Thomas Mullaly wrote: > @@ -75,6 +77,22 @@ static void test_CreateUri_InvalidFlags(void) { > } > } > > +/* > + * CreateUri returns E_INVALIDARG if the IUri it recieves is NULL. > + * CreateUri returns E_INVALIDARG if the uri string is NULL and sets the IUri to NULL. > + */ I don't think these comments are needed as the same is shown in the tests below (I was actually triggered by the wrong spelling of 'receives' btw). > +static void test_CreateUri_InvalidArgs(void) { > + HRESULT hr; > + IUri*uri = (void*) 0xdeadbeef; > + > + hr = pCreateUri(http_urlW, 0, 0, NULL); > + ok(hr == E_INVALIDARG, "Error: CreateUri returned 0x%08x, expected 0x%08x\n", hr, E_INVALIDARG); > + > + hr = pCreateUri(NULL, 0, 0,&uri); > + ok(hr == E_INVALIDARG, "Error: CreateUri returned 0x%08x, expected 0x%08x\n", hr, E_INVALIDARG); > + ok(uri == NULL, "Error: Expected the IUri to be NULL, but it was %p instead\n", uri); > +} -- Cheers, Paul.

2 1

Re: winemp3.acm: Fixes the Mac-specific code
by Aric Stewart 13 May '10

13 May '10

Hi, It is good to see someone working on this code. But your patch makes it so that all the mp3 sound clips in the game that I was coding for stop working. trace:mpeg3:mp3_leopard_horse ndst 147456 0x2eab348 <- 19901 0x2ea657c trace:mpeg3:mp3_leopard_horse First 16 bytes to input: "\x00\x1f\x84\n\x92_\x81h\x00\x00\x00\x00\x00\x00\x00\x00" trace:mpeg3:mp3_leopard_horse Invalid header at 0x2ea657c I was also under the impression that a single input stream could come through as a series of ACMDM_STREAM_CONVERT messages that may or may not align as containing full packets or have a header on each call. This may not be what is happening here since it appear to be happening at the beginning of a given sound clip. But that is why I used the AudioFileStream (that and i was seeing apple documentation recommending so) -aric Kristofer Henriksson wrote: > The current winemp3.acm does not work if the Mac-specific code is > used. This rewrites the relevant portion to fix, for example, > background music on things like Oblivion. > > > ------------------------------------------------------------------------ > >

1 0

Re: [PATCH 0/2] Unaligned mmap() on Mac OS X
by Ken Thomases 13 May '10

13 May '10

On May 12, 2010, at 2:30 PM, Charles Davis wrote: > In Mac OS X 10.5, mmap() was changed to conform to UNIX '03. Among other > things, this means that mmap() no longer supports unaligned file offsets > (like Linux). What problems does this cause? > However, by reading Darwin source, I learned that the check for unaligned > file offsets is done at the library level, and not in the kernel. This is > to support older binaries compiled for Tiger and earlier. This means that Wine > compiled for Tiger should support unaligned file offsets, like want. But it > also means that, if we make the syscall ourselves instead of calling libc, we > can support them on Leopard (and by extension, Snow Leopard) too! This patch > series does just that. Can't we achieve that just by avoiding the mapping of the "mmap" identifier to the _mmap$UNIX2003 symbol? http://developer.apple.com/mac/library/releasenotes/Darwin/SymbolVariantsRe… It may be sufficient to #define _NONSTD_SOURCE, #include <sys/mman.h> as the first header, #undef _NONSTD_SOURCE, and then continue to include any other headers. Alternatively, you can probably use an approach like this: http://source.winehq.org/git/wine.git/?a=commitdiff;h=028b763f2f51e78084129… Regards, Ken

3 4

Re: [kernel32] Return the correct processor arch and type in wow64 mode
by testbot＠testbot.winehq.org 13 May '10

13 May '10

2 1

Re: [WineHQ][WWN] WWN 362 - Brought to you by Edward Savage
by Sven Baars 13 May '10

13 May '10

Zachary Goldberg wrote: > +<topic>AppDB / BugZilla</topic> > +<center>BugZilla Changes:</center> > + > +<center> > +<table border="1" bordercolor="#222222" cellspacing="0" cellpadding="3"> > +<tr> > +<td align="center"> > + Category > +</td> > +<td> > +Total Bugs Last Issue > +</td> > +<td> > + Total Bugs This Issue > +</td> > +<td> > + Net Change > +</td> > +</tr> > + > +<tr> > +<td align="center"> > + UNCONFIRMED > +</td> > +<td align="center"> > + 2795 > +</td> > +<td align="center"> > + 2821 > +</td> > + > +<td align="center"> > + +26 > +</td> > +</tr> > + > +<tr> > +<td align="center"> > + NEW > +</td> > +<td align="center"> > + 2677 > +</td> > +<td align="center"> > + 2683 > +</td> > + > +<td align="center"> > + +6 > +</td> > +</tr> > + > +<tr> > +<td align="center"> > + ASSIGNED > +</td> > +<td align="center"> > + 28 > +</td> > +<td align="center"> > + 26 > +</td> > + > +<td align="center"> > + -2 > +</td> > +</tr> > + > +<tr> > +<td align="center"> > + REOPENED > +</td> > +<td align="center"> > + 119 > +</td> > +<td align="center"> > + 117 > +</td> > + > +<td align="center"> > + -2 > +</td> > +</tr> > + > +<tr> > +<td align="center"> > + CLOSED > +</td> > +<td align="center"> > + 3 > +</td> > +<td align="center"> > + 1 > +</td> > + > +<td align="center"> > + -2 > +</td> > +</tr> > + > +<tr> > +<td align="center"> > + TOTAL OPEN > +</td> > +<td align="center"> > + 5619 > +</td> > +<td align="center"> > + 5647 > +</td> > +<td align="center"> > + +28 > +</td> > +</tr> > +<tr> > +<td align="center"> > + TOTAL > +</td> > +<td align="center"> > + 5622 > +</td> > +<td align="center"> > + 5648 > +</td> > +<td align="center"> > + +26 > +</td> > +</tr> > +</table> > Hey Zach, This says that there is 1 closed bug, while there must be thousands. That can't be right. Also, it doesn't say anything about not-closed resolved bugs (like fixed ones), so it doesn't say anything about the real total. Sven

1 0

Re: wine-devel Digest, Vol 58, Issue 30
by Maik Masling 12 May '10

12 May '10

Am 12.05.2010 19:00, schrieb wine-devel-request(a)winehq.org: > Send wine-devel mailing list submissions to > wine-devel(a)winehq.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.winehq.org/mailman/listinfo/wine-devel > or, via email, send a message with subject or body 'help' to > wine-devel-request(a)winehq.org > > You can reach the person managing the list at > wine-devel-owner(a)winehq.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of wine-devel digest..." > > > Today's Topics: > > 1. Re: Release plans (Alexandre Julliard) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 12 May 2010 18:55:21 +0200 > From: Alexandre Julliard<julliard(a)winehq.org> > Subject: Re: Release plans > To: Scott Ritchie<scott(a)open-vote.org> > Cc: wine-devel(a)winehq.org > Message-ID:<87k4r93vra.fsf(a)wine.dyndns.org> > Content-Type: text/plain; charset=us-ascii > > Scott Ritchie<scott(a)open-vote.org> writes: > > >> On 05/09/2010 05:00 PM, Alexandre Julliard wrote: >> >>> We definitely need a release changelog, yes. >>> >> It seems to me what we really want is more than a changelog but a proper >> release announcement. I want a journalist who has hardly heard of Wine >> to read the page and understand what we've done and why it's great. >> > Sure, that's the press release, we should have one too, but it's a > different thing. A changelog would be a detailed description of changes > that matter from a user point of view. It would list for instance new > builtin programs, new configuration options, new behaviors, new system > dependencies, backwards compatibility concerns, etc. You can't put that > sort of things in the press release. > > That is a certain point. If the changelog would nounce namely working programs in series 1.2, than people would be more attracted into testing those but could be more dissappointed, because in fact more regressions to those "featured program"-list would pop up, especially after changes and with following 1.2.x. To tell a non-programmer from a user-perspective point of view the advantages in featuring functionalities and supported application of the wine-project stable snapshots must not be like coding it again in foolish human language. What I think the announcement really need to be is giving me/us a focus on the range of the advantages. "What is the evolutionary point?" I would be perfectly informed and proud to see it just like that: Some few new famous massively used and working single/multiplayer games or programs that people heavily rely on. For example top 10 games + top 10 applications that work platinum with 1.2 plus an numeral overview of the status quo compared to 1.1 in platin,gold,silver,bronce,fixed bugs etc. Compared: 1.0 / 1.1 Platin: # / # Gold: " Silver: " Bronce: " Fixed Bugs: " What i really liked in earlier days was the animation with the gold,silver,bronce-bars, because that would easily visualise those process. Wow, user thinks "How comes?" and we give him a additional sum-up of the changelogs main-points from all 1.1.* announcements plus the standard "additional/other/various bugfixes/improvements"-sentences that are regularly in part of the announcements. I see no problem in just announcing it within WWN. We could also just put the techie point inside of WWN and refer to it in the press release for a more detailed technical overvie of the advantages.

1 0

Re: Release plans
by James Mckenzie 12 May '10

12 May '10

> >On 05/09/2010 05:00 PM, Alexandre Julliard wrote: >> Edward Savage <epssyis(a)gmail.com> writes: >> >>> On Sun, May 9, 2010 at 4:42 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: >>>> >>>> Unless some major problems come up, 1.1.44 will be the last of the 1.1.x >>>> series. The next release will be 1.2-rc1, which will mark the beginning >>>> of the code freeze. This should result in a 1.2 final sometime in June. >>>> >>> >>> Would it be worthwhile to put together some sort of release >>> announcement detailing changes and improvements in Wine between 1 and >>> 1.2? Some thing similar to what other projects release that tech sites >>> can pickup and talk about. Maybe even a more formal press release >>> style document. >> >> We definitely need a release changelog, yes. >> > >It seems to me what we really want is more than a changelog but a proper >release announcement. I want a journalist who has hardly heard of Wine >to read the page and understand what we've done and why it's great. > We need BOTH a change log and the press release. The Press release needs to highlight the changes like adding Windows-on-Windows 64 code and the ability to work with .NET 2.0. The Changelog should be extremely detailed and directed at the user to advise what was fixed and what is still broken or will be broken by using this release. >I've created a rough skeleton of things to have here: >http://wiki.winehq.org/Wine1.2Announcement > >I'm very busy at the Ubuntu Developer Summit at the moment but I'll put >some good work into it soon. > Thank you for starting work on the announcement. The changelog will be a much more lengthy work. James McKenzie

1 0

Re: [PATCH 1/5] ws2_32/tests: add some socket event tests
by testbot＠testbot.winehq.org 12 May '10

12 May '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=2019 Your paranoid android. === W98SE (32 bit sock) === sock.c:3280: Test failed: Failed to empty buffer: 0 - 0 sock.c:3281: Test failed: Expected event sequence [FD_READ(0)], got [FD_CLOSE(0)] sock.c:3285: Test failed: Failed to empty buffer: 0 - 0 sock.c:3171: Test failed: Expected event sequence [], got [FD_READ(0)]

1 0

Absynth 4 though fst
by Salvatore De Paolis 11 May '10

11 May '10

Hi, i'm trying to run Absynth 4 using fst, the plugin loads but it doesn't show the GUI, just a black screen. Here's the debug log http://filebin.ca/hwgvnw/absynth4.log i'm running wine git version under debian sid do you have idea what's wrong? regards S.

2 1

← Newer
1
...
17
18
19
20
21
22
23
...
29
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 May 2010