Signed-off-by: Jacek Caban jacek@codeweavers.com --- dlls/ntoskrnl.exe/ntoskrnl.exe.spec | 6 +- dlls/ntoskrnl.exe/tests/driver.c | 139 +++++++++++++++++++++++++++- 2 files changed, 140 insertions(+), 5 deletions(-)
Hi,
While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check?
Full results can be found at: https://testbot.winehq.org/JobDetails.pl?Key=48272
Your paranoid android.
=== debian9 (32 bit Chinese:China report) ===
ntoskrnl.exe: driver.c:553: Test failed: got 0 driver.c:556: Test failed: got 0x102
On 2/26/19 6:38 AM, Jacek Caban wrote:
- if (sizeof(void *) != 4) /* avoid dealing with fastcall */
- {
ObfReferenceObject(obj1);ObDereferenceObject(obj1);- }
The tests aren't going to run on 64-bit Windows, so it may be worth just adding fastcall thunks like we have in kernel32:sync.
Hi Zebediah,
On 2/26/19 4:05 PM, Zebediah Figura wrote:
On 2/26/19 6:38 AM, Jacek Caban wrote:
+ if (sizeof(void *) != 4) /* avoid dealing with fastcall */ + { + ObfReferenceObject(obj1); + ObDereferenceObject(obj1); + }
The tests aren't going to run on 64-bit Windows,
Did you mean 32-bit Windows?
so it may be worth just adding fastcall thunks like we have in kernel32:sync.
The test is not very interesting anyway. That, combined with the fact that actual 32-bit Windows are rather rare, made me think that it's not worth the trouble. Could we leave it as a possible follow-up?
Thanks for the review,
Jacek
On 2/26/19 10:12 AM, Jacek Caban wrote:
Hi Zebediah,
On 2/26/19 4:05 PM, Zebediah Figura wrote:
On 2/26/19 6:38 AM, Jacek Caban wrote:
+ if (sizeof(void *) != 4) /* avoid dealing with fastcall */ + { + ObfReferenceObject(obj1); + ObDereferenceObject(obj1); + }
The tests aren't going to run on 64-bit Windows,
Did you mean 32-bit Windows?
I mean ntoskrnl driver tests don't run at all on 64-bit Windows, because it refuses to load unsigned drivers.
so it may be worth just adding fastcall thunks like we have in kernel32:sync.
The test is not very interesting anyway. That, combined with the fact that actual 32-bit Windows are rather rare, made me think that it's not worth the trouble. Could we leave it as a possible follow-up?
Sure, no objection from me.
On 2/26/19 5:18 PM, Zebediah Figura wrote:
On 2/26/19 10:12 AM, Jacek Caban wrote:
Hi Zebediah,
On 2/26/19 4:05 PM, Zebediah Figura wrote:
On 2/26/19 6:38 AM, Jacek Caban wrote:
+ if (sizeof(void *) != 4) /* avoid dealing with fastcall */ + { + ObfReferenceObject(obj1); + ObDereferenceObject(obj1); + }
The tests aren't going to run on 64-bit Windows,
Did you mean 32-bit Windows?
I mean ntoskrnl driver tests don't run at all on 64-bit Windows, because it refuses to load unsigned drivers.
FWIW, I run them on 64-bit Windows locally. It requires booting Windows with special options, but other than that it works fine. It would be great if we could find a way for Testbot to be able to run them.
Jacek
On 2/26/19 10:23 AM, Jacek Caban wrote:
On 2/26/19 5:18 PM, Zebediah Figura wrote:
On 2/26/19 10:12 AM, Jacek Caban wrote:
Hi Zebediah,
On 2/26/19 4:05 PM, Zebediah Figura wrote:
On 2/26/19 6:38 AM, Jacek Caban wrote:
+ if (sizeof(void *) != 4) /* avoid dealing with fastcall */ + { + ObfReferenceObject(obj1); + ObDereferenceObject(obj1); + }
The tests aren't going to run on 64-bit Windows,
Did you mean 32-bit Windows?
I mean ntoskrnl driver tests don't run at all on 64-bit Windows, because it refuses to load unsigned drivers.
FWIW, I run them on 64-bit Windows locally. It requires booting Windows with special options, but other than that it works fine. It would be great if we could find a way for Testbot to be able to run them.
Ah, I wasn't aware that was possible. If it's just a matter of booting Windows with certain options, I guess it shouldn't be too hard to make that work on the testbot?
-
Jacek Caban -
Marvin -
Zebediah Figura