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=20356
Your paranoid android
On Wed, Jan 6, 2010 at 3:28 PM, Detlef Riekenberg wrote:
> According to MSDN, both parameter are unused and must be 0/NULL
> A FIXME for every call is useless
>
> (there is no PATCH 1/2, so a resend without that prefix)
>
> --
> By by ... Detlef
>
>
> --
Hans Leidekker writes:
> Some more testing suggests that the installable set is a superset of
> the valid codepages set. So we could just return the set of valid
> codepages for now and not hardcode anything.
Yes, it should probably use something like IMultiLanguage2_ValidateCodePageEx
(and the
On Wednesday 01 July 2009 01:09:52 pm Alexandre Julliard wrote:
> >> IsValidCodePage might be helpful yes, although marking it broken is
> >> a bit too strong I think, it's just a difference in codepage databases.
> >>
> >> -Hans
> > Yes, broken() seems strong but it's actually meant as
> > behav
Alexandre Julliard wrote:
Paul Vriens writes:
Hans Leidekker wrote:
On Wednesday 01 July 2009 12:12:47 pm Paul Vriens wrote:
Would using IsValidCodePage() be helpful here?
Yep, something like:
hr = IMultiLanguage2_IsCodePageInstallable(ml2, i);
if (i == 29001 || /* win2
Paul Vriens writes:
> Hans Leidekker wrote:
>> On Wednesday 01 July 2009 12:12:47 pm Paul Vriens wrote:
>>
Would using IsValidCodePage() be helpful here?
>>> Yep, something like:
>>>
>>> hr = IMultiLanguage2_IsCodePageInstallable(ml2, i);
>>> if (i == 29001 || /* win2k
Hans Leidekker wrote:
On Wednesday 01 July 2009 12:12:47 pm Paul Vriens wrote:
Would using IsValidCodePage() be helpful here?
Yep, something like:
hr = IMultiLanguage2_IsCodePageInstallable(ml2, i);
if (i == 29001 || /* win2k3 */
i == 50930 || i == 50931 || i =
On Wednesday 01 July 2009 12:12:47 pm Paul Vriens wrote:
> > Would using IsValidCodePage() be helpful here?
> >
> Yep, something like:
>
> hr = IMultiLanguage2_IsCodePageInstallable(ml2, i);
> if (i == 29001 || /* win2k3 */
> i == 50930 || i == 50931 || i == 50933
Paul Vriens wrote:
Hans Leidekker wrote:
Passes on win2k3, vista and the win7 release candidate.
Would using IsValidCodePage() be helpful here?
Yep, something like:
hr = IMultiLanguage2_IsCodePageInstallable(ml2, i);
if (i == 29001 || /* win2k3 */
i == 50930 ||
Hans Leidekker wrote:
Passes on win2k3, vista and the win7 release candidate.
Hi Hans,
These are the results on Win95:
mlang.c:2002: Test failed: 37: expected S_OK, got 0x80070057
mlang.c:2002: Test failed: 500: expected S_OK, got 0x80070057
mlang.c:2002: Test failed: 855: expected S_OK, got
Hi Detlef,
> The mlang tests where reordered and now it crashed on
> on your Win98 machine with mlang.dll "4.72.3110.0".
>
>
http://test.winehq.org/data/675e6e93b1d2b4555d05e311764510abf763d21d/98_gvg-
w98/mlang:mlang.html
>
> Please send me the resu
Hi Ge
The mlang tests where reordered and now it crashed on
on your Win98 machine with mlang.dll "4.72.3110.0".
http://test.winehq.org/data/675e6e93b1d2b4555d05e311764510abf763d21d/98_gvg-w98/mlang:mlang.html
Please send me the results for the test with:
set WINETEST_REPORT_SUCCESS=
Paul Vriens wrote:
Hi,
It's only my Win95 box that has this failure (the other ones don't even
run these particular tests).
Changelog
Fix a test failure on Win95
This also fixes this same test failure on some W2K boxes, so it looks
like an IE version specific issue (as already indicated in
Detlef Riekenberg writes:
> @@ -1164,6 +1165,14 @@ static void test_GetRfc1766Info(IMultiLanguage2 *iML2)
> ok(!lstrcmpA(rfc1766A, info_table[i].rfc1766),
> "#%02d: got '%s' (expected '%s')\n", i, rfc1766A,
> info_table[i].rfc1766);
>
> +if (!localenameA[0]) {
> +
Detlef Riekenberg wrote:
On Mi, 2009-06-03 at 10:50 +0200, Paul Vriens wrote:
This patch introduces test failures on what seems:
- all Win95 boxes
- some Win98 boxes
- some W2K boxes
Could you have a look?
Here is a fix.
Hi Detlef,
Is there no way to have a broken() in here:
+
Detlef Riekenberg wrote:
Hi Detlef,
This patch introduces test failures on what seems:
- all Win95 boxes
- some Win98 boxes
- some W2K boxes
See: http://test.winehq.org/data/tests/mlang:mlang.html
There is one XP bo
"Hans Leidekker" wrote:
> IE7 imports these and possibly others by ordinal.
>
> -Hans
>
> diff --git a/dlls/mlang/mlang.spec b/dlls/mlang/mlang.spec
> index 1e8f022..689ad27 100644
> --- a/dlls/mlang/mlang.spec
> +++ b/dlls/mlang/mlang.spec
nguage pack not handled\n");
>
> return S_FALSE;
> }
IsValidCodePage() covers only kernel32 supported code pages, you probably
need to follow what GetCodePageDescription() does and use internal mlang
data.
--
Dmitry.
On Friday 28 November 2008 07:53:40 Dmitry Timoshkov wrote:
> "Vitaly Perov" <[EMAIL PROTECTED]> wrote:
> > Changes since last send:
> > - Used local mlang_data structure instead of calling internal function
> > wine_cp_enum_table.
> > - Used macro instead of "iface->lpVtbl->"
>
> Lo
"Vitaly Perov" <[EMAIL PROTECTED]> wrote:
> Changes since last send:
> - Used local mlang_data structure instead of calling internal function
> wine_cp_enum_table.
> - Used macro instead of "iface->lpVtbl->"
Looks good to me.
--
Dmitry.
"Vitaly Perov" <[EMAIL PROTECTED]> wrote:
> Changes since last send:
> - Used WINAPI function instead of accessing Wine internal code page
> structures.
You still access internal Wine code page structures, I'm not sure why you
claim otherwise.
> "Dmitry Timoshkov" <[EMAIL PROTECTED]> wrote:
>
On Wednesday 12 November 2008 13:37:32 Hans Leidekker wrote:
> This version converts the stream all at once.
Hold on, I realize now that I can avoid an allocation.
-Hans
"Hans Leidekker" <[EMAIL PROTECTED]> wrote:
> +while (1)
> +{
> +hr = IStream_Read(pstmIn, src, sizeof(src), &bytes_read);
> +if (FAILED(hr)) goto exit;
> +
> +srclen = bytes_read;
> +dstlen = buffer_size;
> +ConvertINetString(pdwMode, dwSrcEncoding,
or MSDN declares as supported, the only thing that matters is what code pages
are valid for mlang APIs.
> For example, we use a symbol from Latin1 codepage.
> All codepages are include this symbol.
> So if we use EnumSystemCodePage() it enumerates codepages from the cptables
> array. Th
> I can't read your mind or guess what those "some extra bits" are. Why can't
> you mark the failing tests with todo_wine and think later how to make the
> tests pass?
>
This function must set only supported codepages bits
The supported codepages are:
ttp://www.microsoft.com/globaldev/reference/W
mind or guess what those "some extra bits" are. Why can't you
mark the failing tests with todo_wine and think later how to make the tests
pass?
>>> ... or rather use mlang internal mlang_data structures.
>
>>I's good idea! Thank you!
>
> So, I use mla
ng
>> Wine internals directly.
>I used EnumSystemCodePages before, but in this case GetCharCodePages set some
>extra bits in result. So the result differ from Windows
>> ... or rather use mlang internal mlang_data structures.
>I's good idea! Thank you!
So, I use mla
"Vitaly Perov" <[EMAIL PROTECTED]> wrote:
> Changed since last send: use mlang internal mlang_data structures instead of
> static array.
You still haven't done the other part: use Win32 APIs EnumSystemCodePages/
GetCPInfo/WideCharToMultiByte instead of access
Aric Stewart <[EMAIL PROTECTED]> writes:
> @@ -259,6 +259,15 @@ static BOOL check_convertible(IMultiLanguage2 *iML2,
> UINT from, UINT to)
>
> static WCHAR strW[] = {'a','b','c',0};
>
> +if (from == 1361 || to == 1361)
> +{
> +/*
> + * This is Korean (Johab). Thi
Sorry all, this patch is clearly incorrect. I am continuing to try to
find out why these test fail on my windows 2000 japanese vm.
-aric
Aric Stewart wrote:
> ---
> dlls/mlang/tests/mlang.c | 100
> +-
> 1 files changed, 63 inser
2008/9/27 Aric Stewart <[EMAIL PROTECTED]>:
> +if (hr != S_FALSE)
> +/*
> + * this happens when 'kok' instead matches to a different Rfc1766
> name
> + * for example 'ko' so it is not a falure but does not give us what
"falure" -> spelling mistake
> + * we are
Aric Stewart wrote:
> That is interesting... I am pretty confident that test passed when I
> was testing it on Japanese windows XP. I will try it again to be sure.
>
I guess it should pass on all Windows and Wine boxes unless it has to be
skipped.
--
Cheers,
Paul.
Interestingly I am also seeing this failure with my Japanese windows
2000 VM. I do not have access to windows XP at this time. I would
support removing that test for now and I will write it in my list of
TODOs to investigate that more when I next have access to Japanese
Windows XP.
-aric
Pau
That is interesting... I am pretty confident that test passed when I
was testing it on Japanese windows XP. I will try it again to be sure.
-aric
Paul Vriens wrote:
> Hi,
>
> (Grabbed this mail from http://www.winehq.org/pipermail/wine-patches)
>
> This test however fails on Windows and succ
Hi,
(Grabbed this mail from http://www.winehq.org/pipermail/wine-patches)
This test however fails on Windows and succeeds on Wine so there must be
something wrong (not 100% correct) in Wine? Maybe Aric should check this one
out?
--
Cheers,
Paul.
directly.
I used EnumSystemCodePages before, but in this case GetCharCodePages set some
extra bits in result. So the result differ from Windows
> ... or rather use mlang internal mlang_data structures.
I's good idea! Thank you!
--
Best wishes,
Vitaly Perov
Russia, Saint-Petersburg. www.etersoft.ru
Wine internals directly.
... or rather use mlang internal mlang_data structures.
--
Dmitry.
"Vitaly Perov" <[EMAIL PROTECTED]> wrote:
> +/* Tests for GetCharCodePages */
> +/* Latin 1 */
> +ok(IMLangFontLink_GetCharCodePages(iMLFL, 'd', &dwCodePages) == S_OK,
> +"IMLangFontLink_GetCharCodePages failed\n");
> +ok(dwCodePages == 2032127, "Incorrect CodePages returne
"Vitaly Perov" <[EMAIL PROTECTED]> wrote:
> @@ -1855,8 +1855,56 @@ static HRESULT WINAPI
> fnIMLangFontLink_GetCharCodePages(
> WCHAR chSrc,
> DWORD* pdwCodePages)
> {
> -FIXME("\n");
> -return E_NOTIMPL;
> +/* codepages, supported by Windows */
> +static const
> +interface IMLangLineBreakConsole : IUnknown
> +{
> +HRESULT BreakLineML(
> +[in] IUnknown* pSrcMLStr, /* FIXME: IMLangString */
> +[in] long lSrcPos,
> +[in] long lSrcLen,
> +[in] long cMinColumns,
> +[in] long cMaxColumns,
> +[out] long* plLi
On Mon, Jul 7, 2008 at 12:08 AM, Dan Kegel <[EMAIL PROTECTED]> wrote:
> On Sun, Jul 6, 2008 at 10:29 AM, James Hawkins <[EMAIL PROTECTED]> wrote:
>> No, this is hiding a bug. The test code conforms with the API. The
>> problem is that ConvertINetMultiByteToUnicode uses the value of an
>> out-only
On Sun, Jul 6, 2008 at 10:29 AM, James Hawkins <[EMAIL PROTECTED]> wrote:
> No, this is hiding a bug. The test code conforms with the API. The
> problem is that ConvertINetMultiByteToUnicode uses the value of an
> out-only parameter (NULL pDstStr, non-NULL pcDstSize). Check out the
> code block
2008/7/6 Dan Kegel <[EMAIL PROTECTED]>:
> The mlang test assumed that the output of ConvertStringFromUnicode
> was null terminated, but it seems not to be.
>
> Fixes the valgrind warning:
> Conditional jump or move depends on uninitialised value(s)
> at strlen (mc_repl
On Thu, Jul 3, 2008 at 11:22 AM, Alexandre Julliard <[EMAIL PROTECTED]> wrote:
> "John Klehm" <[EMAIL PROTECTED]> writes:
>
>> Add your fix to w32api (mingws headers) with a patch or use wines
>> headers to cross compile. If you patch w32api send your patch to Paul
>> Millar. If you want to use Wi
"John Klehm" <[EMAIL PROTECTED]> writes:
> Add your fix to w32api (mingws headers) with a patch or use wines
> headers to cross compile. If you patch w32api send your patch to Paul
> Millar. If you want to use Wine's headers try my script.
>
> http://klehm.net/wine/crossbuild_tricks.sh.
Note tha
On Thu, Jul 3, 2008 at 9:47 AM, Vitaly Perov <[EMAIL PROTECTED]> wrote:
> "make" command works, but when I try "make crosstest" the following message
> appears:
> mlang.cross.o: In function `func_mlang':
> /home/vitperov/Projects/wine/dlls/mlang/
"make" command works, but when I try "make crosstest" the following message
appears:
mlang.cross.o: In function `func_mlang':
/home/vitperov/Projects/wine/dlls/mlang/tests/mlang.c:831: undefined reference
to `_IID_IMultiLanguage2'
/home/vitperov/Projects/win
On Thu, 5 Jun 2008, James Hawkins wrote:
> http://winehq.org/pipermail/wine-cvs/2008-June/044013.html
I'm getting old and slow, I guess. :-/
Gerald
2008/6/5 Gerald Pfeifer <[EMAIL PROTECTED]>:
>
> ChangeLog:
> Remove unused variable in test_EnumScripts().
>
> Index: dlls/mlang/tests/mlang.c
> ===
> RCS file: /home/wine/wine/dlls/mlang/tests/mlang.c,v
ame,
> though that would mean making a copy. Would
> you prefer it that way instead?
>
> This doesn't change the miserable status of the
> mlang tests on XP:
> http://test.winehq.org/data/200805211000/#group_XP:mlang:mlang
>
Those are fixed by this patch:
http://wine
"Maarten Lankhorst" <[EMAIL PROTECTED]> wrote:
> It disallows certain conversions now.
Please don't commit this and other mlang related patches,
they are wrong.
Maarten, if your only intent is to show clean results under
test.winehq.org that's not worth an effort w
"Maarten Lankhorst" <[EMAIL PROTECTED]> wrote:
>> The statement above is not true. The reason for mlang test failures is that
>> apparently mlang in Windows has its own idea of supported locales not
>> connected
>> to real kernel32 implementation. I
CodePage ==
> 28591 || cpinfo[i].uiCodePage == 28605)
> > +expected = S_FALSE;
> >
>
> The statement above is not true. The reason for mlang test failures is that
> apparently mlang in Windows has its own idea of supported locales not
> connected
> t
The statement above is not true. The reason for mlang test failures is that
apparently mlang in Windows has its own idea of supported locales not connected
to real kernel32 implementation. I'd leave the tests as they are, there is
nothing wrong in them, we can't fix Windows bugs.
--
Dmitry.
[EMAIL PROTECTED]>
>> * dlls/mlang/mlang.c:
>>mlang: fix memory leaks in error path (found by Smatch).
>>
>> diff --git a/dlls/mlang/mlang.c b/dlls/mlang/mlang.c
>> index eb14ad0..c6274c5 100644
>> --- a/dlls/mlang/mlang.c
>> +
"Tijl Coosemans" <[EMAIL PROTECTED]> wrote:
> > hr = ConvertINetMultiByteToUnicode(pdwMode, dwSrcEncoding,
> > pSrcStr, pcSrcSize, pDstStrW, &cDstSizeW);
> > if (hr != S_OK)
> > -return hr;
> > +goto cleanup;
> >
> > hr = ConvertINetUnicodeToMu
Lionel_Debroux wrote:
> EnumRfc1766_create leaks some heap memory in two error paths. Found in
> Michael Stefaniuc's list of Wine potential bugs detected by Smatch.
>
> 2007-09-24 Lionel Debroux <[EMAIL PROTECTED]>
>* dlls/mlang/mlang.c:
>mlang: fi
On Monday 24 September 2007 14:20:51 Lionel_Debroux wrote:
> ConvertINetString leaks some heap memory in an error path. Found in
> Michael Stefaniuc's list of Wine potential bugs detected by Smatch.
>
> 2007-09-24 Lionel Debroux <[EMAIL PROTECTED]>
>* dlls/mla
Dmitry Timoshkov <[EMAIL PROTECTED]> writes:
> the only import from user32 which mlang uses is wsprintfW, and it's only used
> by the DllRegisterServer code, so it's reasonable to move user32 to delay load
> imports.
As long as mlang imports ole32 which imports user32,
Well, looks like i misread the MSDN page on that one. Thanks! I will
rewrite those parts of the code to use that.
-aric
Dmitry Timoshkov wrote:
"Aric Stewart" <[EMAIL PROTECTED]> wrote:
I did not see a way to go both ways. From a CHARSET to CodePage was
given in TranslateCharsetInfo but
"Aric Stewart" <[EMAIL PROTECTED]> wrote:
> I did not see a way to go both ways. From a CHARSET to CodePage was
> given in TranslateCharsetInfo but unless i missed it there was not a way
> to go from CodePage to CHARSET. If there is a way then i can make that
> work then I will change things to
:
On Fri, Sep 23, 2005 at 01:38:39PM -0500, Aric Stewart wrote:
Implement a basic beginning for
fnIMLangFontLink_CodePageToCodePages,
fnIMLangFontLink_CodePagesToCodePage and fnIMLangFontLink_GetFontCodePages.
Also some tests for the new functions.
Index: dlls/mlang/mlang.c
On Fri, Sep 23, 2005 at 01:38:39PM -0500, Aric Stewart wrote:
> Implement a basic beginning for
>fnIMLangFontLink_CodePageToCodePages,
> fnIMLangFontLink_CodePagesToCodePage and fnIMLangFontLink_GetFontCodePages.
> Also some tests for the new functions.
> Index: dll
"Felix Nawothnig" <[EMAIL PROTECTED]> wrote:
> --- include/mlang.idl 19 Nov 2004 17:59:41 - 1.5
> +++ include/mlang.idl 9 Dec 2004 16:08:02 -
> @@ -545,6 +545,8 @@ cpp_quote("STDAPI Rfc1766ToLcidA(LCID *,
> cpp_quote("STDAPI Rfc1766ToLcidW(LCID *, LPCWSTR);")
> cpp_quote("#define Rfc1766
Changes stub to FIXME for GetGlobalFontLinkObject in mlang DLL
The patch is attached.
--
Vitaly Lipatov, ALT Linux Team
Russia, Saint-Petersburg, www.etersoft.ru
Index: dlls/mlang/mlang.c
===
RCS file: /home/wine/wine/dlls/mlang
On Tue, 14 Sep 2004 18:56:40 +0900, Mike McCormack <[EMAIL PROTECTED]> wrote:
>
> ChangeLog:
> * use Interlocked* functions in AddRef and Release
>
>
> static ULONG WINAPI fnIEnumCodePage_Release(
> IEnumCodePage* iface)
> {
> ICOM_THIS_MULTI(EnumCodePage_impl, vtbl_IEnumCodePage,
66 matches
Mail list logo
