October 2008 - Wine-devel - list.winehq.org

Re: cryptui: Add a partial implementation of CryptUIWizImport.
by Juan Lang 22 Oct '08

22 Oct '08

> Yes, so those users may benefit from the stub as well. And I do print > a FIXME. This is nothing new, we've been ignoring invalid certificates > in wininet for years where we should stop and show a UI. When I tested with native cryptui and imported a cert, it didn't pick the root store. So I'm just not convinced it's doing the correct thing. That the root store is at present read-only makes it even more certain it doesn't do what the user expects at the moment. Perhaps that needs to be fixed as well, but that's a separate discussion. We need to be sure adding to the root store is the correct thing in the first place. I'm not against stubs, I just think this one needs some tests. They shouldn't be that hard to write: test the root store before and after importing a cert with no UI, and see if the cert is added to the root store. Try with a few different kinds of certs (self-signed, not self-signed.) If they're always added to the root store, I'll be more persuaded. Right now I'm not. --Juan

1 0

Re: cryptui: Add a partial implementation of CryptUIWizImport.
by Hans Leidekker 22 Oct '08

22 Oct '08

On Wednesday 22 October 2008 16:37:16 you wrote: > I don't think that's typical usage at all: typical usage presents a > UI. It's called from elsewhere in cryptui, so it's under the control Sure, but the app may present its own UI like Outlook does, and call this function with CRYPTUI_WIZ_NO_UI set. > of the user how frequently this is used. You add a cert to the root > store even when a UI is requested. This is clearly incorrect. Yes, so those users may benefit from the stub as well. And I do print a FIXME. This is nothing new, we've been ignoring invalid certificates in wininet for years where we should stop and show a UI. I'm not saying we shouldn't implement this or not be secure, it's just a matter of priorities. -Hans

1 0

Re: [PATCH 3/3] ole32: Call the appropriate storage function when we run the object.
by Rob Shearman 22 Oct '08

22 Oct '08

