July 2009 - Wine-Devel - list.winehq.org

MaxVertexBlendMatrices issue
by Karl Vogel July 11, 2009

July 11, 2009

Just tracked down a crash in the game Dark Age of Camelot (daoc) when pixelshaders are enabled. The game issues a GetDeviceCaps() and then checks if MaxVertexBlendMatrices >= 4, which on wine is set to zero on my videocard (Geforce 6800), whereas a windows box returns 4. I found this old post concerning MaxVertexBlendMatrices causing issues in another game (EQ): http://www.winehq.org/pipermail/wine-devel/2008-February/062432.html http://www.winehq.org/pipermail/wine-devel/2008-February/062437.html So I was wondering what the proper way to fix this would be? Should this be made overrideable by a registry setting for certain games? Or should the GL check be changed? Or is that software emulated vertex blending patch needed to correctly fix the issue? Bugzilla has 3 other games where the simple 'fix' of returning 4 makes the game work (Warhammer, EQ, Shin Megami Tensei Online): http://bugs.winehq.org/buglist.cgi?quicksearch=MaxVertexBlendMatrices -- For reference the daoc bug is http://bugs.winehq.org/show_bug.cgi?id=10832

1 0

GSoC mid-term evaluations due
by Kai Blin July 11, 2009

July 11, 2009

Hi GSoC students and mentors, Just a little reminder that you need to fill out your GSoC surveys by monday. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

1 0

[2/2] msxml3: Register Missing Components
by Lady Bug July 11, 2009

July 11, 2009

2 1

Re: [1/2](resend)advapi: break the core of LookupAccountNameW out into helper functions.
by Juan Lang July 10, 2009

July 10, 2009

Hi Aric, it strikes me that this could be broken up a bit further. This'd make it rather easier to review. For example, --- a/dlls/advapi32/advapi32_misc.h +++ b/dlls/advapi32/advapi32_misc.h @@ -24,4 +24,15 @@ const char * debugstr_sid(PSID sid); BOOL ADVAPI_IsLocalComputer(LPCWSTR ServerName); BOOL ADVAPI_GetComputerSid(PSID sid); +BOOL lookup_local_wellknown_name(LPCWSTR lpAccountName, DWORD ccAccountName, + PSID Sid, LPDWORD cbSid, + LPWSTR ReferencedDomainName, + LPDWORD cchReferencedDomainName, + PSID_NAME_USE peUse, BOOL *ret); +BOOL lookup_local_user_name(LPCWSTR lpAccountName, DWORD ccAccountName, + PSID Sid, LPDWORD cbSid, + LPWSTR ReferencedDomainName, + LPDWORD cchReferencedDomainName, + PSID_NAME_USE peUse, BOOL *ret); In the initial patch, these aren't referenced outside of security.c, so leaving them static there would make the changes smaller. A subsequent patch that does reference them from lsa.c could make them non-static. +static inline WCHAR *strnrchrW(const WCHAR *str, WCHAR ch, DWORD *len) It's not clear to me what this function does from its name, and you didn't document it. There's no corresponding strnrchr libc function, so that doesn't help either. It appears from reading it that you made a function like strrchrW that returns the location of the found ch in str, like strrchrW does, but also sets *len to the position at which it's found? If that's correct, you could accomplish the same thing by calling strrchrW and doing pointer arithmetic with its return value. These suggestions notwithstanding, it seems like introducing this helper function is one change, and deserving of its own patch. + +/* + * Helper function for LookupAccountNameW and LookupNames2 in lsa.c The second part of that comment, that it's a helper for LookupNames2, isn't correct in this first patch. It becomes true later, but the comment should be changed then, not in the first patch. (Minor nit: mentioning the file LookupNames2 is in seems superfluous.) + * returns TRUE if the AccountName is handled (even if with an error). + * returns FALSE if not. + */ + +BOOL lookup_local_wellknown_name(LPCWSTR lpAccountName, DWORD ccAccountName, + PSID Sid, LPDWORD cbSid, + LPWSTR ReferencedDomainName, + LPDWORD cchReferencedDomainName, + PSID_NAME_USE peUse, BOOL *ret) The use of two BOOLs is confusing to me. For one thing, it makes the patch larger: - ret = CreateWellKnownSid(ACCOUNT_SIDS[i].type, NULL, pSid, &sidLen); + *ret = CreateWellKnownSid(ACCOUNT_SIDS[i].type, NULL, pSid, &sidLen); This change could be avoided if you returned the old meaning of ret, and used the BOOL * parameter to indicate whether the AccountName is handled. Finally, I'd suggest that breaking out looking up well known names could be separate from breaking out looking up local names. Hope that helps, --Juan

