Re: [PATCH 2/3] ntoskrnl.exe: Improve IoGetCurrentProcess stub.

[Dmitry Timoshkov]

Christian Costa  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?

[PATCH 2/3] ntoskrnl.exe: Improve IoGetCurrentProcess stub.

[Christian Costa]

2012/10/5 Dmitry Timoshkov
> Christian Costa  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 ?

[PATCH 2/3] ntoskrnl.exe: Improve IoGetCurrentProcess stub.

[Dmitry Timoshkov]

Christian Costa  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.

[PATCH 2/3] ntoskrnl.exe: Improve IoGetCurrentProcess stub.

[Christian Costa]

2012/10/5 Dmitry Timoshkov
> Christian Costa  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.

[PATCH 2/3] ntoskrnl.exe: Improve IoGetCurrentProcess stub.

[Dmitry Timoshkov]

Christian Costa  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.

[PATCH 2/3] ntoskrnl.exe: Improve IoGetCurrentProcess stub.

[Christian Costa]

2012/10/5 Dmitry Timoshkov
> Christian Costa  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.

[PATCH 2/3] ntoskrnl.exe: Improve IoGetCurrentProcess stub.

[Saulius Krasuckas]

* On Fri, 5 Oct 2012, Christian Costa wrote:
> 2012/10/5 Dmitry Timoshkov
> > > 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

[PATCH 2/3] ntoskrnl.exe: Improve IoGetCurrentProcess stub.

[Christian Costa]

Le 05/10/2012 23:01, Saulius Krasuckas a écrit :
> - On Fri, 5 Oct 2012, Christian Costa wrote:
> > 2012/10/5 Dmitry Timoshkov
> > > > 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.