October 2010 - Wine-Devel - list.winehq.org

Re: [3/5] mscoree: Add test for creating CLRMetaHost.

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=5753 Your paranoid android. === WINEBUILD (build) === Make in include dir failed

Oct. 3, 2010

Re: Question on use of TextMetricsW

by Paul Vriens

On 10/03/2010 08:44 PM, James McKenzie wrote: > All: > > I am running code like the following in a richedit control to set the > font to Courier 12 point font: > > > + static const WCHAR courier[] = {'C','o','u','r','i','e','r',0}; > + testFont1 = CreateFontW (12,0,0,0,FW_LIGHT, 0, 0, 0, ANSI_CHARSET, > + OUT_DEFAULT_PRECIS, CLIP_DEFAULT_PRECIS, DEFAULT_QUALITY, DEFAULT_PITCH | > + FF_DONTCARE, courier); > + > + /*Set test font to be Courier font */ > + SendMessageW(hwndRichEdit, WM_SETFONT, (WPARAM)testFont1, > MAKELPARAM(TRUE, 0)); > + /*Verify font is set */ > + SendMessageW(hwndRichEdit, EM_GETCHARFORMAT, SCF_DEFAULT, (LPARAM) > &CharFont1Unicode); > + GetObjectW(testFont1, sizeof(LOGFONTW), &sentLogFont); > + ok (!lstrcmpW(sentLogFont.lfFaceName, CharFont1Unicode.szFaceName), > "WM_SETFONT set wrong font. " \ > + "Font was set to %s or %s, was supposed to be \"Courier\".\n", > wine_dbgstr_w(CharFont1Unicode.szFaceName), > wine_dbgstr_w(sentLogFont.lfFaceName)); > + > + ret = GetTextMetricsW (hdc, &tmw); > + ok (ret, "GetTextMetricsW failed\n"); > + > + ok (7 == tmw.tmAveCharWidth, "Average Character Width for Courier 12 > is %d\n", tmw.tmAveCharWidth); > > I also set the font to MS Sans Serif, and two different font sizes for > Arial. However, the tmAveCharWidth value remains at 7 and I am of the > opinion that this should change for each font change and also for the > font size change. Am I doing something improper? Should I clear the tmw > structure between calls to GetTextMetricsW? > > When I run this on native WindowsXP (which I have access to) the average > character width changes to 9, but remains the same for all four font types. > TTIA. > > James McKenzie > > > Hi James, Doesn't the WM_SETFONT only set it for the control? You are retrieving the font characteristics from the DC though. -- Cheers, Paul.

Oct. 3, 2010

Re: (5th try) winhlp32: Added Hebrew translation

by Paul Vriens

On 10/03/2010 05:04 PM, Yaron Shahrabani wrote: > + > +LANGUAGE LANG_ENGLISH, SUBLANG_DEFAULT > + Hi Yaron, This piece should go. And I still have an apply warning for your Makefile.in patch. -- Cheers, Paul.

Oct. 3, 2010

Question on use of TextMetricsW

by James McKenzie

All: I am running code like the following in a richedit control to set the font to Courier 12 point font: + static const WCHAR courier[] = {'C','o','u','r','i','e','r',0}; + testFont1 = CreateFontW (12,0,0,0,FW_LIGHT, 0, 0, 0, ANSI_CHARSET, + OUT_DEFAULT_PRECIS, CLIP_DEFAULT_PRECIS, DEFAULT_QUALITY, DEFAULT_PITCH | + FF_DONTCARE, courier); + + /*Set test font to be Courier font */ + SendMessageW(hwndRichEdit, WM_SETFONT, (WPARAM)testFont1, MAKELPARAM(TRUE, 0)); + /*Verify font is set */ + SendMessageW(hwndRichEdit, EM_GETCHARFORMAT, SCF_DEFAULT, (LPARAM) &CharFont1Unicode); + GetObjectW(testFont1, sizeof(LOGFONTW), &sentLogFont); + ok (!lstrcmpW(sentLogFont.lfFaceName, CharFont1Unicode.szFaceName), "WM_SETFONT set wrong font. " \ + "Font was set to %s or %s, was supposed to be \"Courier\".\n", wine_dbgstr_w(CharFont1Unicode.szFaceName), wine_dbgstr_w(sentLogFont.lfFaceName)); + + ret = GetTextMetricsW (hdc, &tmw); + ok (ret, "GetTextMetricsW failed\n"); + + ok (7 == tmw.tmAveCharWidth, "Average Character Width for Courier 12 is %d\n", tmw.tmAveCharWidth); I also set the font to MS Sans Serif, and two different font sizes for Arial. However, the tmAveCharWidth value remains at 7 and I am of the opinion that this should change for each font change and also for the font size change. Am I doing something improper? Should I clear the tmw structure between calls to GetTextMetricsW? When I run this on native WindowsXP (which I have access to) the average character width changes to 9, but remains the same for all four font types. TTIA. James McKenzie

Oct. 3, 2010

Re: include: Added d3d10_1.idl.

by Rico Schüller

Am 02.10.2010 15:29, schrieb Jacek Caban: +typedef enum D3D10_SRV_DIMENSION1 +{ + D3D10_1_SRV_DIMENSION_UNKNOWN = 0, ... + D3D10_1_SRV_DIMENSION_TEXTURECUBE = 9, + D3D10_1_SRV_DIMENSION_TEXTURECUBEARRAY = 10 +} D3D10_SRV_DIMENSION1; You probably might add those to d3dcommon.h and only add a typedef. It was changed in one of the sdks. Cheers Rico

Oct. 3, 2010

Re: cmd: Add a space at the end of the first echo'ed batch line

by GOUJON Alexandre

On 10/03/2010 03:37 PM, Jacek Caban wrote: > @todo_space@ is meant to do tests in todo_wine block. You should > change @todo_space@ to spec in .exp file instead. If we're convinced > that the whole keyword is not useful anymore, the whole handling code > should be removed (although I think we'd better keep it). I just sent a try2 and I changed the .exp file instead. I guess you meant space (0x20) by 'spec'. > More tests would be nice. Done. In fact, I just duplicated the echo section of the test with echo on then echo off. > Jacek Thanks for your comment

Oct. 3, 2010

Re: [PATCH1/3] include/winternl: Add Logical Processor Information to SYSTEM_CPU_INFORMATION

by Rudolf Mayerhofer

On Sunday 03 October 2010 16:22:07 Eric Pouech wrote: > > SystemCpuInformation seems not defined anywhere outside Wine. > > It's not defined on MSDN, neither can it be found on any Wine-unrelated > > Documentations/Source-codes or Documentations. If you have any links or > > documentation for SystemCpuInformation, could you send them please ? > > > > If i can't extend the struct, i think it would be easier to just move the > > parser into kernel32/process as well and avoid modifiying this interface > > as NtQuerySystemInformation is marked as deprecated on MSDN anyway. > > try SystemProcessorInformation and SYSTEM_PROCESSOR_INFORMATION (instead > of SystemCpuInformation and SYSTEM_CPU_INFORMATION) and you'll see that > it's not Wine specific. so you cannot extend them > > moreover, don't trust MSDN... they're simply saying that if there's the > same API in kernel32 it should be prefered over it's ntdll counterpart... > > regarding your patch, the core of the work has to be done in ntdll. you > just have to find the correct API in ntdll that does the job > you're not using the right one (at least for the class of the query) > for example, SystemNumaProcessorMap could help you... (even I coudn't > find some docs about the structures, but I didn't search a lot), and > reverse engineering (using ntdll as a blackbox) may be of some help > > A+ I just found out that SystemProcessorInformation is the same as SystemCpuInformation in Wine, both of them are SystemClass 0x01, so that class won't be of much help either. Thats also why i couldn't find anything related to SystemCpuInformation and that also means that my first set of patches was definitly the wrong approach. Since i had some free time today, i have rewritten and submitted the patch not using the ntdll interface as i suggested before already. I'll also try to find out if there is any usable SystemClass, hopefully there is one.

