March 2010 - Wine-devel - list.winehq.org

Fastcall calling convention
by Damjan Jovanovic 23 Mar '10

23 Mar '10

Hi Wine doesn't seem to support the fastcall calling convention: include/winternl.h: /* These are implemented as __fastcall, so we can't let Winelib apps link with them */ dlls/hal/hal.c: #ifdef __i386__ #define DEFINE_FASTCALL1_ENTRYPOINT( name ) \ __ASM_STDCALL_FUNC( name, 4, \ "popl %eax\n\t" \ "pushl %ecx\n\t" \ "pushl %eax\n\t" \ "jmp " __ASM_NAME("__regs_") #name __ASM_STDCALL(4)) GCC seems to support fastcall from version 3.4: http://www.ohse.de/uwe/articles/gcc-attributes.html Should we support it? Its absence makes kernel driver code a lot uglier (eg. irp->Tail.Overlay.s.u2.CurrentStackLocation instead of IoGetCurrentIrpStackLocation()). We also can't declare fastcall functions in header files, so some functions that are actually implemented are missing from header files and thus unusable from inside Wine. Thank you Damjan Jovanovic

2 2

Re: [PATCH 2/7] msvcr90: Added strnlen implementation (try2)
by Alexandre Julliard 23 Mar '10

23 Mar '10

Piotr Caban <piotr(a)codeweavers.com> writes: > diff --git a/dlls/msvcr80/msvcr80.spec b/dlls/msvcr80/msvcr80.spec > index ed283d9..cc900ca 100644 > --- a/dlls/msvcr80/msvcr80.spec > +++ b/dlls/msvcr80/msvcr80.spec > @@ -1389,7 +1389,7 @@ > @ cdecl strncmp(str str long) msvcrt.strncmp > @ cdecl strncpy(ptr str long) msvcrt.strncpy > @ stub strncpy_s > -@ stub strnlen > +@ cdecl strnlen(str long) msvcr90.strnlen > @ cdecl strpbrk(str str) msvcrt.strpbrk > @ cdecl strrchr(str long) msvcrt.strrchr > @ cdecl strspn(str str) msvcrt.strspn This should be added to msvcrt and forwarded to it. Same for the other functions like strtoi64 that exist in recent msvcrt. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: rpcrt4: Added stub function CreateStubFromTypeInfo
by Nikolay Sivov 23 Mar '10

23 Mar '10

On 3/22/2010 12:32, Alistair Leslie-Hughes wrote: > Hi, > > > Changelog: > rpcrt4: Added stub function CreateStubFromTypeInfo > > + typedef INT (WINAPI *MessageBoxA)(HWND,LPCSTR,LPCSTR,UINT); > + HMODULE hUser32 = LoadLibraryA("user32"); > + MessageBoxA pMessageBoxA = (void *)GetProcAddress(hUser32, "MessageBoxA"); > + > + FIXME("%p %s %p %p\n", pTypeInfo, debugstr_guid(riid), pUnkServer, ppStub); > + if (pMessageBoxA) > + { > + pMessageBoxA(NULL, > + "The native implementation of OLEAUT32.DLL cannot be used " > + "with Wine's RPCRT4.DLL. Remove OLEAUT32.DLL and try again.\n", > + "Wine: Unimplemented CreateProxyFromTypeInfo", > + 0x10); > + ExitProcess(1); > + } > + return E_NOTIMPL; > Displaying messagebox is a bit questionable, ExitProcess is even worse. If you mean here that native oleaut32 uses this call, a general FIXME is enough. If you really don't want to survive from such call you don't need this stub at all.

2 1

Re: shell32: remove unneeded parsing of SHELLEXECUTEINFO.lpFile [try 2]
by Ilya Basin 23 Mar '10

23 Mar '10

Hi! Sorry for being annoying, will you accept my patch? http://www.winehq.org/pipermail/wine-patches/2010-March/086009.html --

2 2

Re: [PATCH 5/6] msvcr90: Implement _encode_pointer and _decode_pointer
by Alexandre Julliard 23 Mar '10

23 Mar '10

Detlef Riekenberg <wine.dev(a)web.de> writes: > --- > dlls/msvcr90/msvcr90.c | 21 +++++++++++++++++++++ > dlls/msvcr90/msvcr90.spec | 4 ++-- > 2 files changed, 23 insertions(+), 2 deletions(-) This doesn't build on 64-bit Mingw because it comes with its own version of these functions. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: 4/4 wined3d: move color keyed blitting in its own function
by Henri Verbeet 22 Mar '10

22 Mar '10

On 22 March 2010 22:36, Roderick Colenbrander <thunderbird2k(a)gmail.com> wrote: > +static HRESULT surface_blt_color_keyed_surface_to_drawable(IWineD3DSurfaceImpl *This, const RECT *DestRect, IWineD3DSurfaceImpl *Src, const RECT *SrcRect, DWORD Flags, WINEDDCOLORKEY SrcColorkey) Calling the destination surface "This" isn't a sane naming convention. When you create a "new" function, try to make it at least somewhat sane and consistent, rather than just cutting and pasting something together.

1 0

[PATCH] dlls/msxml3: Using strlenW instead of SysStringLen to check node name length
by Eric Lanz 22 Mar '10

22 Mar '10

Hello, Decided to keep it simple for my first patch. SysStringLen was returning 0 for bstrs from our updater application which caused the domdoc_createNode function to exit early even though the bstr actually contained a valid name. It seems that other functions in this file use strlenW for this purpose which seems to always return the correct length. Eric

2 2

Re : shell32: Add IShellFolderView:: GetSelectedObjects implementation for IShellView.
by Juan Lang 22 Mar '10

22 Mar '10

Hi Nikolay, I know this one's already been comitted, but I have a small complaint about a comment: + /* it's documented that caller shouldn't PIDLs, only array itself */ I think you're missing a verb there. A caller shouldn't do what to PIDLs, exactly? Perhaps it should be obvious to me, but I couldn't guess by looking at it. Thanks, --Juan

2 1

Re: [PATCH 1/7] msvcr90: Added _encode_pointer and _decode_pointer tests
by Paul Vriens 22 Mar '10

22 Mar '10

On 03/22/2010 05:01 PM, Piotr Caban wrote: > + if(!p_encode_pointer || !p_decode_pointer) { > + skip("_encode_pointer or _decode_pointer not found\n"); > + return; > + } win_skip() is more appropriate as these are implemented on Wine. -- Cheers, Paul.

1 0

Warnings on ignored returned values
by Octavian Voicu 22 Mar '10

22 Mar '10

Hello, I'm trying to compile wine with --enable-maintainer-mode and I get lots of errors like `ignoring return value of ‘xxx’, declared with attribute warn_unused_result'. I would like to submit a few patches to fix them. I noticed there's a page on the wiki for this: http://wiki.winehq.org/IgnoredReturnValues On the other hand, there are no indications on the policy of handling them. Sometimes we just don't care about the return value, but I haven't found a way to tell this to the compiler other than actually using the return value. In other cases, errors might be relevant. For example, for the code: if (newdir) chdir(newdir); would the following be an acceptable fix? if (newdir) if (chdir(newdir) == -1) /* ignore error */ ; Should I use WARNs to print the error, in cases where it might be relevant? Thanks, Octavian

4 5