#wine-staging

AmineKhaldi: thx for pointing that out

AmineKhaldi: does kmtests support driver traces?

slackner: your patch is not in the approved list!

revert!

titan38: it seems like they do - https://github.com/mirror/reactos/blob/master/r...

puk: lol ;)

slackner: maybe he wanted to do a quick commit round to give your ntdll: Implement Rtl[Add|Remove]VectoredContinueHandler semi-stubs. more time to test

puk: my patchset included tests ... moreover it would be the first time that he pushes commits multiple times a day ;)

nah

he won't push more commits

just giving people more time to test

puk: not sure about your small strlen fixes

and I had tests too when I introduced regressions

puk: maybe he pushes them before the release ;)

nah

no janitorial work

titan38: i already wrote a standalone test yesterday with mingw, but had trouble to get wine to load my driver

those will go in on Monday

i'm not in a hurry

will need to check what is going wrong, but the way they compiled the driver in the links you send was unnecessary complicated

slackner: indeed. It seems to be a custom trace system. I also wonder what is the difference between DPRINT and trace

DarkPlayer: good. can you put it somewhere to take a look?

DarkPlayer: So you try to load a windows driver build with mingw under wine with your test app?

titan38: i would first like to fix the problem why wine does not load the driver and moreover i want to test some other linker flags

seems like "--wdm" might be even sufficient

but I did not test it yet

DarkPlayer: it doesn't has to be fully functional, feel free to put the experimental code somewhere, and we can take a look

ugh -.-

the problem was that i called the driver wine.sys

somehow wine wants to load an internal dll in this case which does not exist

now, wine loads the driver, but unloading does not seem to work

DarkPlayer: btw does wine even handle driver unloading? Never paid attention

titan38: sure, it supports some DRM drivers like safedisc 1 and 2

DarkPlayer: yes it does load drivers and runs them but does unloading works?

DarkPlayer: In your case Unload entry point is not called?

titan38: yes, loading works, but for unloading the entry point is not called, and the API call fails

titan38: but maybe i am also just doing it wrong

although i have defined an unloading function: trace:winedevice:init_driver - DriverUnload = 0x541044

DarkPlayer: kk so winedevice does the call to unload entry point, it call something but not you entry point and return an error; correct?

wow, seems like the driver loaded perfectly on Windows XP :-)!

someone needs to implement a DriverIoControl command to actually test the driver

titan38, slackner: https://dl.dropboxusercontent.com/u/61413222/dr...

DarkPlayer: thx

the driver does not do anything yet

well, it should be sufficient to check how we can integrate this in the wine makefile

but we should also think about ways how to structure the driver test framework

if you take a look at th driver.h you will see i was going to implement an IOCTL_GET_WINE which returns "Wine" as result ;-)

how to count errors? should all testcases go into a single driver?

can we test the stacked driver stuff without actually loading multiple drivers?

(which should also work of course, but makes the test framework more complicated)

well, you can communicate with the other windows drivers

DarkPlayer: kk thx

the code already handles the embedding of the .sys file and extracting it

however, there is most probably space for improvement

for example I wrote the driver loading code based on an example which also loads the driver when it was already registered

this should not happen in our case

i am away for about an hour, so if you guys have improvements feel free to change the code

DarkPlayer: btw wine does not call DriverUnload which what I was suspected.

DarkPlayer: They probably didn't bothered as the process is shut down when the app exists.

puk: i told you!

:D

lol

only the second or third time he does this

probably because the commit was so early

hmm

aah, yeah

test and appwiz.cpl

not much that can break

;)

xD

and of course obviously correct

;)

famous last words

slackner: more time for you to release a new wine staging

slackner, ehoover: https://appdb.winehq.org/commentview.php?iAppId... ;-)

ah slackner already responded to that

titan38: did you already take a look at the driver files?

DarkPlayer: yup :)

DarkPlayer: I saw DbgPrint is used for trace. I wonder if this is from ddk

DbgPrint is part of the ddk

wine directly prints the message, but i did not test on how to get the output in windows

i don't know if you need to attach a kernel debugger or if there is a direct way to get these messages

i am not sure what would be the best way to collect test results from the driver

I read they can be retreive from user and a "consumer" must be written

you could also implement the ReadFile function for the driver and read data from the driver instead of using ioctl

anyway, we can not use the wine test functions directly, they rely on a c library

but there is no printf in the kernel

kmtests from reactos seems to use a custom interface with user space

didn't dig much

tough

yup kmtests does this

btw did you test if driver loading works in wine testbot?

no

though it seems like the mostly write the results into a buffer

which is passed back using DeviceIoControl

the DPRINT stuff seems to be optional

optional? what do you mean?

the results are stored in the buffer specified using IOCTL_KMTEST_SET_RESULTBUFFER

i don't think that the DPRINT are necessary for the results

kk

if you want to make something similar to the way how the current tests work, it would most probably endup being something like this:

you define an IO control code which uses a structure as output, the first field is the number of failed tests and the second field is a larger text buffer

in the kernel itself, you would define ok(..) in a way that it uses RtlStringCchPrintf

all the output is printed into this buffer

and the counter is increased during a test failure

when the iocontrol returns, the number of test failure is added to the counter in the user mode program and the buffer is simply print to stdout

you only need to make sure that the buffer is big enough for all the fail messages

seems good

that said that would be nice to use a standard interface for that

I wonder if SW tracing could be used for that: http://msdn.microsoft.com/en-us/library/windows...

we also need something that works in Wine

we could implement this interface maybe

hmm, I am wondering whether the user mode program may pass it's stdout handle to the driver

so that the driver could directly print into the programs stdout

or stderr

dunno need to read more about

it is possible to pass a handle from the usermode to the kernel

you simply pass the handle using DeviceIoControl anhd kernel calls ObReferenceObjectByHandle on the handle

and then you can use NtWriteFile on this handle

her I tought you were talking about SW trace sorry

so in theory we could directly print to stderr