wine-devel January 2008

wine-devel@winehq.org

126 participants
290 discussions

Re: [WineHQ][WWN] WWN 340
by Dmitry Timoshkov 22 Jan '08

22 Jan '08

"Zachary Goldberg" <zgs(a)seas.upenn.edu> wrote: > +<section > + title="Theming WINE" > + subject="WINE" Could you please use a commonly accepted capitalization of the project name - Wine? -- Dmitry.

1 0

Re: WineD3D: don't use texture_rectangle for paletted textures
by Stefan Dösinger 22 Jan '08

22 Jan '08

Am Montag, 21. Januar 2008 22:33:17 schrieb Roderick Colenbrander: > Hi, > > Don't use ARB_texture_rectangle in combination with EXT_paletted_texture. > This should get StarCraft running again on Geforce1-FX cards in case of > DirectDrawRenderer opengl with RenderTargetLockMode readtex. (bug 10697) You'll have to modify IWineD3DDeviceImpl_CreateTexture as well

1 0

Re: Fix detection error in configure.ac
by Alexandre Julliard 22 Jan '08

22 Jan '08

Thomas Zimmermann <kuhundbaer(a)web.de> writes: > this patch fixes a detection error in configure.ac. > > 'Xrandr' and 'Xinerama' detection fails if GCC is set to Ansi mode. > The reason is the use of 'typeof' in the test. GCC does not support > this keyword when it is in Ansi mode. The patch solves that problem by > using __typeof__ instead. I tested the patch on my machine. Since the corresponding code won't build either, it's actually a feature that the configure check fails. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: gdi32: Make GetICMProfile behave more like native. Rewrite ansi version as a wrapper and move color management functions to their own file.
by Detlef Riekenberg 22 Jan '08

22 Jan '08

On Mo, 2008-01-21 at 16:33 +0100, Hans Leidekker wrote: - gdi32: Make GetICMProfile behave more like native. Rewrite ansi version as a wrapper and move color management functions to their own file. The large subject is an indicator, that the Patch can be splitted. IMHO, moving the stubs to a different file can be a seperate patch. > +BOOL WINAPI GetICMProfileA(HDC hdc, LPDWORD size, LPSTR filename) > + if (!hdc || !size || !filename) return FALSE; This is not the same as documented in MSDN, and > +BOOL WINAPI GetICMProfileW(HDC hdc, LPDWORD size, LPWSTR filename) > + > + if (!hdc || !size) return FALSE; ANSI and UNICODE are different. Are you really sure? (Please insert a big warning in the comment then) Returning FALSE without a SetLastError() looks not correct, compared to SetLastError(ERROR_INSUFFICIENT_BUFFER) below. Sorry, i'm unable to test your code now. I try to do it tomorrow. -- By by ... Detlef

3 2

Re: Fix for LoadStringW
by Dmitry Timoshkov 22 Jan '08

22 Jan '08

