October 2012 - Wine-Devel - list.winehq.org

Re: Help getting amd64 assembly patch into wine?

by Dan Kegel

On Thu, Oct 4, 2012 at 1:52 PM, Kyle Auble <randomidman48(a)yahoo.com> wrote: > I'm just wondering is assembly definitely needed? > This is just based on some googling and skimming > through StackOverflow, but it sounds like you can > still use va_list on amd64. It just takes some > tweaking: > http://stackoverflow.com/questions/8047362 Thanks for the reply. Maarten also replied via chat. For the first function, I might be able to get rid of assembly. It's complicated by the fact that Visual C uses a different varargs implementation. I did try using __ms_va_list to get gcc to behave like Visual C here, but failed. Maarten suggested I try __ms_va_list again, if that works, I can collapse the first two functions together into a single C function, which would be great. He also pointed out that I might be abusing DWORD for pointers. I'll have a look at his suggestions and send him a new draft for private review. - Dan

Oct. 4, 2012

Re: Help getting amd64 assembly patch into wine?

by Kyle Auble

On 10/03/2012 09:49 PM, Dan Kegel wrote: > The main challenge was figuring out how to get the variable > list of arguments off the stack, and then put them back onto > the stack when calling the provided function pointer. > This bit of varargs hackery can't be done in pure C as far as I > can tell, so I used assembly. > I started programming in machine language long ago, > so getting that working wasn't too hard once I > realized that's what was needed. Getting it to pass the > Alexandre test is another matter. > Alexandre did give feedback on one earlier iteration of > the patch, telling me I was re-inventing the wheel, so I > tossed my old assembly and copied the helper-calling code > nearly verbatim from call_method in oleaut32/typelib.c I haven't studied assembly in a while, and I've never looked at this part of Wine before, but every once in a while, a silly question from a novice doesn't hurt. I'm just wondering is assembly definitely needed? This is just based on some googling and skimming through StackOverflow, but it sounds like you can still use va_list on amd64. It just takes some tweaking: http://stackoverflow.com/questions/8047362 One method involves a "va_copy" macro, but that may only apply to C99 or later: https://forums.oracle.com/forums/message.jspa?messageID=8536520 The other solution mentioned just involves wrapping va_list inside a struct, as mentioned in the top answer of the first link. I don't know if that helps or if I'm totally misunderstanding the problem. - Kyle

Oct. 4, 2012

Re: [PATCH 2/2] mshtml: Added ActiveX event binding test

by Jacek Caban

On 10/04/12 15:02, Marvin wrote: > 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=22013 > > Your paranoid android. Can someone please clear TestBot queue? Every time I send a series of two patches, it tries to test my previous series, which usually (like in this case) is already in Git. Jacek

Oct. 4, 2012

Re: [PATCH 2/2] mshtml: Added ActiveX event binding test

by Marvin

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=22013 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

Oct. 4, 2012

Re: [PATCH 5/5] winex11: Don't send SC_RESTORE when a maximized window switches to fullscreen.

by Dmitry Timoshkov

Henri Verbeet <hverbeet(a)codeweavers.com> wrote: > - if (style & WS_MAXIMIZE) > + if ((style & WS_MAXIMIZE) && (style & WS_CAPTION) == WS_CAPTION) Probably you should test for WS_MAXIMIZEBOX instead. -- Dmitry.

Oct. 4, 2012

Re: [PATCH 1/2] ntoskrnl.exe: Implement IoGetCurrentProcess and KeGetCurrentThread.

by Christian Costa