1 0

Re: winemine: Add ellipses for menu entries that open new dialog windows (DE)
by Paul Vriens July 10, 2009

July 10, 2009

Detlef Riekenberg wrote: > There are more winemine translations without the ellipses. > Can the changes all in one Patch? > > There are non UTF8 - resources with special characters. > Should they change to UTF8 first? > > > > > ------------------------------------------------------------------------ > > Hi Detlef, There is patch in the queue that actually gets rid of some ellipses as there was a discussion about this on wine-devel. -- Cheers, Paul.

1 0

Warnings on the translation page
by Paul Vriens July 10, 2009

July 10, 2009

Hi, I found an anomaly on the translations page. Whenever the Makefile shows a generic rc file (last one added for RC_SRCS) the language before that shows warnings on the page. Example: http://source.winehq.org/transl/lang.php?lang=004%3A01 zh (Chinese (Traditional)) shows up most of the warning as the entries in the Makefile are sorted. Not sure yet, if this is an issue with wrc or transl. -- Cheers, Paul.

2 4

Wine very very slow in Chinese language of Linux
by axel_xia＠sohu.com July 10, 2009

July 10, 2009

Dear Madam / Sir, How are you? I am writing email to you for the issue probably caused by Chinese fonts. When using WINE in Chinese environment Linux, the WINE works very very slow even opening windows / clicking buttons.... I search the problem in google, found lots of users have same issue regardless Fedora or Ubuntu or other distributed Linux OS. Someone presented the resolution by changing Chinese fonts configuration because they think WINE is always searching suitable GKB font sets (which sometimes are not exisiting in Linux OS), someone said it was related to X11 (not compatiable or some linux OS not using X11)..., and others guess the issue related to other reason..... So, dear Madam / Sir, could you please help the WINE fans who are using Linux in Chinese environment to figure out this kind of issue? Or is that possible to put the fixed WINE into Yum or someother software database? Hopefully, the user of different distributed Linux can be of no issue when WINE M$ software in Chinese? Thanks and best regards! Yours sincerely, Axel

1 0

Re: wined3d: Fix some checkGLcalls.
by Henri Verbeet July 10, 2009

July 10, 2009

Most of those looked good enough to me to begin with, but I guess it doesn't hurt.

1 0

Re: Check if WINED3DRS_VERTEXBLEND is dirty in transform_world
by Henri Verbeet July 9, 2009

July 9, 2009

2009/7/5 Lisa Denia <eiffel56(a)gmail.com>: > This fixes the flickering cursor mentioned in Bug > #14375(http://bugs.winehq.org/show_bug.cgi?id=14375). > The cursor flickers because the scene gets rendered twice a draw, which is > known and expected. The cursor is not one of that usual animated 2d things, > but a 3d object. So, in every draw, the scene gets rendered, the cursor gets > rendered, and the scene gets rendered again. The attached patch checks for > that special case. > It's not entirely clear to me why this should work.

2 1

Re: kernel32/nls: Add Lithuanian winerr translation
by Paul Vriens July 9, 2009

July 9, 2009

Hi Aurimas, Congratulations !! -- Cheers, Paul.

2 1