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

Re: accessing WRT binaries on the web

by Saulius Krasuckas

* On Wed, 24 Aug 2005, Paul Millar wrote: > > No, this isn't intentional. The cross-building part needs patching so > it knows about an additional part of the Win32 API. Nothing new there. Ok, but I perhaps do not understand, what the exact code is or looks like. Is it available on the net? And are you working alone? > But rather than just patching the (somewhat ancient) version of the > w32api, I've decided to upgrade to the latest version. This means going > through the large number of patches to Win32api figuring out which are > now redundant and which are still needed, and fixing the patches so they > work again. Once this is done, things should be up and running again. Thanks, Paul, for the clarification.

Aug. 25, 2005

Re: Loading resources from wine dlls

by Alexandre Julliard

Robert Shearman <rob(a)codeweavers.com> writes: > Anything that uses SearchPath is similarly broken when needing to find a > builtin dll or exe. We should add a hack^H^H^H^Hextension to that > function to make it be able to find installed .so files with a similar name. That won't really help, because even if CreateFile succeeds we can't retrieve the resources from the ELF file. PrivateExtractIcons should probably try to do a LoadLibrary if the file doesn't exist. -- Alexandre Julliard julliard(a)winehq.org

Aug. 25, 2005

Re: Loading resources from wine dlls

by Michael Jung

Hi Rob, On Thursday 25 August 2005 06:50, you wrote: > Anything that uses SearchPath is similarly broken when needing to find a > builtin dll or exe. We should add a hack^H^H^H^Hextension to that > function to make it be able to find installed .so files with a similar > name. I think that's just part of the problem. If I create a symbolic link from .wine/drive_c/windows/system32/shell32.dll to /usr/local/lib/wine/shell32.dll.so SearchPath succeeds. But then USER32_GetResourceTable (dlls/user/exticon.c, line 128) fails (I guess it can't handle ELF wrapped PEs?). Would it be ok to look for an ELF header and then for an enclosed PE header in USER32_GetResourceTable (and then return IMAGE_NT_SIGNATURE and the correct pointer)? Where can I find informations about the format of ELF wrapped PEs? Bye, -- Michael Jung mjung(a)iss.tu-darmstadt.de

Aug. 25, 2005

Re: Loading resources from wine dlls

by Robert Shearman

