August 2004 - Wine-Devel - list.winehq.org

Re: list view completely mangled in WINE

by Filip Navara

Dan Kegel wrote: > Hi Filip, > if you're looking for testcases, could you try the demo programs in > http://bugs.winehq.org/show_bug.cgi?id=1268 and Sort of works. All the items are displayed, but when I switch to "Large Icons" mode all the items are placed at the position 0,0 above themselves. > http://bugs.winehq.org/show_bug.cgi?id=1404 This one works now. The spacing between the items isn't equal to the one with native COMCTL32, but the items are displayed. Regards, Filip

Aug. 6, 2004

Problem with ITypeInfo

by jack

Hi. I've tryed to run game Project Entropia and I got segmentation fault because of a bug in OLE. I've hacked code and I found two bugs: 1. ITypeInfo has back pointer to ITypeLib, but it's possible (and happened) that ITypeLib is destroyed and later ITypeInfo calls its function. I've solve this problem by call ITypeLib_AddRef while creating ITypeInfo (and ITypeLib_Release while destroying ITypeInfo). 2. ITypeInfo_Invoke doesn't support optional parameters. I've added support for cParamsOpt>0. MSDN says that optional parameter is when VARTYPE equals VT_EMPTY, but in my case it was a VT_BYREF | VT_VARIANT type but the pointer was NULL. When I treated it as VT_EMPTY, it was OK. I enclose my patch. My knownlage about OLE is sparse so I'm not able to test this. Thanks, Jacek

Aug. 6, 2004

Re: vc++ install requires NetUserModalsGet

by Saulius Krasuckas

On Sat, 31 Jul 2004, James Hawkins wrote: > Looking into netapi32/access.c, NetUserModalsGet is a stub and returns > NERR_InternalError by default. I think vcsetup is requiring this call > to succeed so it bails out because of the error. > > Reading the trace and the msdn docs about NetUserModalsGet, vcsetup is > calling with the level parameter == 2 so it is requesting the domain > name and identifier. > > With the included patch, I have stubbed the structure of the 4 levels > that can be queried, but I haven't written the code to handle them > yet. If anyone has any information or links that will enlighten me > about netapi32 or anything pertaining to this matter, I would greatly > appreciate it. I see [1] you've tried to implement the case of NetUserModalsGet() functionality where level == 2, also. Thanks, I need it, too. AFAIK it would suffice only to copy information pointed by the *PPOLICY_PRIMARY_DOMAIN_INFO struct to the *PUSER_MODALS_INFO_2 struct for that, while you have done something very complex IMHO: -NET_API_STATUS WINAPI NetUserModalsGet(LPCWSTR szServer, DWORD level, LPBYTE *pbuffer) +NET_API_STATUS WINAPI NetUserModalsGet(LPCWSTR server, DWORD level, LPBYTE *bufptr) + ... + PPOLICY_ACCOUNT_DOMAIN_INFO domainInfo; + PSID domainIdentifier; + ... + domainNameLen = lstrlenW(domainInfo->DomainName.Buffer) + 1; + ... + NetApiBufferAllocate(domainNameLen * sizeof(WCHAR) + sizeof(PSID), (LPVOID *)bufptr); + + umi = (USER_MODALS_INFO_2 *) *bufptr; + umi->usrmod2_domain_name = (LPWSTR) (*bufptr + sizeof(USER_MODALS_INFO_2)); + umi->usrmod2_domain_id = (PSID) ( + ((PBYTE) umi->usrmod2_domain_name) + domainNameLen * sizeof(WCHAR)); + + lstrcpynW(umi->usrmod2_domain_name, domainInfo->DomainName.Buffer, domainNameLen); + + CopySid(sizeof(umi->usrmod2_domain_id), + umi->usrmod2_domain_id, domainIdentifier); AFAICS: 1, there is big memory block allocated during the call to a NetApiBufferAllocate(). What for? Why just not use a size of a USER_MODALS_INFO_2 ? And yes, then you need to allocate the space twice more - for a string and for the new SID copy. 2, maybe you want to allocate all needed space using a single buffer? Then what does this size mean: "domainNameLen * sizeof(WCHAR) + sizeof(PSID)" ? 3, the domainIdentifier variable is left uninitialized. Does the patch work for you? I know, instead of asking I should sit down and just write some additional tests for the netapi32.dll. What I cannot decide myself here (after having read the MSDN docs) is the responsibility for freeing memory blocks, one allocated for the unicode string (usrmod2_domain_name) and another one to hold the copy of SID (usrmod2_domain_id). MSDN tells only to free the memory allocated for the buffer (pointed by the *bufptr). Every sample of C code on the net I've found which calls NetUserModalsGet() (and where the buffer contains some pointers by itself: USER_MODALS_INFO_1, USER_MODALS_INFO_2) isn't freeing those internal pointers: [2], [3], [4]. Does this mean the code (caller) leaks memory or it's just some automagic used on the system side (callee) to free the memory (on real Windows) later? > quote from MSDN: > "The NetUserModalsGet function retrieves global information for all > users and global groups in the security database, which is the > security accounts manager (SAM) database or, in the case of domain > controllers, the Active Directory." > > Does wine have a security accounts manager or an Active Directory? Good q. Will someone answer it, please? [1] http://www.winehq.org/hypermail/wine-patches/2004/08/0003.html [2] http://www.faqchest.com/msdn/ATL/atl-99/atl-9901/atl-990100/atl99012521_198… [3] http://66.102.11.104/search?q=cache:www.ntdev.org/archive/ntdev9807/msg0256… [4] http://66.102.11.104/search?q=cache:pintday.org/downloads/enum_tar.gz+NetUs…

Aug. 6, 2004

Re: vc++ install requires NetUserModalsGet

by Mike Hearn