"Christopher" <raccoonone(a)procyongames.com> wrote: > @@ -363,10 +363,14 @@ INT WINAPI LoadStringW( HINSTANCE instance, UINT resource_id, > WCHAR *p; > int string_num; > int i; > + int strlen; strlen is not the best variable name. > TRACE("instance = %p, id = %04x, buffer = %p, length = %d\n", > instance, resource_id, buffer, buflen); > > + if (buffer == NULL) > + return 0; Please add a check whether last error value should be set as well. Also this fix breaks other places in Wine which rely on previous behaviour (I repeat it the 3rd time already). > + /* Copy the resource since it is not '\0' terminated, and add '\0' to the end */ > + if(resourcepointer != NULL) > + { > + memcpy(copiedstring, resourcepointer, strlen * sizeof(WCHAR)); > + copiedstring[strlen] = '\0'; > + } Again, if () above is not needed. But ok(resourcepointer != NULL) is (right after appropriate LoadStringW call). -- Dmitry.

1 0

Re: gdi32: Add tests for GetICMProfile and SetICMMode.
by Detlef Riekenberg 22 Jan '08

22 Jan '08

On Mo, 2008-01-21 at 16:33 +0100, Hans Leidekker wrote: > > +static void test_GetICMProfileA( HDC dc ) Please check GetLastError() as much as possible (Add comments, when GetLastError() does not return something usable > + size = MAX_PATH; > + ret = GetICMProfileA( dc, &size, NULL ); > + ok( !ret, "GetICMProfileA succeeded\n" ); This is different from GetICMProfileW and MSDN. Please add a comment. > + size = 0; > + SetLastError(0xdeadbeef); > + ret = GetICMProfileA( dc, &size, filename ); > + error = GetLastError(); > + ok( !ret, "GetICMProfileA succeeded\n" ); > + ok( size, "expected size > 0\n" ); > + ok( error == ERROR_INSUFFICIENT_BUFFER, "got %d, expected > ERROR_INSUFFICIENT_BUFFER\n", error ); what are the advantages compared to one test for all? ok ( !ret && (GetLastError() == ERROR_INSUFFICIENT_BUFFER) && (size > 0), "got %u with %u and size %d (expected '0' with " "ERROR_INSUFFICIENT_BUFFER and '> 0'\n", ret, GetLastError(), size); > + size = MAX_PATH; > + ret = GetICMProfileA( dc, &size, filename ); > + ok( ret, "GetICMProfileA failed %d\n", GetLastError() ); Does the size include the terminating '\0'? what about tests with: size == needed_size -1 size == needed_size size == needed_size +1 I'm unable to test your Patch now. will try to do it tomorrow. -- By by ... Detlef

2 1

Testing on Windows for conformance
by Darragh Bailey 21 Jan '08

21 Jan '08

Wondering what flavour of Windows XP people would recommend for testing on? Is there any benefit to getting Professional over the Home edition? Or does Home have everything that is needed to be capable of developing and testing conformance tests? -- Darragh "Nothing is foolproof to a sufficiently talented fool."

2 1

Shared IDL Imports
by Robert Shearman 21 Jan '08

21 Jan '08

Hi all, I've got a patch pending in my tree that adds another IDL file in include/wine/ but it has a dependency on another new IDL file in the same directory. The trouble is that the patch in the import statement gets lost in the generated IDL file. The attached diff shows an example of this, which gives the following error: ~/Documents/wine/dlls/ole32 rob$ make ../../tools/widl/widl -I. -I. -I../../include -I../../include -D__WINESRC__ -D_OLE32_ -DCOM_NO_WINDOWS_H -h -H irot.h irot.idl gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_OLE32_ -DCOM_NO_WINDOWS_H -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 -o moniker.o moniker.c In file included from moniker.c:48: irot.h:11:18: error: test.h: No such file or directory I see an number of options for fixing this, but they all have problems: Solution 1: Fix the generation of include statements in header files generated from the IDL to include the path. This has the issue that it is not compatible with MIDL, so testing our IDL files with it becomes difficult (MIDL appears to only search in the current directory when it encounters an import statement with a path). Solution 2: Include the dependent IDL file instead of importing it. This has the issue that the include needs to be guarded so that the definitions don't get declared if the dependent IDL file's header is imported before or after the first IDL file's header. This also has the trouble that it isn't compatible with MIDL as the guards are different between MIDL and widl. Solution 3: Put the IDL files in another directory (e.g. include/idl) and add that to the -I statement in CFLAGS and not using a path in the import statment in the first IDL file. This has the issue of having to change the name of the IDL file in the DLL or program directory to avoid an infinite recursion of includes. Which of these is the best solution or is there another solution? Thanks, -- Rob Shearman diff --git a/include/wine/irot.idl b/include/wine/irot.idl index 54d8653..927ee13 100644 --- a/include/wine/irot.idl +++ b/include/wine/irot.idl @@ -16,6 +16,7 @@ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA */ +import "wine/test.idl"; import "wtypes.idl"; cpp_quote("#define IROT_PROTSEQ {'n','c','a','l','r','p','c',0}") diff --git a/include/wine/test.idl b/include/wine/test.idl new file mode 100644 index 0000000..e69de29

2 1

Re: mscoree: Stub for LoadStringRCEx and LoadStringRC
by Dmitry Timoshkov 21 Jan '08

21 Jan '08

"Paul Chitescu" <paulc(a)voip.null.ro> wrote: > +HRESULT WINAPI LoadStringRCEx(LCID culture, UINT resId, LPWSTR pBuffer, int iBufLen, int bQuiet, int* pBufLen) > +{ > + HRESULT res = S_OK; > + if ((iBufLen <= 0) || !pBuffer) > + return E_INVALIDARG; > + pBuffer[0] = 0; > + if (resId) { > + WARN("(%d, %x, %p, %d, %d, %p): semi-stub\n", culture, resId, pBuffer, iBufLen, bQuiet, pBufLen); This should be a FIXME not a WARN. > + res = ERROR_CALL_NOT_IMPLEMENTED; > + } > + else > + res = E_FAIL; You are mixing OLE error codes with ERROR_xxx ones, this doesn't look right. -- Dmitry.

1 0

Re: Fix makedep to work on windows again
by Dmitry Timoshkov 21 Jan '08

21 Jan '08

"Steven Edwards" <winehacker(a)gmail.com> wrote: > Make on mingw does not like mixed line endings. Don't do it, ever. > diffed from a cvs checkout > as MSYS git is slower than molasses flowing uphill on a Minnesota winter day. > > Changelog: open makedep in binary mode when writing or appending, move > the EOF marker I guess that you just use the sources fetched in Linux? Don't do that, get the source via cvs under Windows instead, in that case you don't get mixed line endings. Or alternatively convert LF to CRLF before building. -- Dmitry.

2 5

← Newer
1
...
7
8
9
10
11
12
13
...
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 January 2008