Re: PowerPC MacOSX work...
Please bottom-post on wine mailing lists. 2009/5/26 : > No No No People... Please read the messages before replying. > > I know the difference betweeen my 6502, 6800, Z80, 68k, x86, 7400. I know > Wine is focused on running MSWindows based software on x86 processors. I > also know there exists PowerPC code in the wine project because people were > interested in bridging the gap to running x86 code via emulation... So you also know you can't run x86 apps on PPC platforms without emulation, just like you can't run z80 code on x86 without emulation. Also, where is this PPC code in Wine exactly? What source file exactly? > For the record... I am not looking to run another full out emulation. The > best example of what I have in mind is what Apple did when they moved their > processor base from 68K to PPC. And I am wondering if the same could be > done for Wine. By the looks of things some of the framework to make that > happen are already there in the form of thunk code... Apple used what they > called trampolines iirc. I believe 68k and PPC are architecturally quite similar, along the lines of the 80386 (which has 16bit and 32bit modes). With Windows programs being x86 apps, the translation between the two architectures is very tricky (as has been previously noted on this thread). > I am not sure that WineLib is what I am looking to use as the wine script & > loader seems to achieve much of what I am already looking to do. Winelib would be good if you had the source code for your Win32/Win16 apps and wanted to produce PPC binaries of them. Sounds like that's not what you're trying to do though.
Re: PowerPC MacOSX work...
On Thu, May 28, 2009 at 04:00, James McKenzie wrote: > The question is: Were there any programs written for WindowsNT for the > PPC? I don't know of any, off hand. > A few seem to exist... Probably nothing without a x86 versions though. Compatibility with PowerPC NT applications might at least give a few programs, even if just MS's applications that got bundled with PPC NT, to test with. It would probably not have much (if any) real-world uses, but it might point out portability issues that might affect other architectures, which might have more applications available, such as x86_64 and Itanium.
Re: PowerPC MacOSX work...
* On Tue, 26 May 2009, mghug...@embarqmail.com wrote: > > Download link did not work... Would have been good to look > at/try/experiment with, but not what I am looking/aiming for. You could probably want to google for Programmer's File Editor v0.07.001 (file pfe0701p.zip), for example this link: [1]. Quoting [2]: | This is the 0.07.001 release of Programmer's File Editor, a | large-capacity multi-file programming oriented editor for Windows 95, | Windows NT 3.51 and 4.0 on Intel and PowerPC platforms, and Windows 3.1x [1] http://128.40.77.181/ccp/web-mirrors/pfe/people/cpaap/pfe/pfe0701p.zip [2] http://www-personal.engin.umd.umich.edu/~nnarasim/courses/ece373/hc11/pfe32/readme.txt
Re: DIB Engine : passing all tests
On Wed, May 27, 2009 at 8:47 PM, James McKenzie wrote: > So what say all, shall we try to make coding better and as Max stated, > fun. Most of the folks here do not support this project for a living > and we should not restrict this project to those who do. However, it > appears that a vast majority of the patches are coming from those who > either are long time Wine 'hackers' or those whose living depends on > this project's survival. > I'm not sure why it's a strange thing that the people that spend the most time with wine code have the most patches committed. To try and make an accusation that the project is restricted to paid peoples is both false and pointlessly inflammatory. If there was a glut of manpower there'd be plenty of time to give full reviews of every patch. As it is everyone gives the time they can. --John Klehm
Re: winebrowser: Fix unicode recognition
"André Hentschel" wrote: This converts the DDE-Callbackfunction to Unicode. After days of winebrowser-hacking i turned it down to this clean code. It uses the function IsTextUnicode instead of guessing.(IsTextUnicode is guessing too, but in a cleaner way) Please add a test case which uses mixed ansi/unicode DDE client/server and only then start fixing the code. -- Dmitry.
Re: PowerPC MacOSX work...
mghug...@embarqmail.com wrote: > No No No People... Please read the messages before replying. > > I know the difference betweeen my 6502, 6800, Z80, 68k, x86, 7400. I > know Wine is focused on running MSWindows based software on x86 > processors. I also know there exists PowerPC code in the wine project > because people were interested in bridging the gap to running x86 code > via emulation... > > For the record... I am not looking to run another full out > emulation. The best example of what I have in mind is what Apple did > when they moved their processor base from 68K to PPC. And I am > wondering if the same could be done for Wine. By the looks of things > some of the framework to make that happen are already there in the > form of thunk code... Apple used what they called trampolines iirc. The question is: Were there any programs written for WindowsNT for the PPC? I don't know of any, off hand. The real problem is that most, if not all, Windows based programs were written for the X86 platform. The makes the use of a CPU emulator necessary. I know of only on FOSS project that is working on this, and that is the Qemu (?) project. The Darwine project was trying to combine the PPC->X86 emulator with Wine. Again, this project has stopped progress and probably needs help getting restarted. The Darwine project does exist on SourceForge and could be revived with someone displaying interest in getting it running again. I do have PPC Mac here, but I think I messed up the power port on it and thus batteries are not fully charging. I stopped working on another FOSS project because running the test suite takes over a day and I could not trust the power supply to last that long. James McKenzie
Re: DIB Engine : passing all tests
Massimo Del Fedele wrote: > Alexandre Julliard ha scritto: >> >> The last time I rejected a simple patch from Massimo, he basically said >> that he didn't have time to fix the patch and just dropped it. That >> doesn't encourage me to spend more effort on reviewing his more complex >> stuff. >> > > Hi again :-) > > Well, to be precise those were some patches rejected, one with some > explanation > and others not. > Former was about adding page size support to wineps.drv. I haven't > dropped it, > but you told me that an almost complete rewrite of cups printers > handling was > foreseen and preferred, so I kept it on my tree. I have really not > enough skills > nor time to do such a complex job. My patch was just sending the > missing page size > string to lpr along as printer name, which is by now the only stuff sent. > I can understand, of course, that going through lpr is not a very nice > way. > I'm using the patch for my daily job, it's not dropped. > > Latters were one testcase (which was meant preparing some gdiplus > patches) which > was rejected because "too long" and "with meaningless comments" and a > couple of > gdiplus functions that were missing (and are still missing) needed by > autocad to > run with builtin gdiplus, rejected because "contains errors" > (possible, but which ?) and > were "a pain to review" (h). > BTW, about comments, I'm sorry but my memory is not perfect and I tend > to forget what I did > and why after a couple of monthes, so the reason of maybe > over-commenting all my code :-) I tend to disagree with your self evaluation of 'too many'. There is NO such thing in coding. I've seen code with too little comments and then had to figure out what the heck the coder was trying to do inside the code. Of course, talking to the coder resulted in a "I know what I'm doing" conversation that resulted in no forward movement on a fixable problem that may have resulted in the company's demise. > I must say that the must difficult part of writing my engine was to > try to figure out what > gdi32/winex11 code does, and some comments more woul have been of > great help ! > This is very true. Code should at a minimum point out where the examples can be found. MSDN is very frustrating when it comes to how a piece of code is supposed to work. What I see here is a lack of assistance from those who grade the code. This is what I consider unacceptable and has resulted in the stoppage of fixes being submitted by folks who 'code for food', that is they write code for a living. I evaluate and support programs for a living. Guess what? I don't recommend that folks use Wine on Macs for production level work. It just is not 'there'. Sadly, these same folks want to walk away from using Microsoft Software because, pardon the phrase, it just plain sucks. It is poorly written and full of bugs (and some of those bugs have been there for years.) I appreciate AJs efforts to keep the code base 'clean'. In the process, however, you have to tell folks what to do in order to keep the base clean. That is just plain being nice and is good ettiquitte. Otherwise, all you are doing is attempting to shoo away those who could really help move the project along and fix long standing problems. It does not take more time to state: Your code does not meet Wine standards because it has tabs in it", then to say "You can do better".Adding comments to what a certain chunk of code does is not expensive and it does make troubleshooting code much easier at a later time by a different person. One line comments are best. So what say all, shall we try to make coding better and as Max stated, fun. Most of the folks here do not support this project for a living and we should not restrict this project to those who do. However, it appears that a vast majority of the patches are coming from those who either are long time Wine 'hackers' or those whose living depends on this project's survival. James McKenzie
Re: AppDB - Incorrect entry
On Wed, May 27, 2009 at 2:01 PM, Danila Sentiabov wrote: > Hi. I've found incorrect AppDB entry that needs to be merged with another > one. App maintainer could not do that. > Could someone (with admin access to AppDB) help? > > http://appdb.winehq.org/objectManager.php?sClass=version&iId=7641 Done. -- -Austin
AppDB - Incorrect entry
Hi. I've found incorrect AppDB entry that needs to be merged with another one. App maintainer could not do that. Could someone (with admin access to AppDB) help? http://appdb.winehq.org/objectManager.php?sClass=version&iId=7641 -- Best regards, Danila Sentiabov aka dsent
Re: wined3d: {Name of patch here}
Pavel: Just as a hint, can you name your patches to be more descriptive. I am looking for a fix to this problem, and will attempt to test this against DooM to see if the slowness problem I have is fixed. Thank you for contributing to the Wine Project. James McKenzie -Original Message- >From: Pavel Prochazka >Sent: May 27, 2009 5:40 AM >To: wine-patc...@winehq.org >Subject: wined3d: > >
Re: wined3d:
Am Mittwoch, 27. Mai 2009 14:40:20 schrieb Pavel Prochazka: > IWineGDISwapChainImpl_Present repaired when there is only one backbuffer Hmm. Situations where flip is called on a single-buffered surface should be cought in ddraw I think. If I remember correctly, calling flip on a single buffered surface should return an error
Re: comctl32/ipaddress: Skip test on Win95 with common controls 4.70 (try2)
Paul Vriens wrote:
Nikolay Sivov wrote:
+ok(hwnd != NULL, "Expected window to be created\n");
+if (!hwnd)
+{
+win_skip("IPAddress control not implemented\n");
+return;
+}
/* check text just after creation */
r = GetWindowText(hwnd, ip, sizeof(ip)/sizeof(CHAR));
I would either get rid of the ok(hwnd ...) altogether or move it after
the if(). win_skip() means we are ok with a failure on some Windows
boxes so a test failure just before that doesn't make sense.
Agreed. Try 3 should be fine.
Re: comctl32/ipaddress: Skip test on Win95 with common controls 4.70 (try2)
Nikolay Sivov wrote:
For version 4.0 we are skipping earlier on initialization.
Changelog:
- try2: use win_skip()
- Skip test on Win95 with common controls 4.70
From 81645944ef518860de7ddcd1b64fadd11277a915 Mon Sep 17 00:00:00 2001
From: Nikolay Sivov
Date: Wed, 27 May 2009 15:39:20 +0400
Subject: Skip test on Win95 with common controls 4.70
---
dlls/comctl32/tests/ipaddress.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/dlls/comctl32/tests/ipaddress.c b/dlls/comctl32/tests/ipaddress.c
index d04223c..13af687 100644
--- a/dlls/comctl32/tests/ipaddress.c
+++ b/dlls/comctl32/tests/ipaddress.c
@@ -33,8 +33,6 @@ static HWND create_ipaddress_control (void)
handle = CreateWindowEx(0, WC_IPADDRESS, NULL,
WS_BORDER|WS_VISIBLE, 0, 0, 0, 0,
NULL, NULL, NULL, NULL);
-assert(handle);
-
return handle;
}
@@ -45,6 +43,12 @@ static void test_get_set_text(void)
INT r;
hwnd = create_ipaddress_control();
+ok(hwnd != NULL, "Expected window to be created\n");
+if (!hwnd)
+{
+win_skip("IPAddress control not implemented\n");
+return;
+}
/* check text just after creation */
r = GetWindowText(hwnd, ip, sizeof(ip)/sizeof(CHAR));
I would either get rid of the ok(hwnd ...) altogether or move it after
the if(). win_skip() means we are ok with a failure on some Windows
boxes so a test failure just before that doesn't make sense.
--
Cheers,
Paul.
Re: comctl32/ipaddress: Use ok() test instead of assert()
Paul Vriens wrote: Maybe it's true. But what about two others boxes: http://test.winehq.org/data/bf353f180d622cbf8508af7dbc9590e33293a6ab/95_gvg-w95/version.html http://test.winehq.org/data/bf353f180d622cbf8508af7dbc9590e33293a6ab/95_fg-win95/version.html Version reported as 4.0, so it's pure Win95 - tests pass on it. Not really, all tests are skipped on these two boxes ;). Oh, sorry. You're right I'll post a win_skip version.
Re: comctl32/ipaddress: Use ok() test instead of assert()
Nikolay Sivov wrote:
Paul Vriens wrote:
Paul Vriens wrote:
Nikolay Sivov wrote:
This test fails to create window sometimes on Win95,
let's turn it into general failure.
Changelog:
- replace assert() with ok() test
From b63fc6defb497505ecaab4921449327e875ab252 Mon Sep 17 00:00:00 2001
From: Nikolay Sivov
Date: Wed, 27 May 2009 14:26:37 +0400
Subject: Use ok() test instead of assert()
---
dlls/comctl32/tests/ipaddress.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/dlls/comctl32/tests/ipaddress.c
b/dlls/comctl32/tests/ipaddress.c
index d04223c..b8f30e4 100644
--- a/dlls/comctl32/tests/ipaddress.c
+++ b/dlls/comctl32/tests/ipaddress.c
@@ -33,8 +33,6 @@ static HWND create_ipaddress_control (void)
handle = CreateWindowEx(0, WC_IPADDRESS, NULL,
WS_BORDER|WS_VISIBLE, 0, 0, 0, 0,
NULL, NULL, NULL, NULL);
-assert(handle);
-
return handle;
}
@@ -45,6 +43,7 @@ static void test_get_set_text(void)
INT r;
hwnd = create_ipaddress_control();
+ok(hwnd != NULL, "Expected window to be created\n");
Shouldn't you insert a return here when hwnd is NULL. The following
tests will fail as well I guess.
Just had a look and it seems that only one box actually has this
failure. Maybe a win_skip() would be 'better'?
hwnd = create_ipaddress_control();
if (!hwnd)
{
win_skip();
return;
}
Maybe even printing the last error in that win_skip() ?
Especially as MSDN states:
The IP address control is implemented in version 4.71 and later of
Comctl32.dll.
And this box has 4.70.0.1146.
Maybe it's true. But what about two others boxes:
http://test.winehq.org/data/bf353f180d622cbf8508af7dbc9590e33293a6ab/95_gvg-w95/version.html
http://test.winehq.org/data/bf353f180d622cbf8508af7dbc9590e33293a6ab/95_fg-win95/version.html
Version reported as 4.0, so it's pure Win95 - tests pass on it.
Not really, all tests are skipped on these two boxes ;).
--
Cheers,
Paul.
Re: comctl32/ipaddress: Use ok() test instead of assert()
Paul Vriens wrote:
Paul Vriens wrote:
Nikolay Sivov wrote:
This test fails to create window sometimes on Win95,
let's turn it into general failure.
Changelog:
- replace assert() with ok() test
From b63fc6defb497505ecaab4921449327e875ab252 Mon Sep 17 00:00:00 2001
From: Nikolay Sivov
Date: Wed, 27 May 2009 14:26:37 +0400
Subject: Use ok() test instead of assert()
---
dlls/comctl32/tests/ipaddress.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/dlls/comctl32/tests/ipaddress.c
b/dlls/comctl32/tests/ipaddress.c
index d04223c..b8f30e4 100644
--- a/dlls/comctl32/tests/ipaddress.c
+++ b/dlls/comctl32/tests/ipaddress.c
@@ -33,8 +33,6 @@ static HWND create_ipaddress_control (void)
handle = CreateWindowEx(0, WC_IPADDRESS, NULL,
WS_BORDER|WS_VISIBLE, 0, 0, 0, 0,
NULL, NULL, NULL, NULL);
-assert(handle);
-
return handle;
}
@@ -45,6 +43,7 @@ static void test_get_set_text(void)
INT r;
hwnd = create_ipaddress_control();
+ok(hwnd != NULL, "Expected window to be created\n");
Shouldn't you insert a return here when hwnd is NULL. The following
tests will fail as well I guess.
Just had a look and it seems that only one box actually has this
failure. Maybe a win_skip() would be 'better'?
hwnd = create_ipaddress_control();
if (!hwnd)
{
win_skip();
return;
}
Maybe even printing the last error in that win_skip() ?
Especially as MSDN states:
The IP address control is implemented in version 4.71 and later of
Comctl32.dll.
And this box has 4.70.0.1146.
Maybe it's true. But what about two others boxes:
http://test.winehq.org/data/bf353f180d622cbf8508af7dbc9590e33293a6ab/95_gvg-w95/version.html
http://test.winehq.org/data/bf353f180d622cbf8508af7dbc9590e33293a6ab/95_fg-win95/version.html
Version reported as 4.0, so it's pure Win95 - tests pass on it.
Re: [mshtml/tests] Fix 2 test failures on IE8
Paul Vriens wrote: Jacek Caban wrote: Hi Paul, Paul Vriens wrote: Changelog Fix 2 test failures on IE8 -ok(disp == (void*)0xdeadbeef, "disp=%p\n", disp); +ok(disp == (void*)0xdeadbeef || + disp == NULL, /* IE8 */ This test does no longer make sense. It would be better to remove it and preferably change implementation to match IE8. Thanks, Jacek Hi Jacek, Something like the attached? Yes, it looks good. Thanks, Jacek
Re: comctl32/ipaddress: Use ok() test instead of assert()
Paul Vriens wrote:
Nikolay Sivov wrote:
This test fails to create window sometimes on Win95,
let's turn it into general failure.
Changelog:
- replace assert() with ok() test
From b63fc6defb497505ecaab4921449327e875ab252 Mon Sep 17 00:00:00 2001
From: Nikolay Sivov
Date: Wed, 27 May 2009 14:26:37 +0400
Subject: Use ok() test instead of assert()
---
dlls/comctl32/tests/ipaddress.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/dlls/comctl32/tests/ipaddress.c
b/dlls/comctl32/tests/ipaddress.c
index d04223c..b8f30e4 100644
--- a/dlls/comctl32/tests/ipaddress.c
+++ b/dlls/comctl32/tests/ipaddress.c
@@ -33,8 +33,6 @@ static HWND create_ipaddress_control (void)
handle = CreateWindowEx(0, WC_IPADDRESS, NULL,
WS_BORDER|WS_VISIBLE, 0, 0, 0, 0,
NULL, NULL, NULL, NULL);
-assert(handle);
-
return handle;
}
@@ -45,6 +43,7 @@ static void test_get_set_text(void)
INT r;
hwnd = create_ipaddress_control();
+ok(hwnd != NULL, "Expected window to be created\n");
Shouldn't you insert a return here when hwnd is NULL. The following
tests will fail as well I guess.
Just had a look and it seems that only one box actually has this
failure. Maybe a win_skip() would be 'better'?
hwnd = create_ipaddress_control();
if (!hwnd)
{
win_skip();
return;
}
Maybe even printing the last error in that win_skip() ?
Especially as MSDN states:
The IP address control is implemented in version 4.71 and later of
Comctl32.dll.
And this box has 4.70.0.1146.
--
Cheers,
Paul.
Re: comctl32/ipaddress: Use ok() test instead of assert()
Paul Vriens wrote: Nikolay Sivov wrote: This test fails to create window sometimes on Win95, let's turn it into general failure. Changelog: - replace assert() with ok() test From b63fc6defb497505ecaab4921449327e875ab252 Mon Sep 17 00:00:00 2001 From: Nikolay Sivov Date: Wed, 27 May 2009 14:26:37 +0400 Subject: Use ok() test instead of assert() --- dlls/comctl32/tests/ipaddress.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/dlls/comctl32/tests/ipaddress.c b/dlls/comctl32/tests/ipaddress.c index d04223c..b8f30e4 100644 --- a/dlls/comctl32/tests/ipaddress.c +++ b/dlls/comctl32/tests/ipaddress.c @@ -33,8 +33,6 @@ static HWND create_ipaddress_control (void) handle = CreateWindowEx(0, WC_IPADDRESS, NULL, WS_BORDER|WS_VISIBLE, 0, 0, 0, 0, NULL, NULL, NULL, NULL); -assert(handle); - return handle; } @@ -45,6 +43,7 @@ static void test_get_set_text(void) INT r; hwnd = create_ipaddress_control(); +ok(hwnd != NULL, "Expected window to be created\n"); Shouldn't you insert a return here when hwnd is NULL. The following tests will fail as well I guess. The reason was to count failures as usual instead of exit a test hardly. I still don't know why it can't be created some times so I think win_skip doesn't mean much till we don't know a cause.
Re: comctl32/ipaddress: Use ok() test instead of assert()
Nikolay Sivov wrote: This test fails to create window sometimes on Win95, let's turn it into general failure. Changelog: - replace assert() with ok() test From b63fc6defb497505ecaab4921449327e875ab252 Mon Sep 17 00:00:00 2001 From: Nikolay Sivov Date: Wed, 27 May 2009 14:26:37 +0400 Subject: Use ok() test instead of assert() --- dlls/comctl32/tests/ipaddress.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/dlls/comctl32/tests/ipaddress.c b/dlls/comctl32/tests/ipaddress.c index d04223c..b8f30e4 100644 --- a/dlls/comctl32/tests/ipaddress.c +++ b/dlls/comctl32/tests/ipaddress.c @@ -33,8 +33,6 @@ static HWND create_ipaddress_control (void) handle = CreateWindowEx(0, WC_IPADDRESS, NULL, WS_BORDER|WS_VISIBLE, 0, 0, 0, 0, NULL, NULL, NULL, NULL); -assert(handle); - return handle; } @@ -45,6 +43,7 @@ static void test_get_set_text(void) INT r; hwnd = create_ipaddress_control(); +ok(hwnd != NULL, "Expected window to be created\n"); Shouldn't you insert a return here when hwnd is NULL. The following tests will fail as well I guess. -- Cheers, Paul.
Re: DIB Engine : passing all tests
2009/5/27 Roderick Colenbrander > On Wed, May 27, 2009 at 10:26 AM, Vit Hrachovy > wrote: > > would it be possible to craft a wikipage on Wine Wiki, that would > encompass > > * official DIB implementation requirements > > * high level description of Huw's solution > > * description of Your solution incl. proposed integration plan > > > > I have asked Alexandre about it but it wasn't really an option. Even > for Huw writing a full dib engine (if he resumed his current code) > would take five months or so full time. Filling in the 'easy' bits > (which Alexandre considers most of the things done so far) is not that > much work (the easy bits are the software drawing functions). I'm not sure I understand this answer, as all but the first line doesn't seem to relate to the question. Are you saying that you have been told that making the documentation Vit described wasn't an option? -- Chris
Re: DIB Engine : passing all tests
On Wed, May 27, 2009 at 10:26 AM, Vit Hrachovy wrote: > Massimo Del Fedele wrote: >> >> Btw, sorry all but I begins to be tired of telling same stuffs again and >> again. I made a proposal for something that *could* help the migration to >> final design, a *working* proposal, not just a prototype, and I believe on >> it. >> If that's not what most devels think, for me is ok. >> The engine will be available as a patch for whom needs/likes it, point. > > Hi Max, > would it be possible to craft a wikipage on Wine Wiki, that would encompass > * official DIB implementation requirements > * high level description of Huw's solution > * description of Your solution incl. proposed integration plan > > It would ease the orientation, prevent repeating the same stuff again and > again and it could also serve as a solid base for further discussion about > DIB integration requirements. > > Regards > Hark > > > I have asked Alexandre about it but it wasn't really an option. Even for Huw writing a full dib engine (if he resumed his current code) would take five months or so full time. Filling in the 'easy' bits (which Alexandre considers most of the things done so far) is not that much work (the easy bits are the software drawing functions). Roderick
Re: DIB Engine : passing all tests
Massimo Del Fedele wrote: Btw, sorry all but I begins to be tired of telling same stuffs again and again. I made a proposal for something that *could* help the migration to final design, a *working* proposal, not just a prototype, and I believe on it. If that's not what most devels think, for me is ok. The engine will be available as a patch for whom needs/likes it, point. Hi Max, would it be possible to craft a wikipage on Wine Wiki, that would encompass * official DIB implementation requirements * high level description of Huw's solution * description of Your solution incl. proposed integration plan It would ease the orientation, prevent repeating the same stuff again and again and it could also serve as a solid base for further discussion about DIB integration requirements. Regards Hark
Re: [mshtml/tests] Fix 2 test failures on IE8
Jacek Caban wrote:
Hi Paul,
Paul Vriens wrote:
Changelog
Fix 2 test failures on IE8
-ok(disp == (void*)0xdeadbeef, "disp=%p\n", disp);
+ok(disp == (void*)0xdeadbeef ||
+ disp == NULL, /* IE8 */
This test does no longer make sense. It would be better to remove it and
preferably change implementation to match IE8.
Thanks,
Jacek
Hi Jacek,
Something like the attached?
--
Cheers,
Paul.
diff --git a/dlls/mshtml/htmlnode.c b/dlls/mshtml/htmlnode.c
index 32b0801..720bbfe 100644
--- a/dlls/mshtml/htmlnode.c
+++ b/dlls/mshtml/htmlnode.c
@@ -157,6 +157,11 @@ static HRESULT WINAPI
HTMLDOMChildrenCollection_item(IHTMLDOMChildrenCollection
TRACE("(%p)->(%d %p)\n", This, index, ppItem);
+if (ppItem)
+*ppItem = NULL;
+else
+return E_POINTER;
+
nsIDOMNodeList_GetLength(This->nslist, &length);
if(index < 0 || index >= length)
return E_INVALIDARG;
diff --git a/dlls/mshtml/tests/dom.c b/dlls/mshtml/tests/dom.c
index aaf1a39..497fc0a 100644
--- a/dlls/mshtml/tests/dom.c
+++ b/dlls/mshtml/tests/dom.c
@@ -4456,15 +4456,17 @@ static void test_elems(IHTMLDocument2 *doc)
IHTMLDOMNode_Release(node);
}
-disp = (void*)0xdeadbeef;
+hres = IHTMLDOMChildrenCollection_item(child_col, length - 1, NULL);
+ok(hres == E_POINTER, "item failed: %08x, expected E_POINTER\n", hres);
+
+hres = IHTMLDOMChildrenCollection_item(child_col, length, NULL);
+ok(hres == E_POINTER, "item failed: %08x, expected E_POINTER\n", hres);
+
hres = IHTMLDOMChildrenCollection_item(child_col, 6000, &disp);
ok(hres == E_INVALIDARG, "item failed: %08x, expected E_INVALIDARG\n",
hres);
-ok(disp == (void*)0xdeadbeef, "disp=%p\n", disp);
-disp = (void*)0xdeadbeef;
hres = IHTMLDOMChildrenCollection_item(child_col, length, &disp);
ok(hres == E_INVALIDARG, "item failed: %08x, expected E_INVALIDARG\n",
hres);
-ok(disp == (void*)0xdeadbeef, "disp=%p\n", disp);
test_child_col_disp(child_col);
Re: DIB Engine : passing all tests
On Wed, May 27, 2009 at 2:11 AM, Massimo Del Fedele wrote: > Strange enough, as the consensus on Huw's design was great, and it used > a *real* external driver, and *not* an intermediate one as mine. > But I start thinking that the requirements and consensus are very fluid and > moving matters, lately. > > Btw, sorry all but I begins to be tired of telling same stuffs again and > again. I made a proposal for something that *could* help the migration to > final design, a *working* proposal, not just a prototype, and I believe on > it. > If that's not what most devels think, for me is ok. > The engine will be available as a patch for whom needs/likes it, point. Not directed toward you, Massimo, but others: Keep in mind, Massimo has sent patches dozens of times, along with explanations/critiques. Unless you have something *NEW* to add (check the archives), please refrain from commenting since in waste a lot of time. -- -Austin
Re: DIB Engine : passing all tests
Ben Klein ha scritto: A little while ago I was trying to run an app that uses Win16 DIB.DRV (I forget which app it was). My research indicated that although DIB.DRV was an actual driver (similar in architecture to Max's proposed DIB engine) in Win16 systems, in Windows 95 the functionality was rolled into GDI. For my app, this means that (in theory) exposing appropriate, existing DIB functions to my Win16 app in the form of a virtual DIB.DRV should work. For Max's engine, we're looking at diverging from Microsoft's modern architecture and switching back to something that was "good enough" 25 years ago. I begin thinking to not be clear enough in what I write.. 2 Last words: 1) Huw's starting engine *was* a driver's one, and many people told it was the right way. Worse, it forked driver from inside gdi32, which was awful to maintain. 2) My engine insertrs itself between gdi32 and the display driver; I begins to be tired repeating that it's a step through the final design on where DIB are handled fully inside gdi32. The step is, imho, necessary to split DIB handling from DDB without having to rewrite at once half of gdi32 + half of winex11.drv and maybe others. It is *not* the final step, now it wants to be. It's made so to prepare the switching in a painless way, *if* accepted. If not, just prepare to have the sampe problems we had with mshtml switching on each gecko change. In my case that broke a lot of stuffs. We all know AJ wants things to be done "the right way" the first time. I agree with this policy, because it makes for more maintainable code, less duplication, etc. again, I agree with that. Defining what is "the right way" is still a mysterious matter. Wine's patch acceptance policy specifically prohibits "hack it until it works, which hack ? then worry about it later" style programming, and the consensus of devs seems to be that adding a new DIB *driver* as an intermediary between GDI32 and hardware drivers is the wrong way to go about things. Strange enough, as the consensus on Huw's design was great, and it used a *real* external driver, and *not* an intermediate one as mine. But I start thinking that the requirements and consensus are very fluid and moving matters, lately. Btw, sorry all but I begins to be tired of telling same stuffs again and again. I made a proposal for something that *could* help the migration to final design, a *working* proposal, not just a prototype, and I believe on it. If that's not what most devels think, for me is ok. The engine will be available as a patch for whom needs/likes it, point. Last work about accepting or not hacks: I never proposed such patches. The most "hacky" stuff I sent (and was rejected, with a motivation that could be right) was the addition of page size handling inside wineps.drv. Motivation was that the printer driver shoul be rewritten for cups without lpr usage. I agree. But by now *is* using lpr and *is* lacking support for page size and other stuffs. So I asked myself : it's better to wait up we have the "complete right code", leaving the printer driver missing stuffs, or for the moment extend it while waiting for the right one ? I would have chosen the second solution, but as usual is a matter of taste. Max
