Re: [user32: 2/2] Testcase for font size = 0x7fff

[Dmitry Timoshkov]

"Koro"  wrote:
> +static INT_PTR CALLBACK messageBoxFontDlgWinProc (HWND hDlg, UINT uiMsg, WPARAM wParam,
> -
>    LPARAM lParam)
>
> +{
> - return (uiMsg == WM_INITDIALOG);
>
> +}
> -
>
> +static void test_MessageBoxFontTest(void)
> +{
> - /* Define a dialog that sets 0x7fff as font, and define one control. If the
> -
> * dialog is created correctly, it means the 0x7fff was skipped correctly. */
> -
> - static unsigned char test[] =
> - {
> -
>    /* Dialog header */
> -
>    0x01,0x00,              /* Version */
> -
>    0xff,0xff,              /* Extended template marker */
> -
>    0x00,0x00,0x00,0x00,    /* Context Help ID */
> -
>    0x00,0x00,0x00,0x00,    /* Extended style */
> -
>    0xc0,0x00,0xc8,0x80,    /* Style (WS_SYSMENU|WS_CAPTION|WS_POPUP|DS_SETFONT|DS_MODALFRAME) */
> -
>    0x01,0x00,              /* Control count */
> -
>    0x00,0x00,              /* X */
> -
>    0x00,0x00,              /* Y */
> -
>    0x80,0x00,              /* Width */
> -
>    0x80,0x00,              /* Height */
> -
>    0x00,0x00,              /* Menu name */
> -
>    0x00,0x00,              /* Class name */
> -
>    'T',0x00,'e',0x00,      /* Caption (unicode) */
> -
>    's',0x00,'t',0x00,
> -
>    0x00,0x00,
> -
>    0xff,0x7f,              /* Font height (0x7fff = message box font) */
> -
> -
>    /* Control #1 */
> -
>    0x00,0x00,              /* Align to DWORD (header is 42 bytes) */
> -
>    0x00,0x00,0x00,0x00,    /* Context Help ID */
> -
>    0x00,0x00,0x00,0x00,    /* Extended style */
> -
>    0x00,0x00,0x00,0x50,    /* Style (WS_CHILD|WS_VISIBLE) */
> -
>    0x00,0x00,              /* X */
> -
>    0x00,0x00,              /* Y */
> -
>    0x80,0x00,              /* Width */
> -
>    0x80,0x00,              /* Height */
> -
>    0xff,0xff,0xff,0xff,    /* Control ID */
> -
>    0xff,0xff,0x82,0x00,    /* Class (Static) */
> -
>    'W',0x00,'I',0x00,      /* Caption (unicode) */
> -
>    'N',0x00,'E',0x00,
> -
>    ' ',0x00,'d',0x00,
> -
>    'i',0x00,'a',0x00,
> -
>    'l',0x00,'o',0x00,
> -
>    'g',0x00,' ',0x00,
> -
>    't',0x00,'e',0x00,
> -
>    's',0x00,'t',0x00,
> -
>    '.',0x00,0x00,0x00,
> -
>    0x00,0x00,              /* Size of extended data */
> -
> -
>    0x00,0x00               /* Align to DWORD */
> - };
> -
> - /* Now check if it can be created */
> - HWND hdlg = CreateDialogIndirectParam(g_hinst, (LPCDLGTEMPLATE)test, NULL, messageBoxFontDlgWinProc, 0);
> -
> - broken(hdlg == NULL);

Is there a Windows version where CreateDialogIndirectParam fails?
> - if (hdlg)
> -
>    ok(IsWindow(hdlg), "dialog with message box font was successfully created");

What exactly this code is supposed to test? So far it doesn't test
anything related to the font size.

Re[1] [user32: 2/2] Testcase for font size = 0x7fff

[Koro]

> Is there a Windows version where CreateDialogIndirectParam fails?

It's not supposed to fail in Windows using the template that is passed 
to it. But it fails in WINE without my patch.
> What exactly this code is supposed to test? So far it doesn't test
> anything related to the font size.

As I said in part 1 on my patch, there is a "special case" for dialog 
templates where "font height" is 0x7fff.

Normally, the font specification of dialog template (DIALOGEX) would go 
like this:

WORD wPoint;        // point size
WORD wWeight;       // font weight
BYTE bItalic;       // 1 if italic, 0 if not
BYTE bCharSet;      // character set
WCHAR szFontName[]; // variable-length

However, should wPoint happen to be 0x7fff, the four next members "don't 
exist" anymore, and the dialog should use the message box font. 
Therefore the next thing that is supposed to be there is the first 
control definition (DWORD-aligned of course).

WINE failed to take this into account, and, since it read a few bytes 
too much by trying to read the 4 last members even in the 0x7fff case, 
it was all off into the dialog template, therefore reading all wrong 
class names/atoms, etc etc for the rest of the dialog, eventually 
totally failing to create it.

This test goes to show that (with my patch) WINE now does the right 
thing and skips them when the font size is 0x7fff, creating a dialog 
with one static control in it.

I also ran that code on Windows, and, as expected, the dialog and its 
static control gets created correctly and assigned the message box font.

Re[1] [user32: 2/2] Testcase for font size = 0x7fff

[Dmitry Timoshkov]

"Koro"  wrote:
> > Is there a Windows version where CreateDialogIndirectParam fails?
>
> It's not supposed to fail in Windows using the template that is passed 
> to it. But it fails in WINE without my patch.

Then you shouldn't mark it as broken(), or expect a failure, but
either send the fix 1st, or mark this as todo_wine.
> > What exactly this code is supposed to test? So far it doesn't test
> > anything related to the font size.
>
> As I said in part 1 on my patch, there is a "special case" for dialog 
> templates where "font height" is 0x7fff.

Then you need to test the resulting font attributes to see if they
match the message box font. I'd suggest to make sure that the test
gets committed first, and only then try to make it pass.

Also, is there a real world application that uses that undocumented
feature?

Re[3] [user32: 2/2] Testcase for font size = 0x7fff

[Koro]

> Then you shouldn't mark it as broken(), or expect a failure, but
> either send the fix 1st, or mark this as todo_wine.

I actually sent the fix first, but somehow, (at least if I rely on the 
newsgroup) it ended up appearing a lot later than this actual test case.

As for the broken() and ok() I must admit it was my first test case, so 
I tried to look at the other functions and do the same, I may have been 
totally wrong. If you could enlighten me on proper broken/ok use, i'd be 
happy.
> Then you need to test the resulting font attributes to see if they
> match the message box font. I'd suggest to make sure that the test
> gets committed first, and only then try to make it pass.

I shall do that then (after this one gets commited, as per your suggestion).
> Also, is there a real world application that uses that undocumented
> feature?

I wrote one this summer (http://www.korosoft.net/projects/tdemu/). In 
fact, this is what made me find that bug in WINE pretty quick. Since it 
emulates functionality akin to a message box, it's only logical that it 
uses the message box font.

Re[3] [user32: 2/2] Testcase for font size = 0x7fff

[Dmitry Timoshkov]

"Koro"  wrote:
> As for the broken() and ok() I must admit it was my first test case, so 
> I tried to look at the other functions and do the same, I may have been 
> totally wrong. If you could enlighten me on proper broken/ok use, i'd be 
> happy.

ok() is for calls never expected to fail, broken() is for broken API
implementations and should never be used for Wine.
> > Then you need to test the resulting font attributes to see if they
> > match the message box font. I'd suggest to make sure that the test
> > gets committed first, and only then try to make it pass.
>
> I shall do that then (after this one gets commited, as per your suggestion).

This one will not be committed, since it doesn't test anything useful.
> > Also, is there a real world application that uses that undocumented
> > feature?
>
> I wrote one this summer (http://www.korosoft.net/projects/tdemu/).

What's the source of info you have used for that?
> In 
> fact, this is what made me find that bug in WINE pretty quick. Since it 
> emulates functionality akin to a message box, it's only logical that it 
> uses the message box font.

Then I'd say there is nothing to fix in Wine, go ahead and fix your app
instead.

Re[5] [user32: 2/2] Testcase for font size = 0x7fff

[Koro]

> ok() is for calls never expected to fail, broken() is for broken API
> implementations and should never be used for Wine.

Noted.
> What's the source of info you have used for that?

It was on a comment to that post: 
http://blogs.msdn.com/oldnewthing/archive/2005/04/29/412577.aspx

It seems to have been deleted since then though. The comment said about 
the 0x7fff part, but not about the missing members. I found about the 
missing members through experimentation after that.
> Then I'd say there is nothing to fix in Wine, go ahead and fix your app
> instead.

I thought the idea was that "if there's a quirk in Wine you need to work 
around, it's much better to fix it in Wine", as said on 
http://www.winehq.org/site/docs/wine-faq/index#HOW-CAN-I-DETECT-WINE

If I had to detect WINE and work around it, it would quite defeat the 
purpose I think...

Re[5] [user32: 2/2] Testcase for font size = 0x7fff

[Michael Karcher]

Am Sonntag, den 12.10.2008, 01:33 -0400 schrieb Koro:
> > ok() is for calls never expected to fail, broken() is for broken API
> > implementations and should never be used for Wine.
>
> Noted.

More specifically: You *never* use broken on its own.

This is an explanation of the test primitives. Feel free to put it on
the Wine wiki, if you like it.

All tests are spelled out in form of ok(), and you write your ok
statement in a way that it expresses what behaviour is OK according to
the Win32 API. There might be more than one possibility, like

status = WinFrobnicate(foo);
  ok(status == E_FAIL /* Win98*/ ||
     status == E_INVALIDARG /* WinNT,2k,XP*/, "status %08x\n",status);

if we think that E_FAIL and E_INVALIDARG are both valid responses. Now,
it could be that Wine does not yet handle the WinFrobnicate call yet and
returns E_NOT_IMPLEMENTED. As we do not want the test suite on Wine, you
might be tempted to write this:

status = WinFrobnicate(foo);
  ok(status == E_FAIL /* Win98*/ ||
     status == E_INVALIDARG /* WinNT,2k,XP*/ ||
     status == E_NOT_IMPLEMENTED /* Wine */, "status %08x\n",status);

DO NOT DO THAT! This means, that the return code E_NOT_IMPLEMENTED is
OK. It definitely is not, but the work on Wine that fixes this problem
has still *to be done*, so you should use a todo block:

status = WinFrobnicate(foo);
  todo_wine ok(status == E_FAIL /* Win98*/ ||
     status == E_INVALIDARG /* WinNT,2k,XP*/, "status %08x\n",status);

A todo block is used like an if statement or a for loop. The todo
applies to the next statement or to all statements inside a block
following the todo, like here:

answer = 0;
  status = WinFrobnicateWithOutput(foo, &answer);
  todo_wine {
     ok(status == E_FAIL /* Win98*/ ||
       status == E_INVALIDARG /* WinNT,2k,XP*/, "status %08x\n",status);
     ok(answer == 42, "Expected the universal answer, got %d\n",answer);
  }

If todo is applied to an OK statement, it must(!) fail for the test to
be successfull. As the Wine test suite is meant to not only show what
how wine should behave but also document where wine does misbehave, the
todo has to be removed as soon as Wine is going to behave correctly. The
only common form of the todo block is the todo_wine block that enters
the todo mode (inverting tests) if the test is run on Wine and does
nothing if the test is run on windows.

Next, lets assume that WinFrobnicate is not implemented on Win95/Win98,
but implemented on WinNT and up. So in this case, one would write

status = WinFrobnicate(foo);
  ok(status == E_NOT_IMPLEMENTED /* Win98*/ ||
     status == E_INVALIDARG /* WinNT,2k,XP*/, "status %08x\n",status);

But in this case, we allow both W_NOT_IMPLEMENTED and E_INVALIDARG as
valid return values, and even Wine passes the test if it just returns
E_INVALIDARG. If Wine should implement this interface, Wine should not
get away with E_NOT_IMPLEMENTED. This is where broken() is used.
broken() returns the value of its argument if the test runs on Windows,
but always false (even if the argument is true) if the test runs on
Wine, so the example should be written like this:

status = WinFrobnicate(foo);
  ok(broken(status == E_NOT_IMPLEMENTED) /* Win98*/ ||
     status == E_INVALIDARG /* WinNT,2k,XP*/, "status %08x\n",status);

The last testing primitive to introduce is skip. skip is meant to be
used if a part of tests could not be executed because the tested system
lacks prerequisites, for example a font with a special codepage, a CD
drive, a sufficiently recent version of a DLL or because the operations
the test wants to perform needs administrative priviledges that the test
does not have. It has just statistical value, in incrementing the number
of skips. It is used like this:

pMagic = CreateMagicInterface("xyzzy");
  if(pMagic)
  {
     ISpell *spell = IMagic_CreateSpell(pMagic,NULL);
     /* lots of tests */
     IMagic_Release(pMagic);
  }
  else
    skip("CreateMagicInterface returned NULL\n");

Again, this is like the multiple alternatives in the ok() function: Wine
gets away without an error being flagged (just a skip, which might be OK
in certain tests) if it does not create the magic interface. So like the
broken() function inside the ok() function, the Wine testing framework
provides a primitive called win_skip() that logs a skip on Windows but
an error on Wine.
> > What's the source of info you have used for that?
>
> It was on a comment to that post: 
> http://blogs.msdn.com/oldnewthing/archive/2005/04/29/412577.aspx
>
> It seems to have been deleted since then though. The comment said about 
> the 0x7fff part, but not about the missing members. I found about the 
> missing members through experimentation after that.

Use this URL instead:
http://web.archive.org/web/20061224095348/http://blogs.msdn.com/oldnewthing/...

Regards,
  Michael Karcher

Re[7] [user32: 2/2] Testcase for font size = 0x7fff

[Koro]

> This is an explanation of the test primitives. Feel free to put it on
> the Wine wiki, if you like it.

That is an *excellent* explanation. Everything becomes clear now, and 
indeed this should be documented somewhere (except I can't find how to 
edit the wiki without making an account). Maybe somebody could wikify it 
for me?
> Use this URL instead:
> http://web.archive.org/web/20061224095348/http://blogs.msdn.com/oldnewthing/...

Oh! Thanks a lot! So, on THIS page, it's the fourth comment down, that 
reads:

"The hack in windows is to just set the font height to 0x7fff (don't 
fill in the other font fields but it still has to be aligned) and it 
will use the lfMessageFont for you."

In the beginning I did read the "don't fill in the other font fields" as 
"set them to zero" but then I understood later it means "they must not 
be there."

Latest Windows Conformance Tests

[Chris Ahrendt]

Causes windows XP SP3 to reboot during d3d test..

What and where do I need to send in the information
on the issue.

Microsoft Windows XP
Home Edition
Version 2002
Sp 3

Pent 4 3.2ghz
2 gig ram

Chris

Latest Windows Conformance Tests

[James Hawkins]

On Sun, Oct 12, 2008 at 2:02 PM, Chris Ahrendt  wrote:
> Causes windows XP SP3 to reboot during d3d test..
>
> What and where do I need to send in the information
> on the issue.

You're going to have to set up a cross-build environment to compile
the d3d tests and figure out which test exactly is causing your
machine to reboot.

Latest Windows Conformance Tests

[Chris Ahrendt]

James Hawkins wrote:
> On Sun, Oct 12, 2008 at 2:02 PM, Chris Ahrendt  wrote:
> > Causes windows XP SP3 to reboot during d3d test..
> >
> > What and where do I need to send in the information
> > on the issue.
>
> You're going to have to set up a cross-build environment to compile
> the d3d tests and figure out which test exactly is causing your
> machine to reboot.

so standard VC++ etc?

Chris

Latest Windows Conformance Tests

[James Hawkins]

On Sun, Oct 12, 2008 at 2:09 PM, Chris Ahrendt  wrote:
> James Hawkins wrote:
> > On Sun, Oct 12, 2008 at 2:02 PM, Chris Ahrendt  wrote:
> > > Causes windows XP SP3 to reboot during d3d test..
> > >
> > > What and where do I need to send in the information
> > > on the issue.
> >
> > You're going to have to set up a cross-build environment to compile
> > the d3d tests and figure out which test exactly is causing your
> > machine to reboot.
>
> so standard VC++ etc?

That's a possibility.  By cross-build, I really meant building the
tests in *nix with mingw and then running the tests, usually in a vm,
but you should use whichever way is fastest for you.

Latest Windows Conformance Tests

[John Klehm]

On Sun, Oct 12, 2008 at 2:02 PM, Chris Ahrendt  wrote:
> Causes windows XP SP3 to reboot during d3d test..
>
> What and where do I need to send in the information
> on the issue.
>
> Microsoft Windows XP
> Home Edition
> Version 2002
> Sp 3
>
> Pent 4 3.2ghz
> 2 gig ram

Probably bugzilla with your video card driver info too.

Cheers,
--John Klehm

Latest Windows Conformance Tests

[Vitaliy Margolen]

Chris Ahrendt wrote:
> Causes windows XP SP3 to reboot during d3d test..

Would you please stop hijacking threads! Do NOT reply when starting a new
topic!!! This is highly annoying and it's deemed a really bad habit.

Vitaliy.

Latest Windows Conformance Tests

[Chris Ahrendt]

Vitaliy Margolen wrote:
> Chris Ahrendt wrote:
> > Causes windows XP SP3 to reboot during d3d test..
>
> Would you please stop hijacking threads! Do NOT reply when starting a new
> topic!!! This is highly annoying and it's deemed a really bad habit.
>
> Vitaliy.

I did not hijack a thread I opened a brand new note thank you...
and I was talking about the windows conformance tests which I am running 
on my home machine... So before you jump on someone by assuming like you 
prefer to do Vitaliy why dont you ask if this is one or not....

Again havent hijacked a thread.. this is a new thread with a problem I 
just got by running on a WINDOWS machine the WINE CONFORMANCE TEST from
http://www.winehq.org/site/docs/winedev-guide/testing-windows
using the precompiled binaries link from that page...

So if you dont mind I would like an appology for you butting in and 
claiming that I am doing something I most certainly am not doing.

Chris

Latest Windows Conformance Tests

[Jérôme Gardou]

Chris Ahrendt a écrit :
> Vitaliy Margolen wrote:
> > Chris Ahrendt wrote:
> > > Causes windows XP SP3 to reboot during d3d test..
> >
> > Would you please stop hijacking threads! Do NOT reply when starting a new
> > topic!!! This is highly annoying and it's deemed a really bad habit.
> >
> > Vitaliy.
>
> I did not hijack a thread I opened a brand new note thank you...
> and I was talking about the windows conformance tests which I am running 
> on my home machine... So before you jump on someone by assuming like you 
> prefer to do Vitaliy why dont you ask if this is one or not....
>
> Again havent hijacked a thread.. this is a new thread with a problem I 
> just got by running on a WINDOWS machine the WINE CONFORMANCE TEST from
> http://www.winehq.org/site/docs/winedev-guide/testing-windows
> using the precompiled binaries link from that page...
>
> So if you dont mind I would like an appology for you butting in and 
> claiming that I am doing something I most certainly am not doing.
>
> Chris

For me too, this thread is in the middle of "[user32] Testcase for font 
size = 0x7ff"
This is annoying, but there is no need to be so harsh.
BTW, thanks for the link above, I didn't know it existed :)

Latest Windows Conformance Tests

[Vitaliy Margolen]

Chris Ahrendt wrote:
> Vitaliy Margolen wrote:
> > Chris Ahrendt wrote:
> > > Causes windows XP SP3 to reboot during d3d test..
> >
> > Would you please stop hijacking threads! Do NOT reply when starting a new
> > topic!!! This is highly annoying and it's deemed a really bad habit.
> >
> > Vitaliy.
>
> I did not hijack a thread I opened a brand new note thank you...
> and I was talking about the windows conformance tests which I am running
> on my home machine... So before you jump on someone by assuming like you
> prefer to do Vitaliy why dont you ask if this is one or not....
>
> Again havent hijacked a thread.. this is a new thread with a problem I
> just got by running on a WINDOWS machine the WINE CONFORMANCE TEST from
> http://www.winehq.org/site/docs/winedev-guide/testing-windows
> using the precompiled binaries link from that page...
>
> So if you dont mind I would like an appology for you butting in and
> claiming that I am doing something I most certainly am not doing.
>
> Chris

Then get a new e-mail client. Or read the manual for how to use your
existing one. From the message you sent:
> To: wine-devel 
> Subject: Latest Windows Conformance Tests
> References: 							
>    
> In-Reply-To:

They match the previous message's:
> Message-id: 
> References: 
>    
>    
>    
>    
>    
>    

So I'm asking one more time. Please DO NOT reply to the messages when you
starting a new topic!!! Make a new message.

Vitaliy.

Re[7] [user32: 2/2] Testcase for font size = 0x7fff

[Reece Dunn]

2008/10/12 Koro :
> "The hack in windows is to just set the font height to 0x7fff (don't
> fill in the other font fields but it still has to be aligned) and it
> will use the lfMessageFont for you."
>
> In the beginning I did read the "don't fill in the other font fields" as
> "set them to zero" but then I understood later it means "they must not
> be there."

This will also affect the Wine RC compiler as well.

- Reece

Re[9] [user32: 2/2] Testcase for font size = 0x7fff

[Koro]

> This will also affect the Wine RC compiler as well.

Even the Windows RC compiler emits an invalid template in that case.
I just tested with this .rc file:

----
#include <windows.h>

MSGBOXFONT DIALOGEX 0,0,128,128
STYLE WS_SYSMENU|WS_CAPTION|WS_POPUP|DS_SETFONT|DS_MODALFRAME
CAPTION "Test"
FONT 0x7fff,"",0,0,0
BEGIN
LTEXT "WINE dialog test.",-1,0,0,128,128
END
----

RC version is 6.1.6723.1

It would complain that the font name was missing if I'd give it only 
"FONT 0x7fff". And it emits the 6 bytes for the '"",0,0,0' part (which 
it shouldn't)