Re: [user32: 2/2] Testcase for font size = 0x7fff
"Koro" <webmaster(a)korosoft.net> 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. -- Dmitry.
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.
"Koro" <webmaster(a)korosoft.net> 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? -- Dmitry.
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.
"Koro" <webmaster(a)korosoft.net> 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. -- Dmitry.
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...
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
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."
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
On Sun, Oct 12, 2008 at 2:02 PM, Chris Ahrendt <celticht32(a)aol.com> 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. -- James Hawkins
James Hawkins wrote:
On Sun, Oct 12, 2008 at 2:02 PM, Chris Ahrendt <celticht32(a)aol.com> 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
On Sun, Oct 12, 2008 at 2:09 PM, Chris Ahrendt <celticht32(a)aol.com> wrote:
James Hawkins wrote:
On Sun, Oct 12, 2008 at 2:02 PM, Chris Ahrendt <celticht32(a)aol.com> 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. -- James Hawkins
On Sun, Oct 12, 2008 at 2:02 PM, Chris Ahrendt <celticht32(a)aol.com> 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
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
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 :)
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 <wine-devel(a)winehq.org> Subject: Latest Windows Conformance Tests References: <48EFB559.7060207(a)korosoft.net> <FBB3029D864B44AF9C010D32512E907A(a)DMITRY> <48F098C0.4070008(a)korosoft.net> <06283CBD326E491CBDF265B60DFF0613(a)DMITRY> <48F133E5.3030607(a)korosoft.net> <BC1EB2CB7E90454F93D0B268E906F354(a)DMITRY> <48F18C18.4010301(a)korosoft.net> <1223813616.2611.220.camel(a)hermes2.karcher.local> <48F247F8.5040500(a)korosoft.net> In-Reply-To: <48F247F8.5040500(a)korosoft.net>
They match the previous message's:
Message-id: <48F247F8.5040500(a)korosoft.net> References: <48EFB559.7060207(a)korosoft.net> <FBB3029D864B44AF9C010D32512E907A(a)DMITRY> <48F098C0.4070008(a)korosoft.net> <06283CBD326E491CBDF265B60DFF0613(a)DMITRY> <48F133E5.3030607(a)korosoft.net> <BC1EB2CB7E90454F93D0B268E906F354(a)DMITRY> <48F18C18.4010301(a)korosoft.net> <1223813616.2611.220.camel(a)hermes2.karcher.local>
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.
2008/10/12 Koro <webmaster(a)korosoft.net>:
"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
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)
participants (9)
-
Chris Ahrendt -
Dmitry Timoshkov -
James Hawkins -
John Klehm -
Jérôme Gardou -
Koro -
Michael Karcher -
Reece Dunn -
Vitaliy Margolen