Saulius Krasuckas wrote: >>Does wine have a security accounts manager or an Active Directory? > > > Good q. Will someone answer it, please? Wine does not implement any security APIs beyond the stubs needed for apps to work, it delegates security to the host system. Active Directory is not really in scope for Wine, that's more a Samba project, though we'll need to co-operate with them on it at some point (for instance COM can use Active Directory). thanks -mike

Aug. 6, 2004

Re: Different approach to a->w cleanup of crypt

by James Hawkins

On Fri, 6 Aug 2004 02:34:51 -0500, James Hawkins <truiken(a)gmail.com> wrote: > Hi, > > I have been trying to get my a->w cleanup of crypt committed for > quite some time now, and mostly with no luck because of all the bugs, > but I have a better idea about how accomplish this. The problem is > that crypt requires a lot of changes to get rid of the w->a calls (the > patch was ~27k), and it's too risky to commit the patch even though it > looks like all the bugs are gone. The solution is that I will change > one piece of crypt at a time and submit small patches that are easier > to find bugs in. There are a number of private functions in crypt > though that cant be changed to unicode because it will break > compilation before the rest of the patches are submitted, so I will > submit unicode patches with a W appended to the name of the function > as in > > static inline PSTR CRYPT_GetProvKeyName(PCSTR pProvName) > static inline PWSTR CRYPT_GetProvKeyNameW(PCWSTR pProvName) //added > > Any public api functions that I change until the final patch will use > the W version while the unchanged version will continue using the > regular ansii version so as to not break compilation. > > Along with the changes, I will also submit tests for the new unicode > api functions so they can be verified to be correct. > > The first patch adds CRYPT_GetProvKeyNameW. > > -- > James Hawkins > > > I forgot to mention that I have tested the new CRYPT_GetProvKeyNameW and it works exactly as the ansii version, but in unicode. -- James Hawkins

Aug. 6, 2004

Different approach to a->w cleanup of crypt

by James Hawkins

Hi, I have been trying to get my a->w cleanup of crypt committed for quite some time now, and mostly with no luck because of all the bugs, but I have a better idea about how accomplish this. The problem is that crypt requires a lot of changes to get rid of the w->a calls (the patch was ~27k), and it's too risky to commit the patch even though it looks like all the bugs are gone. The solution is that I will change one piece of crypt at a time and submit small patches that are easier to find bugs in. There are a number of private functions in crypt though that cant be changed to unicode because it will break compilation before the rest of the patches are submitted, so I will submit unicode patches with a W appended to the name of the function as in static inline PSTR CRYPT_GetProvKeyName(PCSTR pProvName) static inline PWSTR CRYPT_GetProvKeyNameW(PCWSTR pProvName) //added Any public api functions that I change until the final patch will use the W version while the unchanged version will continue using the regular ansii version so as to not break compilation. Along with the changes, I will also submit tests for the new unicode api functions so they can be verified to be correct. The first patch adds CRYPT_GetProvKeyNameW. -- James Hawkins

Aug. 6, 2004

Re: list view completely mangled in WINE

by Dan Kegel

Hi Filip, if you're looking for testcases, could you try the demo programs in http://bugs.winehq.org/show_bug.cgi?id=1268 and http://bugs.winehq.org/show_bug.cgi?id=1404 ? Especially the latter one, which has a tiny MFC demo program in both source code form and precompiled. It misbehaves badly with Wine, and has for years, but perhaps your patch will fix it. Thanks, Dan -- My technical stuff: http://kegel.com My politics: see http://www.misleader.org for examples of why I'm for regime change

Aug. 6, 2004

Re: [D3D] Fixed XYZRHW vertex handling

by Christian Costa

Francois Gouget wrote: >--- dlls/ddraw/d3ddevice/mesa_old.c 2004-08-05 15:11:43.000000000 +0100 >+++ dlls/ddraw/d3ddevice/mesa.c 2004-08-05 12:50:45.000000000 +0100 >@@ -1172,7 +1172,7 @@ > glVertex3fv(coords); > } > inline static void handle_xyzrhw(D3DVALUE *coords) { >- if (coords[3] < 1e-8) >+ if ((coords[3] < 1e-8) && (coords[3] > -1e-8)) > glVertex3fv(coords); > else { > GLfloat w = 1.0 / coords[3]; > >This could be a job for fabsf of fabs (might be more portable): > >+ if (fabsf(coords[3]) < 1e-8) > > > > > This is cleaner but it adds an extra call. Since handle_xyzrhw is "call" for each vertex, I would leave it as is. :-) Bye, Christian

Aug. 6, 2004

BeginUpdateResource, UpdateResource and EndUpdateResource

by Vincent Béron

Hi, I'd like to implement those 3 APIs (both the A and W variants) as the process to update the Mozilla installer for a localized build uses them. Anybody has some pointers where to begin? I tried following the FindResourceEx path, but got lost in ntdll. Vincent

Aug. 5, 2004

Re: [D3D] Fixed XYZRHW vertex handling

by Francois Gouget

--- dlls/ddraw/d3ddevice/mesa_old.c 2004-08-05 15:11:43.000000000 +0100 +++ dlls/ddraw/d3ddevice/mesa.c 2004-08-05 12:50:45.000000000 +0100 @@ -1172,7 +1172,7 @@ glVertex3fv(coords); } inline static void handle_xyzrhw(D3DVALUE *coords) { - if (coords[3] < 1e-8) + if ((coords[3] < 1e-8) && (coords[3] > -1e-8)) glVertex3fv(coords); else { GLfloat w = 1.0 / coords[3]; This could be a job for fabsf of fabs (might be more portable): + if (fabsf(coords[3]) < 1e-8) -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Any sufficiently advanced bug is indistinguishable from a feature. -- from some indian guy

Aug. 5, 2004