New winetricks-alpha 20110222-alpha: new verbs d3dx11_43, dragonage2_demo, regedit, shell, taskmgr, winecfg
Right, it's only been a couple days, but here's a new winetricks already. This release adds dragonage2_demo (released earlier today -- hey, we're starting to keep up!) as well as the handy verbs d3dx11_43, regedit, shell, taskmgr, and winecfg, and a few bugfixes. Download url: http://winetricks.org/winetricks-alpha svn repository / bug tracker: http://winetricks.org Changes since 20110219b-alpha: Dan Kegel: Added Status column to gui, containing 'cached' if game installer is cached. bioshock_demo: add mwo=force for bug 6971 cnc3_demo: fixed install check d3dx11_43: new verb dragonage2_demo: new verb Display install size and time for (some) games. Fix 'winetricks-alpha list'. Thanks to doh123 for pointing out the problem. Pre-check checkboxes for things that are already installed. (winezeug bug 128) regedit: new verb shell: new verb (handy for debugging) taskmgr: new verb tmnationsforever: mention portaudio workaround for choppiness winecfg: new verb Changes since 20110219-alpha: hko: removed, since they no longer offer the torrent download. utorrent: updated to 2.2.1beta. hegemony_demo: update sha1sum gecko is no longer a real verb, so remove media type. Fixes one reported failure in test suite. dc2ba_demo: updated sha1sum d3dxof: fix location of downloaded file msls31: fix typo that broke downloading with clean cache. Fixes ie6. Also mention where files are being downloaded to in console.
Re: Apologies to the List
On Wed, Feb 23, 2011 at 10:52 AM, James McKenzie wrote: > On 2/22/11 4:37 AM, Alexandre Julliard wrote: > >> James McKenzie writes: >> >> First, my tirade was not intended to be as such. I wanted to pull the >>> patch because it was incorrect and I did not want anyone else working >>> on it while I silently trimmed it and made it better. >>> Second, I realize this has affected my 'Jeremy White' score. I hope >>> that AJ understands why the code was pulled and that this happens >>> frequently with a project this large. >>> >> No, it doesn't. Requesting your code to be pulled is a serious matter, >> and a major break of the trust that is necessary for us all to work >> together. You can't do something like this and expect it not to have >> consequences. >> >> It was already unlikely that you would get any of your patches in, based >> on their technical merit, but now even if you managed to make your code >> acceptable, I wouldn't put it in, because I can't trust you not to make >> me pull it out again next time you get mad at me. >> >> And I agree with this decision. You are technically "the keeper of the > code" and I have on more than one occasion transgressed this unwritten rule. > > However, I will still post patches for comments in Wine Development and > subsequently release them to the LGPL/Wine in Wine-Patches so that others > can work with them. I feel that is only fair for what I have done. Is that > acceptable? > > This seems to be the method used by others, however I have been known to be > massively incorrect in the past, and I could be wrong now. > > If posting them to bug reports is the preferred method I will that instead. > > James McKenzie > > > Hello James, This is just my opinion OK, So don't take this as the opinion of Wine/WineHQ or anyone else. In the past I had a very serious drinking problem and I pissed off allot of people, and most of them were my friends. So one day I decided to stop drinking and to try and repair old friendships, saying sorry will only get you, or me, or anyone of us just so far... The only way to get back trust and friendship is to earn it a little each day by your actions. And not to overreact to a past overreaction. :) So my suggestion is to take it a day at a time and try and mend past mistakes by future actions. I wish you the best! Tom Wickline -- Wine is not a conclusion but a process...
Re: gdi32: first look for a printer driver name in the registry (try 2)
On 02/22/2011 09:28 AM, Vitaly Perov wrote:
> Fixed possible hKey leak since last send
>
> +static const WCHAR user_printers_reg_key[] = {
> 'S','o','f','t','w','a','r','e','\\',
The actual key doesn't look like have anything to do with printers. Please
use variable name that more corresponds to the actual content of the
unicode string.
> +if (!res && !RegQueryValueExW(hKey, device, NULL, NULL, (LPBYTE) driver,
> &size))
> +{
> +TRACE("Get value from registry\n");
> +}
Message is not really helpful. And just hides empty if() case. It's better to
reverse logic to check for error and combine with the win.ini check. Something
like:
if ((RegOpenKeyExW(HKEY_CURRENT_USER, user_printers_reg_key, 0, KEY_READ,
&hKey) ||
RegQueryValueExW(hKey, device, NULL, NULL, (LPBYTE) driver, &size) &&
!GetProfileStringW(devicesW, device, empty_strW, driver, size))
> WARN("Unable to find %s in [devices] section of win.ini\n",
> debugstr_w(device));
This should also mention registry.
> +if (!res) RegCloseKey(hKey);
Instead of using res, initialize hKey to NULL and close it if it's not NULL.
It's
more foolproof.
Vitaliy
Re: Apologies to the List
On 2/22/11 4:37 AM, Alexandre Julliard wrote: James McKenzie writes: First, my tirade was not intended to be as such. I wanted to pull the patch because it was incorrect and I did not want anyone else working on it while I silently trimmed it and made it better. Second, I realize this has affected my 'Jeremy White' score. I hope that AJ understands why the code was pulled and that this happens frequently with a project this large. No, it doesn't. Requesting your code to be pulled is a serious matter, and a major break of the trust that is necessary for us all to work together. You can't do something like this and expect it not to have consequences. It was already unlikely that you would get any of your patches in, based on their technical merit, but now even if you managed to make your code acceptable, I wouldn't put it in, because I can't trust you not to make me pull it out again next time you get mad at me. And I agree with this decision. You are technically "the keeper of the code" and I have on more than one occasion transgressed this unwritten rule. However, I will still post patches for comments in Wine Development and subsequently release them to the LGPL/Wine in Wine-Patches so that others can work with them. I feel that is only fair for what I have done. Is that acceptable? This seems to be the method used by others, however I have been known to be massively incorrect in the past, and I could be wrong now. If posting them to bug reports is the preferred method I will that instead. James McKenzie
Re: RFC: Patch to change what sets the is_win9x in riched20/tests
On 2/22/11 12:42 AM, Paul Vriens wrote: On 02/22/2011 01:21 AM, James McKenzie wrote: All: Upon examining other test code that creates a variable called is_win9x, I realized that using get_version and comparing it to a fixed value may not be best for the riched20 tests and have attached a proposed change to how this variable is set. It uses a called function, lstrcmpW and if it does not exist, the variable is set to a false value. This change has been tested on the testbot for Windows95/98/98SE/2K/2K3/XP/XP_64/Vista/Vista64/Win7/Win7_64 and no discrepancies were found. Win9x tests are no longer run with winetest. I also see that Austin sent some 9x cleanup patches. That said, I think the best way is to get rid of all the win9x 'hacks' in editor.c and rely on the fact that we have NT4+. Paul: While that is true, I thought the consensus was that testing would still be available for Window9X/ME. There are users (like me) that are running Windows9x/ME programs and don't want to loose the ability to run them under Wine. This function may not exist in Windows versions after Windows2K either, that is why I proposed changing this from a version check to actually checking for the called function. And lastly, I agree with adding tests to specifically check what happens in the riched20.dll for UNICODE calls. James McKenzie
winetricks
Could you correct link to msxml3 in winetricks instaler ? Fhx
Re: Valgrind --malloc-fill=A5 --free-fill=DE crashes Wine
On Mon, Feb 21, 2011 at 09:10, Maarten Lankhorst wrote: > Hi Joerg, > > Op 21-02-11 12:26, joerg-cyril.hoe...@t-systems.com schreef: >> >> Hi, >> >> I used to run Valgrind with the additional options >> --malloc-fill=A5 --free-fill=DE >> around Wine 1.2 times. Now I retried it and it crashes >> Wine 1.3.13 and 1.3.14 (it fails to load kernel32.dll). >> >> It turns out that malloc-fill is harmless, -free-fill causes havoc >> currently. >> >> Am I the only one using or seeing this (Ubuntu Lucid)? > > It's most likely a valgrind/wine bug, does this patch work? Works for me on Gentoo 32-bit. -- -Austin
Re: GSOC idea to implement the explorer
Hi Andrew, > Though I understand this is probably the lower priority on the wine > developers list. As integrating into Linux desktop is probably the > preferred and most used mode. I thought that sharing reactos explorer > and working on making a complete explorer(including extensions) would > be the goal. > Though now I'm saying it I feel rather silly, as this really is the > least important part of wine. Hey, if it's your itch, feel free to scratch it. I actually would like to see a better explorer in Wine, if nothing else to have a more intuitive way to play around with the shell namespace than opening a file/save dialog. I haven't had time to work on it myself. Regarding sharing code: last I heard, the official attitude is "it's complicated." C++ code isn't acceptable in the Wine tree at all, of course, so that ruled out ReactOS's explorer long ago. New submissions that are aimed at their tree as well as ours would probably be acceptable. --Juan
Re: gdi32: first look for a printer driver name in the registry
Vitaly Perov wrote:
> +if (!RegOpenKeyExW(HKEY_CURRENT_USER, user_printers_reg_key, 0,
> KEY_READ, &hKey)
> +&& !RegQueryValueExW(hKey, device, NULL, NULL, (LPBYTE) driver,
> &size))
> +{
> +TRACE("Get value from registry\n");
> +RegCloseKey(hKey);
> +}
You are leaking hKey if RegOpenKeyExW() succeeds but RegQueryValueExW() does
not.
--
Dmitry.
Re: gdi32: first look for a printer driver name in the registry
Hi Vitaly,
On 2/22/11 4:01 PM, Vitaly Perov wrote:
+if (!RegOpenKeyExW(HKEY_CURRENT_USER, user_printers_reg_key, 0,
KEY_READ,&hKey)
+&& !RegQueryValueExW(hKey, device, NULL, NULL, (LPBYTE) driver,&size))
+{
+TRACE("Get value from registry\n");
+RegCloseKey(hKey);
+}
You leak hKey on RegQueryValueExW failure.
Jacek
Re: wined3d profiling
In case of Intel make sure you use drivers with debug symbols :) Yeah, you could use oprofile, but for some quick and easy profiling sysprof can be easier and much quicker. Roderick On Tue, Feb 22, 2011 at 2:55 AM, Jeff Zaroyko wrote: > On Tue, Feb 22, 2011 at 8:53 PM, Tobias Jakobi wrote: >> >> What is the recommended way of profiling wine components? oprofile? >> > > See http://wiki.winehq.org/Performance > > oprofile works well if things are cpu bound, or for illustrating cases > of redundant calls. If oprofile shows a lot of time in video drivers, > you could try gDEBugger mentioned on the above wiki page to gain some > insight. > > Jeff > > >
Re: oleaut32: Implement ITypeInfo_GetNames Stub/Proxy (resend)
On Tue, Feb 22, 2011 at 09:02:38PM +1100, Alistair Leslie-Hughes wrote: > >From 6aa7bfa0c06b746ee64daf56f2b02e6f38542d54 Mon Sep 17 00:00:00 2001 > From: Alistair Leslie-Hughes > Date: Fri, 18 Feb 2011 12:04:56 +1100 > Subject: [PATCH] Implement ITypeInfo_GetNames Stub/Proxy > To: wine-patches > > --- > dlls/oleaut32/usrmarshal.c | 10 ++ > 1 files changed, 6 insertions(+), 4 deletions(-) This looks good to me. I'm not sure why this function is marked as [call_as], I expect they originally had planned to allow for a NULL pcNames if cMaxNames == 1 (rather like IEnum*_Next). However a quick test shows that this doesn't appear to be the case. Huw.
Re: Apologies to the List
On Tue, Feb 22, 2011 at 7:37 PM, Alexandre Julliard wrote: > > It was already unlikely that you would get any of your patches in, based > on their technical merit, but now even if you managed to make your code > acceptable, I wouldn't put it in, because I can't trust you not to make > me pull it out again next time you get mad at me. > +1 :) > > -- > Alexandre Julliard > julli...@winehq.org > > > -- Wine is not a conclusion but a process...
Re: Apologies to the List
James McKenzie writes: > First, my tirade was not intended to be as such. I wanted to pull the > patch because it was incorrect and I did not want anyone else working > on it while I silently trimmed it and made it better. > Second, I realize this has affected my 'Jeremy White' score. I hope > that AJ understands why the code was pulled and that this happens > frequently with a project this large. No, it doesn't. Requesting your code to be pulled is a serious matter, and a major break of the trust that is necessary for us all to work together. You can't do something like this and expect it not to have consequences. It was already unlikely that you would get any of your patches in, based on their technical merit, but now even if you managed to make your code acceptable, I wouldn't put it in, because I can't trust you not to make me pull it out again next time you get mad at me. -- Alexandre Julliard julli...@winehq.org
Re: wined3d profiling
On Tue, Feb 22, 2011 at 8:53 PM, Tobias Jakobi wrote: > > What is the recommended way of profiling wine components? oprofile? > See http://wiki.winehq.org/Performance oprofile works well if things are cpu bound, or for illustrating cases of redundant calls. If oprofile shows a lot of time in video drivers, you could try gDEBugger mentioned on the above wiki page to gain some insight. Jeff
wined3d profiling
Hey there, I'm experiencing some performance problems with wined3d. The affected game is FEAR (demo does the trick). At first I thought it was related to running the demo on my Intel i965, but I got the same problem running the demo on my Radeon HD4750@r600g. If anyone wants to test this himself: http://www.gamershell.com/download_10167.shtml Performance collapses (kinda SW rendering level) after exiting the first underground section. My guess is that the water plane rendering is causing the issue. So anyway, I wanted to profile this one, but gprof doesn't seem to work so well with wine. I tried to only compile wined3d with -pg, but this doesn't seem to have any effect. At least I don't get any gmon.out after the process exits. What is the recommended way of profiling wine components? oprofile? Thanks, Tobias
