wine-devel September 2006

wine-devel@winehq.org

139 participants
257 discussions

Whither msxml?
by Dan Kegel 25 Sep '06

25 Sep '06

For the past two years, I've helped UCLA's cs130 by pointing them at an area of Wine that needs improvement and helping them get patches submitted. For Winter 2007, I'm considering having them focus on msxml3. So I'm starting to look at bugzilla (see my previous message) and dig up demo apps and articles that might help us understand where wine's msxml needs to go. Man, oh, man are there a lot of pages about msxml out there. If anyone has tips on sore spots with Wine's msxml, please let me … [View More]

3 2

An MSVCRT_fgetc bug
by Tobias Ringström 25 Sep '06

25 Sep '06

There's a bug in MSVCRT_fgetc in 0.9.21 (likely introduced in 0.9.19) in that it sometimes sign extends the byte read from the file. The following program illustrates the problem: #include <stdio.h> int main() { FILE *f = fopen("tmp.bin", "w+"); fputc(0xe0, f); fputc(0xe0, f); rewind(f); printf("0x%08x\n", fgetc(f)); printf("0x%08x\n", fgetc(f)); fclose(f); return 0; } The output is: … [View More]

2 1

Re: LOSTWAGES: WWN 292 & 320 updates
by Tom Wickline 25 Sep '06

25 Sep '06

On 9/23/06, Mirek <thunder.m(a)email.cz> wrote: > > > > Also Wine reports 64MB of video memory not 16MB > > I think there shuld be option in winecfg to set this, because it is not easy to > find how anyone can do that. http://wiki.winehq.org/UsefulRegistryKeys Tom

1 1

Re: Governance revisited (Wineconf report)
by Ge van Geldorp 25 Sep '06

25 Sep '06

> From: Kai Blin <kai.blin(a)gmail.com> > > On Saturday 23 September 2006 10:32, Scott Ritchie wrote: > > Frankly, all we really need is for Alexandre to write a 10-second > > reply to wine-devel for each patch he rejects. > > On WineConf, we decided against this. That would still slow > down the overall patch submission speed. Consider you have a > patch that's just fine, but before you sent that, I sent in > ten patches with C++ style comments. … [View More]Alexandre would now have > to reply to ten patches with "No C++ style comments" before > processing your patch. Everybody reading wine-patches > could point out what was wrong with my patches. You must be kidding. Even in your somewhat convoluted example, it would be fine to receive just a single notification "No C++ style comments" and I really wouldn't care if the notification came from Alexandre or from someone else on wine-patches. The reality is that a lot of patches (I haven't kept a precise count, but I estimate about a third of my own patches) are dropped silently, without any feedback at all. I have absolutely no problem with a strict patch acceptance policy, designed to keep the Wine quality high. Alexandre is amazingly smart and when he tells me why a certain patch was rejected I'll usually agree with him and even if I don't agree, I have enough confidence in him to accept his judgement. But having your patches dropped silently is pretty annoying. The usual response from the core Wine developers is "well, just resubmit". I fail to see how this helps Alexandres productivity (or my own for that matter). If patches weren't dropped silently the sequence of events would be: 1) Submit patch 2) Alexandre looks at patch 3) Alexandre writes 10-second rejection reply With the resubmit: 1) Submit patch 2) Alexandre looks at patch 3) Wait a week 4) Resubmit patch 5) Alexandre looks at patch again 6) Alexandre writes 10-second rejection reply Seems to me this incurs extra work for Alexandre (number 5). The patch processes isn't very transparant. For example, I submitted a patch on 20 June 2006 to dlls/kernel/heap.c (www.winehq.org seems to be unreachable for me at the moment so I can't give a URL to the message) to fix a problem with the heap on Win64. This patch was silently dropped. On July 21 a change very similar to what I submitted was committed but not attributed to me. Now, either the commit was not based on my patch (in which case someone else spent another 2-3 days (it was one of those problems where a chain of out-of-buffer memory writes take place and you have to work your way up the chain to find the root cause) on tracking down an already known problem for which a fix was already available) or it was based on my patch (in which case my patch shouldn't have been dropped and I should have been given credit). Like I said before, I have a lot of respect for Alexandres technical abilities. But when I read comments in the Wineconf report about git: "Developers might not like it, but Alexandre does so it's a success" (did I mention I dislike git also???) and the inability of the Wine community to set up a patch management system (so patches won't disappear into the big void) because Alexandre refuses to use it if it won't work in Emacs I'm starting to wonder if people realise that the developers don't work for Alexandre. He's a great Benovelent Dictator on technical issues, but in my opinion only a Dictator on patch process management. Ge van Geldorp. [View Less]

2 1

Governance revisited
by Steven Edwards 25 Sep '06

25 Sep '06

---------- Forwarded message ---------- From: Steven Edwards <winehacker(a)gmail.com> Date: Sep 25, 2006 1:27 AM Subject: Re: Governance revisited To: Troy Rollo <wine(a)troy.rollo.name> On 9/25/06, Troy Rollo <wine(a)troy.rollo.name> wrote: > The present system turns people off even before you've had time to learn > whether they are capable or not. Which is why we want to have the ambassadors project to help new people in to wine. The thinking goes that if we have … [View More]

2 1

my dsound/winealsa hacks
by Tomas Carnecky 24 Sep '06

24 Sep '06

My ultimate goal was to solve the dsound underruns which were so horrible that I had to disable sound in World of Warcraft. While I managed to get the sound working flawlessly (really... I never heard such clear sound under wine) in WoW, it required WoW-specific hacks so my patch will never make it (in its current form) into the official git tree, but maybe someone can use some of my ideas to improve dsound/winealsa. The basic idea is to let alsa mix the sound instead of the infamous … [View More]dsound mixer. The advantage is that if the hardware supports mixing, there is very little overhead, if not, there's still dmix which can do that, but dsound doesn't need to care how it's done, it's entirely up to alsa. Now to the actual implementation, it's pretty straight-forward: I 'forced' CreateSoundBuffer to create a hardware buffer (right now it creates a hw buffer only for the primary buffer) and changed the winealsa driver to support that. Because winealsa driver opens only one 'connection' (snd_pcm_t) to the soundcar (allowing only one buffer per device), I simply opened a new 'connection' for each buffer and configured the hardware for 44100Hz/U16LE/stereo (that's what WoW expects). Up to this point it was easy. One of the big problems was that WoW requests a 16kb buffer, but alsa is unable to allocate a buffer with this exact size, and it caused problems if I passed the alsa buffer to WoW (so WoW could write directly to it). I had to allocate a separate buffer, keep track of the play/write positions in both buffers and copy the data from one to the other. I'm fairly sure this all could be done in a WoW-independent way, eg. configure the hardware as the application requests it (by passing LPCDSBUFFERDESC to the low-level driver etc) and keeping track of the read/write positions could also be done in a better way. There are a free questions that should be answered before someone can go on and make a 'proper' implementation. I simply bypassed the primary buffer, it doesn't exist since the data from the secondary buffers are written directly to the soundcard. If it should be possible to read the data from the primary buffer then we should forget this all and look for another solution. I believe that it's not possible (it's not possible to write to the primary buffer and the API doesn't differentiate between reads and writes), but someone should test that under windows. (this is only one question but I'm sure you'll come up with more ;) ) Here is the complete patch, I also changed the IDirectSound interface and a lot unrelated code, so the patch is a bit big :-/ There also are a few memory leaks, I didn't bother freeing the memory etc. http://dbservice.com/ftpdir/tom/dsound-alsa.patch tom [View Less]