2012/10/4 Thomas Faber <thfabba(a)gmx.de> > On 2012-10-04 13:07, Christian Costa wrote: > > 2012/10/4 Paul Chitescu <paulc(a)voip.null.ro> > >> AFAIK the structure differs for each major version of Windows and some > SP > >> too. > >> > >> > > I was expecting something like this. :( > > > > > >> At the minimum I saw some drivers expecting that at the returned pointer > >> to be > >> a "System" C-style string. > >> > > > > Which windows version it is ? In Vista definition the first basic element > > can be either an UCHAR or an ULONG. Not a char buffer. > > What all versions have in common is that processes are dispatcher > objects. Thus the EPROCESS/KPROCESS structure starts with a > DISPATCHER_HEADER. > I known. And in DISPATCHER_HEADER, the first type can be either an UCHAR or an ULONG. That said I found why your patch works for you : > The process name offset can be founded form peprocess but you should write a simple code. > First of all call PsGetCurrentProcess() to achieve the address of peprocess of current process then search for the string "System" > in the increasing offsets form peprocess. If you find "System " string , the related offset is the name offset. Found at http://www.osronline.com/showthread.cfm?link=157240 So "system" should be elsewhere in the structure. Probably ImageFileName.

Oct. 4, 2012

Re: [PATCH 1/2] ntoskrnl.exe: Implement IoGetCurrentProcess and KeGetCurrentThread.

by Thomas Faber

On 2012-10-04 13:07, Christian Costa wrote: > 2012/10/4 Paul Chitescu <paulc(a)voip.null.ro> >> AFAIK the structure differs for each major version of Windows and some SP >> too. >> >> > I was expecting something like this. :( > > >> At the minimum I saw some drivers expecting that at the returned pointer >> to be >> a "System" C-style string. >> > > Which windows version it is ? In Vista definition the first basic element > can be either an UCHAR or an ULONG. Not a char buffer. What all versions have in common is that processes are dispatcher objects. Thus the EPROCESS/KPROCESS structure starts with a DISPATCHER_HEADER.

Oct. 4, 2012

Re: [PATCH 1/2] ntoskrnl.exe: Implement IoGetCurrentProcess and KeGetCurrentThread.

by Christian Costa

2012/10/4 Paul Chitescu <paulc(a)voip.null.ro> > On Thursday 04 October 2012 08:25:13 am Dmitry Timoshkov wrote: > > Christian Costa <titan.costa(a)gmail.com> wrote: > > > PEPROCESS WINAPI IoGetCurrentProcess(void) > > > { > > > - FIXME("() stub\n"); > > > - return NULL; > > > + TRACE("()\n"); > > > + > > > + /* Return current process id since PEPROCESS is opaque and drivers > > > should not access the struct directly */ + return > > > (PEPROCESS)PsGetCurrentProcessId(); > > > } > > > > The returned pointer is supposed to be passed to various other ntoskrnl > > APIs, and it's needs to be a valid pointer to the kernel object. Besides > > many not trivial kernel drivers (if not all) really dig into internal > > kernel structures. > > > > Same for KeGetCurrentThread. > > AFAIK the structure differs for each major version of Windows and some SP > too. > > I was expecting something like this. :( > At the minimum I saw some drivers expecting that at the returned pointer > to be > a "System" C-style string. > Which windows version it is ? In Vista definition the first basic element can be either an UCHAR or an ULONG. Not a char buffer. > > I tried submitting a patch before but was not accepted. > >

Oct. 4, 2012

Re: [PATCH] reg.exe: comparing the names of registry keys

by Jacek Caban

On 10/04/12 08:03, Mieczyslaw Nalewaj wrote: > +static BOOL strings_equal(LPWSTR lpString1, const WCHAR *lpString2) > +{ > + int cchCount; Please avoid Hungarian style variable names. Also is seems like the function not exactly compares strings, so something like is_subkey could be more appropriate function name. > + if ((!lpString1 || !*lpString1) && (!lpString2 || !*lpString2)) /* both empty */ > + return TRUE; > + if ( !lpString1 || !*lpString1 || !lpString2 || !*lpString2 ) /* one empty */ > + return FALSE; How about simplifying it to: if(!str1 || !*str1) return !str2 || !*str2; if(!str2 || !*str2) return FALSE; > + cchCount = strlenW(lpString2); > + if (strlenW(lpString1)<cchCount) /* too short */ > + return FALSE; > + > + if ( (CompareStringW(CP_ACP,NORM_IGNORECASE,lpString1,cchCount,lpString2,cchCount)==CSTR_EQUAL) > + && ((lpString1[cchCount] == 0) || (lpString1[cchCount] == (WCHAR){'\\'}))) > + return TRUE; > + else > + return FALSE; This could be simplified: len = strlenW(str2); return !strncmpiW(str1, str2, len) && (!str1[len] || str1[len] == '\\'); Cheers, Jacek

Oct. 4, 2012

Re: [PATCH 1/2] ntoskrnl.exe: Implement IoGetCurrentProcess and KeGetCurrentThread.

by Paul Chitescu

On Thursday 04 October 2012 08:25:13 am Dmitry Timoshkov wrote: > Christian Costa <titan.costa(a)gmail.com> wrote: > > PEPROCESS WINAPI IoGetCurrentProcess(void) > > { > > - FIXME("() stub\n"); > > - return NULL; > > + TRACE("()\n"); > > + > > + /* Return current process id since PEPROCESS is opaque and drivers > > should not access the struct directly */ + return > > (PEPROCESS)PsGetCurrentProcessId(); > > } > > The returned pointer is supposed to be passed to various other ntoskrnl > APIs, and it's needs to be a valid pointer to the kernel object. Besides > many not trivial kernel drivers (if not all) really dig into internal > kernel structures. > > Same for KeGetCurrentThread. AFAIK the structure differs for each major version of Windows and some SP too. At the minimum I saw some drivers expecting that at the returned pointer to be a "System" C-style string. I tried submitting a patch before but was not accepted.

Oct. 4, 2012