Re: .net 3.5sp1 status check, blocking GFWL
On 16 March 2010 00:55, Dan Kegel wrote: > 4) Install gfwlivesetupmin.exe but without .NET Framework <--snip--> > The playonlinux script for that game, > http://www.playonlinux.com/repository/?script=402 > shows that the way to do 4) is > > wine gfwlivesetupmin.exe /nodotnet Added to the HOWTO.
Re: .net 3.5sp1 status check, blocking GFWL
On Tue, Mar 16, 2010 at 12:55 AM, Dan Kegel wrote: > The appdb for another game, Fallout 3, > http://appdb.winehq.org/objectManager.php?sClass=version&iId=14322 > suggests > "1) Download msasn1.dll from e.g. here > 2) Override msasn1.dll in Wine Configuration. How to Override DLL > 3) Download gfwlivesetupmin.exe from e.g. here > 4) Install gfwlivesetupmin.exe but without .NET Framework > 5) Only set xlive to native in Wine Configuration." > > The playonlinux script for that game, > http://www.playonlinux.com/repository/?script=402 > shows that the way to do 4) is > > wine gfwlivesetupmin.exe /nodotnet > > Does that help? > > I guess winetricks should add a gfwl verb that does that, > but we would need a better source for msasn1.dll. There > might be a usable one inside > http://download.microsoft.com/download/d/b/4/db49275f-7741-47cc-b8d5-42a3129499c1/Q835732_xpe_sp2_x86_enu.exe > can somebody try it? > > And then, as http://wiki.winehq.org/msasn1 suggests, we ought to implement > msasn1 in wine. > - Dan > Vitaliy Bioshock 2 was not in my list as it was a personal list of games I knew to be affected. If you know more please add to the list as I know there are a number! Dan when you first run games in Steam that require redist of some type Steam will run a 'first use' script that attempts to install the required software packages. In the case of GFWL the script falls over as it cannot handle installing GFWL sans .net and the game cannot be played as this first use script cannot be skipped. If you install GFWL as a stand alone application it actually installs without .net 3.5sp1 present. It has a check box in the installer allowing you to continue and makes a note that it will not work until you have .net at the final screen (/nodotnet must be the cli invocation of this). Steam how ever does not check if the redists have been install previously. This was the reason for my suggestion of faking .net being installed to satisfy this Steam script and allow games to be run regardless. Of course leap frogging this issue still leaves GFWL unrunnable. In most games this means you cannot save progress and others not be able to run at all. I take it .net 3.5 support is in the too hard basket?
Re: [9/9] shell32/shellview: Don't crash on ::DragLeave called without droptraget
On 03/13/2010 10:10 PM, Nikolay Sivov wrote: That causes a crash in Office 2k3 Save As menu at least, while trying to drapdrop something. Hi Nikolay, These new tests (don't know which ones of the patchset) introduce test failures on Vista+: http://test.winehq.org/data/tests/shell32:shlview.html Could you have a look? -- Cheers, Paul.
Re: [PATCH] cmd: added some expansion tests. (try 2)
On 03/09/2010 01:15 PM, Yann Droneaud wrote: diff --git a/programs/cmd/tests/test_builtins.cmd b/programs/cmd/tests/test_builtins.cmd index ed2b75b..e346ffa 100644 --- a/programs/cmd/tests/test_builtins.cmd +++ b/programs/cmd/tests/test_builtins.cmd @@ -23,6 +23,21 @@ cd dummydir echo %~dp0 cd .. rmdir dummydir +echo %CD% Hi Yann, This one doesn't work on NT4: http://test.winehq.org/data/tests/cmd.exe:batch.html Could you have a look ? -- Cheers, Paul.
Re: rsaenh(2/6): Add support for SHA-256, SHA-384, and SHA-512 (try 2)
> ULL constants are not portable and should be avoided. Ah, right. Sorry, I only glanced at the source after checking the license. I'll fix and resend (and have a closer look.) --Juan
Re: comctl32: resend [Bug 17251] cchTextMax needs to be set for LVS_OWNERDATA as it uses LVN_GETDISPINFO notifications
On 3/15/2010 16:08, Jeff Latimer wrote: Changed LISTVIEW_EndEditLabel to set up the call to LISTVIEW_GetItemT the same as LISTVIEW_EditLabel If not set then no value is returned and in the case of uTorrent the next entry selected is renamed. http://bugs.winehq.org/show_bug.cgi?id=17251 A test case has proved difficult to construct as the event is triggered by mouse clicks and the behaviour of EditLabel appears to be different in test. --- dlls/comctl32/listview.c |5 - 1 files changed, 4 insertions(+), 1 deletions(-) I think this looks reasonable. Does it fix a bug by the way?
Re: rsaenh(2/6): Add support for SHA-256, SHA-384, and SHA-512 (try 2)
Juan Lang writes:
> +/* Hash constant words K for SHA-384 and SHA-512: */
> +const static sha2_word64 K512[80] = {
> + 0x428a2f98d728ae22ULL, 0x7137449123ef65cdULL,
> + 0xb5c0fbcfec4d3b2fULL, 0xe9b5dba58189dbbcULL,
ULL constants are not portable and should be avoided.
--
Alexandre Julliard
julli...@winehq.org
Re: .net 3.5sp1 status check, blocking GFWL
On Mon, Mar 15, 2010 at 5:55 AM, Dan Kegel wrote: > I guess winetricks should add a gfwl verb that does that, > but we would need a better source for msasn1.dll. There > might be a usable one inside > http://download.microsoft.com/download/d/b/4/db49275f-7741-47cc-b8d5-42a3129499c1/Q835732_xpe_sp2_x86_enu.exe > can somebody try it? > > And then, as http://wiki.winehq.org/msasn1 suggests, we ought to implement > msasn1 in wine. Also, we should see if providing a stub xlive.dll in wine would be useful.
re: .net 3.5sp1 status check, blocking GFWL
The appdb for another game, Fallout 3, http://appdb.winehq.org/objectManager.php?sClass=version&iId=14322 suggests "1) Download msasn1.dll from e.g. here 2) Override msasn1.dll in Wine Configuration. How to Override DLL 3) Download gfwlivesetupmin.exe from e.g. here 4) Install gfwlivesetupmin.exe but without .NET Framework 5) Only set xlive to native in Wine Configuration." The playonlinux script for that game, http://www.playonlinux.com/repository/?script=402 shows that the way to do 4) is wine gfwlivesetupmin.exe /nodotnet Does that help? I guess winetricks should add a gfwl verb that does that, but we would need a better source for msasn1.dll. There might be a usable one inside http://download.microsoft.com/download/d/b/4/db49275f-7741-47cc-b8d5-42a3129499c1/Q835732_xpe_sp2_x86_enu.exe can somebody try it? And then, as http://wiki.winehq.org/msasn1 suggests, we ought to implement msasn1 in wine. - Dan
Re: [PATCH] configure.ac: use proper quoting throughout the file
Le lundi 15 mars 2010 à 13:05 +0100, Alexandre Julliard a écrit : > Yann Droneaud writes: > > >> Note: Quoting were not added for WINE macros related to Makefile generation > >> as they broke things: there are some quoting magic in aclocal.m4 not > >> fixed by this patch. > > > > As stated in the patch log, it can be applied safely. > > > > But once applied on current HEAD, most pending patches on configure.ac > > won't apply. > > Which is why the patch won't be applied. There's no need for such a > large scale cleanup. If some macros really have quoting issues you can > fix those and leave the rest alone. > Yes, I can fix only those. But, the patch was targeting consistency: configure.ac script uses macros sometimes with proper quoting, sometimes not. There's no rule. This patch was trying to ensure that all macro calls were written the same way, so if someone was looking for some copy/paste to add new tests/new features, only sane default would be used. So I'm dropping this patch and will send multiple small fix to specific macro calls. Regards. -- Yann Droneaud
Re: On cygwin, these programs fails because they lack __wargv definition. So adding -mno-cygwin flag tell winegcc to link them with msvcrt instead of libc
Alexandre Goujon writes: > --- > programs/cmd/Makefile.in |2 +- > programs/dxdiag/Makefile.in |2 +- > programs/explorer/Makefile.in|2 +- > programs/extrac32/Makefile.in|2 +- > programs/mshta/Makefile.in |2 +- > programs/reg/Makefile.in |2 +- > programs/start/Makefile.in |2 +- > programs/svchost/Makefile.in |2 +- > programs/termsv/Makefile.in |2 +- > programs/uninstaller/Makefile.in |2 +- > programs/winebrowser/Makefile.in |2 +- > programs/winedevice/Makefile.in |2 +- > programs/winepath/Makefile.in|2 +- > 13 files changed, 13 insertions(+), 13 deletions(-) These apps don't link to msvcrt on purpose. If things are broken on cygwin that needs to be handled in winegcc, you shouldn't have to touch the makefiles. -- Alexandre Julliard julli...@winehq.org
Re: comctl32: [Bug 17251] cchTextMax needs to be set for LVS_OWNERDATA as it uses LVN_GETDISPINFO notifications
On 15/03/10 23:33, Nikolay Sivov wrote: On 3/15/2010 15:08, Jeff Latimer wrote: LISTVIEW_GetItemW Hm, actually EditLabel and EndEditLabel looks quite different. EditLabel uses static buffer, and EndEditLabel doesn't even set a buffer pointer. That's most likely a real problem here, could you try to copy way we call LISTVIEW_GetItemW to EndEditLabel? That looks to be a winner. Will resubmit soon. Ta
Re: comctl32: [Bug 17251] cchTextMax needs to be set for LVS_OWNERDATA as it uses LVN_GETDISPINFO notifications
On 3/15/2010 15:08, Jeff Latimer wrote: LISTVIEW_GetItemW Hm, actually EditLabel and EndEditLabel looks quite different. EditLabel uses static buffer, and EndEditLabel doesn't even set a buffer pointer. That's most likely a real problem here, could you try to copy way we call LISTVIEW_GetItemW to EndEditLabel?
Re: comctl32: [Bug 17251] cchTextMax needs to be set for LVS_OWNERDATA as it uses LVN_GETDISPINFO notifications
On 3/15/2010 15:08, Jeff Latimer wrote:
On 13/03/10 20:30, Nikolay Sivov wrote:
On 3/13/2010 06:35, Jeff Latimer wrote:
If not set then no value is returned and in the case of uTorrent the
next entry selected is renamed.
http://bugs.winehq.org/show_bug.cgi?id=17251
No value returned from what?
LISTVIEW_GetItemW
Ok. From what I see now we have a special path for LVIF_TEXT:
---LISTVIEW_GetItemT---
if (lpLVItem->mask & LVIF_TEXT)
{
if (lpLVItem->mask & LVIF_NORECOMPUTE)
/* reset mask */
dispInfo.item.mask &= ~(LVIF_TEXT | LVIF_NORECOMPUTE);
else
{
dispInfo.item.pszText = lpLVItem->pszText;
dispInfo.item.cchTextMax = lpLVItem->cchTextMax;
}
}
---
So if you request LVIF_TEXT cchTextMax should be overwritten here, if we
are at LVIF_NORECOMPUTE we don't even request LVIF_TEXT.
Have you determine exact cause of failure returning text from
LISTVIEW_GetItemW, including failing path? That's what we really need.
dispInfo.item.iItem = editedItem;
dispInfo.item.iSubItem = 0;
dispInfo.item.stateMask = ~0;
+dispInfo.item.cchTextMax = textlenT(pszText, isW)+2;
if (!LISTVIEW_GetItemW(infoPtr,&dispInfo.item))
Could you explain what this change fixes exactly? As I remember
uTorrent uses an LVS_OWNERDATA listview, so this cchTextMax isn't
processed in LISTVIEW_GetItemW.
I have added some traces and a code fragment to
http://bugs.winehq.org/show_bug.cgi?id=17251 showing the before and
after inserting dispInfo.item.cchTextMax = textlenT(pszText, isW)+2;
into LISTVIEW_EndEditLabelT
Also I'm not sure what you mean here
---
textlenT(pszText, isW)+2
---
pszText is Edit control text at this point (or NULL). How it's
related to LISTVIEW_GetItemW? And what this +2 adding mean?
Yes pszText is Edit control text or NULL. textLenT returns the length
of the without the trailing Null. What's required here is a buffer
at least 1 character longer than pszText+Null so that when
LISTVIEW_GetItemW returns dispInfo.item.pszText we can determine
whether it is longer than pszText. We need +2 at least for this.
I don't get it, sorry. What is a trick here? Assume I'm ok with +1 here,
but how 'it is longer than pszText' is important?
Re: comctl32: [Bug 17251] cchTextMax needs to be set for LVS_OWNERDATA as it uses LVN_GETDISPINFO notifications
On 13/03/10 20:30, Nikolay Sivov wrote: On 3/13/2010 06:35, Jeff Latimer wrote: If not set then no value is returned and in the case of uTorrent the next entry selected is renamed. http://bugs.winehq.org/show_bug.cgi?id=17251 No value returned from what? LISTVIEW_GetItemW dispInfo.item.iItem = editedItem; dispInfo.item.iSubItem = 0; dispInfo.item.stateMask = ~0; +dispInfo.item.cchTextMax = textlenT(pszText, isW)+2; if (!LISTVIEW_GetItemW(infoPtr,&dispInfo.item)) Could you explain what this change fixes exactly? As I remember uTorrent uses an LVS_OWNERDATA listview, so this cchTextMax isn't processed in LISTVIEW_GetItemW. I have added some traces and a code fragment to http://bugs.winehq.org/show_bug.cgi?id=17251 showing the before and after inserting dispInfo.item.cchTextMax = textlenT(pszText, isW)+2; into LISTVIEW_EndEditLabelT Also I'm not sure what you mean here --- textlenT(pszText, isW)+2 --- pszText is Edit control text at this point (or NULL). How it's related to LISTVIEW_GetItemW? And what this +2 adding mean? Yes pszText is Edit control text or NULL. textLenT returns the length of the without the trailing Null. What's required here is a buffer at least 1 character longer than pszText+Null so that when LISTVIEW_GetItemW returns dispInfo.item.pszText we can determine whether it is longer than pszText. We need +2 at least for this.
Re: [PATCH] configure.ac: use proper quoting throughout the file
Yann Droneaud writes: >> Note: Quoting were not added for WINE macros related to Makefile generation >> as they broke things: there are some quoting magic in aclocal.m4 not >> fixed by this patch. > > As stated in the patch log, it can be applied safely. > > But once applied on current HEAD, most pending patches on configure.ac > won't apply. Which is why the patch won't be applied. There's no need for such a large scale cleanup. If some macros really have quoting issues you can fix those and leave the rest alone. -- Alexandre Julliard julli...@winehq.org
Re: Documentation?
Luke Benstead writes: > While on the subject of documentation... would it be a good idea to > begin documenting functions with something like Doxygen or similar? > I'm just wondering if we could be building our own, much more > accurate, MSDN. Is there a reason that Wine isn't documented in this > way? Yes, it's not useful. Wine implements the Win32 API, and there's plenty of documentation for it already. If you want to replicate MSDN you are welcome to do it, but there's no reason to do it in Wine, the Win32 API is not defined by the Wine code. -- Alexandre Julliard julli...@winehq.org
Re: [PATCH] configure.ac: use proper quoting throughout the file
Hi, Le lundi 15 mars 2010 à 11:13 +0100, Yann Droneaud a écrit : > Added quoting around macro parameters as recommanded by autoconf: > http://www.gnu.org/software/autoconf/manual/html_node/Autoconf-Language.html#Autoconf-Language > > Autoconf output was checked to be the same with and without the patch, > so that it's easy to validate the patch: configure script is exactly the > same with or without the patch. > > Note: Quoting were not added for WINE macros related to Makefile generation > as they broke things: there are some quoting magic in aclocal.m4 not > fixed by this patch. As stated in the patch log, it can be applied safely. But once applied on current HEAD, most pending patches on configure.ac won't apply. So if this patch is going to be applied, developer must be warned first and hold their own patches. I'm ok to hold this one a week or two, so pending patches could be applied without modification before this one get applied. I have another patches waiting to fix some autoconf constructs. Regards. -- Yann Droneaud