Michael Jung wrote: >Hello, > >I would like to add a 'My Documents' icon to shell32. This icon has a resource >ID of 235 in WinXP's shell32. > >Apparently one can't load resources from wine's own dlls, though. If you call >PrivateExtractIcons with 'c:\windows\system32\shell32.dll' as the file name >parameter, you'll get a 'WARN: File %s not found or path too long'. I guess >that's because there is no such file in wine's fake windows environment. > >There is a hack (which is even declared as a hack in the comment) in the >initialization code of the 'Shell Icon Cache' (starting from line 372 in >'dlls/shell32/iconcache.c'). It loads the first 38 icons from shell32 at >initialization time, and later returns them from the cache without having to >access the file (which would'nt work). > >This seems to be a principal problem (Loading resources from wine dlls, if >they are accessed by the filename they have on a windows system). Are there >any plans on how to fix this? > > Anything that uses SearchPath is similarly broken when needing to find a builtin dll or exe. We should add a hack^H^H^H^Hextension to that function to make it be able to find installed .so files with a similar name. -- Rob Shearman

Aug. 25, 2005

Re: Throwing in an idea (probably it was discussed before though)

by Vincent Béron

Le lun 22/08/2005 à 07:58, John Smith a écrit : [snip] > 2. (not really relevant to this discussion, but relevant to the whole issue > of supporting end-users): binary RPMs for RedHat/Fedora on winehq.org are > still 20050524, and winecfg is pretty much useless there. If WINE team does > care about end-users, it would be nice to have binary RPMs for the most > popular distribution not that much out-of-date. Yes, that's my fault. After moving in June, I haven't found the time yet to reinstall all my computer stuff (I'm typing this sitting on the floor with my keybord on my knees), so I don't know when I'll get back to it. I already missed two releases, and haven't produced any rpm for FC4 (for which I get a couple emails per week). If somebody wants to step up to the task (at least temporarily), I'd be glad to share my experience with them. Vincent

Aug. 25, 2005

Re: secur32: Getting some real functionality into the NTLM provider, try 2

by Juan Lang

Hi Kai, In ntlm.c, + /* convert the program name to Unicode */ (snip) + /* and back to the CP_UNIXCP */ This round-tripping is unnecessary when the text is already ASCII. ASCII values are just as valid in UTF8 as they are in CP1252 or whatever. Basically, don't bother converting anything you can type. + if(pAuthData == NULL) In this if statement, you duplicate the business of converting the user name and domain name to CP_UNIXCP in both branches. You should instead store a pointer to the user name and domain name, and convert them in one common branch after the if statement. + SEC_CHAR *client_argv[] = + { + program, + client_protocol, + client_user_arg, + client_domain_arg, + NULL + }; You must declare variables at the beginning of the block, not in the middle. Not all C compilers allow this. + if(pszPackage != NULL) + { + int package_sizeW = MultiByteToWideChar(CP_ACP, 0, pszPackage, -1, + NULL, 0); Since you don't use pszPackage in ntlm_AcquireCredentialsHandleW, why bother converting it? Just pass NULL. + if(identity->Flags == SEC_WINNT_AUTH_IDENTITY_ANSI) (snip) + else + { + memcpy(pAuthDataW, identity, sizeof(SEC_WINNT_AUTH_IDENTITY_W)); + } This looks funny. Why not just set pAuthDataW to identity in this case? That way you avoid the memcpy. Something like this: PSEC_WINNT_AUTH_IDENTITY_W pAuthDataW; if (identity->Flags == SEC_WINNT_AUTH_IDENTITY_ANSI) { /* convert it like you do */ } else pAuthDataW = (PSEC_WINNT_AUTH_IDENTITY_W)identity; /* call ntlm_AcquireCredentialsHandleW */ if (pAuthDataW != identity) HeapFree(GetProcessHeap(), 0, pAuthDataW); + if((ret = encodeBase64(helper->password, + helper->pwlen-2, buffer+3, + max_len-3, &buffer_len)) != SEC_E_OK) + { + HeapFree(GetProcessHeap(), 0, buffer); + HeapFree(GetProcessHeap(), 0, bin); + return ret; + } You ought to zero the memory of the password and free it, regardless of whether encodeBase64 succeeds or fails. (Really you ought to call SecureZeroMemory, but wine hasn't implemented that.. oh well.) In tests/ntlm.c: + //lstrcpyA(identity->Password, pass ? pass :""); No C++ style comments, please. More generally, on the tests, I like them because they should nearly always succeed in Windows. But they're not very likely to succeed in Wine, are they? You handle not having an ntlm_auth fairly gracefully, I think, and also handle not being able to create an inbound context, which you say may not work without some magic setup. But this won't generally work out of the box if ntlm_auth works and an inbound context can be created, can it? The tests will try to authenticate with whatever domain name is in the registry, or default to WORKGROUP if that's empty, and your UNIX username, and no password. That's not very likely to succeed. So, it would be nice to have these tests somewhere for people to check that this code indeed works.. but I'm not sure they can go into the regression test suite. Unless I'm mistaken. Thanks, --Juan ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs

Aug. 25, 2005

Bugzilla - old rubbish bugs...

by Ann & Jason Edmeades

I asked this a while ago and noone was too upset, but I am going to try to spend some time slowly closing off some of the bugs which do not have enough info in them to be reproduced, and have not had a response to a request to see if the problem persists for a long time (e.g. 6 months). I wont close anything which is reproducible (I'll try if I can) and I believe if something is wrongfully closed it can always be reopened? If anyone else has a spare moment, feel free to help! At the moment there is >1300 available bugs, but looking at lots of them in detail I doubt there's 500 which are worth keeping! (I was bored and looking for some things to fix and it's like a needle in the haystack looking in bugzilla at the moment). Jason

Aug. 24, 2005

OpenGL windowing and wglMakeCurrent

by Russ

Trying to get my 3-D app to run under WINE using the same binary with the odd workaround or two. It uses OpenGL in various subwindows of the main window as needed. Under WINE, the subwindow graphics all get drawn in the lower left corner of the overall X11 window, and the entire X11 window's redraw is mangled---OpenGL is affecting the entire X11 Window. In Win32, when you call wglMakeCurrent, the opengl context is configured to match the size/position of the HWND for the HDC, even if it is only a small child window, so drawing openGL goes just into the desired subwindow. However, the WINE implementation of wglMakeCurrent just calls glXMakeCurrent (and glXCreateContext), which produces the entire size of the X11 window, resulting in the incorrect behavior observed. In my Mac OS X port, I have a similar issue, resolved by calling aglSetInteger(glContext, AGL_BUFFER_RECT,... I'm not sure what a glX equivalent would be to try. It is possible that glScissor might be used. A more accurate wglMakeCurrent emulation is necessary for a usable port. Suggestions welcome. Thanks, Russ __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

Aug. 24, 2005

Re: [Bug 3148] Mouse: multi-file "selection" & drag behavior broken

by Vitaly Lipatov

В сообщении от 24 Август 2005 22:14 Вы написали: > If Vitaly is busy and won't object, I can resync his changes to the > current CVS and send a patch from his name. Well, I resent my patch again to wine-devel... -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru

Aug. 24, 2005

Re: [Bug 3148] Mouse: multi-file "selection" & drag behavior broken

by Saulius Krasuckas

* On Wed, 24 Aug 2005, Hiji wrote: > --- Saulius Krasuckas <saulius2(a)ar.fi.lt> wrote: > > > > a, header of its first section refers to > > "sysparams.c" and "dlls/user/sysparams.c", > > which makes patcher to not find needed file > > (dlls/user/tests/sysparams.c). > > > > b, first hunk of the second section > > (dlls/user/sysparams.c) is already in the > > tree, so it fails too. > > Ok, I had applied it to the July release, but if some > changes are already in the tree, then that's good > news. Not very good, as the mentioned change is only cosmetic. > Vitaly, any thoughts on this? If Vitaly is busy and won't object, I can resync his changes to the current CVS and send a patch from his name.

Aug. 24, 2005