Oct. 3, 2010

Re: [PATCH1/3] include/winternl: Add Logical Processor Information to SYSTEM_CPU_INFORMATION

by Eric Pouech

> SystemCpuInformation seems not defined anywhere outside Wine. > It's not defined on MSDN, neither can it be found on any Wine-unrelated > Documentations/Source-codes or Documentations. If you have any links or > documentation for SystemCpuInformation, could you send them please ? > > If i can't extend the struct, i think it would be easier to just move the > parser into kernel32/process as well and avoid modifiying this interface as > NtQuerySystemInformation is marked as deprecated on MSDN anyway. > try SystemProcessorInformation and SYSTEM_PROCESSOR_INFORMATION (instead of SystemCpuInformation and SYSTEM_CPU_INFORMATION) and you'll see that it's not Wine specific. so you cannot extend them moreover, don't trust MSDN... they're simply saying that if there's the same API in kernel32 it should be prefered over it's ntdll counterpart... regarding your patch, the core of the work has to be done in ntdll. you just have to find the correct API in ntdll that does the job you're not using the right one (at least for the class of the query) for example, SystemNumaProcessorMap could help you... (even I coudn't find some docs about the structures, but I didn't search a lot), and reverse engineering (using ntdll as a blackbox) may be of some help A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

Oct. 3, 2010

Re: cmd: Add a space at the end of the first echo'ed batch line

by Jacek Caban

