Re: [ros-dev] [ros-diffs] [tkreuzer] 26396: NtGdiGetObject: - return 0 if buffer != 0 and count == 0 - don't write beyond umode buffer size (max count bytes!) - use SEH only once - No need for Ret & RetCount, use only RetCount - document the function

[Ged]

>   + * @remarks
>  + *   The function will always return the complete size of the object's 
>  data,
>  + *   but will copy only a maximum of count bytes to the specified buffer. 


This isn't necessarily true, and the function is slightly flawed because of
it. It's a rather weird API in terms of it's results.
Your rewrite doesn't take into account the following cases, according to XP:

................................................................

BITMAP behaviour

GetObjectW(hBmp, -1, &bmp)  returns 24 and fills the struct
GetObjectW(hBmp, 0, &bmp)   returns 0 and doesn't fill the struct
GetObjectW(hBmp, 1, &bmp)   returns 0 and doesn't fill the struct
GetObjectW(hBmp, sizeof(BITMAP), &bmp)   returns 24 and fills the struct
GetObjectW(hBmp, 5000, &bmp)   returns 24 and fills the struct

DIBSECTION behaviour

GetObjectW(hBmp, -1, &dib)  returns 24 and fills the struct
GetObjectW(hBmp, 0, &dib)   returns 0 and doesn't fill the struct
GetObjectW(hBmp, 1, &dib)   returns 0 and doesn't fill the struct
GetObjectW(hBmp, sizeof(BITMAP), &dib)   returns 24 and fills the struct
GetObjectW(hBmp, sizeof(DIBSECTION), &dib)   returns 24 and fills the struct
GetObjectW(hBmp, 5000, &dib)   returns 24 and fills the struct

Non struct behaviour

The function will always return 24, no matter what size is passed.

................................................................

So, we can conclude that if size is less than 0, it works.
If size if between 0 and 23, it doesn't, and anything above works.
If we pass NULL, as the struct, we return 24, but obviously don't fill the
struct.

I would have grabbed you on IRC, but you weren't around ;)

Ged.











This message contains confidential information and is intended only for the individual
named. If you are not the named addressee you should not disseminate, distribute or copy
this e-mail. Please notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be
guaranteed to be secure or error-free as information could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does
not accept liability for any errors or omissions in the contents of this message, which
arise as a result of e-mail transmission. If verification is required please request a
hard-copy version. 

Amteus PLC
57 Cardigan Lane,
Leeds, 
LS4 2LE
t:[phone]
f: [phone]

Registered in England No 4760795

http://www.amteus.com

[Timo Kreuzer]

Hmm. I got different results with a BRUSH. I'll have a look at that 
later, must work now.


Ged wrote:
> >   + * @remarks
> >  + *   The function will always return the complete size of the object's 
> >  data,
> >  + *   but will copy only a maximum of count bytes to the specified buffer.
> >       
>
>
>  This isn't necessarily true, and the function is slightly flawed because of
>  it. It's a rather weird API in terms of it's results.
>  Your rewrite doesn't take into account the following cases, according to XP:
>
>  ................................................................
>
>  BITMAP behaviour
>
>  GetObjectW(hBmp, -1, &bmp)  returns 24 and fills the struct
>  GetObjectW(hBmp, 0, &bmp)   returns 0 and doesn't fill the struct
>  GetObjectW(hBmp, 1, &bmp)   returns 0 and doesn't fill the struct
>  GetObjectW(hBmp, sizeof(BITMAP), &bmp)   returns 24 and fills the struct
>  GetObjectW(hBmp, 5000, &bmp)   returns 24 and fills the struct
>
>  DIBSECTION behaviour
>
>  GetObjectW(hBmp, -1, &dib)  returns 24 and fills the struct
>  GetObjectW(hBmp, 0, &dib)   returns 0 and doesn't fill the struct
>  GetObjectW(hBmp, 1, &dib)   returns 0 and doesn't fill the struct
>  GetObjectW(hBmp, sizeof(BITMAP), &dib)   returns 24 and fills the struct
>  GetObjectW(hBmp, sizeof(DIBSECTION), &dib)   returns 24 and fills the struct
>  GetObjectW(hBmp, 5000, &dib)   returns 24 and fills the struct
>
>  Non struct behaviour
>
>  The function will always return 24, no matter what size is passed.
>
>  ................................................................
>
>  So, we can conclude that if size is less than 0, it works.
>  If size if between 0 and 23, it doesn't, and anything above works.
>  If we pass NULL, as the struct, we return 24, but obviously don't fill the
>  struct.
>
>  I would have grabbed you on IRC, but you weren't around ;)
>
>  Ged.
>
>
>
>
>
>
>
>
>
>
>
>  This message contains confidential information and is intended only for the individual
> named. If you are not the named addressee you should not disseminate, distribute or copy
> this e-mail. Please notify the sender immediately by e-mail if you have received this
> e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be
> guaranteed to be secure or error-free as information could be intercepted, corrupted,
> lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does
> not accept liability for any errors or omissions in the contents of this message, which
> arise as a result of e-mail transmission. If verification is required please request a
> hard-copy version. 
>
>  Amteus PLC
>  57 Cardigan Lane,
>  Leeds, 
>  LS4 2LE
>  t:[phone]
>  f: [phone]
>
>  Registered in England No 4760795
>
>  http://www.amteus.com
>
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>
>

