Re: [PATCH 2/3] ntoskrnl.exe: Improve IoGetCurrentProcess stub.
Christian Costa <titan.costa(a)gmail.com> wrote:
+EPROCESS process_info; + #ifdef __i386__ #define DEFINE_FASTCALL1_ENTRYPOINT( name ) \ __ASM_STDCALL_FUNC( name, 4, \ @@ -1200,8 +1203,11 @@ NTSTATUS WINAPI FsRtlRegisterUncProvider(PHANDLE MupHandle, PUNICODE_STRING Redi */ PEPROCESS WINAPI IoGetCurrentProcess(void) { - FIXME("() stub\n"); - return NULL; + FIXME("(): partial stub\n"); + + process_info.UniqueProcessId = (PVOID)PsGetCurrentProcessId(); + + return &process_info; }
Why do you think that returning the structure filled with garbage is better than returning NULL? -- Dmitry.
2012/10/5 Dmitry Timoshkov <dmitry(a)baikal.ru>
Christian Costa <titan.costa(a)gmail.com> wrote:
+EPROCESS process_info; + #ifdef __i386__ #define DEFINE_FASTCALL1_ENTRYPOINT( name ) \ __ASM_STDCALL_FUNC( name, 4, \ @@ -1200,8 +1203,11 @@ NTSTATUS WINAPI FsRtlRegisterUncProvider(PHANDLE MupHandle, PUNICODE_STRING Redi */ PEPROCESS WINAPI IoGetCurrentProcess(void) { - FIXME("() stub\n"); - return NULL; + FIXME("(): partial stub\n"); + + process_info.UniqueProcessId = (PVOID)PsGetCurrentProcessId(); + + return &process_info; }
Why do you think that returning the structure filled with garbage is better than returning NULL?
It is not supposed to return NULL afaik but a valid pointer as you said before. The structure is zeroed except UniqueProcessId I need for MDL functions. MDL struct have a PEPROCESS field and I would like to do things in a clean way. What's the problem with that ?
Christian Costa <titan.costa(a)gmail.com> wrote:
Why do you think that returning the structure filled with garbage is better than returning NULL?
It is not supposed to return NULL afaik but a valid pointer as you said before. The structure is zeroed except UniqueProcessId I need for MDL functions. MDL struct have a PEPROCESS field and I would like to do things in a clean way. What's the problem with that ?
The problem is that the returned info in the structure must be valid, you can't initialize single field and pretend as done with it. -- Dmitry.
2012/10/5 Dmitry Timoshkov <dmitry(a)baikal.ru>
Christian Costa <titan.costa(a)gmail.com> wrote:
Why do you think that returning the structure filled with garbage is better than returning NULL?
It is not supposed to return NULL afaik but a valid pointer as you said before. The structure is zeroed except UniqueProcessId I need for MDL functions. MDL struct have a PEPROCESS field and I would like to do things in a clean way. What's the problem with that ?
The problem is that the returned info in the structure must be valid, you can't initialize single field and pretend as done with it.
This struct is huge. Do you have some fields in mind? What matters is what drivers need. I can add some typical fields if needed but that could be done in other patches when needed as well.
Christian Costa <titan.costa(a)gmail.com> wrote:
This struct is huge. Do you have some fields in mind? What matters is what drivers need. I can add some typical fields if needed but that could be done in other patches when needed as well.
There are basic things like the header and object list management, besides things like ActiveProcessors, Affinity, BasePriority is not hard to fill from the start. Probably you need to duscuss how this should be done, something tells me that without server support this is not going to work very well. -- Dmitry.
2012/10/5 Dmitry Timoshkov <dmitry(a)baikal.ru>
Christian Costa <titan.costa(a)gmail.com> wrote:
This struct is huge. Do you have some fields in mind? What matters is what drivers need. I can add some typical fields if needed but that could be done in other patches when needed as well.
There are basic things like the header and object list management, besides things like ActiveProcessors, Affinity, BasePriority is not hard to fill from the start. Probably you need to duscuss how this should be done, something tells me that without server support this is not going to work very well.
What do you mean by object list management ? There is only one element for now : nothing before nothing after. Unless lists are circular. I'm open for discussion but it's hard without an idea of what drivers do and what we want to support since wine is not intended to run all driver types. So at the beginning, maybe we can do something simple and improve the infrastructure as needs appear.
* On Fri, 5 Oct 2012, Christian Costa wrote:
2012/10/5 Dmitry Timoshkov <dmitry(a)baikal.ru>
What matters is what drivers need. I can add some typical fields if needed but that could be done in other patches when needed as well.
There are basic things like the header and object list management, besides things like ActiveProcessors, Affinity, BasePriority is not hard to fill from the start. Probably you need to duscuss how this should be done, something tells me that without server support this is not going to work very well.
What do you mean by object list management ?There is only one element for now : nothing before nothing after. Unless lists are circular.
I'm open for discussion but it's hard without an idea of what drivers do and what we want to support since wine is not intended to run all driver types.
So at the beginning, maybe we can do something simple and improve the infrastructure as needs appear.
This is nth time the discussion drives to the question: How do you test ntoskrnl &co functionality, folks? I suppose Christian debugs some application which loads own, custom sys-drivers. Wine has no tests which would build / load some simple sys-driver; and that needs to change in future, I'd say. Well, this topic already was brought in once by Damjan Jovanovic. [1] Plus, there are guys compiling kernel mode drivers with MinGW(-64) already: [2][3][4] Or am I misunderstanding the right way to go? S. [1] http://www.winehq.org/pipermail/wine-devel/2010-March/082460.html [2] http://strdup.livejournal.com/34596.html [3] http://sourceforge.net/projects/mingw-w64/forums/forum/723797/topic/3163052 [4] http://www.fccps.cz/download/adv/frr/win32_ddk_mingw/win32_ddk_mingw.html
Le 05/10/2012 23:01, Saulius Krasuckas a écrit :
* On Fri, 5 Oct 2012, Christian Costa wrote:
2012/10/5 Dmitry Timoshkov <dmitry(a)baikal.ru>
What matters is what drivers need. I can add some typical fields if needed but that could be done in other patches when needed as well. There are basic things like the header and object list management, besides things like ActiveProcessors, Affinity, BasePriority is not hard to fill from the start. Probably you need to duscuss how this should be done, something tells me that without server support this is not going to work very well. What do you mean by object list management ?There is only one element for now : nothing before nothing after. Unless lists are circular.
I'm open for discussion but it's hard without an idea of what drivers do and what we want to support since wine is not intended to run all driver types.
So at the beginning, maybe we can do something simple and improve the infrastructure as needs appear. This is nth time the discussion drives to the question: How do you test ntoskrnl &co functionality, folks?
I suppose Christian debugs some application which loads own, custom sys-drivers.
Wine has no tests which would build / load some simple sys-driver; and that needs to change in future, I'd say. Well, this topic already was brought in once by Damjan Jovanovic. [1]
Plus, there are guys compiling kernel mode drivers with MinGW(-64) already: [2][3][4]
Or am I misunderstanding the right way to go?
S.
[1] http://www.winehq.org/pipermail/wine-devel/2010-March/082460.html [2] http://strdup.livejournal.com/34596.html [3] http://sourceforge.net/projects/mingw-w64/forums/forum/723797/topic/3163052 [4] http://www.fccps.cz/download/adv/frr/win32_ddk_mingw/win32_ddk_mingw.html
Right. Mainly game and their copy protection stuff. Having a testing environment would be great. It's hard to test things. Thanks for the links.
participants (3)
-
Christian Costa -
Dmitry Timoshkov -
Saulius Krasuckas