6 10

Call for Installer Bugs...
by Dan Kegel 24 Sep '06

24 Sep '06

Lots of progress has been made in fixing installer bugs lately, but there are probably many such bugs hiding in plain view still. It would be very helpful if people could look for bugs which: a) appear to be MSI or setupapi related, and b) occur in freely downloadable executables (e.g. trial versions) c) aren't already in bugzilla (see http://bugs.winehq.org/buglist.cgi?product=Wine&component=wine-msi&keywords… for list) and file reports as appropriate at http://bugs.winehq.org. Thanks! - Dan

4 3

RFC: wine ASIO driver available for testing
by Robert Reif 24 Sep '06

24 Sep '06

I just uploaded a simple wine ASIO driver to http://bugs.winehq.org/show_bug.cgi?id=2161 for testing and feedback. Please look at it and give me feedback. Playback works. Recording is untested due to lack of software. Full duplex doesn't work for me but I'm not sure if it's a software issue or a problem with my hardware and OS setup. The software is a long way from being ready for submission so any feedback or help would be appreciated.

4 4

Re: LOSTWAGES: WWN 292 & 320 updates
by H. Verbeet 24 Sep '06

24 Sep '06

On 23/09/06, Mirek <thunder.m(a)email.cz> wrote: > > I also changed what benchmarks I had running at this years WineConf > > 3DMark2000, 3DMark2001SE and 3DMark2003... I have 3DMark2006 running > > and its beautiful, well beauty is in the eye of the beholder > > All of the test run in all three of the benchmarks to completion and > > there is only two test out of all test that have minor problems, and > > Henri has one of the test fixed in his tree. … [View More]

1 0

Server instability warning
by Jeremy White 24 Sep '06

24 Sep '06

Hi Folks, The server crashed early yesterday evening, and again sometime over the night. It's a new server - and in fact, I think it's the new 'new' server - seems like it always takes a while to get a server stabilized). Jeremy Newman is coming back from England today, and I prefer to leave these sort of repairs to him, otherwise he grouses at me (rightly, I might add :-/). So it's back up now, but I'm not sure for how long that will be true. Sorry for the hassle; if it gets worse this … [View More]

1 0

← Newer
1
...
8
9
10
11
12
13
14
...
26
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 September 2006