March 2008 - Wine-Devel - list.winehq.org

WineHQ should discourage the use of cracks
by Dan Kegel March 7, 2008

March 7, 2008

I've been fighting against the notion that the wine project encourages cracks for some time now. Cracked versions of apps are bad because they are a) illegal (at least in the US), b) disrespectful of the author of the app, and c) much more likely to be infected with malware. One place we still do it is in our appdb ratings definitions; http://appdb.winehq.org//help/?sTopic=maintainer_ratings which say "Gold: Application works flawlessly with some DLL overrides or other settings, crack etc. " I propose that we change the appdb ratings definitions so that an app that only works with a crack gets no higher than bronze. Any objections? - Dan

20 39

Re: [rsaenh] Fix AES Provider Handling for Windows XP (resend)
by Vijay Kiran Kamuju March 7, 2008

March 7, 2008

Hi, Please let me know why this patch has been rejected. http://www.winehq.org/pipermail/wine-patches/2008-February/049817.html It seems this patch has gone completely unnoticed. Please Comment. Somehow, my patches are not getting commited/reviewed. Did I do anything wrong, please do tell me. Thanks, Vijay > 2008/2/8 Vijay Kiran Kamuju <infyquest(a)gmail.com>: > > > > ChangeLog > > ---------------- > > Fix the AES Provider Handling for Windows XP by adding AES Provider > > string for XP in wine registry > > > > Bug#11509 > > >

1 0

Re: [1/2]try3. Add new dll. Wbemprox.dll
by Detlef Riekenberg March 7, 2008

March 7, 2008

On Fr, 2008-03-07 at 13:19 +0300, Ivan Sinitsin wrote: > +++ configure.ac 21 Feb 2008 13:19:10 -0000 > +++ Makefile.in 21 Feb 2008 13:21:30 -0000 > +++ dlls/Makefile.in 21 Feb 2008 15:04:36 -0000 This does not work. Please follow our guidelines about "Implementing a new DLL": http://wiki.winehq.org/Developers-Hints You can also learn from the commit-messages, especially from the commits, when a new dll was added. > +++ tools/wine.inf 22 Feb 2008 07:10:09 -0000 We create only a fake dll, when and application requires the dll to be present and fail without the fake dll. Thanks for helping wine. -- By by ... Detlef

1 0

Problem open files/folders with ShellExecute.
by Bruno Cabral March 7, 2008

March 7, 2008

Hi guys i trying make my windows software "wine compatible" . It use ShellExecute(..) , how could i use that to open a folder in Kde or Gnome ? The best that i got is to open the wineefile with this: ShellExecute(handle, "open", "explorer", "path_to_folder", NULL, SW_SHOWNORMAL); And i try to open a file too(for example a mp3), but it do nothing too. ShellExecute(NULL, NULL, "path_to_mp3", NULL, NULL, SW_SHOW); Both examples work fine with all version of windows. So, how can execute a file , and howi could open a folder with kde/gnome ? Thanks !

1 0

Re: [2/2]try3.add new dll. wbemprox.dll
by Detlef Riekenberg March 7, 2008

March 7, 2008

On Fr, 2008-03-07 at 13:19 +0300, Ivan Sinitsin wrote: > This patch add new library to the project wine. Name of the library > is - "wbemprox.dll". Since you read the Developer-Hints, you are now aware, that "Makefile.in" is wrong here. I have no Idea about COM, but you should studdy commits for new dlls, when COM functionality was added (Patch-Size, Complexity). Since you used some code from Roy as template, i suggest to study the commits for his recent Patches. As Examples: http://source.winehq.org/git/wine.git/?a=history;f=dlls/qmgrprxy or http://source.winehq.org/git/wine.git/?a=history;f=dlls/qmgr A "\n" at the start of a TRACE is wrong. A "\t" in a TRACE is not needed. A FIXME for an unimplemented function is a good idea, but a simple FIXME("\n"); is not informative. Thanks for helping Wine -- By by ... Detlef

1 0

Re: msi: ACTION_RegisterProduct store all InstallProperties
by Adam Strzelecki March 7, 2008

March 7, 2008