2008/10/21 Huw Davies <huw(a)codeweavers.com>: > @@ -1728,6 +1767,10 @@ static HRESULT WINAPI DefaultHandler_IPersistStorage_HandsOffStorage( > if(SUCCEEDED(hr) && object_is_running(This)) > hr = IPersistStorage_HandsOffStorage(This->pPSDelegate); > > + old_stg = InterlockedExchangePointer((void**)&This->storage, NULL); IIRC, the default handler is apartment-threaded only, meaning that a default handler object cannot be used on a thread other than the one it was created on. Adding constructs like this introduce confusion to future developers about whether the code is or isn't thread-safe and so it should be avoided and a non-thread-safe construct used instead. > + if(old_stg) IStorage_Release(old_stg); > + This->storage_state = storage_state_uninitialised; > + > return hr; > } -- Rob Shearman

2 3

Re: cryptui: Add a partial implementation of CryptUIWizImport.
by Juan Lang 22 Oct '08

22 Oct '08

Hi Hans, I know this patch already got committed. +BOOL WINAPI CryptUIWizImport(DWORD dwFlags, HWND hwndParent, LPCWSTR pwszWizardTitle, + PCCRYPTUI_WIZ_IMPORT_SRC_INFO pImportSrc, HCERTSTORE hDestCertStore) +{ + static const WCHAR Root[] = {'R','o','o','t',0}; (snip) + if (!(cert = CertCreateCertificateContext(encoding, buffer, size))) + { + WARN("unable to create certificate context\n"); + HeapFree(GetProcessHeap(), 0, buffer); + return FALSE; + } + /* FIXME: verify certificate and determine store name dynamically */ + if (!(store = CertOpenStore(CERT_STORE_PROV_SYSTEM_W, 0, 0, CERT_SYSTEM_STORE_CURRENT_USER, Root))) + { + WARN("unable to open certificate store\n"); + CertFreeCertificateContext(cert); + HeapFree(GetProcessHeap(), 0, buffer); + return FALSE; + } + ret = CertAddCertificateContextToStore(store, cert, CERT_STORE_ADD_REPLACE_EXISTING, NULL); This doesn't look correct. Why are you always using the root store, and ignoring hDestCertStore? Even if you expect hDestCertStore to be NULL (in which case a default store may make sense), using the Root store seems like it won't do what the user wants. The certificate won't be persisted if it's added to the Root store, because the Root store is only read from the local system. When the process (Outlook) exits, the certificate will no longer exist. It should be possible to add a test that shows which store the certificate should be added to, if nothing else to satisfy my doubt. --Juan

4 14

Re: wine users forum registration issue
by James Mckenzie 22 Oct '08

22 Oct '08

Kai Blin <kai.blin(a)gmail.com> at Oct 22, 2008 12:36 AM wrote about wine users forum registration issue > >On Tuesday 21 October 2008 18:25:19 Andreas Mohr wrote: > >Given that most people on this list don't seem to use the forum and thus don't >notice, how about the people who actually use the forum get together and >figure out a way to make it work? Alternatively, as was suggested before, we >could ditch the forums and point people to the google groups interface for >the wine-users list. +1 > >> Doing severe cross-posting to make sure this does get noticed, thanks. > >Have a cookie. Don't know why CCing wine-patches should help, unless you want >patchwatcher to notice. > Or have an adult beverage if you can. In other words: Chill. Life is not worth getting wrapped up in this stuff. > >Right. So the forum software is broken, and all of the Wine devs would rather >fix Wine than the forums? Sounds like a good case for ditching the forums. +1. The forums have been nothing but a problem since their incorporation into the mailing list. Several long time mailing list users have left due to this. Their experiences are invaluable and they will not be back until the forums are long gone. > >Will code for cotton. Will code for food, drink and a place to live. James McKenzie

1 0

Re: configure: Require at least version 1.6 of gnutls.
by James Mckenzie 22 Oct '08

22 Oct '08

Francois Gouget <fgouget(a)free.fr> at Oct 22, 2008 2:15 AM wrote about configure: Require at least version 1.6 of gnutls. > >On Tue, 21 Oct 2008, James Mckenzie wrote: > >> Henri Verbeet <hverbeet(a)gmail.com> at Oct 21, 2008 10:04 AM wrote about configure: Require at least version 1.6 of gnutls. >> >> Why are we looking to use gnutls 1.6? Is there a feature that is >> needed for Wine? If so, I will have to check Fink before building >> Darwine again. > >Yes, we use the following types and functions (and maybe more) which are >not available in the very old Gnutls versions: > Since you stated 'very old' version, so I have a question. When did these functions become available? I am not going to assume that they were introduced with version 1.6. > gnutls_alert_description_t > gnutls_transport_set_errno > > >For the autoconf check it's probably enough to just check for >gnutls_transport_set_errno() and warn if it's missing. This is a good idea. We should check for the newest function and if it is not available, force an error and let the user know that these are available with version 1.6. <HUMOR> > The software said it requires Win95 or better, so I installed Linux. I used "The software said it requires Win95 or better, so I installed OS/2". I miss it. Now I use a Mac and wish I had started with one. </HUMOR> James McKenzie

1 0

re: QueryDosDevice
by Dan Kegel 22 Oct '08

22 Oct '08

Tomasz Salacinski wrote: > I was trying to find a solution for bug 5351... Are you trying to fix it, or just work around it? "winetricks volnum" works around it just fine. > I need to have Visual Studio on Linux (otherwise I will have > to install Windows), and I can try to fix the problem. I can code in C, > but I need Visual Studio and C# for my school Which version? 2005 kind of works, see http://appdb.winehq.org/objectManager.php?sClass=version&iId=14208 http://appdb.winehq.org/objectManager.php?sClass=version&iId=4494 but 2008 doesn't, see http://appdb.winehq.org/objectManager.php?sClass=version&iId=11210 http://appdb.winehq.org/objectManager.php?sClass=version&iId=11022 2008 is likely to be difficult to support, so don't get your hopes up there. - Dan

1 0

Re: Dylan Smith : richedit:Added tests for ctrl-key shortcut handling in WM_KEYDOWN.
by Dmitry Timoshkov 22 Oct '08

22 Oct '08

"Alexandre Julliard" <julliard(a)winehq.org> wrote: > +static BOOL hold_key(int vk) > +{ > + BYTE key_state[256]; > + BOOL result; > + > + result = GetKeyboardState((LPBYTE)&key_state); > + ok(result, "GetKeyboardState failed.\n"); > + if (!result) return FALSE; > + key_state[vk] |= 0x80; > + result = SetKeyboardState((LPBYTE)&key_state); > + ok(result, "SetKeyboardState failed.\n"); > + return result != 0; > +} > + > +static BOOL release_key(int vk) > +{ > + BYTE key_state[256]; > + BOOL result; > + > + result = GetKeyboardState((LPBYTE)&key_state); > + ok(result, "GetKeyboardState failed.\n"); > + if (!result) return FALSE; > + key_state[vk] &= ~0x80; > + result = SetKeyboardState((LPBYTE)&key_state); > + ok(result, "SetKeyboardState failed.\n"); > + return result != 0; > +} This is already committed, but the casts in the above code clearly show that the pointer syntax is wrong there. -- Dmitry.

1 0

Re: [PATCH 1/3] ole32: Create the '\1Ole' stream.
by Rob Shearman 22 Oct '08

22 Oct '08

2008/10/21 Huw Davies <huw(a)codeweavers.com>: > +/*********************************************************************** > + * init_ole_stream > + * > + * Creates the '\1Ole' stream. > + * The format of this stream is as follows: > + * > + * DWORD Version == 0x02000001 > + * DWORD Flags - high bit set indicates the object is a link otherwise it's embedded. > + * DWORD LinkupdateOption - [MS-OLEDS describes this as an implementation specific hint > + * supplied by the app that creates the data structure. May be > + * ignored on processing]. > + * > + * DWORD Revserved == 0 Typo. > + * DWORD MonikerStreamSize - size of the rest of the data (ie CLSID + moniker stream data). > + * CLSID clsid - class id of object capable of processing the moniker > + * BYTE data[] - moniker data for a link > + */ Please add some tests that show the layout as documented here is correct and is what the code does. -- Rob Shearman

1 0

QueryDosDevice
by Tomasz Salacinski 22 Oct '08

22 Oct '08

Hello, I was trying to find a solution for bug 5351 and I've found it. When user is trying to install Visual Studio he gets a message: Unable to find a volume for file extraction. Please verify that you have proper permissions. The problem is, that when vcssetup.exe is running, it is using function QueryDosDeviceW to query dos devices on the system and looks for device with either "harddisk" or "ramdisk" in its name. Because it fails, installation cannot proceed. It checks drives like this: QueryDosDevice for C:\ returns "\\drive_c" <-- no harddisk in the string QueryDosDevice for D:\ returns "\\home\\something" <-- again, the same QueryDosDevice for Z:\ returns "\\" <-- still the same There are few possible solutions on how to fix this: 1) Rename drive_c to harddiskvolume1 - this could force users to install applications again, but new wine version could just move the files to the new directory on startup and change the configuration file for drive C:\ to point to harddiskvolume1 2) Create a symlink to drive_c in wine directory and automatically create drive D:\ which points to that symlink (which is very bad, because user will have two drives that point to the same location). 3) Convert QueryDosDeviceW so that it will return always "harddiskvolume1" when application asks for "c". This can, but doesn't have to break some applications, though. I've applied the second solution to WINE and Visual Studio continues to install, but WINE should apply this automatically so these installers could work out-of-the-box (AFAIK this bug applies to other applications as well, such as MS Office - but I can't confirm that). Please tell me, which solution is the best one (or if you have a different solution, tell me). I need to have Visual Studio on Linux (otherwise I will have to install Windows), and I can try to fix the problem. I can code in C, but I need Visual Studio and C# for my school (yes, I know Monodevelop but I need to have Visual Studio projects). Cheers.

1 0