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

[patch review] add gl_vertex_program_point_size to state_pscale
by Erik Inge Bolsø 12 Mar '09

12 Mar '09

Hello! I'd like a review of this patch - does the approach look reasonable? (Not my code, but it fixes a bug I reported.) "The fires and smoke aren't fading, they're just not being sized properly. The game uses point sprites for these effects. No matter what distance, the pointsize is being set to 1." It fixes http://bugs.winehq.org/show_bug.cgi?id=8826 - I'm not sure if it breaks other apps yet. Patch from Cody Hamilton <codyh(a)ctzns.net> : *** state.c --- dlls/wined3d/state.c 2009-03-05 00:42:57.000000000 +1100 *************** *** 1448,1453 **** --- 1448,1461 ---- att[1] = B.f / scaleFactor; att[2] = C.f / scaleFactor; } + + if(stateblock->wineD3DDevice->shader_backend == &glsl_shader_backend) { + glEnable(GL_VERTEX_PROGRAM_POINT_SIZE); + checkGLcall("glEnable(GL_VERTEX_PROGRAM_POINT_SIZE)"); + } else { + glDisable(GL_VERTEX_PROGRAM_POINT_SIZE); + checkGLcall("glDisable(GL_VERTEX_PROGRAM_POINT_SIZE)"); + } if(GL_SUPPORT(ARB_POINT_PARAMETERS)) { GL_EXTCALL(glPointParameterfvARB)(GL_POINT_DISTANCE_ATTENUATION_ARB, att); -- -erik http://useofwords.blogspot.com/

2 1

Re: [5/6] wined3d: Get rid of some calls to getFormatDescEntry().
by Stefan Dösinger 12 Mar '09

12 Mar '09

Am Donnerstag, 12. März 2009 09:57:18 schrieb Henri Verbeet: I think these patches are a really good idea(4 and 5 specifically)! Once all the getFormatDescEntry() calls are gone from the rendering loop functions we can take out the search hack for the RGB formats in getFormatDescEntry()

1 0

Re: mshtml: Change long to LONG in mshtml.idl (HTML*Element stuff).
by Michael Stefaniuc 12 Mar '09

12 Mar '09

Alistair Leslie-Hughes wrote: > In Microsoft mshtml.idl "IHTMLElement.sourceIndex" has the long type, not LONG. LONG is typedef'ed to long in IDL. > Whats the reason for the change? long is always 32bit in IDL files but long is a 64bit integer on non-Windows 64bit OSes. Thus widl has to be fixed to output a 32bit integer for long when generating the C files. The widl fix itself is probably small but the "collateral damage" in the rest of the Wine code is one big patch with a 4 digit changed lines figure. This are preparation patches to make the final widl patch be a lot smaller. bye michael

1 0

Taking a break from Wine
by Dan Kegel 12 Mar '09

12 Mar '09

Every now and then, my wrists force me to take a break from Wine development. This time it's also a matter of focus; I would like to spend more time with my family while also focussing more on my day job. One of the three had to go, for a while at least. I will still try to update winetricks once a month, but it might be good if other folks volunteered to help out there; drop me a line if you're interested. Likewise, it would be good if someone else took on running patchwatcher. (Shame, I have these nice boxes here, just waiting to run it, and no time to do it.) I'd be happy to answer questions from anyone who wants to give it a shot. I may also still give talks about Wine here and there, if a good venue presents itself. Ta for now! - Dan

4 4

Re: Wiki challenge question on user account creation
by King InuYasha 11 Mar '09

11 Mar '09

Oops... ---------- Forwarded message ---------- From: King InuYasha <ngompa13(a)gmail.com> Date: Thu, Mar 5, 2009 at 4:34 AM Subject: Re: Wiki challenge question on user account creation To: Dmitry Timoshkov <dmitry(a)codeweavers.com> On Thu, Mar 5, 2009 at 12:07 AM, Dmitry Timoshkov <dmitry(a)codeweavers.com>wrote: > "Dimi Paun" <dimi(a)lattica.com> wrote: > > On Wed, 2009-03-04 at 11:59 -0600, John Klehm wrote: >> >>> I wouldn't really want per save captcha either, per account creation >>> is what I was hoping would cut down the spam. If the accounts are >>> created manually not much we can do about it :( >>> >> >> I think that's the case. Which is why I think it's not worth doing, >> as we would just make it harder on most real users, while not detracting >> any of the spammers. >> > > Actually if there are a lot of user account creation every day in the Wine > wiki then there is something wrong with it. There are not that much Wine > developers and probably some active testers/appdb maintainers, who else > could pretend to have a user account in the Wine wiki? > > Moreover it will add additional maintenance >> burden on our part to keep the captchas operational. >> > > Isn't that an one time effort? > > -- > Dmitry. > > > A wiki shouldn't have users creating accounts every day, that is a bad indicator. Also, in theory, CAPTCHA code does only need a one-time effort, but most wikis do not implement the best way to do CAPTCHA, so unless Wine was to use ReCAPTCHA, they would need to make sure that the CAPTCHA made is confusing enough that a computer cannot read it, which means mixing colors, strike lines, shapes, etc. It doesn't help that WineHQ uses MoinMoin wiki, which afaik does not have a CAPTCHA extension available. Also, it's quite obvious that the Moin engine on WineHQ is modified, so even if there was one, it may not work, depending on the intensity of the changes to the engine.

3 7

Re: [ntdll] lookup_assembly function should returns STATUS_SUCCESS
by André Hentschel 11 Mar '09

11 Mar '09

STATUS_SUCCESS is 0x0, see http://source.winehq.org/source/include/ntstatus.h#L30

1 0

Re: [ntdll] Care about empty fields of assembly_identity structure in actctx.c
by Jacek Caban 11 Mar '09

11 Mar '09

Hi Roman, > On parsing of manifest in PE module is possible access to zero address > and crash. It's happens because not all manifest attributes can be > specified and pointers in assembly_identity structure can be > uninitialized. This patch adds function for setting empty strings in > structure elements when they not initialized. Your patch looks like a workaround. You should fix the code to cope with NULL pointers correctly instead of allocating useless empty strings. Also initialize_assembly_identity doesn't make sense. ai is initialized a few lines later by memset call. Jacek

3 7

Re: shlwapi: Correct AssocCreate and tests (try 2)
by Jacek Caban 11 Mar '09

11 Mar '09

Hi Alistair, Alistair Leslie-Hughes wrote: > Hi, > Added check for IUnknown, thanks Jacek. It would be better to return correct error on QueryInterface failure. Otherwise you're duplicating the code. Jacek

1 0

Re: [PATCH] 0001-Fixed-tests-in-dlls-ws2_32-tests-sock.c-for-simple_s.patch
by Juan Lang 11 Mar '09

11 Mar '09

Hi Andrew, diff --git a/dlls/dbghelp/type.c b/dlls/dbghelp/type.c index 947eb49..4e426e2 100644 --- a/dlls/dbghelp/type.c +++ b/dlls/dbghelp/type.c It seems rather unlikely that dbghelp is causing failures in the winsock tests. Perhaps dbghelp is getting invoked due to a crash? Besides, - sym_info->TypeIndex = (DWORD)type; + sym_info->TypeIndex = (DWORD_PTR)type; This doesn't appear correct. sym_info is a SYMBOL_INFO *, and SYMBOL_INFO.TypeIndex is declared as ULONG. The fix is likely to require storing an index into a table rather than a pointer in TypeIndex, since type (a struct symt **) won't fit in a ULONG. - tifp->ChildId[i] = (DWORD)*pt; + tifp->ChildId[i] = (DWORD_PTR)*pt; Same here. - WS(u_long) S_addr; + ULONG S_addr; (snip) -#define FIONBIO _IOW('f', 126, u_long) +#define FIONBIO _IOW('f', 126, ULONG) These casts are fishy. Why are ULONG and u_long (WS_u_long) different sizes? If they are, the includes are broken somehow, as there's simply no need for S_addr to be anything but 32 bits. --Juan

1 0

LookupAccountSidW returns "unexpected" username
by Andreas Rosenberg 11 Mar '09

11 Mar '09

While I did some experimenting with the proposals from Vitaliy Margolen to get an accepted patch for GetUserProfileDirectoryW, I found this behavior: OpenProcessToken(hProcess,TOKEN_QUERY,&hToken); ... GetTokenInformation( hToken, TokenUser, ptiUser, cbti, &cbti ) ... LookupAccountSidW( NULL, ptiUser->User.Sid, lpUserName, lpchSize,lpDomain, &cbDomain, &snu ); In Windows XP SP3 the LookupAccountSidW fills lpUserName with the name of the current user (same as GetUserName) Running this code in Wine results in the username: 'INTERACTIVE'. Seems like the LookupAccountSidW does something not compatible with Windows. Im thinking about writing a test code, but simply checking if the above code returns the same as GetUserNameW seems not correct, if test code should run under a different account as the actual login user. Is this a requirement for running the wine tests?

2 1