Problem with out current NtGdiExtGetObjectW implementation

[Timo Kreuzer]

Hi,

although I like the way NtGdiExtGetObjectW is using the union, we will 
get a problem with it.
We don't know how many styles an extpen has, so we cannot statically 
allocate a kmode buffer that is big enough.

I can currently think of 3 possible solutions:

1. Add a big additional hack for GDI_OBJECT_TYPE_EXTPEN in 
NtGdiExtGetObjectW, that will copy the styles, wich seems to be a bad idea.

2. Use the old method of first calling IntGdiExtGetObjectW to get the 
needed buffer size then allocate a kernelmode buffer then call 
IntGdiExtGetObjectW again to tranfer the data then copy to usermode. 
This is slower and needs extra memory.

3. Move the copying to usermode to the XXX_GetObject functions. This 
would remove the need for an extra kernelmode buffer and we wouldn't 
really need IntGdiExtGetObjectW anymore. But it doesn't match the rest 
of our call chain design.

Comments appreciated.
Timo

[James Tabor]

Hi! & All!
Timo Kreuzer wrote:
> Move the copying to usermode to the XXX_GetObject functions. This
>
> would remove the need for an extra kernelmode buffer and we wouldn't 
> really need IntGdiExtGetObjectW anymore. But it doesn't match the rest 
> of our call chain design.
>
> Comments appreciated.
> Timo

IntGdiExtGetObjectW, I think is ok and it does work with the internal kernel Gdi
handle system. So this needs to be handled in kernel space.

Thanks,
James

[James Tabor]

Timo Kreuzer wrote:
> Hi,
> 2. Use the old method of first calling IntGdiExtGetObjectW to get the 
> needed buffer size then allocate a kernelmode buffer then call 
> IntGdiExtGetObjectW again to tranfer the data then copy to usermode. 
> This is slower and needs extra memory.

Calling kernel space is a bad idea, if you can avoid it. If the function can be
handled in user mode, intercept it there and return to the calling app. Most NtGdi
functions have no choice but to be called due to compatibility and test cases.
So, if that is the only way to get the size than we are stuck with it, until
we have a better way of fixing it.

I haven't imp the DC_ATTR yet, this may fix some issues.
James

[Alex Ionescu]

Hi,

The NtGdi function in NT, according to my tests, only copies whatever can
fit in the union. I suggest we keep this behaviour.

Best regards,
Alex Ionescu

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Timo Kreuzer
Sent: April-30-07 9:38 AM
To: [e-mail]
Subject: [ros-dev] Problem with out current NtGdiExtGetObjectW
implementation

Hi,

although I like the way NtGdiExtGetObjectW is using the union, we will 
get a problem with it.
We don't know how many styles an extpen has, so we cannot statically 
allocate a kmode buffer that is big enough.

I can currently think of 3 possible solutions:

1. Add a big additional hack for GDI_OBJECT_TYPE_EXTPEN in 
NtGdiExtGetObjectW, that will copy the styles, wich seems to be a bad idea.

2. Use the old method of first calling IntGdiExtGetObjectW to get the 
needed buffer size then allocate a kernelmode buffer then call 
IntGdiExtGetObjectW again to tranfer the data then copy to usermode. 
This is slower and needs extra memory.

3. Move the copying to usermode to the XXX_GetObject functions. This 
would remove the need for an extra kernelmode buffer and we wouldn't 
really need IntGdiExtGetObjectW anymore. But it doesn't match the rest 
of our call chain design.

Comments appreciated.
Timo

_______________________________________________
Ros-dev mailing list
[e-mail]
http://www.reactos.org/mailman/listinfo/ros-dev

[Jerry]

What about a stack buffer that can hold most of all cases?

On 4/30/07, Alex Ionescu [e-mail] wrote:
> Hi,
>
> The NtGdi function in NT, according to my tests, only copies whatever can
> fit in the union. I suggest we keep this behaviour.
>
> Best regards,
> Alex Ionescu
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Timo Kreuzer
> Sent: April-30-07 9:38 AM
> To: [e-mail]
> Subject: [ros-dev] Problem with out current NtGdiExtGetObjectW
> implementation
>
> Hi,
>
> although I like the way NtGdiExtGetObjectW is using the union, we will
> get a problem with it.
> We don't know how many styles an extpen has, so we cannot statically
> allocate a kmode buffer that is big enough.
>
> I can currently think of 3 possible solutions:
> Add a big additional hack for GDI_OBJECT_TYPE_EXTPEN in
>
> NtGdiExtGetObjectW, that will copy the styles, wich seems to be a bad idea.
> Use the old method of first calling IntGdiExtGetObjectW to get the
>
> needed buffer size then allocate a kernelmode buffer then call
> IntGdiExtGetObjectW again to tranfer the data then copy to usermode.
> This is slower and needs extra memory.
> Move the copying to usermode to the XXX_GetObject functions. This
>
> would remove the need for an extra kernelmode buffer and we wouldn't
> really need IntGdiExtGetObjectW anymore. But it doesn't match the rest
> of our call chain design.
>
> Comments appreciated.
> Timo
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Timo Kreuzer]

That's what we are using.
And in fact it seems that Windows supports a maximum of 16 styles for 
extpens and that will fit in our union.
Yay! ;-)

Jerry schrieb:
> What about a stack buffer that can hold most of all cases?
>
> On 4/30/07, Alex Ionescu [e-mail] wrote:
> > Hi,
> >
> > The NtGdi function in NT, according to my tests, only copies whatever can
> > fit in the union. I suggest we keep this behaviour.
> >
> > Best regards,
> > Alex Ionescu
> >
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On
> > Behalf Of Timo Kreuzer
> > Sent: April-30-07 9:38 AM
> > To: [e-mail]
> > Subject: [ros-dev] Problem with out current NtGdiExtGetObjectW
> > implementation
> >
> > Hi,
> >
> > although I like the way NtGdiExtGetObjectW is using the union, we will
> > get a problem with it.
> > We don't know how many styles an extpen has, so we cannot statically
> > allocate a kmode buffer that is big enough.
> >
> > I can currently think of 3 possible solutions:
> > Add a big additional hack for GDI_OBJECT_TYPE_EXTPEN in
> >
> > NtGdiExtGetObjectW, that will copy the styles, wich seems to be a bad idea.
> > Use the old method of first calling IntGdiExtGetObjectW to get the
> >
> > needed buffer size then allocate a kernelmode buffer then call
> > IntGdiExtGetObjectW again to tranfer the data then copy to usermode.
> > This is slower and needs extra memory.
> > Move the copying to usermode to the XXX_GetObject functions. This
> >
> > would remove the need for an extra kernelmode buffer and we wouldn't
> > really need IntGdiExtGetObjectW anymore. But it doesn't match the rest
> > of our call chain design.
> >
> > Comments appreciated.
> > Timo
> >
> > Ros-dev mailing list
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
> >
> > Ros-dev mailing list
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev