On 05/09/2010 07:06 AM, Gerald Pfeifer wrote:
> ---
>case WM_ENABLE:
> -return LISTVIEW_Enable(infoPtr, (BOOL)wParam);
> +return LISTVIEW_Enable(infoPtr);
This indicates a bug. The parameter should really be used by LISTVIEW_Enable().
Vitaliy.
On 05/07/2010 01:06 PM, Gerald Pfeifer wrote:
> -oldPen = SelectObject(hdc, greenPen);
> +SelectObject(hdc, greenPen);
If it's not used it's a bug. Everything should be reset to original state to
prevent influence on following tests. There are number of such places in
Wine's test suite that
On 05/09/2010 03:15 PM, Jerome Leclanche wrote:
> On Sun, May 9, 2010 at 11:55 PM, Jerome Leclanche wrote:
>> Testcase for bug 18864.
>>
> This patch reveals a crash in GetObject in wine which I'm unsure how
> to fix. Someone proposed using IsBadWritePtr(), but from what I
> understand, this is no
On 05/09/2010 01:12 PM, Henry Blum wrote:
> I'm not sure if that is proper behavior
It's not. That patch is an outright hack specifically for your game.
The proper way to fix it is to send correct ACLs to the server when new
process is created. Wine still doesn't do it.
Vitaliy.
On 05/09/2010 03:50 PM, marco wrote:
> Thank you all for your reply,
>
> Do I have to install git en download the complete source of the website?
Yes and yes. Here is the page with lots of details:
http://wiki.winehq.org/GitWine
All you really need to do is:
1. Install git
2. Get WineHQ's source
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=1987
Your paranoid android.
On Sun, May 9, 2010 at 4:14 PM, Dan Kegel wrote:
> in general, Wine's D3D version achieves only half to three-quarters the
> performance
> of Vista's.
I just tried 'winetricks glsl-disable' on heaven2_d3d9. It sped it up
about 8% (to 16.0 fps), but added some fun problems (e.g. scenes
7, 10, an
http://kegel.com/wine/yagmarkdata now has data from five different
benchmarks:
3dmark{2000, 2001, 06} and heaven2_{opengl, d3d9}, and running on a
semi-whimpy
e8400 dual core box with an nvidia gt 220 card, on both Vista and
Ubuntu+Wine.
First, the good news:
the OpenGL version of the Heaven bench
Thank you all for your reply,
I'm not familiar with this process , but I will try to find out how this
works.
Do I have to install git en download the complete source of the website,
or can I only download the download.template change that and submit that
somewhere ?
Marco
On 06-05-10 17:5
On Sat, 8 May 2010, wy...@volny.cz wrote:
[...]
> > * Not testing the code under Release conditions.
>
> I guess, that running Word2007 under linux/wine also does not meet release
> conditions by Microsoft ;-) Anyway, i hope that if i run Win program
> calculating PI on 4 decimal place, both -O0 a
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=1983
Your paranoid android.
On 5/9/2010 16:43, Gerald Pfeifer wrote:
isW is not actually used by is_textT, so we can simplify listview.c a
bit by omitting the useless parameter.
-static inline BOOL is_textT(LPCWSTR text, BOOL isW)
+static inline BOOL is_textT(LPCWSTR text)
There's no reason to keep this helper
PS, please don't commit, the check is wrong. I'll resend it later.
J. Leclanche / Adys
On Mon, May 10, 2010 at 12:15 AM, Jerome Leclanche wrote:
> On Sun, May 9, 2010 at 11:55 PM, Jerome Leclanche wrote:
>> Testcase for bug 18864.
>>
>> J. Leclanche
>>
>
> This patch reveals a crash in GetOb
On Sun, May 9, 2010 at 11:55 PM, Jerome Leclanche wrote:
> Testcase for bug 18864.
>
> J. Leclanche
>
This patch reveals a crash in GetObject in wine which I'm unsure how
to fix. Someone proposed using IsBadWritePtr(), but from what I
understand, this is not a recommended solution. Any idea?
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=1981
Your paranoid android.
I looked further into the problem I set out to fix, and realize that this patch
is pretty terrible. The real bug is 22006
http://bugs.winehq.org/show_bug.cgi?id=22006 and affects the game Continuum
http://appdb.winehq.org/appview.php?iVersionId=3703 basically, OpenProcess
doesn't enfore ACLs
I
On Sun, 9 May 2010, test...@testbot.winehq.org wrote:
> === WINEBUILD (build) === Patch failed
The issue was that a previous patch of mine (which got accepted)
conflicted and my local tree was not right. Fixed and resubmitted,
testing at Wine Test Bot went well now:
https://testbot.winehq.org/
Looking at
RPC_STATUS WINAPI RpcBindingVectorFree( RPC_BINDING_VECTOR** BindingVector )
{
RPC_STATUS status;
ULONG c;
TRACE("(%p)\n", BindingVector);
for (c=0; c<(*BindingVector)->Count; c++) {
status = RpcBindingFree(&(*BindingVector)->BindingH[c]);
}
HeapFree(
On Sun, May 9, 2010 at 8:23 PM, Alexandre Julliard wrote:
> You can't print warnings from the server, they usually won't go where
> you want them to.
That's unfortunate. The only remaining place to do that is in
ntdll/FILE_CreateFile and check for status code
STATUS_TOO_MANY_OPENED_FILES.
We can
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=1977
Your paranoid android.
Octavian Voicu writes:
> I was looking at http://bugs.winehq.org/show_bug.cgi?id=19861 and it
> seemed pretty easy to fix.
>
> In my opinion, the warning should either go in server/file.c -
> file_set_error() or in server/fd.c - open_fd().
You can't print warnings from the server, they usually w
I think this should be removed entirely. I added it in 2005 because Mesa back
then choked on our protected memory(X server freeze or kernel panic). Around
2008 I checked if this bug still exists, and it seems to be fixed.
If anyone still runs into this bug he should seriously consider upgrading
Edward Savage writes:
> On Sun, May 9, 2010 at 4:42 AM, Alexandre Julliard
> 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
On Sun, May 9, 2010 at 4:42 AM, Alexandre Julliard 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
Le dimanche 09 mai 2010 13:09:47, Marcus Meissner a écrit :
> As __cdecl (for the compare function) is not the UNIX cdecl in Win64
> anymore, we need to reimplement sort to call the right comparator
> functions.
Not that it's important, but that reminded me of this:
http://docs.python.org/librar
There are a couple of shortcomings in our current console
implementation. To name a few:
- the "bare console handles" concept has very short limitations (see
bug reports #5541, or #13189). Globally, bare handles are actually
handles to files, whereas lots of programs expect them to behave
li
I was looking at http://bugs.winehq.org/show_bug.cgi?id=19861 and it
seemed pretty easy to fix.
In my opinion, the warning should either go in server/file.c -
file_set_error() or in server/fd.c - open_fd().
open_fd() is pretty much the only place where open() is called, so
it's a good candidate.
Tom Wickline writes:
> I thought the code freeze, RC cycle would be more like three months not
> three releases, e.g six weeks.
> But I'm 100% sure AJ knows best. :)
Nobody said it can't be three months. It will last as long as good fixes
keep pouring in. In practice after 1-2 months we usually
Le dimanche 09 mai 2010 11:05:55, Stefan Leichter a écrit :
> Failing tests on wine needs to be marked with the todo_wine macro
Yes, but as I said in my first mail I would prefer to get hints on how this
should be fixed. I know nothing about path handling in wine, if it turns out
to be trivial t
Ben Klein writes:
> I'm more interested to know in the status of WoW64 in Wine. Can 64bit
> and 32bit Wine be installed sensibly and concurrently?
Yes, everything should work as expected now. Please test it.
--
Alexandre Julliard
julli...@winehq.org
Am Sunday 09 May 2010 10:26:07 schrieb Vincent Pelletier:
> This test passes on win2k & winxp, fails on wine.
>
Failing tests on wine needs to be marked with the todo_wine macro see
http://www.winehq.org/site/docs/winedev-guide/testing-platforms and
http://www.winehq.org/pipermail/wine-devel/200
Le samedi 08 mai 2010 18:14:49, Vincent Pelletier a écrit :
> This test passes on win2k & winxp, fails on wine.
Bug opened for this issue:
http://bugs.winehq.org/show_bug.cgi?id=22635
Updated patch, with (too ?) many more test cases.
Interesting URLs:
http://msdn.microsoft.com/en-
us/library/aa3
On 5/8/2010 01:36, Gerald Pfeifer wrote:
This one felt a bit like peeling an onion, but indeed while we have been
setting those three variables, we're never using them. And also ptr is
not used beyond this point, so we can remove a bunch of dead code.
I don't think it's dead. Variable ptr i
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=1974
Your paranoid android.
34 matches
Mail list logo
