wine-devel October 2007

wine-devel@winehq.org

141 participants
271 discussions

Start a nNew thread

Anything wrong with my patch from 16.10. about w32x86 and win40 creation?
by Markus Gömmel 26 Oct '07

26 Oct '07

I think it's not a big deal but would help making on of our EmTec products more compatible... Markus

5 13

Re: [1/5] (resend) WineD3D: Enable the draw buffers extension only when used
by Stefan Dösinger 26 Oct '07

26 Oct '07

Please ignore this patch. I just saw that macos advertises 4 draw buffers, but only one was used inside wined3d because we weren't using fbo offscreen rendering. Now macos supports the extension, 4 draw buffers but still complains... oh well > Am Freitag, 26. Oktober 2007 12:45:57 schrieb Stefan Dösinger: > > In a last discussion with Henri on IRC I fixed a concern he had about the > > old patch(dropped extension check). As for the general concern about > > driver issue fixups, we didn't come to a final conclusion and decided to > > ask Alexandre for his opinion. Just to sum up the pros/cons: > > > > -) Makes the code more complex to work around another's issues > > -) Will most likely never be removed should the driver be fixed > > > > +) Compiling the shader without warnings makes real issues more visible > > and important > > +) Avoids confusing mac users and developers with the false warnings > > +) MacOS Tiger Driver will propably never get fixed > > Use the attached patch instead, it follows a suggestion by Chris and is > less intrusive.

1 0

Re: d3dx8 math implementation + tests: use more "," instead of ";".
by Alexandre Julliard 26 Oct '07

26 Oct '07

Lionel Debroux <lionel_debroux(a)yahoo.fr> writes: > I noticed several "," in the implementation and tests of D3DX8 math > functions. I added more, since this may help the auto-vectorizer of > some compilers noticing that x86 SIMD could be used. I don't see any reason why that would make the slightest difference, what makes you think this is needed? -- Alexandre Julliard julliard(a)winehq.org

1 0

re: Improving http://tests.winehq.org/data/
by Dan Kegel 26 Oct '07

26 Oct '07

James wrote: >Looking at the test data, all of the msi:install tests timeout. I >just ran the install tests in XP running under vmware on a 3ghz >machine. The tests took 9m41s. That completely blows away the 2min >timeout. There's nothing wrong with the tests, they just take a long >time. I don't think we should extend the timeout, because it's very >subjective and more tests will be added, meaning we'll have to change >the timeout eventually. I do think we should have a flag or variable >that allows the timeout to be ignored for certain tests. Any >opinions? I'd like a way to specify the expected runtime, for use on tests that we observe take a long time. It would be used in two ways: 1) runtest could take an option --skip-long-tests which would skip all tests that had that option set, and 2) by default runtest would only abort those tests if they took one minute over their expected time (say). That would give us both a quick interactive make test and a more reliable slow-but-complete make test. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

4 4

Re: Word crash
by Kai Blin 26 Oct '07

26 Oct '07

On Friday 26 October 2007 09:28:09 Marco Stornelli wrote: > Hi all, > > I'm using wine 0.9.44-15 for openSuse 10.3 and office 2000. Excel > works fine, powerpnt doesn't start and wine doesn't print nothing in > console about it, and about word, wine prints this: Please don't send emails to wine-bugs. Open a bugreport on http://bugs.winehq.org/ instead. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

1 0

Beer apps under Wine :-)
by Dan Kegel 26 Oct '07

26 Oct '07

Seems that most beer apps run ok on wine, judging by this thread: http://www.tastybrew.com/forum/thread/120190

1 0

Re: crypt32: Remove a test because of a Windows 2003 SP1 bug
by Reece Dunn 25 Oct '07

25 Oct '07

Juan Lang wrote: > - /* Now check just the time */ > - flags = CERT_STORE_TIME_VALIDITY_FLAG; > - parent = CertGetIssuerCertificateFromStore(store, child, NULL, &flags); > - ok(parent != NULL, "CertGetIssuerCertificateFromStore failed: %08x\n", > - GetLastError()); > - /* Oops: the child is not expired, so the time validity check actually > - * succeeds, even though the signing cert is expired. > + /* Checking time validity is not productive, because while most Windows > + * versions return 0 (time valid) because the child is not expired, > + * Windows 2003 SP1 returns that it is expired. Thus the range of > + * possibilities is covered, and a test verifies nothing. > */ The test being removed is correct and valid. Removing it could lead to a regression in Wine as this case is not being covered when this patch is applied. While a 100% pass rate is ideal, on Windows 2003 SP1 that test *is* failing due to a bug. However, this is the correct behaviour, and the bug is detected by this test. - Reece

2 4

How long should 'make test' take?
by Dan Kegel 25 Oct '07

25 Oct '07

Here are all the tests that take more than five seconds: 5.407s advapi32_test.exe.so service.c 6.010s kernel32_test.exe.so console.c 6.252s user32_test.exe.so msg.c 9.657s kernel32_test.exe.so process.c 12.053s winmm_test.exe.so timer.c 14.080s shell32_test.exe.so shlexec.c 17.760s msi_test.exe.so install.c 24.018s winmm_test.exe.so wave.c 648.722s wininet_test.exe.so ftp.c Other than wininet's ftp test and maybe winmm's wave test, the overall time seems reasonable. IMHO we should disable the ftp test until its runtime can be brought down below 20 seconds. It's just too slow, and too dependent on stuff not under Wine's control (e.g. one's internet connection). And I have a really fast internet connection... it's just that my ping time to winehq is 80ms. I bet the ftp test runs fast in Minneapolis... - Dan

4 5

Re: Start: Convert start to Unicode.
by Dmitry Timoshkov 25 Oct '07

25 Oct '07

"Anatoly Lyutin" <vostok(a)etersoft.ru> wrote: > -/** > +WINE_DEFAULT_DEBUG_CHANNEL(start); > + > +/* All these changes /** -> /* make the diff larger, and are not really necessary. > Output given message to stdout without formatting. > */ > -static void output(const char *message) > +static void output(const WCHAR *message) > { > DWORD count; > - WriteFile(GetStdHandle(STD_OUTPUT_HANDLE), message, strlen(message), &count, NULL); > + DWORD res; > + int wlen = strlenW(message); Once you change your editor settings to use natural 8 spaces for a tab you will see how ugly the formatting in your new code is. > -static void fatal_error(const char *msg, DWORD error_code) > +static void fatal_error(const WCHAR *msg, DWORD error_code) fatal_error() is not called with strings outside of ASCII charset, so there is no much point in converting it to unicode. It only makes your patch full of controversial changes. IMHO fatal_error() should be removed altogether, and replaced by proper error handling instead. -- Dmitry.

3 5

Re: winmm: fix uninitialized variable that caused near-infinite loop
by Alexandre Julliard 25 Oct '07

25 Oct '07

"Dan Kegel" <dank(a)kegel.com> writes: > Without this patch, winmm/tests/mixer.c appears to hang on one of my machines. > > I think the problem was capsA was uninitialized in: > for (d=0;d<capsA.cDestinations;d++) { That's just hiding the bug. If mixerGetDevCapsA failed we shouldn't go on to use the data that it hasn't returned, we should abort the test. -- Alexandre Julliard julliard(a)winehq.org

1 0

← Newer
1
...
5
6
7
8
9
10
11
...
28
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 October 2007