Re: server: Fix compilation on systems with a two-argument sched_setaffinity prototype.
Hello Andrew! Andrew Nguyen wrote: This lets Wine compile successfully on CentOS 3. CentOS 3? Alexandre was bitching about RHEL 5 being prediluvian ... RHEL 3 has a 2.4.21 based kernel, is over 7 years old and EOL. I'm not sure it is worth spending the effort to make current Wine compile and run on such an old system. bye michael
Re: msxml3: Add IObjectWithSite support to IXMLHttpRequest
On 2/17/11 10:47 AM, Alistair Leslie-Hughes wrote: Hi, Changelog: msxml3: Add IObjectWithSite support to IXMLHttpRequest More tests, please. Jacek
Re: mshtml: Implement IHTMLAnchorElement get/put target
On 2/18/11 9:54 AM, Alistair Leslie-Hughes wrote:
static HRESULT WINAPI HTMLAnchorElement_get_target(IHTMLAnchorElement *iface,
BSTR *p)
{
HTMLAnchorElement *This = impl_from_IHTMLAnchorElement(iface);
-FIXME((%p)-(%p)\n, This, p);
-return E_NOTIMPL;
+nsAString target_str;
+nsresult nsres;
+HRESULT hres = S_OK;
+
+TRACE((%p)-(%p)\n, This, p);
+
+nsAString_Init(target_str, NULL);
+nsres = nsIDOMHTMLAnchorElement_GetTarget(This-nsanchor,target_str);
+if(NS_SUCCEEDED(nsres)) {
+const PRUnichar *target;
+
+nsAString_GetData(target_str,target);
+*p = *target ? SysAllocString(target) : NULL;
+}else {
+ERR(GetHref failed: %08x\n, nsres);
+hres = E_FAIL;
+}
+
+nsAString_Finish(target_str);
+return hres;
}
Please use use return_nsstr here.
Jacek
Re: server: Fix compilation on systems with a two-argument sched_setaffinity prototype.
On 02/21/2011 04:43 AM, Michael Stefaniuc wrote: Hello Andrew! Andrew Nguyen wrote: This lets Wine compile successfully on CentOS 3. CentOS 3? Alexandre was bitching about RHEL 5 being prediluvian ... RHEL 3 has a 2.4.21 based kernel, is over 7 years old and EOL. I'm not sure it is worth spending the effort to make current Wine compile and run on such an old system. bye michael The fact that CentOS 3 has a Linux 2.4 kernel is precisely why I tried compiling Wine on the system. My motivation was to determine the reason that the reporter of bug 26088 (http://bugs.winehq.org/show_bug.cgi?id=26088) felt the need to compile Wine configured with --without-pthread, which doesn't seem to be something anyone should be doing. CentOS 3 seemed to be a natural candidate for testing, although later developments revealed that the reporter's system of concern was actually Debian Sarge. Given that there are apparently a non-zero number of users wanting to compile and run at least stable Wine on antique platforms, a few patches to accommodate such users doesn't seem to be too much trouble. The sched_setaffinity compile error was the only real blocker for compilation on CentOS 3, and after fixing it, I was able to at least successfully launch winecfg. signature.asc Description: OpenPGP digital signature
Valgrind --malloc-fill=A5 --free-fill=DE crashes Wine
Hi, I used to run Valgrind with the additional options --malloc-fill=A5 --free-fill=DE around Wine 1.2 times. Now I retried it and it crashes Wine 1.3.13 and 1.3.14 (it fails to load kernel32.dll). It turns out that malloc-fill is harmless, -free-fill causes havoc currently. Am I the only one using or seeing this (Ubuntu Lucid)? Thanks for your help, Jörg Höhle
Re: msxml3: Assign the IBindStatusCallback as soon as it created.
On 2/18/11 10:24 AM, Alistair Leslie-Hughes wrote: Hi, This stops a crash in httprequest_get_responseText, when running from a webpage since This-bsc was NULL. Tests, please. Jacek
Re: server: Fix compilation on systems with a two-argument sched_setaffinity prototype.
Andrew Nguyen angu...@codeweavers.com writes: My motivation was to determine the reason that the reporter of bug 26088 (http://bugs.winehq.org/show_bug.cgi?id=26088) felt the need to compile Wine configured with --without-pthread, which doesn't seem to be something anyone should be doing. CentOS 3 seemed to be a natural candidate for testing, although later developments revealed that the reporter's system of concern was actually Debian Sarge. Given that there are apparently a non-zero number of users wanting to compile and run at least stable Wine on antique platforms, a few patches to accommodate such users doesn't seem to be too much trouble. The sched_setaffinity compile error was the only real blocker for compilation on CentOS 3, and after fixing it, I was able to at least successfully launch winecfg. It's not worth making the code more complicated for this. You should disable it entirely if configure detects a broken prototype. -- Alexandre Julliard julli...@winehq.org
Re: gdiplus: Implement in-memory font-storage
I approve of this product and/or service. On Mon, Feb 21, 2011 at 3:54 AM, Maarten Lankhorst m.b.lankho...@gmail.com wrote: ---
Re: ws2_32: make gethostbyname fail if WSAStartup was not called before
Alexandre Goujon ale.gou...@gmail.com writes: @@ -1104,6 +1106,7 @@ int WINAPI WSAStartup(WORD wVersionRequested, LPWSADATA lpWSAData) /* don't do anything with lpWSAData-lpVendorInfo */ /* (some apps don't allocate the space for this field) */ +WSAStartup_called = TRUE; TRACE(succeeded\n); return 0; There's already a counter for tracking WSAStartup calls. -- Alexandre Julliard julli...@winehq.org
Re: Valgrind --malloc-fill=A5 --free-fill=DE crashes Wine
Hi Joerg,
Op 21-02-11 12:26, joerg-cyril.hoe...@t-systems.com schreef:
Hi,
I used to run Valgrind with the additional options
--malloc-fill=A5 --free-fill=DE
around Wine 1.2 times. Now I retried it and it crashes
Wine 1.3.13 and 1.3.14 (it fails to load kernel32.dll).
It turns out that malloc-fill is harmless, -free-fill causes havoc currently.
Am I the only one using or seeing this (Ubuntu Lucid)?
It's most likely a valgrind/wine bug, does this patch work?
Cheers,
Maarten
From 344c2234deb65b514bf9f10b5e894bde7c49976c Mon Sep 17 00:00:00 2001
From: Maarten Lankhorst m.b.lankho...@gmail.com
Date: Fri, 26 Nov 2010 00:03:40 +0100
Subject: [PATCH 08/24] ntdll: HACK to prevent valgrind --free-fill error
---
dlls/ntdll/heap.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/dlls/ntdll/heap.c b/dlls/ntdll/heap.c
index df94410..933d998 100644
--- a/dlls/ntdll/heap.c
+++ b/dlls/ntdll/heap.c
@@ -747,7 +747,7 @@ static void *realloc_large_block( HEAP *heap, DWORD flags,
void *ptr, SIZE_T siz
ARENA_LARGE *arena = (ARENA_LARGE *)ptr - 1;
void *new_ptr;
-if (arena-block_size - sizeof(*arena) = size)
+if (arena-block_size - sizeof(*arena) = size !RUNNING_ON_VALGRIND)
{
SIZE_T unused = arena-block_size - sizeof(*arena) - size;
@@ -1820,7 +1820,7 @@ PVOID WINAPI RtlReAllocateHeap( HANDLE heap, ULONG flags,
PVOID ptr, SIZE_T size
oldBlockSize = (pArena-size ARENA_SIZE_MASK);
oldActualSize = (pArena-size ARENA_SIZE_MASK) - pArena-unused_bytes;
-if (rounded_size oldBlockSize)
+if (rounded_size oldBlockSize || RUNNING_ON_VALGRIND)
{
char *pNext = (char *)(pArena + 1) + oldBlockSize;
@@ -1835,7 +1835,8 @@ PVOID WINAPI RtlReAllocateHeap( HANDLE heap, ULONG flags,
PVOID ptr, SIZE_T size
}
if ((pNext (char *)subheap-base + subheap-size)
(*(DWORD *)pNext ARENA_FLAG_FREE)
-(oldBlockSize + (*(DWORD *)pNext ARENA_SIZE_MASK) +
sizeof(ARENA_FREE) = rounded_size))
+(oldBlockSize + (*(DWORD *)pNext ARENA_SIZE_MASK) +
sizeof(ARENA_FREE) = rounded_size)
+!RUNNING_ON_VALGRIND)
{
/* The next block is free and large enough */
ARENA_FREE *pFree = (ARENA_FREE *)pNext;
--
1.7.2.3
Re: [PATCH 2/2] jscript: Added more uninitialization tests
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=9399 Your paranoid android. === WVISTAADM (32 bit jscript) === Failure running script in VM: The specified guest user must be logged in interactively to perform this operation
Re: d3dx9: Implement D3DXFloat32To16Array and D3DXFloat16To32Array. (try 2)
2011/2/20 Rico Schüller kgbric...@web.de:
Hi,
I have a small hint to the D3DXFloat32To16Array function. It seems that some
values are handled in some other way.
A small test:
D3DXFLOAT16 res;
union p
{
float f;
DWORD d;
} x;
x.d = 0x33000800;
D3DXFloat32To16Array(res, x.f, 1);
ok(res.value == 1, Failed %f %x\n, x.f, res.value);
This fails with the current implementation. It's not the only value, there
are a couple of them which are of by one. This could be easily seen by
loading both d3dx36.dll (wine and native) and comparing the values directly.
Cheers
Rico
Thanks Rico.
Still trying to investigate this further.
Perhaps, if you have any more hints as to how you arrived at this
magical value, much appreciated.
Namely, at first my hunch was that this value (2.9806e-08 with the
following bitwise representation):
0 01100110 100
was simply being truncated to the smallest denormalized value
representable by a half precision float:
0000.00 00..00016×10-8 (Smallest denormalized value)
but this is clearly not true for other values that are too small (they
are returned as 0.0f).
Thank you
Misha
Re: Two enhancement requests for winetricks
On Wed, Jun 9, 2010 at 6:03 AM, Dan Kegel d...@kegel.com wrote: On Wed, Jun 9, 2010 at 3:03 AM, Octavian Voicu octavian.vo...@gmail.com wrote: If you implement a status feature for every trick, you can change the main UI into a list of checkboxes, with the installed tricks already ticked. Right, of course. I had even realized that before. I guess I was just in 'no' mode... It took me a while, but I finally implemented this in winetricks-alpha today. To get a list of installed verbs from the commandline, you can do winetricks-alpha list-installed In the GUI, the installed verbs now have their checkboxes already checked. Unchecking them does nothing still, though. Please test http://winetricks.googlecode.com/svn/trunk/src/winetricks-alpha and let me know what you think. - Dan
Re: d3dx9: Implement D3DXFloat32To16Array and D3DXFloat16To32Array. (try 2)
Am 21.02.2011 20:19, schrieb Misha Koshelev:
Thanks Rico.
Still trying to investigate this further.
Perhaps, if you have any more hints as to how you arrived at this
magical value, much appreciated.
I got to this value by running the attached test patch applied after
yours. You probably may
modify the for loop. I've chosen the increment because of time/usage.
You may try with 0xff or a lower value instead of 0xfff, but be warned
running at 1 will take a
while to see a failed test.
You need a copy of native d3dx9_36.dll renamed to d3dx9_36_2.dll in the
path. The test
should show the difference between native and wine's implementation. I
haven't run the test
on windows, yet.
Namely, at first my hunch was that this value (2.9806e-08 with the
following bitwise representation):
0 01100110 100
was simply being truncated to the smallest denormalized value
representable by a half precision float:
0000.00 00..00016×10-8 (Smallest denormalized value)
but this is clearly not true for other values that are too small (they
are returned as 0.0f).
I haven't had the time to investigate this completely, yet. But probably
there are a couple of values
produced by the patch which should give a hint to what bits are
truncated/rounded.
Cheers
Rico
diff --git a/dlls/d3dx9_36/tests/math.c b/dlls/d3dx9_36/tests/math.c
index ca1c87d..b418126 100644
--- a/dlls/d3dx9_36/tests/math.c
+++ b/dlls/d3dx9_36/tests/math.c
@@ -2281,6 +2281,37 @@ static void test_D3DXFloat_Array(void)
ok(relative_error(single, testdata[i].single_out_ver2)
admitted_error,
Got %f, expected %f for index %d.\n, single,
testdata[i].single_out_ver2, i);
}
+
+{
+HMODULE dll_handle = NULL;
+D3DXFLOAT16 res, res2;
+D3DXFLOAT16* (WINAPI * float32to16)(D3DXFLOAT16 *pout, CONST FLOAT
*pin, UINT n);
+union
+{
+float f;
+DWORD d;
+} x;
+
+dll_handle = LoadLibraryA(d3dx9_36_2.dll);
+if (!dll_handle) skip(init: Could not load d3dx9_36_2.dll.\n);
+
+float32to16 = (void *)GetProcAddress(dll_handle,
D3DXFloat32To16Array);
+if (!float32to16)
+{
+FreeLibrary(dll_handle);
+skip(init: Could not get function pointer
(D3DXFloat32To16Array).\n);
+}
+
+for (i = 0; i 0xf000; i += 0xfff)
+{
+x.d = i;
+float32to16(res, x.f, 1);
+D3DXFloat32To16Array(res2, x.f, 1);
+
+ok(res.value == res2.value, Failed i=%#x f=%f (%#x!=%#x)\n, i,
x.f, res.value, res2.value);
+}
+FreeLibrary(dll_handle);
+}
}
START_TEST(math)
Re: fix sharing handling for CreateFile
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=9411 Your paranoid android. === W2K3R2SESP2 (32 bit file) === file.c:1929: Test failed: open failed for modes map 4/0/0 file.c:1929: Test failed: open failed for modes map 4/0/1 file.c:1929: Test failed: open failed for modes map 4/0/4 file.c:1929: Test failed: open failed for modes map 4/0/5 file.c:1929: Test failed: open failed for modes map 4/8000/0 file.c:1929: Test failed: open failed for modes map 4/8000/1 file.c:1929: Test failed: open failed for modes map 4/8000/4 file.c:1929: Test failed: open failed for modes map 4/8000/5 file.c:1929: Test failed: open failed for modes map 4/4000/0 file.c:1929: Test failed: open failed for modes map 4/4000/1 file.c:1929: Test failed: open failed for modes map 4/4000/4 file.c:1929: Test failed: open failed for modes map 4/4000/5 file.c:1929: Test failed: open failed for modes map 4/c000/0 file.c:1929: Test failed: open failed for modes map 4/c000/1 file.c:1929: Test failed: open failed for modes map 4/c000/4 file.c:1929: Test failed: open failed for modes map 4/c000/5 file.c:1929: Test failed: open failed for modes map 4/1/0 file.c:1929: Test failed: open failed for modes map 4/1/1 file.c:1929: Test failed: open failed for modes map 4/1/4 file.c:1929: Test failed: open failed for modes map 4/1/5 file.c:1929: Test failed: open failed for modes map 4/8001/0 file.c:1929: Test failed: open failed for modes map 4/8001/1 file.c:1929: Test failed: open failed for modes map 4/8001/4 file.c:1929: Test failed: open failed for modes map 4/8001/5 file.c:1929: Test failed: open failed for modes map 4/4001/0 file.c:1929: Test failed: open failed for modes map 4/4001/1 file.c:1929: Test failed: open failed for modes map 4/4001/4 file.c:1929: Test failed: open failed for modes map 4/4001/5 file.c:1929: Test failed: open failed for modes map 4/c001/0 file.c:1929: Test failed: open failed for modes map 4/c001/1 file.c:1929: Test failed: open failed for modes map 4/c001/4 file.c:1929: Test failed: open failed for modes map 4/c001/5 === WVISTAADM (32 bit file) === file.c:1929: Test failed: open failed for modes map 4/0/0 file.c:1929: Test failed: open failed for modes map 4/0/1 file.c:1929: Test failed: open failed for modes map 4/0/4 file.c:1929: Test failed: open failed for modes map 4/0/5 file.c:1929: Test failed: open failed for modes map 4/8000/0 file.c:1929: Test failed: open failed for modes map 4/8000/1 file.c:1929: Test failed: open failed for modes map 4/8000/4 file.c:1929: Test failed: open failed for modes map 4/8000/5 file.c:1929: Test failed: open failed for modes map 4/4000/0 file.c:1929: Test failed: open failed for modes map 4/4000/1 file.c:1929: Test failed: open failed for modes map 4/4000/4 file.c:1929: Test failed: open failed for modes map 4/4000/5 file.c:1929: Test failed: open failed for modes map 4/c000/0 file.c:1929: Test failed: open failed for modes map 4/c000/1 file.c:1929: Test failed: open failed for modes map 4/c000/4 file.c:1929: Test failed: open failed for modes map 4/c000/5 file.c:1929: Test failed: open failed for modes map 4/1/0 file.c:1929: Test failed: open failed for modes map 4/1/1 file.c:1929: Test failed: open failed for modes map 4/1/4 file.c:1929: Test failed: open failed for modes map 4/1/5 file.c:1929: Test failed: open failed for modes map 4/8001/0 file.c:1929: Test failed: open failed for modes map 4/8001/1 file.c:1929: Test failed: open failed for modes map 4/8001/4 file.c:1929: Test failed: open failed for modes map 4/8001/5 file.c:1929: Test failed: open failed for modes map 4/4001/0 file.c:1929: Test failed: open failed for modes map 4/4001/1 file.c:1929: Test failed: open failed for modes map 4/4001/4 file.c:1929: Test failed: open failed for modes map 4/4001/5 file.c:1929: Test failed: open failed for modes map 4/c001/0 file.c:1929: Test failed: open failed for modes map 4/c001/1 file.c:1929: Test failed: open failed for modes map 4/c001/4 file.c:1929: Test failed: open failed for modes map 4/c001/5 === W2K8SE (32 bit file) === file.c:1929: Test failed: open failed for modes map 4/0/0 file.c:1929: Test failed: open failed for modes map 4/0/1 file.c:1929: Test failed: open failed for modes map 4/0/4 file.c:1929: Test failed: open failed for modes map 4/0/5 file.c:1929: Test failed: open failed for modes map 4/8000/0 file.c:1929: Test failed: open failed for modes map 4/8000/1 file.c:1929: Test failed: open failed for modes map 4/8000/4 file.c:1929: Test failed: open failed for modes map 4/8000/5 file.c:1929: Test failed:
Apologies to the List
First, my tirade was not intended to be as such. I wanted to pull the patch because it was incorrect and I did not want anyone else working on it while I silently trimmed it and made it better. Second, I realize this has affected my 'Jeremy White' score. I hope that AJ understands why the code was pulled and that this happens frequently with a project this large. I am aware that the code was placed into the LGPL at the time it was posted to Wine Patches. Third, I will be posting here three patches for riched20/test/editor.c. It is my desire that these patches be examined, with a critical eye and feedback applied. Be brutal, be blunt and most of all be helpful. If I write back that I don't understand what you are talking about, I really don't and may need additional guidance (examples, pointing out other code with a similar purpose.) This is how we grow and learn. Very respectfully, James McKenzie
RFC: Patch to change what sets the is_win9x in riched20/tests
All: Upon examining other test code that creates a variable called is_win9x, I realized that using get_version and comparing it to a fixed value may not be best for the riched20 tests and have attached a proposed change to how this variable is set. It uses a called function, lstrcmpW and if it does not exist, the variable is set to a false value. This change has been tested on the testbot for Windows95/98/98SE/2K/2K3/XP/XP_64/Vista/Vista64/Win7/Win7_64 and no discrepancies were found. Comments on this patch are appreciated. I would like to submit this for inclusion into the Wine code base on Friday. James McKenzie From b9d828c5cbbcfc53bdb04afad8aca27bbfea1f11 Mon Sep 17 00:00:00 2001 From: James McKenzie jjmckenzi...@earthlink.net Date: Fri, 18 Feb 2011 19:49:51 -0700 Subject: richedit/test. Modify is_win9x determination to use actual called UNICODE function vice testing get_version. --- dlls/riched20/tests/editor.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/dlls/riched20/tests/editor.c b/dlls/riched20/tests/editor.c index a91d984..2dab92b 100644 --- a/dlls/riched20/tests/editor.c +++ b/dlls/riched20/tests/editor.c @@ -7101,7 +7101,8 @@ START_TEST( editor ) hmoduleRichEdit = LoadLibrary(RICHED20.DLL); ok(hmoduleRichEdit != NULL, error: %d\n, (int) GetLastError()); - is_win9x = GetVersion() 0x8000; + ret = lstrcmpW(NULL, NULL); + is_win9x = !ret GetLastError() == ERROR_CALL_NOT_IMPLEMENTED; test_WM_CHAR(); test_EM_FINDTEXT(); -- 1.7.3.5
Re: RFC: Patch to change what sets the is_win9x in riched20/tests
On 02/22/2011 01:21 AM, James McKenzie wrote: All: Upon examining other test code that creates a variable called is_win9x, I realized that using get_version and comparing it to a fixed value may not be best for the riched20 tests and have attached a proposed change to how this variable is set. It uses a called function, lstrcmpW and if it does not exist, the variable is set to a false value. This change has been tested on the testbot for Windows95/98/98SE/2K/2K3/XP/XP_64/Vista/Vista64/Win7/Win7_64 and no discrepancies were found. Win9x tests are no longer run with winetest. I also see that Austin sent some 9x cleanup patches. That said, I think the best way is to get rid of all the win9x 'hacks' in editor.c and rely on the fact that we have NT4+. -- Cheers, Paul.