Hello, > I think you need to read through the implementation of > MSI_GetProductInfo more closely and also read the MsiGetProductInfo > tests in tests/msi.c and the test_publish:RegisterProduct tests in > tests/install.c. I think I did, and looking at the tests I see they are testing properties only at Uninstall key, and I think this is wrong, or at least incomplete, as quoted below: > res = RegOpenKeyA(uninstall, prodcode, &prodkey); > ok(res == ERROR_SUCCESS, "Expected ERROR_SUCCESS, got %d\n", res); > > CHECK_REG_DWORD(prodkey, "Version", 0x1010001); > CHECK_REG_DWORD(prodkey, "VersionMajor", 1); > CHECK_REG_DWORD(prodkey, "VersionMinor", 1); > CHECK_REG_DWORD(prodkey, "WindowsInstaller", 1); While MSI_GetProductInfo is reading VersionMajor, VersionMinor, ... etc from InstallProperties key (from szInstallProperties_fmt or szInstaller_LocalSystemProductCodes_fmt), but NOT from Uninstall key as quotes below: > if (classes) > MSIREG_OpenLocalSystemProductKey(szProduct, &userdata, FALSE); > else > MSIREG_OpenInstallPropertiesKey(szProduct, &userdata, FALSE); > > if (!lstrcmpW(szAttribute, INSTALLPROPERTY_HELPLINKW) || > !lstrcmpW(szAttribute, INSTALLPROPERTY_HELPTELEPHONEW) || > !lstrcmpW(szAttribute, INSTALLPROPERTY_INSTALLDATEW) || > !lstrcmpW(szAttribute, > INSTALLPROPERTY_INSTALLEDPRODUCTNAMEW) || > !lstrcmpW(szAttribute, INSTALLPROPERTY_INSTALLLOCATIONW) || > !lstrcmpW(szAttribute, INSTALLPROPERTY_INSTALLSOURCEW) || > !lstrcmpW(szAttribute, INSTALLPROPERTY_LOCALPACKAGEW) || > !lstrcmpW(szAttribute, INSTALLPROPERTY_PUBLISHERW) || > !lstrcmpW(szAttribute, INSTALLPROPERTY_URLINFOABOUTW) || > !lstrcmpW(szAttribute, INSTALLPROPERTY_URLUPDATEINFOW) || > !lstrcmpW(szAttribute, INSTALLPROPERTY_VERSIONMINORW) || > !lstrcmpW(szAttribute, INSTALLPROPERTY_VERSIONMAJORW) || > !lstrcmpW(szAttribute, INSTALLPROPERTY_VERSIONSTRINGW) || > !lstrcmpW(szAttribute, INSTALLPROPERTY_PRODUCTIDW) || > !lstrcmpW(szAttribute, INSTALLPROPERTY_REGCOMPANYW) || > !lstrcmpW(szAttribute, INSTALLPROPERTY_REGOWNERW)) > { > if (!prodkey) > { > r = ERROR_UNKNOWN_PRODUCT; > goto done; > } > > if (!userdata) > return ERROR_UNKNOWN_PROPERTY; > > if (!lstrcmpW(szAttribute, > INSTALLPROPERTY_INSTALLEDPRODUCTNAMEW)) > szAttribute = display_name; > else if (!lstrcmpW(szAttribute, > INSTALLPROPERTY_VERSIONSTRINGW)) > szAttribute = display_version; > > val = msi_reg_get_value(userdata, szAttribute, &type); > if (!val) > val = empty; > } So it does not find any of those properties in the registry, because they're not written there by ACTION_RegisterProduct. And fixing this is the intention of my patch. Regards, -- Adam Strzelecki |: nanoant.com :|

2 4

Re: add realization of HTMLDocument_write,HTMLDocument_open
by Jacek Caban March 7, 2008

March 7, 2008

