Re: msvcrt: Implement _mbctombb.
Hi again,
On Wed, Feb 24, 2010 at 8:27 AM, Maarten Lankhorst
m.b.lankho...@gmail.com wrote:
Hi David,
David Hedberg wrote:
On Wed, Feb 24, 2010 at 7:12 AM, Maarten Lankhorst
m.b.lankho...@gmail.com wrote:
Hi David,
Hi Maarten,
David Hedberg wrote:
+/* Maps multibyte cp932 punctuation marks to single byte equivalents */
+static unsigned int mbctombb_932_punct[] = {
+
0x20,0xa4,0xa1,0x2c,0x2e,0xa5,0x3a,0x3b,0x3f,0x21,0xde,0xdf,0x00,0x00,0x00,0x5e,
+
0x7e,0x5f,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0xb0,0x00,0x00,0x2f,0x00,
+
0x00,0x00,0x7c,0x00,0x00,0x60,0x27,0x00,0x22,0x28,0x29,0x00,0x00,0x5b,0x5d,0x7b,
+
0x7d,0x00,0x00,0x00,0x00,0xa2,0xa3,0x00,0x00,0x00,0x00,0x2b,0x2d,0x00,0x00,0x00,
+
0x00,0x3d,0x00,0x3c,0x3e,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x5c,
+ 0x24,0x00,0x00,0x25,0x23,0x26,0x2a,0x40};
+
+/* Maps multibyte cp932 hiragana/katakana to single-byte equivalents */
+static unsigned int mbctombb_932_kana[] = {
+
0xa7,0xb1,0xa8,0xb2,0xa9,0xb3,0xaa,0xb4,0xab,0xb5,0xb6,0xb6,0xb7,0xb7,0xb8,0xb8,
+
0xb9,0xb9,0xba,0xba,0xbb,0xbb,0xbc,0xbc,0xbd,0xbd,0xbe,0xbe,0xbf,0xbf,0xc0,0xc0,
+
0xc1,0xc1,0xaf,0xc2,0xc2,0xc3,0xc3,0xc4,0xc4,0xc5,0xc6,0xc7,0xc8,0xc9,0xca,0xca,
+
0xca,0xcb,0xcb,0xcb,0xcc,0xcc,0xcc,0xcd,0xcd,0xcd,0xce,0xce,0xce,0xcf,0xd0,0xd1,
+
0xd2,0xd3,0xac,0xd4,0xad,0xd5,0xae,0xd6,0xd7,0xd8,0xd9,0xda,0xdb,0xdc,0xdc,0xb2,
+ 0xb4,0xa6,0xdd,0xb3,0xb6,0xb9};
You're hardcoding this for a single code page? Are you sure you cannot
use a
more generic function instead of hardcoding a table?
I haven't found anything that might handle it. The function in
question maps the characters in a somewhat irregular fashion, and
only makes sense for code page 932. There's a static function
han2zen in dlls/mlang/mlang.c that appears to be the inverse (to
the extent this function is reversible), that one too is implemented
with a couple of tables.
Well, it seems msdn says the function used to be called zentohan, so if the
function only makes sense for cp 932 then adding the table is harmless, I
was afraid that more locales would need that function, in which case a more
generic solution would have been preferred.
Well, I should add that it only makes sense for cp 932 as far as I
know, but then I'm only familiar with Japanese. More important perhaps
is that I also ran some tests on Win XP and Win 7 trying to get it to
return anything for other code pages (basically looped through them
all with _setmbcp), but only with cp 932 did it return anything other
than what was given to it.
I'm no expert on the win32 API though, so it is possible that I have
missed something. :-)
Cheers,
Maarten.
PS: Use 'reply all' so wine-devel gets cc'd.
Woops, sorry!
Thanks,
David
Re: msvcrt: Implement _mbctombb.
On 24 February 2010 08:51, David Hedberg david.hedb...@gmail.com wrote: Well, I should add that it only makes sense for cp 932 as far as I know, but then I'm only familiar with Japanese. More important perhaps is that I also ran some tests on Win XP and Win 7 trying to get it to return anything for other code pages (basically looped through them all with _setmbcp), but only with cp 932 did it return anything other than what was given to it. I'm no expert on the win32 API though, so it is possible that I have missed something. :-) Could you add that to your test case, and then run it on the winetestbot with a range of OSs? This will help show that it is only CP 932 that is affected by that function. Thanks, - Reece
Re: PeekMsg/MsgWaitForMultipleObjects question
Hi,
Alexandre wrote:
Message waiting functions only return for new input. You need to make
sure the queue is empty before waiting.
Actually, now that I believe I understand the issue, I'd rephrase it
differently: The queue need not be empty (a message might have
arrived 1 microsecond before the call to MsgWaitFor*). The key
issue is that once you start to call PeekMessage or GetMessage, you
must empty the queue with these functions before calling Wait again,
because all messages present in the queue at Get/PeekMessage
time will be marked not new (my understanding now of MSDN).
for(;;) { PeekMessage(REMOVE)/*=pick 1*/; Wait(); }
will timeout/hang because of this when 2 messages arrive.
Exactly that happened to my code.
Regards,
Jörg Höhle
Re: [PATCH] ole32: ignore HighPart in the Seek method HGLOBAL streams. [try 2]
Reece Dunn mscl...@googlemail.com writes: NOTE: A check for integer overflow would be `position.low + move.low position.low`, but there are no current tests to say if integer overflow is handled (and how it is handled) here in the tests. Therefore, the simplest implementation is just to remove the previous check. It may be the simplest, but the right way is to add such a test and figure out the appropriate behavior. -- Alexandre Julliard julli...@winehq.org
Re: [PATCH] ole32: ignore HighPart in the Seek method HGLOBAL streams. [try 2]
On 24 February 2010 11:06, Alexandre Julliard julli...@winehq.org wrote: Reece Dunn mscl...@googlemail.com writes: NOTE: A check for integer overflow would be `position.low + move.low position.low`, but there are no current tests to say if integer overflow is handled (and how it is handled) here in the tests. Therefore, the simplest implementation is just to remove the previous check. It may be the simplest, but the right way is to add such a test and figure out the appropriate behavior. Will do -- that was next on my things to do. Do I need to do that first before this change, or after it? - Reece
Re: [PATCH] ole32: ignore HighPart in the Seek method HGLOBAL streams. [try 2]
On 24 February 2010 11:41, Alexandre Julliard julli...@winehq.org wrote: Reece Dunn mscl...@googlemail.com writes: On 24 February 2010 11:06, Alexandre Julliard julli...@winehq.org wrote: It may be the simplest, but the right way is to add such a test and figure out the appropriate behavior. Will do -- that was next on my things to do. Do I need to do that first before this change, or after it? Before, since otherwise you are removing code that may still be needed. I have run some tests on XP and Win7: Seek 0x: hr=80030019, High=, Low= Seek 0x8000: hr=80030019, High=, Low= Seek 0x7FFF: hr=, High=, Low=7fff Seek 0x0009: hr=, High=, Low=8008 Seek 0x7FFF: hr=, High=, Low=0007 So it looks like Windows: 1/ does not accept a LowPart that is greater than 0x7FFF; 2/ does not check for integer overflow. I will clean these up and write them as proper tests for ole32:hglobalstream and then fix the todo blocks to implement the correct behaviour later on today. Thanks, - Reece
Re: user32: Windows allows to delete a busy DC, add a test case.
Dmitry Timoshkov dmi...@codeweavers.com writes: The test passes under XP SP3. --- dlls/gdi32/tests/dc.c | 43 ++- dlls/user32/painting.c | 17 - 2 files changed, 46 insertions(+), 14 deletions(-) You'd want to verify this with class and windows DCs too before removing the check. -- Alexandre Julliard julli...@winehq.org
Re: [PATCH] ole32: ignore HighPart in the Seek method HGLOBAL streams. [try 2]
Reece Dunn mscl...@googlemail.com writes: On 24 February 2010 11:06, Alexandre Julliard julli...@winehq.org wrote: It may be the simplest, but the right way is to add such a test and figure out the appropriate behavior. Will do -- that was next on my things to do. Do I need to do that first before this change, or after it? Before, since otherwise you are removing code that may still be needed. -- Alexandre Julliard julli...@winehq.org
Re: tests: WINETEST_STRICT=1 disables broken().
joerg-cyril.hoe...@t-systems.com writes: It would be valuable if, from time to time, WTB on test.winehq would run the XP/7/Vista tests with WINETEST_STRICT to assess how close Wine really is to native behaviour. I'm not 100% satisfied with WINETEST_STRICT. Beside WINETEST_INTERACTIVE, I'm wondering whether it is time to turn WINETEST_DEBUG into a bit field. Then Greg, our WTB hero, would not need to update the web GUI every time a new env variable is proposed. Then everybody could easily submit WTB jobs in either strict or normal mode. You can do the same thing by changing WINETEST_PLATFORM, no need for a separate variable. -- Alexandre Julliard julli...@winehq.org
Re: user32: Use whole window rectangle for UpdateLayeredWindow
Nikolay Sivov nsi...@codeweavers.com writes:
@@ -3398,14 +3398,14 @@ BOOL WINAPI UpdateLayeredWindowIndirect( HWND hwnd,
const UPDATELAYEREDWINDOWINF
if (info-hdcSrc)
{
-HDC hdc = GetDCEx( hwnd, 0, DCX_CACHE );
+HDC hdc = GetWindowDC( hwnd );
if (hdc)
{
int x = 0, y = 0;
RECT rect;
-GetClientRect( hwnd, rect );
+GetWindowRect( hwnd, rect );
if (info-pptSrc)
{
x = info-pptSrc-x;
@@ -3415,8 +3415,8 @@ BOOL WINAPI UpdateLayeredWindowIndirect( HWND hwnd,
const UPDATELAYEREDWINDOWINF
if (!info-prcDirty || (info-prcDirty IntersectRect(rect,
rect, info-prcDirty)))
{
TRACE( copying window %p pos %d,%d\n, hwnd, x, y );
-BitBlt( hdc, rect.left, rect.top, rect.right, rect.bottom,
-info-hdcSrc, rect.left + x, rect.top + y, SRCCOPY );
+BitBlt( hdc, 0, 0, rect.right - rect.left, rect.bottom -
rect.top,
+info-hdcSrc, x, y, SRCCOPY );
Shouldn't you map prcDirty to window coordinates before intersecting?
--
Alexandre Julliard
julli...@winehq.org
Re: user32: DeleteDC() should allow to delete a DC returned by GetDC(). Take 2.
Dmitry Timoshkov dmi...@codeweavers.com writes: The test passes under XP SP3. --- dlls/gdi32/dc.c|2 +- dlls/gdi32/tests/dc.c | 107 +++- dlls/user32/painting.c |2 +- 3 files changed, 108 insertions(+), 3 deletions(-) You still need to test window DCEs (CS_OWNDC). -- Alexandre Julliard julli...@winehq.org
Re: ntdll/tests: Add more tests for registry symlinks.
Hi Alexandre,
This one made my Vista (Ultimate SP2) box starting to crash (the box
itself not just the test). Another Vista Ultimate SP2 system doesn't
show this issue. Both boxes are VMware guests btw though on different hosts.
The attached patch shows the culprit but I'm not sure if the preceding
NtOpenKey block should be skipped as well.
We can just if (0) this whole block but we will never be sure how many
systems were affected. Does the fact that one of my boxes crashes
warrant the skipping of this particular test?
--
Cheers,
Paul.
diff --git a/dlls/ntdll/tests/reg.c b/dlls/ntdll/tests/reg.c
index 8a86627..218b5e7 100644
--- a/dlls/ntdll/tests/reg.c
+++ b/dlls/ntdll/tests/reg.c
@@ -749,6 +749,7 @@ static void test_symlinks(void)
wrong len %u\n, len );
pNtClose( key );
+#if 0
status = pNtCreateKey( key, KEY_ALL_ACCESS, attr, 0, 0, 0, 0 );
ok( status == STATUS_SUCCESS, NtCreateKey failed: 0x%08x\n, status );
len = sizeof(buffer);
@@ -757,6 +758,7 @@ static void test_symlinks(void)
ok( len == FIELD_OFFSET(KEY_VALUE_PARTIAL_INFORMATION,Data) + target_len -
sizeof(WCHAR),
wrong len %u\n, len );
pNtClose( key );
+#endif
if (0) /* crashes the Windows kernel in most versions */
{
Using assert() in wine dll code
Hi! Recently I've run into excessive use of assertions in some code after a regression was caused by one of my commits. A parameter that came from the application was validated this way. The code in question is in quartz.dll but there are asserts in many other places, a short grep in the dlls directory found 1387 of them... I suggest we carefully evaluate asserts from wine dll code. Only locally computed conditions should trigger an assertion failure (in case we have coding errors). Parameters received from function calls should either return an error (and possibly a WARN or ERR message) or segfault if Windows does the same (so a handler would potentially catch the proper exception). Would this qualify as a task or tasklet? Paul Chitescu
Re: [2/2] wordpad: Number of preview pages to show when unzoomed is persistent.
Either one or two pages may be shown in print preview when zoomed out. This value is stored in the registry in native wordpad, and preserved while opening and closing the print preview. Zooming in will only show one page, but the pages shown value must be saved because it will return to the preview pages shown value after unzooming completely. If two pages should be shown when there is only one page of text, then a second blank page is shown. Dylan: The Windows version of Wordpad also stores the last font values (name/point sized) used in the Registry as well. Is this needed/desired with the Wine version? Thank you. James McKenzie
Re: ntdll/tests: Add more tests for registry symlinks.
Paul Vriens paul.vriens.w...@gmail.com writes: Hi Alexandre, This one made my Vista (Ultimate SP2) box starting to crash (the box itself not just the test). Another Vista Ultimate SP2 system doesn't show this issue. Both boxes are VMware guests btw though on different hosts. The attached patch shows the culprit but I'm not sure if the preceding NtOpenKey block should be skipped as well. We can just if (0) this whole block but we will never be sure how many systems were affected. Does the fact that one of my boxes crashes warrant the skipping of this particular test? Sure, the test following it already had to be commented out because it crashes the kernel on most versions. It's just not something apps would be doing. -- Alexandre Julliard julli...@winehq.org
Bad usage of ok() macro in tests
Hi,
While trying to manage to fix warning about unused values, I've found a
problem about some usages of ok() macro.
ok() macros is defined in include/wine/test.h as:
#define ok_(file, line) (winetest_set_location(file, line),
0) ? 0 : winetest_ok
#define ok ok_(__FILE__, __LINE__)
One good example:
ok( val != NULL, Invalid value\n);
is expanded as
(winetest_set_location(file, line), 0) ? 0 : winetest_ok(val != NULL,
Invalid value\n);
One bad example:
if (!ok( val != NULL, Invalid value\n))
is expanded as
if (!(winetest_set_location(file, line), 0) ? 0 : winetest_ok(val !=
NULL, Invalid value\n))
And is then evaluated as
1) if ( !(0) ? 0 : winetest_ok(val != NULL, Invalid value\n))
2) if ( 1 ? 0 : winetest_ok(val != NULL, Invalid value\n))
^
ouch !
3) if (0)
So this is pretty useless.
Hopefully, this is only of limited use in wine test suite: find . -type
d -name tests | xargs grep -r '[=\!][[:space:](]*ok[[:space:]]*('
returns only four cases:
./dlls/user32/tests/scroll.c:if ( !ok( hMainWnd != NULL, Failed to
create parent window. Tests aborted.\n ) )
./dlls/kernel32/tests/file.c:!ok( UnlockFile( handle, 100, 0, 10,
0 ), UnlockFile 100,10 failed\n );
./dlls/comctl32/tests/treeview.c:if ( !ok(hMainWnd != NULL, Failed
to create parent window. Tests aborted.\n) )
./dlls/shell32/tests/autocomplete.c:if(!ok(hMainWnd != NULL, Failed
to create parent window. Tests aborted.\n))
There's only 3 case with a real problem. The fourth is something very
strange: the !ok() in ./dlls/kernel32/tests/file.c seems to be a typo,
or someone wanted to disable the test.
Regards.
--
Yann Droneaud
Re: user32: Use whole window rectangle for UpdateLayeredWindow
On 2/24/2010 15:57, Alexandre Julliard wrote: Shouldn't you map prcDirty to window coordinates before intersecting? Of course, see try3.
Re: Bad usage of ok() macro in tests
Le mercredi 24 février 2010 à 15:47 +0100, Yann Droneaud a écrit :
Hi,
While trying to manage to fix warning about unused values, I've found a
problem about some usages of ok() macro.
ok() macros is defined in include/wine/test.h as:
#define ok_(file, line) (winetest_set_location(file, line),
0) ? 0 : winetest_ok
#define ok ok_(__FILE__, __LINE__)
Hopefully, this is only of limited use in wine test suite: find . -type
d -name tests | xargs grep -r '[=\!][[:space:](]*ok[[:space:]]*('
returns only four cases:
In fact, it seems there's no more than those construct which use ok()
return value.
Try :
find . -type d -and -name 'tests' | xargs grep -nr
'if[[:space:]]*([[:space:]]*\!\?[[:space:](]*ok[[:space:]]*('
find . -type d -and -name 'tests' | xargs grep -r '[=\!]\
+[[:space:](]*ok[[:space:]]*('
So I think it's a good opportunity to simplify ok() and let's it return
void:
#define ok winetest_set_location(__FILE__, __LINE__), winetest_ok
Regards
--
Yann Droneaud
Regression? in first-run of Dragon NaturallySpeaking
I haven't been installing Dragon NaturallySpeaking every day for over a week, but I did try it today, and noticed that a bug has apparently crept in. Here's what happens: Installation runs fine. Then I try running the program for the first time. The microphone level test is fine, and the test for microphone accuracy. But then the window that brings up the training dialogue freezes. I imagine it's probably been noticed, but wanted to make sure before I investigated and filed a bug or did a regression test. Susan
Re: [2/2] wordpad: Number of preview pages to show when unzoomed is persistent.
On Wed, Feb 24, 2010 at 9:04 AM, James Mckenzie jjmckenzi...@earthlink.netwrote: Either one or two pages may be shown in print preview when zoomed out. This value is stored in the registry in native wordpad, and preserved while opening and closing the print preview. Zooming in will only show one page, but the pages shown value must be saved because it will return to the preview pages shown value after unzooming completely. If two pages should be shown when there is only one page of text, then a second blank page is shown. Dylan: The Windows version of Wordpad also stores the last font values (name/point sized) used in the Registry as well. Is this needed/desired with the Wine version? First of all this would be a separate issue from my patch. Secondly I do not see these values in the registry for wordpad, and font name and points size seem to be the same when starting up wordpad regardless of any font changes I make to the text the preview time wordpad was run. I am testing using Windows XP, so perhaps this has changed with newer version of wordpad. Perhaps this could also be related to some system font default which would be independent of wordpad.
Re: shell32[2/2]: implements shell link's GetCurFile (with tests, fixes bug #21297) [try4]
Hi Mikolaj, this one was rejected due to formatting, I imagine because of C++ comments in the tests: +// Setting the same value will not set IsDirty... Would you mind fixing and resending? Thanks, --Juan
Re: Bad usage of ok() macro in tests
On Wed, Feb 24, 2010 at 9:25 AM, Yann Droneaud y...@droneaud.fr wrote:
Le mercredi 24 février 2010 à 15:47 +0100, Yann Droneaud a écrit :
Hi,
While trying to manage to fix warning about unused values, I've found a
problem about some usages of ok() macro.
ok() macros is defined in include/wine/test.h as:
#define ok_(file, line) (winetest_set_location(file, line),
0) ? 0 : winetest_ok
#define ok ok_(__FILE__, __LINE__)
Hopefully, this is only of limited use in wine test suite: find . -type
d -name tests | xargs grep -r '[=\!][[:space:](]*ok[[:space:]]*('
returns only four cases:
In fact, it seems there's no more than those construct which use ok()
return value.
Try :
find . -type d -and -name 'tests' | xargs grep -nr
'if[[:space:]]*([[:space:]]*\!\?[[:space:](]*ok[[:space:]]*('
find . -type d -and -name 'tests' | xargs grep -r '[=\!]\
+[[:space:](]*ok[[:space:]]*('
So I think it's a good opportunity to simplify ok() and let's it return
void:
#define ok winetest_set_location(__FILE__, __LINE__), winetest_ok
Nice catch! Seems Alexandre fixed these issues:
http://source.winehq.org/git/wine.git/?a=commitdiff;h=69ee0ad151b4ae14fa017d3f5a284af587d7de01
http://source.winehq.org/git/wine.git/?a=commitdiff;h=fbbac38e4ed9fd95d5ab3d0422bcc55ee2d39498
http://source.winehq.org/git/wine.git/?a=commitdiff;h=2432b0f6b91e57e886dfe39db83d991fde00c2b5
http://source.winehq.org/git/wine.git/?a=commitdiff;h=d5a54642f478a530cf7672332c423233d11f157f
http://source.winehq.org/git/wine.git/?a=commitdiff;h=d279227538a32130c437ba8523f7c928e1b1d109
--
-Austin
Re: Regression? in first-run of Dragon NaturallySpeaking
On Wed, Feb 24, 2010 at 9:48 AM, Susan Cragin susancra...@earthlink.net wrote: I haven't been installing Dragon NaturallySpeaking every day for over a week, but I did try it today, and noticed that a bug has apparently crept in. Here's what happens: Installation runs fine. Then I try running the program for the first time. The microphone level test is fine, and the test for microphone accuracy. But then the window that brings up the training dialogue freezes. I imagine it's probably been noticed, but wanted to make sure before I investigated and filed a bug or did a regression test. I haven't seen anything on bugzilla yet. For what it's worth, while I'm sure others use it pretty often, you're the main source of bug/testing reports on it. It's great to see someone really devoted to their applications. Good/quick bug reports are always appreciated :-). -- -Austin
Re: shell32[2/2]: implements shell link's GetCurFile (with tests, fixes bug #21297) [try4]
Juan Lang pisze: Hi Mikolaj, this one was rejected due to formatting, I imagine because of C++ comments in the tests: +// Setting the same value will not set IsDirty... Would you mind fixing and resending? Thanks, --Juan Yes, I've sent the old patch with C++ comments (and a typo). I should be able to generate a correct one today. Mikołaj
grr. america's army 3 downloader requires .net 3.5...
http://www.americasarmy.com/downloads/ lists two ways to download: 1) steam, which works, after some tweaking. 2) deploy client (see http://www.aadeploy.com ), which uses .net 3.5. Bleah.
Preferred way of dll registration
Hi, We seem to have 2 different approaches for dll registration: 1) a regsvr.c file with all the necessary functions and registry information. 2) an inf file and some code to register/unregister the dll. The first one is the most common in our source but I can remember a comment from AJ about favoring the latter (or at least something like maybe we should start using inf files for registration). Thoughts? -- Cheers, Paul.
Re: Preferred way of dll registration
Hi Paul, On 2/24/10 8:59 PM, Paul Vriens wrote: Hi, We seem to have 2 different approaches for dll registration: 1) a regsvr.c file with all the necessary functions and registry information. 2) an inf file and some code to register/unregister the dll. 3) IRegistrar from atl.dll The first one is the most common in our source but I can remember a comment from AJ about favoring the latter (or at least something like maybe we should start using inf files for registration). Thoughts? I think both 2) and 3) are way better than regsvr.c. It avoids code duplication and you can add much more custom registries without a single line of C (I'd call it more flexible, but it's more a better flexibility/efforts factor). IRegistrar is much simplier than .inf parser, so it has fewer builtin features. Most useful things may be handled IRegistrar and very simple code in DllRegisterServer implementation to pass some string replacements. Using it would also require moving atliface.idl to include directory. Its advantage is that .rgs files are much cleaner as they represent keys as a tree (see dlls/atl/atl.rgs for an example). I usually use .inf files, but if we'd be considering standardization, my vote would go for IRegistrar and I'm surely all for limiting regsvr.c use. Thanks, Jacek
Re: dns-sd dll implementation -- Needs work
On Feb 23, 2010, at 12:31 PM, Gert van den Berg wrote:Just a note: According to Wikipedia, Photoshop CS3 is among theapplications using Bonjour under Windows:http://blogs.adobe.com/jnack/2007/01/cs3_doesnt_inst.htmlGertAnd I read a bugzilla report that CS3 was having issues because of it.From what I can tell, DNS SD uses obscure structs and memory is allocated / deallocated using it's own functions. This wrapper wraps each function.I did edit the configure.ac file, but couldn't get autoconf to create a good configure file.Patch v2 attached dns-sd.diff Description: Binary data
Re: Preferred way of dll registration
Jacek Caban ja...@codeweavers.com writes: I think both 2) and 3) are way better than regsvr.c. It avoids code duplication and you can add much more custom registries without a single line of C (I'd call it more flexible, but it's more a better flexibility/efforts factor). IRegistrar is much simplier than .inf parser, so it has fewer builtin features. Most useful things may be handled IRegistrar and very simple code in DllRegisterServer implementation to pass some string replacements. Using it would also require moving atliface.idl to include directory. Its advantage is that .rgs files are much cleaner as they represent keys as a tree (see dlls/atl/atl.rgs for an example). I usually use .inf files, but if we'd be considering standardization, my vote would go for IRegistrar and I'm surely all for limiting regsvr.c use. Certainly anything is better than regsvr.c files. The ideal solution would be to be able to generate the registration code with widl, along the lines of dlldata.c (though we could also have it generate a .inf/.rgs file if that's easier). It would probably require defining some sort of magic attributes to add to the headers. -- Alexandre Julliard julli...@winehq.org
Re: gdiplus: Implement GdipImageRotateFlip.
Sorry, this is wrong. It'll clobber the bitmap's palette if it originally has one. On Wed, Feb 24, 2010 at 5:10 PM, Vincent Povirk vinc...@codeweavers.com wrote:
Re: [PATCH 1/2] gdiplus/test: Add GdipGetNearestColor test [try 2]
Thanks for reviewing the patch Vincent!
I'm reworking the test to use bitmaps but I've run into a problem.
I'm using GdipGetImageGraphicsContext to convert from a bitmap
to a graphic, this works fine at 16bpp and higher, but below that it
returns OutOfMemory on Window (seems that this function doesn't
accept palettized images). Thoughts on how to test at these
color depths?
Justin
On Tue, Feb 23, 2010 at 10:55 PM, Vincent Povirk
madewokherd+8...@gmail.com wrote:
You should probably use a Bitmap object rather than the display for
this, since the pixel format is important. That should make it
possible to test other depths, even though they can't yet be
implemented properly in Wine.
Also, you should mark tests that fail in wine with todo_wine and
remove the todo_wine in any subsequent patches that fix them.
On Tue, Feb 23, 2010 at 8:56 PM, Justin Chevrier jchevr...@gmail.com wrote:
---
dlls/gdiplus/tests/graphics.c | 45
+
1 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/dlls/gdiplus/tests/graphics.c b/dlls/gdiplus/tests/graphics.c
index 45bd9f7..97c520d 100644
--- a/dlls/gdiplus/tests/graphics.c
+++ b/dlls/gdiplus/tests/graphics.c
@@ -21,6 +21,7 @@
#include windows.h
#include gdiplus.h
#include wingdi.h
+#include winuser.h
#include wine/test.h
#include math.h
@@ -2270,6 +2271,49 @@ static void test_GdipIsVisibleRect(void)
ReleaseDC(0, hdc);
}
+static void test_GdipGetNearestColor(void)
+{
+ GpStatus status;
+ GpGraphics *graphics = NULL;
+ ARGB color = 0xdeadbeef;
+ HDC hdc = GetDC(0);
+ DEVMODEA dmA;
+ BOOL ret;
+
+ /* create a graphics object */
+ ok(hdc != NULL, Expected HDC to be initialized\n);
+
+ status = GdipCreateFromHDC(hdc, graphics);
+ expect(Ok, status);
+ ok(graphics != NULL, Expected graphics to be initialized\n);
+
+ status = GdipGetNearestColor(graphics, NULL);
+ expect(InvalidParameter, status);
+
+ status = GdipGetNearestColor(NULL, color);
+ expect(InvalidParameter, status);
+
+ ret = EnumDisplaySettingsA(NULL, ENUM_CURRENT_SETTINGS, dmA);
+ if (!ret)
+ {
+ skip(Could not determine color depth\n);
+ goto end;
+ }
+
+ if (dmA.dmBitsPerPel = 24)
+ {
+ status = GdipGetNearestColor(graphics, color);
+ expect(Ok, status);
+ ok(color == 0xdeadbeef, expected 0xdeadbeef, got: 0x%08x\n,
color);
+ }
+ else
+ skip(Color depth less than 24bpp.\n);
+
+ end:
+ GdipDeleteGraphics(graphics);
+ ReleaseDC(0, hdc);
+}
+
START_TEST(graphics)
{
struct GdiplusStartupInput gdiplusStartupInput;
@@ -2296,6 +2340,7 @@ START_TEST(graphics)
test_GdipDrawLineI();
test_GdipDrawLinesI();
test_GdipDrawString();
+ test_GdipGetNearestColor();
test_GdipGetVisibleClipBounds();
test_GdipIsVisiblePoint();
test_GdipIsVisibleRect();
--
1.6.5.rc1
Re: [PATCH 1/2] gdiplus/test: Add GdipGetNearestColor test [try 2]
Well, that's interesting.
It would be worth trying your test on Windows 7, as some other
problems with paletted images were fixed in that version.
You could also try creating an 8-bit device-independent bitmap using
gdi32 and selecting it into a compatible DC.
On Wed, Feb 24, 2010 at 6:29 PM, Justin Chevrier jchevr...@gmail.com wrote:
Thanks for reviewing the patch Vincent!
I'm reworking the test to use bitmaps but I've run into a problem.
I'm using GdipGetImageGraphicsContext to convert from a bitmap
to a graphic, this works fine at 16bpp and higher, but below that it
returns OutOfMemory on Window (seems that this function doesn't
accept palettized images). Thoughts on how to test at these
color depths?
Justin
On Tue, Feb 23, 2010 at 10:55 PM, Vincent Povirk
madewokherd+8...@gmail.com wrote:
You should probably use a Bitmap object rather than the display for
this, since the pixel format is important. That should make it
possible to test other depths, even though they can't yet be
implemented properly in Wine.
Also, you should mark tests that fail in wine with todo_wine and
remove the todo_wine in any subsequent patches that fix them.
On Tue, Feb 23, 2010 at 8:56 PM, Justin Chevrier jchevr...@gmail.com wrote:
---
dlls/gdiplus/tests/graphics.c | 45
+
1 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/dlls/gdiplus/tests/graphics.c b/dlls/gdiplus/tests/graphics.c
index 45bd9f7..97c520d 100644
--- a/dlls/gdiplus/tests/graphics.c
+++ b/dlls/gdiplus/tests/graphics.c
@@ -21,6 +21,7 @@
#include windows.h
#include gdiplus.h
#include wingdi.h
+#include winuser.h
#include wine/test.h
#include math.h
@@ -2270,6 +2271,49 @@ static void test_GdipIsVisibleRect(void)
ReleaseDC(0, hdc);
}
+static void test_GdipGetNearestColor(void)
+{
+ GpStatus status;
+ GpGraphics *graphics = NULL;
+ ARGB color = 0xdeadbeef;
+ HDC hdc = GetDC(0);
+ DEVMODEA dmA;
+ BOOL ret;
+
+ /* create a graphics object */
+ ok(hdc != NULL, Expected HDC to be initialized\n);
+
+ status = GdipCreateFromHDC(hdc, graphics);
+ expect(Ok, status);
+ ok(graphics != NULL, Expected graphics to be initialized\n);
+
+ status = GdipGetNearestColor(graphics, NULL);
+ expect(InvalidParameter, status);
+
+ status = GdipGetNearestColor(NULL, color);
+ expect(InvalidParameter, status);
+
+ ret = EnumDisplaySettingsA(NULL, ENUM_CURRENT_SETTINGS, dmA);
+ if (!ret)
+ {
+ skip(Could not determine color depth\n);
+ goto end;
+ }
+
+ if (dmA.dmBitsPerPel = 24)
+ {
+ status = GdipGetNearestColor(graphics, color);
+ expect(Ok, status);
+ ok(color == 0xdeadbeef, expected 0xdeadbeef, got: 0x%08x\n,
color);
+ }
+ else
+ skip(Color depth less than 24bpp.\n);
+
+ end:
+ GdipDeleteGraphics(graphics);
+ ReleaseDC(0, hdc);
+}
+
START_TEST(graphics)
{
struct GdiplusStartupInput gdiplusStartupInput;
@@ -2296,6 +2340,7 @@ START_TEST(graphics)
test_GdipDrawLineI();
test_GdipDrawLinesI();
test_GdipDrawString();
+ test_GdipGetNearestColor();
test_GdipGetVisibleClipBounds();
test_GdipIsVisiblePoint();
test_GdipIsVisibleRect();
--
1.6.5.rc1
Re: [PATCH 1/2] gdiplus/test: Add GdipGetNearestColor test [try 2]
I tried creating a DIB, then converting it to a GpBitmap via:
GdipCreateBitmapFromHBITMAP and piping that into
GdipGetImageGraphicsContext with the same result.
I also tried selecting the DIB and sending the DC into GdipCreateFromHDC,
same deal. Maybe you're talking about doing something else though.
I don't have Windows 7 here, what's the easiest way to test that out?
Get the test
committed leaving the test expecting OutOfMemory and see if Win7
returns something
else?
Justin
On Wed, Feb 24, 2010 at 8:12 PM, Vincent Povirk
madewokherd+8...@gmail.com wrote:
Well, that's interesting.
It would be worth trying your test on Windows 7, as some other
problems with paletted images were fixed in that version.
You could also try creating an 8-bit device-independent bitmap using
gdi32 and selecting it into a compatible DC.
On Wed, Feb 24, 2010 at 6:29 PM, Justin Chevrier jchevr...@gmail.com wrote:
Thanks for reviewing the patch Vincent!
I'm reworking the test to use bitmaps but I've run into a problem.
I'm using GdipGetImageGraphicsContext to convert from a bitmap
to a graphic, this works fine at 16bpp and higher, but below that it
returns OutOfMemory on Window (seems that this function doesn't
accept palettized images). Thoughts on how to test at these
color depths?
Justin
On Tue, Feb 23, 2010 at 10:55 PM, Vincent Povirk
madewokherd+8...@gmail.com wrote:
You should probably use a Bitmap object rather than the display for
this, since the pixel format is important. That should make it
possible to test other depths, even though they can't yet be
implemented properly in Wine.
Also, you should mark tests that fail in wine with todo_wine and
remove the todo_wine in any subsequent patches that fix them.
On Tue, Feb 23, 2010 at 8:56 PM, Justin Chevrier jchevr...@gmail.com
wrote:
---
dlls/gdiplus/tests/graphics.c | 45
+
1 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/dlls/gdiplus/tests/graphics.c b/dlls/gdiplus/tests/graphics.c
index 45bd9f7..97c520d 100644
--- a/dlls/gdiplus/tests/graphics.c
+++ b/dlls/gdiplus/tests/graphics.c
@@ -21,6 +21,7 @@
#include windows.h
#include gdiplus.h
#include wingdi.h
+#include winuser.h
#include wine/test.h
#include math.h
@@ -2270,6 +2271,49 @@ static void test_GdipIsVisibleRect(void)
ReleaseDC(0, hdc);
}
+static void test_GdipGetNearestColor(void)
+{
+ GpStatus status;
+ GpGraphics *graphics = NULL;
+ ARGB color = 0xdeadbeef;
+ HDC hdc = GetDC(0);
+ DEVMODEA dmA;
+ BOOL ret;
+
+ /* create a graphics object */
+ ok(hdc != NULL, Expected HDC to be initialized\n);
+
+ status = GdipCreateFromHDC(hdc, graphics);
+ expect(Ok, status);
+ ok(graphics != NULL, Expected graphics to be initialized\n);
+
+ status = GdipGetNearestColor(graphics, NULL);
+ expect(InvalidParameter, status);
+
+ status = GdipGetNearestColor(NULL, color);
+ expect(InvalidParameter, status);
+
+ ret = EnumDisplaySettingsA(NULL, ENUM_CURRENT_SETTINGS, dmA);
+ if (!ret)
+ {
+ skip(Could not determine color depth\n);
+ goto end;
+ }
+
+ if (dmA.dmBitsPerPel = 24)
+ {
+ status = GdipGetNearestColor(graphics, color);
+ expect(Ok, status);
+ ok(color == 0xdeadbeef, expected 0xdeadbeef, got: 0x%08x\n,
color);
+ }
+ else
+ skip(Color depth less than 24bpp.\n);
+
+ end:
+ GdipDeleteGraphics(graphics);
+ ReleaseDC(0, hdc);
+}
+
START_TEST(graphics)
{
struct GdiplusStartupInput gdiplusStartupInput;
@@ -2296,6 +2340,7 @@ START_TEST(graphics)
test_GdipDrawLineI();
test_GdipDrawLinesI();
test_GdipDrawString();
+ test_GdipGetNearestColor();
test_GdipGetVisibleClipBounds();
test_GdipIsVisiblePoint();
test_GdipIsVisibleRect();
--
1.6.5.rc1
Re: [PATCH 1/2] gdiplus/test: Add GdipGetNearestColor test [try 2]
If you send me a patch for the test, I'll run it on Windows 7.
Also, there's https://winetestbot.geldorp.nl/
On Wed, Feb 24, 2010 at 8:48 PM, Justin Chevrier jchevr...@gmail.com wrote:
I tried creating a DIB, then converting it to a GpBitmap via:
GdipCreateBitmapFromHBITMAP and piping that into
GdipGetImageGraphicsContext with the same result.
I also tried selecting the DIB and sending the DC into GdipCreateFromHDC,
same deal. Maybe you're talking about doing something else though.
I don't have Windows 7 here, what's the easiest way to test that out?
Get the test
committed leaving the test expecting OutOfMemory and see if Win7
returns something
else?
Justin
On Wed, Feb 24, 2010 at 8:12 PM, Vincent Povirk
madewokherd+8...@gmail.com wrote:
Well, that's interesting.
It would be worth trying your test on Windows 7, as some other
problems with paletted images were fixed in that version.
You could also try creating an 8-bit device-independent bitmap using
gdi32 and selecting it into a compatible DC.
On Wed, Feb 24, 2010 at 6:29 PM, Justin Chevrier jchevr...@gmail.com wrote:
Thanks for reviewing the patch Vincent!
I'm reworking the test to use bitmaps but I've run into a problem.
I'm using GdipGetImageGraphicsContext to convert from a bitmap
to a graphic, this works fine at 16bpp and higher, but below that it
returns OutOfMemory on Window (seems that this function doesn't
accept palettized images). Thoughts on how to test at these
color depths?
Justin
On Tue, Feb 23, 2010 at 10:55 PM, Vincent Povirk
madewokherd+8...@gmail.com wrote:
You should probably use a Bitmap object rather than the display for
this, since the pixel format is important. That should make it
possible to test other depths, even though they can't yet be
implemented properly in Wine.
Also, you should mark tests that fail in wine with todo_wine and
remove the todo_wine in any subsequent patches that fix them.
On Tue, Feb 23, 2010 at 8:56 PM, Justin Chevrier jchevr...@gmail.com
wrote:
---
dlls/gdiplus/tests/graphics.c | 45
+
1 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/dlls/gdiplus/tests/graphics.c b/dlls/gdiplus/tests/graphics.c
index 45bd9f7..97c520d 100644
--- a/dlls/gdiplus/tests/graphics.c
+++ b/dlls/gdiplus/tests/graphics.c
@@ -21,6 +21,7 @@
#include windows.h
#include gdiplus.h
#include wingdi.h
+#include winuser.h
#include wine/test.h
#include math.h
@@ -2270,6 +2271,49 @@ static void test_GdipIsVisibleRect(void)
ReleaseDC(0, hdc);
}
+static void test_GdipGetNearestColor(void)
+{
+ GpStatus status;
+ GpGraphics *graphics = NULL;
+ ARGB color = 0xdeadbeef;
+ HDC hdc = GetDC(0);
+ DEVMODEA dmA;
+ BOOL ret;
+
+ /* create a graphics object */
+ ok(hdc != NULL, Expected HDC to be initialized\n);
+
+ status = GdipCreateFromHDC(hdc, graphics);
+ expect(Ok, status);
+ ok(graphics != NULL, Expected graphics to be initialized\n);
+
+ status = GdipGetNearestColor(graphics, NULL);
+ expect(InvalidParameter, status);
+
+ status = GdipGetNearestColor(NULL, color);
+ expect(InvalidParameter, status);
+
+ ret = EnumDisplaySettingsA(NULL, ENUM_CURRENT_SETTINGS, dmA);
+ if (!ret)
+ {
+ skip(Could not determine color depth\n);
+ goto end;
+ }
+
+ if (dmA.dmBitsPerPel = 24)
+ {
+ status = GdipGetNearestColor(graphics, color);
+ expect(Ok, status);
+ ok(color == 0xdeadbeef, expected 0xdeadbeef, got: 0x%08x\n,
color);
+ }
+ else
+ skip(Color depth less than 24bpp.\n);
+
+ end:
+ GdipDeleteGraphics(graphics);
+ ReleaseDC(0, hdc);
+}
+
START_TEST(graphics)
{
struct GdiplusStartupInput gdiplusStartupInput;
@@ -2296,6 +2340,7 @@ START_TEST(graphics)
test_GdipDrawLineI();
test_GdipDrawLinesI();
test_GdipDrawString();
+ test_GdipGetNearestColor();
test_GdipGetVisibleClipBounds();
test_GdipIsVisiblePoint();
test_GdipIsVisibleRect();
--
1.6.5.rc1
Unable to Compile Wine on MacOSX
Interestingly enough, I have run into the 'Unable to compile' problem building the latest git on MacOSX. Maybe there is corruption in my git pull, but this started yesterday It appears that configure never fully finishes and config.status loops. James McKenzie
Re: Unable to Compile Wine on MacOSX
James McKenzie wrote: Interestingly enough, I have run into the 'Unable to compile' problem building the latest git on MacOSX. Maybe there is corruption in my git pull, but this started yesterday It appears that configure never fully finishes and config.status loops. I don't have that problem... And I've been experimenting with clang as my compiler! By the way, I never use git pull. I always do git fetch; git rebase origin, which is what you're supposed to do anyway if you have local patches in your tree. Another thing I do is run autoreconf, because I have local changes to configure.ac in my tree. That might have something to do with it. I have noticed a change in configure behavior, though. config.status creates the makefiles during make, not configure. I find that odd, but it still works, so I'm happy. Chip