On 10/3/10 1:18 PM, Alexandre Goujon wrote: > --- > programs/cmd/tests/batch.c | 2 +- > programs/cmd/wcmdmain.c | 3 +++ > 2 files changed, 4 insertions(+), 1 deletions(-) > > diff --git a/programs/cmd/tests/batch.c b/programs/cmd/tests/batch.c > index cc8c020..d7a5e84 100644 > --- a/programs/cmd/tests/batch.c > +++ b/programs/cmd/tests/batch.c > @@ -131,7 +131,7 @@ static const char *compare_line(const char *out_line, const char *out_end, const > }else if(exp_ptr+sizeof(todo_space_cmd)<= exp_end > && !memcmp(exp_ptr, todo_space_cmd, sizeof(todo_space_cmd))) { > exp_ptr += sizeof(todo_space_cmd); > - todo_wine ok(*out_ptr == ' ', "expected space\n"); > + ok(*out_ptr == ' ', "expected space\n"); @todo_space@ is meant to do tests in todo_wine block. You should change @todo_space@ to spec in .exp file instead. If we're convinced that the whole keyword is not useful anymore, the whole handling code should be removed (although I think we'd better keep it). > if(out_ptr< out_end&& *out_ptr == ' ') > out_ptr++; > continue; > diff --git a/programs/cmd/wcmdmain.c b/programs/cmd/wcmdmain.c > index b50512e..247457a 100644 > --- a/programs/cmd/wcmdmain.c > +++ b/programs/cmd/wcmdmain.c > @@ -1779,8 +1779,11 @@ WCHAR *WCMD_ReadAndParseLine(WCHAR *optionalcmd, CMD_LIST **output, HANDLE readF > if (context) handleExpansion(extraSpace, FALSE, NULL, NULL); > /* Show prompt before batch line IF echo is on and in batch program */ > if (context&& echo_mode&& extraSpace[0]&& (extraSpace[0] != '@')) { > + const WCHAR spc[] = {' ','\0'}; > WCMD_show_prompt(); > WCMD_output_asis(extraSpace); > + /* I don't know why Windows puts a space here but it does */ > + WCMD_output_asis(spc); More tests would be nice. Jacek

Oct. 3, 2010

Re: [PATCH 1/2] mshtml: add support for the HTMLWindow.onunload event.

by Jacek Caban

On 10/3/10 2:24 PM, Reece Dunn wrote: > Implements HTMLWindow_get/put_onunload. + {unloadW, onunloadW, EVENTT_NONE, DISPID_EVMETH_ONUNLOAD, + EVENT_DEFAULTLISTENER|EVENT_FORWARDBODY} EVENT_DEFAULTLISTENER won't work well here. Same for your onerror patch. Jacek

Oct. 3, 2010

Re: [PATCH1/3] include/winternl: Add Logical Processor Information to SYSTEM_CPU_INFORMATION

by Rudolf Mayerhofer

On Sunday 03 October 2010 09:34:02 Dmitry Timoshkov wrote: > Rudolf Mayerhofer <rm(a)eightyfive.net> wrote: > > > Are the additions to the structures your own invention? > > > > Yes, as SystemClass 0x01 and struct SYSTEM_CPU_INFORMATION seem to be > > Wine- only (I could not find anything related to that on MSDN and > > Googling it brings just references to Wine up). So it seems this struct > > was added for internal use in Wine (wineboot to be exact). > > NtQuerySystemInfo/SystemCpuInformation is a public ntdll interface, you > can't add custom extensions to it. SystemCpuInformation seems not defined anywhere outside Wine. It's not defined on MSDN, neither can it be found on any Wine-unrelated Documentations/Source-codes or Documentations. If you have any links or documentation for SystemCpuInformation, could you send them please ? If i can't extend the struct, i think it would be easier to just move the parser into kernel32/process as well and avoid modifiying this interface as NtQuerySystemInformation is marked as deprecated on MSDN anyway.

Oct. 3, 2010

Re: [PATCH1/3] include/winternl: Add Logical Processor Information to SYSTEM_CPU_INFORMATION

by Dmitry Timoshkov

Rudolf Mayerhofer <rm(a)eightyfive.net> wrote: > > Are the additions to the structures your own invention? > > Yes, as SystemClass 0x01 and struct SYSTEM_CPU_INFORMATION seem to be Wine- > only (I could not find anything related to that on MSDN and Googling it brings > just references to Wine up). So it seems this struct was added for internal > use in Wine (wineboot to be exact). NtQuerySystemInfo/SystemCpuInformation is a public ntdll interface, you can't add custom extensions to it. -- Dmitry.

Oct. 3, 2010

Re: oleaut32/tests: added tests for negative fractional variant dates.

by James McKenzie

On 10/2/10 7:00 PM, Jeremy Drake wrote: > On Sat, 2 Oct 2010, James McKenzie wrote: > >> Looks like you got 'bit' by the way that a finite storage method mangles >> floating information. There was a lengthy discussion on how to 'overcome' >> this on the Wine-Development list a short while ago. > No, those tests aleady account for that. > > /* When comparing floating point values we cannot expect an exact match > * because the rounding errors depend on the exact algorithm. > */ > #define EQ_DOUBLE(a,b) (fabs((a)-(b)) / (1.0+fabs(a)+fabs(b))< 1e-14) > #define EQ_FLOAT(a,b) (fabs((a)-(b)) / (1.0+fabs(a)+fabs(b))< 1e-7) > > ok_(__FILE__,line)(r == res&& (FAILED(r) || EQ_DOUBLE(out, dt)), > "expected %x, %.16g, got %x, %.16g\n", r, dt, res, > out); > > > My understanding is that that algorithm should work to account for > floating-point inaccuracies (though technically should be using > DBL_EPSILON and FLT_EPSILON instead of 1e-X constants, but they're > probably not portable enough for this project), > > I was simply bit by my own stupidity, not running my last changes against > a Windows OS before sending my patch. This has been corrected in my try2. Ok. I seen that. However, will this work in Wine as well might come up as it has before. I don't want to raise the 'noise' level and I did not see [try 2] before making my comment, but this might be something you want to keep in mind for the future. Also, please be aware that my comment is based on a previous thread, which you still might want to visit, in this mailing list/forum. It may save you time and give you something to think about in regards to this patch and future patches. Note: My comment is not based on actual programming experience using the Epsilon features and code, but rather on previous comments. I'm just a simple programmer who tests Wine on the Mac platform. Since I tend to remove messages as they no longer apply to my personal habits, however I did find a pointer to the following document written by Bruce Dawson: http://www.cygnus-software.com/papers/comparingfloats/comparingfloats.htm This came from http://www.winehq.org/pipermail/wine-devel/2010-July/085089.html It looks like you read through it, based on a review of the proposed patch. I don't know if this can be applied to the ok() checks though. James McKenzie

Oct. 2, 2010

Re: oleaut32/tests: added tests for negative fractional variant dates.

by Jeremy Drake

On Sat, 2 Oct 2010, James McKenzie wrote: > Looks like you got 'bit' by the way that a finite storage method mangles > floating information. There was a lengthy discussion on how to 'overcome' > this on the Wine-Development list a short while ago. No, those tests aleady account for that. /* When comparing floating point values we cannot expect an exact match * because the rounding errors depend on the exact algorithm. */ #define EQ_DOUBLE(a,b) (fabs((a)-(b)) / (1.0+fabs(a)+fabs(b)) < 1e-14) #define EQ_FLOAT(a,b) (fabs((a)-(b)) / (1.0+fabs(a)+fabs(b)) < 1e-7) ok_(__FILE__,line)(r == res && (FAILED(r) || EQ_DOUBLE(out, dt)), "expected %x, %.16g, got %x, %.16g\n", r, dt, res, out); My understanding is that that algorithm should work to account for floating-point inaccuracies (though technically should be using DBL_EPSILON and FLT_EPSILON instead of 1e-X constants, but they're probably not portable enough for this project), I was simply bit by my own stupidity, not running my last changes against a Windows OS before sending my patch. This has been corrected in my try2. > Maybe Dan Kegel can step in and refresh this. > > James McKenzie > -- The older I grow, the less important the comma becomes. Let the reader catch his own breath. -- Elizabeth Clarkson Zwart

Oct. 2, 2010

Re: oleaut32/tests: added tests for negative fractional variant dates.

by James McKenzie

On 10/2/10 10:13 AM, (Marvin) wrote: > Hi, > > While running your changed tests on Windows, I think I found new failures. > Being a bot and all I'm not very good at pattern recognition, so I might be > wrong, but could you please double-check? > Full results can be found at > http://testbot.winehq.org/JobDetails.pl?Key=5729 > > Your paranoid android. > > > === W98SE (32 bit vartest) === > vartest.c:1685: Test failed: expected 0, -5.99998846, got 0, -5.999988425925926 Looks like you got 'bit' by the way that a finite storage method mangles floating information. There was a lengthy discussion on how to 'overcome' this on the Wine-Development list a short while ago. Maybe Dan Kegel can step in and refresh this. James McKenzie

Oct. 2, 2010

Re: Git server down?

by James McKenzie

On 10/2/10 1:29 PM, Austin English wrote: > On Sat, Oct 2, 2010 at 12:05 PM, Joel Holdsworth > <joel(a)airwebreathe.org.uk> wrote: >> "nmap source.winehq.org" shows no git port. Any ideas? > Seems okay now: > PORT STATE SERVICE > 21/tcp open ftp > 22/tcp open ssh > 53/tcp open domain > 80/tcp open http > 993/tcp open imaps > 2401/tcp open cvspserver Should this port be open considering the CVS server was discontinued? Just asking. If this is used for git as well, I'll have learned something today. James McKenzie

Oct. 2, 2010

Re: Git server down?

by Austin English

On Sat, Oct 2, 2010 at 12:05 PM, Joel Holdsworth <joel(a)airwebreathe.org.uk> wrote: > "nmap source.winehq.org" shows no git port. Any ideas? Seems okay now: PORT STATE SERVICE 21/tcp open ftp 22/tcp open ssh 53/tcp open domain 80/tcp open http 993/tcp open imaps 2401/tcp open cvspserver 5999/tcp closed ncd-conf 8080/tcp closed http-proxy 9418/tcp open unknown -- -Austin

Oct. 2, 2010

Git server down?

by Joel Holdsworth

"nmap source.winehq.org" shows no git port. Any ideas?

Oct. 2, 2010

Re: oleaut32/tests: added tests for negative fractional variant dates.

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=5729 Your paranoid android. === W98SE (32 bit vartest) === vartest.c:1685: Test failed: expected 0, -5.99998846, got 0, -5.999988425925926 === WNT4WSSP6 (32 bit vartest) === vartest.c:1685: Test failed: expected 0, -5.99998846, got 0, -5.999988425925926 === W2KPROSP4 (32 bit vartest) === vartest.c:1685: Test failed: expected 0, -5.99998846, got 0, -5.999988425925926 === WXPPROSP3 (32 bit vartest) === vartest.c:1685: Test failed: expected 0, -5.99998846, got 0, -5.999988425925926 === W2K3R2SESP2 (32 bit vartest) === vartest.c:1685: Test failed: expected 0, -5.99998846, got 0, -5.999988425925926 === WVISTAADM (32 bit vartest) === vartest.c:1685: Test failed: expected 0, -5.99998846, got 0, -5.999988425925926 === W2K8SE (32 bit vartest) === vartest.c:1685: Test failed: expected 0, -5.99998846, got 0, -5.999988425925926 === W7PRO (32 bit vartest) === vartest.c:1685: Test failed: expected 0, -5.99998846, got 0, -5.999988425925926 === W7PROX64 (32 bit vartest) === vartest.c:1685: Test failed: expected 0, -5.99998846, got 0, -5.999988425925926 === W7PROX64 (64 bit vartest) === vartest.c:1685: Test failed: expected 0, -5.99998846, got 0, -5.999988425925926

Oct. 2, 2010

Re: cabinet/tests: Reformated output in case of test failure

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=5725 Your paranoid android. === WINEBUILD (build) === Patch failed

Oct. 2, 2010

Re: [PATCH] winmm/tests: Set a struct member to 0 is obsolete, after adding a memset

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=5717 Your paranoid android. === W7PRO (32 bit midi) === midi.c:238: Test failed: bad message 1e/0 from midiOutOpen, expect 3c7/0 midi.c:295: Test failed: bad message 1e/0 from midiOutLong unprepared, expect 0/feedf00d midi.c:321: Test failed: bad message 1e/0 from midiOutClose, expect 3c8/0 midi.c:322: Test failed: bad message 3c7/0 from midiOut over, expect 0/feedf00d midi.c:398: Test failed: bad message 3c8/0 from midiStreamOpen, expect 3c7/0 midi.c:419: Test failed: bad message 3c7/0 from midiOutLong unprepared, expect 0/feedf00d

Oct. 2, 2010

Re: [PATCH] jscript: throw TypeError if T in 'new T' is not an object. [try 3]

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=5709 Your paranoid android. === W98SE (32 bit) === No test summary line found === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found

Oct. 2, 2010

Re: mshtml.inf: Add default GeckoCabDir

by Jacek Caban

On 10/2/10 4:19 PM, Scott Ritchie wrote: > On 10/01/2010 07:25 AM, Alexandre Julliard wrote: >> Jacek Caban<jacek(a)codeweavers.com> writes: >> >>> That's a matter of trivial patch, but what would be the candidate for >>> a path hardcode? '/usr/share/wine/gecko/' seems like the best choice >>> since that's where most distros will install Gecko. >> I'd say try $datadir and then /usr/share. >> > I would add /usr/local/share in between those two. Distro packages are > supposed to go into /usr, but non distro packages go to /usr/local (eg > where make install will put things). So you might want a gecko > different from the distro provided one that you built yourself, for > instance, but also to have it system wide. That's what $datadir is for. If you install your build in /usr/local, it will use /usr/local/share first, then /usr/share (after committing the patch). Jacek

Oct. 2, 2010

Re: mshtml.inf: Add default GeckoCabDir

by Scott Ritchie

On 10/01/2010 07:25 AM, Alexandre Julliard wrote: > Jacek Caban <jacek(a)codeweavers.com> writes: > >> That's a matter of trivial patch, but what would be the candidate for >> a path hardcode? '/usr/share/wine/gecko/' seems like the best choice >> since that's where most distros will install Gecko. > > I'd say try $datadir and then /usr/share. > I would add /usr/local/share in between those two. Distro packages are supposed to go into /usr, but non distro packages go to /usr/local (eg where make install will put things). So you might want a gecko different from the distro provided one that you built yourself, for instance, but also to have it system wide.

Oct. 2, 2010

Re: mshtml.inf: Add default GeckoCabDir

by Jacek Caban

On 10/1/10 4:25 PM, Alexandre Julliard wrote: > Jacek Caban<jacek(a)codeweavers.com> writes: >> That's a matter of trivial patch, but what would be the candidate for >> a path hardcode? '/usr/share/wine/gecko/' seems like the best choice >> since that's where most distros will install Gecko. > I'd say try $datadir and then /usr/share. OK, that's what my patch does. >> - Windows has builtin support for ZIP files. It's hidden behind an >> obscure APIs, but it's something we could implement and use in MSHTML. >> - Use .tar.gz files. We already use zlib in Wine, we could use it in >> MSHTML. tar format is simple enough to implement its custom handling. >> - Any other idea? > A self-extracting zip may be an option too, not sure how easy they are > to create on Linux. I like the idea. I guess we'd want zip files to be PE, as they are more portable for us. I haven't found such tool after a quick search. p7zip can create self-extracting 7z files (I guess format doesn't really matter as long as it's self-extracting), but only for an architecture it's built on, which would be Linux in our case. However, it should be possible to patch p7zip. All the coded needed for this is in place, we'd just have to teach it to choose architecture in runtime instead of build time and teach it about mingw. > And while you are making changes, adding a checksum > would be a good idea. It was always the plan, but never important enough. I will add it together with other changes. > A more ambitious approach would be to define a generic "Wine add-ons" > mechanism that could also be used for Mono. This would avoid having > detailed knowledge about file formats and download URLs spread around in > various DLLs. Maybe this could go in the appwiz control panel, with a > nice UI showing which add-ons are installed. Sounds like a great idea. Cleaning up Gecko install process is a step in this direction. It would also require changing Vincent's plans of not providing our Mono builds. Thanks, Jacek

Oct. 2, 2010

Re: [PATCH1/3] include/winternl: Add Logical Processor Information to SYSTEM_CPU_INFORMATION

by Rudolf Mayerhofer

On Saturday 02 October 2010 15:15:48 Dmitry Timoshkov wrote: > Rudolf Mayerhofer <rm(a)eightyfive.net> wrote: > > This is used in NTDLL and Kernel32 to provide an Implementation for > > kernel32's GetLogicalProcessorInformation(). > > Are the additions to the structures your own invention? Yes, as SystemClass 0x01 and struct SYSTEM_CPU_INFORMATION seem to be Wine- only (I could not find anything related to that on MSDN and Googling it brings just references to Wine up). So it seems this struct was added for internal use in Wine (wineboot to be exact). Using NtQuerySystemInfo for Class SystemCpuInformation seemed logical for use because Logical Processor Information is related to CPU Information and also because GetLogicalProcessorInformation needs to know if the processor is Hyperthreading capable (which is found in Element FeatureSet) to set a flag. As stated above the struct seems to be wine-internal anyway, so i simply added the missing elements for Cores, Processor Packages, Numa Nodes and Cache Descriptors there. After that was done. The only things left to do were (Patches 2 and 3): - Implementing GetLogicalProcessorInformation() in kernel32/process.c with NtQuerySystemInformation. - Adding the parser for SysFS Information to fill_cpu_info() in ntdll/nt.c (which already parses /proc/cpuinfo for the data in struct SYSTEM_CPU_INFORMATION)

Oct. 2, 2010

Re: [PATCH1/3] include/winternl: Add Logical Processor Information to SYSTEM_CPU_INFORMATION

by Dmitry Timoshkov

Rudolf Mayerhofer <rm(a)eightyfive.net> wrote: > This is used in NTDLL and Kernel32 to provide an Implementation for kernel32's > GetLogicalProcessorInformation(). Are the additions to the structures your own invention? -- Dmitry.

Oct. 2, 2010

Re: [PATCH1/3] include/winternl: Add Logical Processor Information to SYSTEM_CPU_INFORMATION

by Luca Bennati

2010/10/2 Rudolf Mayerhofer <rm(a)eightyfive.net> > On Saturday 02 October 2010 08:15:46 Dmitry Timoshkov wrote: > > Rudolf Mayerhofer <rm(a)eightyfive.net> wrote: > > > /* System Information Class 0x01 */ > > > > > > +typedef struct _SYSTEM_CPU_CACHE_INFORMATION { > > > + ULONG ProcessorMask; > > > + CACHE_DESCRIPTOR CacheInformation; > > > +} SYSTEM_CPU_CACHE_INFORMATION, *PSYSTEM_CPU_CACHE_INFORMATION; > > > > > > typedef struct _SYSTEM_CPU_INFORMATION { > > > > > > WORD Architecture; > > > > > > @@ -1100,6 +1104,10 @@ typedef struct _SYSTEM_CPU_INFORMATION { > > > > > > WORD Revision; /* combination of CPU model and stepping */ > > > WORD Reserved; /* always zero */ > > > DWORD FeatureSet; /* see bit flags below */ > > > > > > + ULONG Cores[64]; /* Contains a Processormask for each > physical > > > core. Index is CoreID*/ + ULONG ProcessorPackages[64]; /* Contains a > > > Processormask for each processorpackage. Index is ProcessorPackage ID*/ > > > + ULONG NumaNodes[64]; /* Contains a Processormask for each numa > > > node. Index is NumaNodeNumber */ + SYSTEM_CPU_CACHE_INFORMATION > > > Caches[256]; /* Contains all cpu cache entries found */ > > > > > > } SYSTEM_CPU_INFORMATION, *PSYSTEM_CPU_INFORMATION; > > > > Where does this come from? At least the processor mask is supposed > > to be an ULONG_PTR. > > You're right. Seem that i have missed that Processormask is ULONG_PTR, will > update that ASAP. > > This is used in NTDLL and Kernel32 to provide an Implementation for > kernel32's > GetLogicalProcessorInformation(). > > > You should break long lines (like the ones on patch 3/3) into lines of 100 characters max

Oct. 2, 2010

Re: [PATCH1/3] include/winternl: Add Logical Processor Information to SYSTEM_CPU_INFORMATION

by Rudolf Mayerhofer

On Saturday 02 October 2010 08:15:46 Dmitry Timoshkov wrote: > Rudolf Mayerhofer <rm(a)eightyfive.net> wrote: > > /* System Information Class 0x01 */ > > > > +typedef struct _SYSTEM_CPU_CACHE_INFORMATION { > > + ULONG ProcessorMask; > > + CACHE_DESCRIPTOR CacheInformation; > > +} SYSTEM_CPU_CACHE_INFORMATION, *PSYSTEM_CPU_CACHE_INFORMATION; > > > > typedef struct _SYSTEM_CPU_INFORMATION { > > > > WORD Architecture; > > > > @@ -1100,6 +1104,10 @@ typedef struct _SYSTEM_CPU_INFORMATION { > > > > WORD Revision; /* combination of CPU model and stepping */ > > WORD Reserved; /* always zero */ > > DWORD FeatureSet; /* see bit flags below */ > > > > + ULONG Cores[64]; /* Contains a Processormask for each physical > > core. Index is CoreID*/ + ULONG ProcessorPackages[64]; /* Contains a > > Processormask for each processorpackage. Index is ProcessorPackage ID*/ > > + ULONG NumaNodes[64]; /* Contains a Processormask for each numa > > node. Index is NumaNodeNumber */ + SYSTEM_CPU_CACHE_INFORMATION > > Caches[256]; /* Contains all cpu cache entries found */ > > > > } SYSTEM_CPU_INFORMATION, *PSYSTEM_CPU_INFORMATION; > > Where does this come from? At least the processor mask is supposed > to be an ULONG_PTR. You're right. Seem that i have missed that Processormask is ULONG_PTR, will update that ASAP. This is used in NTDLL and Kernel32 to provide an Implementation for kernel32's GetLogicalProcessorInformation().

Oct. 2, 2010

Re: ntdll: Fix 64 bit issue within NTDLL_mergesort().

by Marcus Meissner

On Sat, Oct 02, 2010 at 12:31:03AM +0200, Stefan Oberhumer wrote: > --- > dlls/ntdll/misc.c | 6 +++--- > 1 files changed, 3 insertions(+), 3 deletions(-) > What is the alleged 64bit problem here? left and right are indexes, not sizes actually. Ciao, Marcus > diff --git a/dlls/ntdll/misc.c b/dlls/ntdll/misc.c > index 2d7c0a7..39b0ad3 100644 > --- a/dlls/ntdll/misc.c > +++ b/dlls/ntdll/misc.c > @@ -255,11 +255,11 @@ double CDECL NTDLL_tan( double d ) > > /* Merge Sort. Algorithm taken from http://www.linux-related.de/index.html?/coding/sort/sort_merge.htm */ > static void > -NTDLL_mergesort( void *arr, void *barr, int elemsize, int(__cdecl *compar)(const void *, const void *), > - int left, int right ) > +NTDLL_mergesort( void *arr, void *barr, size_t elemsize, int(__cdecl *compar)(const void *, const void *), > + size_t left, size_t right ) > { > if(right>left) { > - int i, j, k, m; > + size_t i, j, k, m; > m=(right+left)/2; > NTDLL_mergesort( arr, barr, elemsize, compar, left, m); > NTDLL_mergesort( arr, barr, elemsize, compar, m+1, right); > >

Oct. 2, 2010

Re: msxml3: Use the existing READYSTAT type instead of creating our own enum READYSTAT (and mixing the two).

by Nikolay Sivov

> If there_is_ a reason to keep the two separate, I strongly suggest to > use different names (having a typedef READYSTAT as well as an enum by > that name is tricky) and someone needs to look in the mixing of types > that happens in line 277. Makes sense, yes. Honestly I didn't check for this type to be defined already, and it just happens to use the same name.

Oct. 2, 2010

Re: oleaut32/tests: added tests for negative fractional variant dates.

by Jeremy Drake

Oops, those empty parens () were intended to cite the URL for the article. Unfortunately, I can't seem to find it now. However, I found an MSDN page that describes the behavior I am testing here: http://msdn.microsoft.com/en-us/library/system.datetime.fromoadate.aspx This is actually documentation of a .NET method, but see the Remarks section for a description of the format. On Fri, 1 Oct 2010, Jeremy Drake wrote: > I recently read an article () mentioning some of the oddities that show up > in negative variant dates with non-zero (midnight) times, and I noticed > that wine had no test coverage for these cases. Until now. > > > > --- > dlls/oleaut32/tests/vartest.c | 32 +++++++++++++++++++++++--------- > 1 files changed, 23 insertions(+), 9 deletions(-) -- Egotist, n.: A person of low taste, more interested in himself than me. -- Ambrose Bierce, "The Devil's Dictionary"

Oct. 2, 2010

Re: [PATCH1/3] include/winternl: Add Logical Processor Information to SYSTEM_CPU_INFORMATION

by Dmitry Timoshkov

Rudolf Mayerhofer <rm(a)eightyfive.net> wrote: > /* System Information Class 0x01 */ > +typedef struct _SYSTEM_CPU_CACHE_INFORMATION { > + ULONG ProcessorMask; > + CACHE_DESCRIPTOR CacheInformation; > +} SYSTEM_CPU_CACHE_INFORMATION, *PSYSTEM_CPU_CACHE_INFORMATION; > > typedef struct _SYSTEM_CPU_INFORMATION { > WORD Architecture; > @@ -1100,6 +1104,10 @@ typedef struct _SYSTEM_CPU_INFORMATION { > WORD Revision; /* combination of CPU model and stepping */ > WORD Reserved; /* always zero */ > DWORD FeatureSet; /* see bit flags below */ > + ULONG Cores[64]; /* Contains a Processormask for each physical core. Index is CoreID*/ > + ULONG ProcessorPackages[64]; /* Contains a Processormask for each processorpackage. Index is ProcessorPackage ID*/ > + ULONG NumaNodes[64]; /* Contains a Processormask for each numa node. Index is NumaNodeNumber */ > + SYSTEM_CPU_CACHE_INFORMATION Caches[256]; /* Contains all cpu cache entries found */ > } SYSTEM_CPU_INFORMATION, *PSYSTEM_CPU_INFORMATION; Where does this come from? At least the processor mask is supposed to be an ULONG_PTR. -- Dmitry.

Oct. 2, 2010

mono packaging, for wine packagers or anyone else who wants to follow along

by Vincent Povirk

Buried in the 1.3.4 announcement is a tiny, insignificant little change that makes it possible for distributors to package Mono for Wine: mscoree: Search for Mono in some predefined paths before using the registry. As happy as I am to have sneaked this in under the radar, as it were, I guess I'm going to have to tell someone if it's ever going to be useful. I have no plans to make an official Wine Mono distribution. It should be easy enough for anyone to build. We currently do not require any changes in Mono for use with Wine. When we do (and it will be soon), I will try very hard to get the things we need merged upstream. Any managed libraries we need instead of or in addition to those shipped with Mono will have to go in Wine. We don't need a fork yet, and I hope we can keep it that way. Mono installs are generally self-contained and do not interfere with each other. Mono does not have to be installed into a bottle before it can be used. Therefore, I have not programmed any sort of install process into Wine. It will simply search for Mono as needed. If you are a distributor, here is how I recommend you distribute Mono for use with Wine: Download and extract the mono 2.6.7 source tarball from http://ftp.novell.com/pub/mono/sources/mono/mono-2.6.7.tar.bz2 Use the instructions at http://wiki.winehq.org/Mono to cross-compile Mono 2.6.7 using mingw32. Tweak the script if you have to (or just want to), but consider contributing any fixes you have to make back to winezeug. This will create a directory named mono-2.6.7. The contents of that directory should be installed to /usr/share/mono/mono-1.0. To make sure this worked, you should try a simple "Hello World" .NET application in Wine. Wikipedia has an example at https://secure.wikimedia.org/wikipedia/en/wiki/C_sharp_programming_language… that you should be able to save as a .cs file and compile to a .exe file using gmcs. If all is well, you should be able to run that exe file in a clean Wine prefix. In the future, we'll need a mono-2.0 directory as well, so we can keep using newer versions of Mono and get .NET 4.0 support. But we're not there yet. In case all these numbers have not confused you yet, the current version of Mono is 2.6.7. This version uses the Mono Embedding API version 1.0, which is why it needs to be placed in a directory named mono-1.0. It normally includes .NET 1.1 and 2.0 runtimes. It can optionally be compiled with a 4.0 runtime as well, but I don't recommend it. I'm expecting to see Mono 2.8 released "soon". That version will use the Embedding API version 2.0, which Wine can't support yet, but when the time comes it will need to be in a directory named mono-2.0. It will include .NET 2.0 and 4.0 runtimes. .NET 3.0 and 3.5 are not runtimes, which is why they were not included in that list. They use the .NET 2.0 runtime. While Mono 2.8 (and eventually 3.0) is the way forward for .NET 2.0 and 4.0 support, we'll need to also have the 2.6 series available so that we can have a .NET 1.1 runtime. Wine will detect which versions are available and what runtimes they have using a system that I'm working on and hope to have ready "soon", and it will select the correct runtime for whatever it's trying to run, or whatever the program selects using the .NET embedding API. (Also coming soon: the .NET embedding API.) I'm treating Mono as an optional dependency, much like the many native libraries Wine already uses. If it's not there, Wine will gracefully report failure to applications that try to use it, which probably won't work, and print some things to the console. I plan to send some changes soon that happen to cause a Wine without Mono to fail some tests, so I do consider an install that's missing Mono to be broken. But for the most part, the user experience will remain the same as it was before if Mono is missing.

Oct. 1, 2010

New version of exe-thumbnailer (0.7)

by Scott Ritchie

Includes much prettier icons, support for Vista icons (with icoutils 0.29.1) and more. Screenshots and a description are at: http://wiki.winehq.org/exe-thumbnailer -Scott Ritchie

Oct. 1, 2010

Re: wininet(4/5): Support querying the cipher strength of an SSL connection

by Juan Lang

> === W2K8SE (32 bit http) === > http.c:406: Test failed: expected status 11 (INTERNET_STATUS_NAME_RESOLVED) 1 times, received 0 times > http.c:413: Test failed: expected status 30 (INTERNET_STATUS_SENDING_REQUEST) 2 times, received 0 times > http.c:414: Test failed: expected status 31 (INTERNET_STATUS_REQUEST_SENT) 2 times, received 0 times > http.c:415: Test failed: expected status 40 (INTERNET_STATUS_RECEIVING_RESPONSE) 2 times, received 0 times > http.c:416: Test failed: expected status 41 (INTERNET_STATUS_RESPONSE_RECEIVED) 2 times, received 0 times > http.c:418: Test failed: expected status 110 (INTERNET_STATUS_REDIRECT) 1 times, received 0 times > http.c:443: Test failed: Wrong URL http://test.winehq.org/testredirect These test failures have nothing to do with the patch, of course. --Juan

Oct. 1, 2010

[tools PATCH] patches: Mention Windows test failures as a cause for 'Test failure' status

by Andrew Eikum

The current 'Test failure' description implies (to me, at least) that it's only Wine failures that cause the status. It might be obvious, but it seems worth explicitly mentioning that Windows failures can cause it as well. --- On 10/01/2010 09:45 AM, Alexandre Julliard wrote: >> On 09/24/2010 02:59 PM, Andrew Eikum wrote: >> These tests don't fail for me. What failures are you seeing? > > The testbot is complaining. > Okay, I'll look into it. Thanks.

Oct. 1, 2010

Re: [2/2] msi: Set more 64-bit properties.

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=5687 Your paranoid android. === W7PROX64 (64 bit install) === install.c:10040: Test failed: key not removed install.c:10050: Test failed: key not removed install.c:10061: Test failed: key not removed install.c:10352: Test failed: key not created

Oct. 1, 2010

Re: [PATCH] user32: Implement GetMenuBarInfo

by Alexandre Julliard

Andrew Eikum <aeikum(a)codeweavers.com> writes: > On 09/24/2010 02:59 PM, Andrew Eikum wrote: >> Likely fixes bug 18776. >> >> This patch is based heavily on a patch from Rein Klazes which was >> rejected last summer. According to comments on the bug, Rein's patch >> appears abandoned. >> <http://www.winehq.org/pipermail/wine-patches/2009-June/074119.html> >> >> The style has been cleaned up, as well as some minor improvements to the >> tests to pass on more platforms. > > These tests don't fail for me. What failures are you seeing? The testbot is complaining. -- Alexandre Julliard julliard(a)winehq.org

Oct. 1, 2010

Re: [PATCH] user32: Implement GetMenuBarInfo

by Andrew Eikum

On 09/24/2010 02:59 PM, Andrew Eikum wrote: > Likely fixes bug 18776. > > This patch is based heavily on a patch from Rein Klazes which was > rejected last summer. According to comments on the bug, Rein's patch > appears abandoned. > <http://www.winehq.org/pipermail/wine-patches/2009-June/074119.html> > > The style has been cleaned up, as well as some minor improvements to the > tests to pass on more platforms. These tests don't fail for me. What failures are you seeing?

Oct. 1, 2010

Re: mshtml.inf: Add default GeckoCabDir

by Alexandre Julliard

Jacek Caban <jacek(a)codeweavers.com> writes: > That's a matter of trivial patch, but what would be the candidate for > a path hardcode? '/usr/share/wine/gecko/' seems like the best choice > since that's where most distros will install Gecko. I'd say try $datadir and then /usr/share. > - Windows has builtin support for ZIP files. It's hidden behind an > obscure APIs, but it's something we could implement and use in MSHTML. > - Use .tar.gz files. We already use zlib in Wine, we could use it in > MSHTML. tar format is simple enough to implement its custom handling. > - Any other idea? A self-extracting zip may be an option too, not sure how easy they are to create on Linux. And while you are making changes, adding a checksum would be a good idea. A more ambitious approach would be to define a generic "Wine add-ons" mechanism that could also be used for Mono. This would avoid having detailed knowledge about file formats and download URLs spread around in various DLLs. Maybe this could go in the appwiz control panel, with a nice UI showing which add-ons are installed. -- Alexandre Julliard julliard(a)winehq.org

Oct. 1, 2010

Re: mshtml.inf: Add default GeckoCabDir

by Vitaliy Margolen

On 10/01/2010 06:53 AM, Jacek Caban wrote: > - Windows has builtin support for ZIP files. It's hidden behind an obscure > APIs, but it's something we could implement and use in MSHTML. > - Use .tar.gz files. We already use zlib in Wine, we could use it in MSHTML. > tar format is simple enough to implement its custom handling. > - Any other idea? > > Do you have any opinion? > Tarballs been always the de facto standard in *NIX world. It would be nice to use that. You could even rely on availability of the command line tools (gzip and tar) to extract gecko files. And packagers can make sure Wine depends on them). Vitaliy.

Oct. 1, 2010

Re: mshtml.inf: Add default GeckoCabDir

by Jacek Caban

On 10/1/10 2:31 PM, Alexandre Julliard wrote: > Jacek Caban<jacek(a)codeweavers.com> writes: > >> You can't do that. The default is what's found by 'step (2)' from your >> description, not any hardcoded path. The version from Gecko package is >> meant for packaged Wine. You should copy the .cab file to appropriate >> directory for your own build. > I don't think there would be any harm in trying some global paths even > when running from the build tree, so that people can install their > distro's wine-gecko package and have private builds take advantage of > it. But of course this should be done directly in the code, not by > changing the default registry entry. That's a matter of trivial patch, but what would be the candidate for a path hardcode? '/usr/share/wine/gecko/' seems like the best choice since that's where most distros will install Gecko. BTW, I don't have much hope that there will be good CAB tool for Linux, so I'd like to get rid of CAB as an archive format for Wine Gecko package in the next release. I think we'd better have the strategy (and maybe code) ready for this now. We need a file format that will be understood by Wine. I can see following options: - Windows has builtin support for ZIP files. It's hidden behind an obscure APIs, but it's something we could implement and use in MSHTML. - Use .tar.gz files. We already use zlib in Wine, we could use it in MSHTML. tar format is simple enough to implement its custom handling. - Any other idea? Do you have any opinion? Thanks, Jacek

Oct. 1, 2010

Re: mshtml.inf: Add default GeckoCabDir

by Alexandre Julliard

Jacek Caban <jacek(a)codeweavers.com> writes: > You can't do that. The default is what's found by 'step (2)' from your > description, not any hardcoded path. The version from Gecko package is > meant for packaged Wine. You should copy the .cab file to appropriate > directory for your own build. I don't think there would be any harm in trying some global paths even when running from the build tree, so that people can install their distro's wine-gecko package and have private builds take advantage of it. But of course this should be done directly in the code, not by changing the default registry entry. -- Alexandre Julliard julliard(a)winehq.org

Oct. 1, 2010

Re: [PATCH 1/5] d3dcompiler_43/tests: Added HLSL test suite

by Henri Verbeet

I think this is going in the right direction, but I still have a couple of comments. On 1 October 2010 00:43, Travis Athougies <iammisc(a)gmail.com> wrote: > +/* Macro to compare two floating point numbers */ > +#define F_EQ(a, b, epsilon) (fabs(a - b) <= epsilon) There's no reason this can't be an inline function. > +/* Color macro to simplify handling of D3DXCOLOR */ > +#define COLOR(r, g, b, a) {r, g, b, a} This looks pretty pointless. > +/* Signals the end of a probe list */ > +#define PROBE_END {-1, 0, {0.0f, 0.0f, 0.0f, 0.0f}, 0.0f, ""} You'll probably want to just pass a count to compute_shader_probe9(). > + /* The x and y coordinate, the width and the height of the region to check. > + When x < 0, this is the last probe */ > + int x, y; There's no width and height here. > + setup_device9(device, &render_target, &readback, D3DFMT_A32B32G32R32F, > + width, height, vshader, pshader); You can't use D3DFMT_A32B32G32R32F without checking if it's available using CheckDeviceFormat() first. > + /* Now go through the probes and check each one */ > + for(;probes->x >= 0;probes++) { > + int index = probes->x + (probes->y * lr.Pitch); > + ok(F_EQ(probes->c.a, pbits_data[index].a, probes->epsilon), > + "In alpha component at (%d, %d): %s: Expected %f, got %f\n", probes->x, probes->y, > + probes->message, probes->c.a, pbits_data[index].a); > + ok(F_EQ(probes->c.b, pbits_data[index].b, probes->epsilon), > + "In blue component at (%d, %d): %s: Expected %f, got %f\n", probes->x, probes->y, > + probes->message, probes->c.b, pbits_data[index].b); > + ok(F_EQ(probes->c.g, pbits_data[index].g, probes->epsilon), > + "In green component at (%d, %d): %s: Expected %f, got %f\n", probes->x, probes->y, > + probes->message, probes->c.g, pbits_data[index].g); > + ok(F_EQ(probes->c.r, pbits_data[index].r, probes->epsilon), > + "In blue component at (%d, %d): %s: Expected %f, got %f\n", probes->x, probes->y, > + probes->message, probes->c.r, pbits_data[index].r); > + } You'll probably want to have a function to compare two D3DXCOLORs. Also, please include the line number of the caller of compute_shader_probe9() somewhere. > + if (caps.PixelShaderVersion >= 0xffff0200) You can still just use D3DPS_VERSION(2, 0) here.

Oct. 1, 2010

Re: mshtml.inf: Add default GeckoCabDir

by GOUJON Alexandre

> That's intended. It's for overwriting defaults (although now that we > install Gecko during wineprefix creation is doesn't make much sense > anyways). > You can't do that. The default is what's found by 'step (2)' from your > description, not any hardcoded path. The version from Gecko package is > meant for packaged Wine. You should copy the .cab file to appropriate > directory for your own build. Ok, so I'm wrong. Sorry for the noise in this case.

Oct. 1, 2010

Re: mshtml.inf: Add default GeckoCabDir

by Jacek Caban

On 10/1/10 1:06 PM, GOUJON Alexandre wrote: > On 10/01/2010 12:17 PM, Austin English wrote: >> On Fri, Oct 1, 2010 at 4:29 AM, Alexandre Goujon<ale.goujon(a)gmail.com> >> wrote: >>> diff --git a/dlls/mshtml/mshtml.inf b/dlls/mshtml/mshtml.inf >>> index d7d2428..dea1712 100644 >>> --- a/dlls/mshtml/mshtml.inf >>> +++ b/dlls/mshtml/mshtml.inf >>> @@ -273,6 +273,7 @@ HKLM,"Software\Microsoft\Internet Explorer\Default >>> Behaviors","TIME",, "CLSID:47 >>> >>> [WineGecko.Reg] >>> >>> HKCU,Software\Wine\MSHTML,"GeckoUrl",,"http://source.winehq.org/winegecko.php" >>> +HKCU,Software\Wine\MSHTML,"GeckoCabDir",,"/usr/share/wine/gecko/" >> The directory isn't always /usr/share, it's relative to where wine is >> installed > dll/mshtml/install.c: > 541 * Try to find Gecko .cab file in following order: > 542 * - directory stored in GeckoCabDir value of > HKCU/Software/MSHTML key > -> install_from_registered_dir() > 543 * - $datadir/gecko > -> install_from_default_dir() > 544 * - download from URL stored in GeckoUrl value of > HKCU/Software/MSHTML key > -> DialogBoxW(hInst, MAKEINTRESOURCEW(ID_DWL_DIALOG), 0, installer_proc); > 545 */ > > The above comment says : > (1) the default way to find gecko is to look at the registry value > (2) if not found, try to find gecko relatively > (3) fallback : ask the user to fetch it from the Internet > > (1) can't work as GeckoCabDir is not defined in the registry > So currently, wine can only find gecko with (2) That's intended. It's for overwriting defaults (although now that we install Gecko during wineprefix creation is doesn't make much sense anyways). > My git-wine directory is at /home/alex/Projects/wine/ > So when I run `/home/alex/Projects/wine/wine winecfg` with an empty > ~/.wine, it looks for gecko in /home/alex/Projects/wine/../gecko/ > Or gecko is present in /usr/share/wine/gecko as I installed the > wine1.3-gecko package > > This patch does not break the current behavior > and let people who are running wine in some weird prefix to use the > packaged gecko > > I read again http://wiki.winehq.org/Gecko and /usr/share/wine/gecko/ > seems to be the default path > > Anyway, thanks for your comment > but I think it's Jacek Caban who have to answer and say if I'm right or > wrong. You can't do that. The default is what's found by 'step (2)' from your description, not any hardcoded path. The version from Gecko package is meant for packaged Wine. You should copy the .cab file to appropriate directory for your own build. Jacek

Oct. 1, 2010

Re: [PATCH] jscript: throw TypeError if T in 'new T' is not an object. [try 2]

by Jacek Caban

On 10/1/10 9:59 AM, Reece Dunn wrote: > Hi, > > try 1 -- throw TypeError if T in 'new T' is not an object. > try 2 -- handle the case when using a null dispatch pointer: `new nullDisp;` > > NOTE: given `new 3;` the engine should report IDS_UNSUPPORTED_ACTION > instead of IDS_NO_PROPERTY but this requires more changes to the code > (constr.vt is VT_EMPTY in both of these cases in engine.c). We most likely should use to_object here. Please add a comment about it. - return E_FAIL; + return throw_type_error(ctx->parser->script, ei, V_DISPATCH(&constr) ? IDS_OBJECT_EXPECTED : IDS_NO_PROPERTY, NULL); You can't access V_DISPATCH(&constr) here as you don't know if constr is of VT_DISPATCH type. Jacek

Oct. 1, 2010

Re: mshtml.inf: Add default GeckoCabDir

by GOUJON Alexandre

On 10/01/2010 12:17 PM, Austin English wrote: > On Fri, Oct 1, 2010 at 4:29 AM, Alexandre Goujon<ale.goujon(a)gmail.com> wrote: > >> diff --git a/dlls/mshtml/mshtml.inf b/dlls/mshtml/mshtml.inf >> index d7d2428..dea1712 100644 >> --- a/dlls/mshtml/mshtml.inf >> +++ b/dlls/mshtml/mshtml.inf >> @@ -273,6 +273,7 @@ HKLM,"Software\Microsoft\Internet Explorer\Default Behaviors","TIME",, "CLSID:47 >> >> [WineGecko.Reg] >> HKCU,Software\Wine\MSHTML,"GeckoUrl",,"http://source.winehq.org/winegecko.php" >> +HKCU,Software\Wine\MSHTML,"GeckoCabDir",,"/usr/share/wine/gecko/" >> > The directory isn't always /usr/share, it's relative to where wine is installed > dll/mshtml/install.c: 541 * Try to find Gecko .cab file in following order: 542 * - directory stored in GeckoCabDir value of HKCU/Software/MSHTML key -> install_from_registered_dir() 543 * - $datadir/gecko -> install_from_default_dir() 544 * - download from URL stored in GeckoUrl value of HKCU/Software/MSHTML key -> DialogBoxW(hInst, MAKEINTRESOURCEW(ID_DWL_DIALOG), 0, installer_proc); 545 */ The above comment says : (1) the default way to find gecko is to look at the registry value (2) if not found, try to find gecko relatively (3) fallback : ask the user to fetch it from the Internet (1) can't work as GeckoCabDir is not defined in the registry So currently, wine can only find gecko with (2) My git-wine directory is at /home/alex/Projects/wine/ So when I run `/home/alex/Projects/wine/wine winecfg` with an empty ~/.wine, it looks for gecko in /home/alex/Projects/wine/../gecko/ Or gecko is present in /usr/share/wine/gecko as I installed the wine1.3-gecko package This patch does not break the current behavior and let people who are running wine in some weird prefix to use the packaged gecko I read again http://wiki.winehq.org/Gecko and /usr/share/wine/gecko/ seems to be the default path Anyway, thanks for your comment but I think it's Jacek Caban who have to answer and say if I'm right or wrong.

Oct. 1, 2010

Re: [PATCH] jscript: throw TypeError if T in 'new T' is not an object. [try 2]

by Ricardo Filipe

2010/10/1 Reece Dunn <msclrhd(a)googlemail.com>: > Hi, > > try 1 -- throw TypeError if T in 'new T' is not an object. > try 2 -- handle the case when using a null dispatch pointer: `new nullDisp;` > > NOTE: given `new 3;` the engine should report IDS_UNSUPPORTED_ACTION > instead of IDS_NO_PROPERTY but this requires more changes to the code > (constr.vt is VT_EMPTY in both of these cases in engine.c). > > - Reece > > > > wouldn't this be more readable in separate lines? one less condition, just repeating the VariantClear...

Oct. 1, 2010