Hi Ivan, Ivan Sinitsin wrote: > This patch adds realization of function HTMLDocument_write, and > HTMLDocument_open (it needed for method HTMLDocument_write). > > Changelog: > This patch adds realization of function HTMLDocument_write, and > HTMLDocument_open. > First of all, these should be two separated patches. > static HRESULT WINAPI HTMLDocument_write(IHTMLDocument2 *iface, SAFEARRAY *psarray) > { > - FIXME("(%p)->(%p)\n", iface, psarray); > - return E_NOTIMPL; > + HRESULT hres; > + VARIANT *pvar; > + IHTMLElement *pbody; > + BSTR vtext; > + int i; > + > + vtext = SysAllocString(L""); > + > + HTMLDocument_get_body(iface,&pbody); You can't assume that write will be called inside body element. > + > + hres = IHTMLElement_get_innerHTML(pbody, &vtext); You leak vtext memory here. Also you shouldn't use get_innerHTML at all. > + if (FAILED(hres)) { > + vtext = SysAllocString(L""); > + } > + > + hres=SafeArrayAccessData(psarray, (void **)&pvar); > + if (FAILED(hres)) return hres; > + for (i=0; i < psarray->rgsabound[0].cElements; i++) { > + hres = VarBstrCat(vtext, V_BSTR(&(pvar[i])), &vtext); You should check if pvar[i] is VT_BSTR before using it. > + if (FAILED(hres)) { > + break; > + } > + } > + > + IHTMLElement_put_innerHTML(pbody,vtext); You can't use put_innerHTML here. It will cause recreating of whole body element content. What you probably want is nsIHTMLDocument::Write. I will send the right write implementation. > + SysFreeString(vtext); > + hres = SafeArrayUnaccessData(psarray); > + > + return S_OK; > } > static HRESULT WINAPI HTMLDocument_writeln(IHTMLDocument2 *iface, SAFEARRAY *psarray) > @@ -688,8 +715,8 @@ static HRESULT WINAPI HTMLDocument_write > static HRESULT WINAPI HTMLDocument_open(IHTMLDocument2 *iface, BSTR url, VARIANT name, > VARIANT features, VARIANT replace, IDispatch **pomWindowResult) > { > - FIXME("(%p)->(%s %p)\n", iface, debugstr_w(url), pomWindowResult); > - return E_NOTIMPL; > + TRACE("(%p)->(%s %p)\n", iface, debugstr_w(url), pomWindowResult); > + return IHTMLDocument2_QueryInterface(iface, &IID_IDispatch, (void**)pomWindowResult); > } This is obviously not IHTMLDocument2::open implementation. Jacek

1 0

Re: [3/6] qmgr: Add a mutex to BackgroundCopyJob.
by Robert Shearman March 7, 2008

March 7, 2008

Dan Hipschman wrote: > Pretty much the same as yesterday but I changed to using mutexes instead > of critical sections since I need to wait on two at once (one for the > job and the other for the file when updating progress). > I'm not sure this is a correct reason for mutexes instead of critical sections. Either way, you need to have a strict ordering so that you don't deadlock and critical sections use mutexes underneath. Unless you're going to be using a named mutex to synchronise across processes or you're going to have threads quit whilst holding the mutex, then the only difference will be that the code is slower when using mutexes because of the necessary server call, which more often than not can be avoided with critical sections. -- Rob Shearman

1 0

Re: Make winecfg DPI interval to be the same as in Windows
by Robert Shearman March 7, 2008

March 7, 2008

L. Rahyen wrote: > @@ -37,7 +37,7 @@ WINE_DEFAULT_DEBUG_CHANNEL(winecfg); > > #define RES_MAXLEN 5 /* the maximum number of characters in a screen dimension. 5 digits should be plenty, what kind of crazy person runs their screen >10,000 pixels across? */ > #define MINDPI 96 > -#define MAXDPI 160 > +#define MAXDPI 480 > #define DEFDPI 96 > > static const char logpixels_reg[] = "System\\CurrentControlSet\\Hardware Profiles\\Current\\Software\\Fonts"; > @@ -243,9 +243,12 @@ static void on_d3d_pshader_mode_clicked(HWND dialog) { > } > static INT read_logpixels_reg(void) > { > + static const WCHAR szLogPixels[] = {'L', 'o', 'g', 'P', 'i', 'x', 'e', 'l', 's', 0}; > DWORD dwLogPixels; > - char *buf = get_reg_key(HKEY_LOCAL_MACHINE, logpixels_reg, > - "LogPixels", NULL); > + WCHAR *buf; > + WCHAR szLogPixelsReg[MAXBUFLEN]; > + MultiByteToWideChar(GetACP(), 0, logpixels_reg, -1, szLogPixelsReg, sizeof(szLogPixelsReg)/sizeof(szLogPixelsReg[0]) ); > + buf = get_reg_keyW(HKEY_LOCAL_MACHINE, szLogPixelsReg, szLogPixels, NULL); > dwLogPixels = buf ? *buf : DEFDPI; > HeapFree(GetProcessHeap(), 0, buf); > return dwLogPixels; > Don't convert a constant string using MultiByteToWideChar. -- Rob Shearman

1 0

Re: WGL/WINED3D: add WGL_WINE_pixel_format_passthrough
by Chris Robinson March 7, 2008

March 7, 2008

On Thursday 06 March 2008 02:36:41 pm Roderick Colenbrander wrote: > WGL only allows you to set the pixel format once for a HDC. This requires a > WINE-specific WGL extension which allows us to set the pixel format again. > The patch does this and it works correctly in DirectX8/9 SDK samples. I'm pretty sure this can cause a resource leak if it's done on a D3D child window (the existing offscreen surfaces won't be destroyed). Though I can't say I like the idea of the patch since it does nothing for non-Wine, or even non-winex11.drv Wine, to fix the issue.

2 1