[Ged]

I only had test results for the bitmap stuff, because that's what I was
working on the other day.

 

Ged

 

 

  _____  

From: ros-dev-bounces(a)reactos.org [mailto:[e-mail]] On
Behalf Of Timo Kreuzer
Sent: 18 April 2007 15:43
To: ReactOS Development List
Subject: Re: [ros-dev] [ros-diffs] [tkreuzer] 26396: NtGdiGetObject: -
return 0 if buffer != 0 and count == 0 - don't write beyond umode buffer
size (max count bytes!) - use SEH only once - No need for Ret & RetCount,
use only RetCount - document the function

 

Hmm. I got different results with a BRUSH. I'll have a look at that later,
must work now.


Ged wrote: 

+ * @remarks
+ *   The function will always return the complete size of the object's 
data,
+ *   but will copy only a maximum of count bytes to the specified buffer.
    

 
 
 
This isn't necessarily true, and the function is slightly flawed because of
it. It's a rather weird API in terms of it's results.
Your rewrite doesn't take into account the following cases, according to XP:
 
................................................................
 
BITMAP behaviour
 
GetObjectW(hBmp, -1, &bmp)  returns 24 and fills the struct
GetObjectW(hBmp, 0, &bmp)   returns 0 and doesn't fill the struct
GetObjectW(hBmp, 1, &bmp)   returns 0 and doesn't fill the struct
GetObjectW(hBmp, sizeof(BITMAP), &bmp)   returns 24 and fills the struct
GetObjectW(hBmp, 5000, &bmp)   returns 24 and fills the struct
 
DIBSECTION behaviour
 
GetObjectW(hBmp, -1, &dib)  returns 24 and fills the struct
GetObjectW(hBmp, 0, &dib)   returns 0 and doesn't fill the struct
GetObjectW(hBmp, 1, &dib)   returns 0 and doesn't fill the struct
GetObjectW(hBmp, sizeof(BITMAP), &dib)   returns 24 and fills the struct
GetObjectW(hBmp, sizeof(DIBSECTION), &dib)   returns 24 and fills the struct
GetObjectW(hBmp, 5000, &dib)   returns 24 and fills the struct
 
Non struct behaviour
 
The function will always return 24, no matter what size is passed.
 
................................................................
 
So, we can conclude that if size is less than 0, it works.
If size if between 0 and 23, it doesn't, and anything above works.
If we pass NULL, as the struct, we return 24, but obviously don't fill the
struct.
 
I would have grabbed you on IRC, but you weren't around ;)
 
Ged.
 
 
 
 
 
 
 
 
 
 
 
This message contains confidential information and is intended only for the
individual named. If you are not the named addressee you should not
disseminate, distribute or copy this e-mail. Please notify the sender
immediately by e-mail if you have received this e-mail by mistake and delete
this e-mail from your system. E-mail transmission cannot be guaranteed to be
secure or error-free as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or contain viruses. The sender
therefore does not accept liability for any errors or omissions in the
contents of this message, which arise as a result of e-mail transmission. If
verification is required please request a hard-copy version. 
 
Amteus PLC
57 Cardigan Lane,
Leeds, 
LS4 2LE
t:[phone]
f: [phone]
 
Registered in England No 4760795
 
http://www.amteus.com
 
 
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
 
  

 



This message contains confidential information and is intended only for the individual
named. If you are not the named addressee you should not disseminate, distribute or copy
this e-mail. Please notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be
guaranteed to be secure or error-free as information could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does
not accept liability for any errors or omissions in the contents of this message, which
arise as a result of e-mail transmission. If verification is required please request a
hard-copy version. 

Amteus PLC
57 Cardigan Lane,
Leeds, 
LS4 2LE
t:[phone]
f: [phone]

Registered in England No 4760795

http://www.amteus.com