DCE problem

[James Tabor]

Hi,
I thought it was a handle management problem but it seems to be just a
GetDC one. I found out when a pOWNED dc or dc owned by a window or
window class after the first GetDC the DCX_CACHE bit become set. This
is wrong behavior. Our UserGetDCEx code is a hodgepodge of wine and
poorly RE, coded by the original authors and does not comply with
known semantics. Sorry I guess? Well~ still rewriting it has become a
headache for me and I guess I'm asking for help. I have attempted more
than twice to rewrite it with porting wine code, etc. All ended in
major crashes, thus validating my claim, if you write code based on
bad code you end up with more bad code.
Using wine testing, Use32 dce test, everything works upto line 93.
    hdc = GetDC( hwnd_owndc );  <----------------- first GetDC call
    SetROP2( hdc, R2_WHITE );
    rop = GetROP2( hdc );
    ok( rop == R2_WHITE, "wrong ROP2 %d\n", rop );
     old_hdc = hdc;
     ReleaseDC( hwnd_owndc, hdc ); <---------------------- first ReleaseDC
     hdc = GetDC( hwnd_owndc ); <---------------------------2nd GetDC
     ok( old_hdc == hdc, "didn't get same DC %p/%p\n", old_hdc, hdc );
     rop = GetROP2( hdc );
-> ok( rop == R2_WHITE, "wrong ROP2 %d after release\n", rop );
     ReleaseDC( hwnd_owndc, hdc );
     rop = GetROP2( hdc );
     ok( rop == R2_WHITE, "wrong ROP2 %d after second release\n", rop );
After the first GetDC the DC is cached by setting bit DCX_CACHE and
this is wrong (BUG) since this DC is owned by a window. The second
GetDC is called and the DC is now a DCX_CACHE. The original data is
now lost due to the first ReleaseDC freeing DC_ATTR, thus normal
behavior for this type of DC with DCX_CACHE set. This results in the
failure at line 93 with the data in the DC_ATTR is set to a CleanDC
state. This is correct for DCX_CACHE'ed DC but not for DCX_WINDOW DC.
DCX_WINDOW DCs keep the original DC_ATTR data and it is not freed
after a ReleaseDC call. The same goes on with class DC tests.
The BUG is in UserGetDCEx, the freeing and allocating DC_ATTR is
correct but somewhere the DCX_CACHE bit get set and that should not
happen for window/class owned DCs.
I hope this clears it up.
I need someone with fresh eyes to help us fix this.
Thanks,
James

[Senthil Kumar]

Greetings everyone,
I recently joined the reactos-dev mailing list because I am interested in
contributing to the development effort.  I am based in Colorado Springs, CO,
USA and am a software enginner. I am good at programming but weak in windows
internals.
I have so far pulled the source and built it. I decided to target the
successful run of Office 2003 on reactos as my goal. (I have no idea how
realistic this goal is, and perhaps it already runs successfully ?).
At this point, I need some pointers on how to go about the job. I have seen
hints that I need to take the code over from wine into reactos etc.
Do I need to run wine in debug mode and see all the win-api calls that happen
and port those calls from wine into react-os ?
Is there a hand-holding documents which describes this ?
Any pointers and help would be much appreciated.
Senthil

[gedmurphy]

Welcome.
First thing's first (I hate that phrase), get yourself into IRC.
You'll find life much easier if you do.
If that's not possible, then we'll discuss things further via the mailing
list.
Regards,
Ged.
-----Original Message-----
From: ros-dev-bounces(a)reactos.org [mailto:[e-mail]] On
Behalf Of Senthil Kumar
Sent: 16 May 2008 05:33
To: ReactOS Development List
Subject: [ros-dev] Introduction & request for help
Greetings everyone,
I recently joined the reactos-dev mailing list because I am interested in
contributing to the development effort.  I am based in Colorado Springs, CO,
USA and am a software enginner. I am good at programming but weak in windows
internals.
I have so far pulled the source and built it. I decided to target the
successful run of Office 2003 on reactos as my goal. (I have no idea how
realistic this goal is, and perhaps it already runs successfully ?).
At this point, I need some pointers on how to go about the job. I have seen
hints that I need to take the code over from wine into reactos etc.
Do I need to run wine in debug mode and see all the win-api calls that
happen
and port those calls from wine into react-os ?
Is there a hand-holding documents which describes this ?
Any pointers and help would be much appreciated.
Senthil
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

[Steven Edwards]

On Fri, May 16, 2008 at 2:57 AM, gedmurphy <gedmurphy(a)gmail.com> wrote:
>   I have so far pulled the source and built it. I
> decided to target the
>  successful run of Office 2003 on reactos as my goal. (I have no idea how
>  realistic this goal is, and perhaps it already runs successfully ?).
>  At this point, I need some pointers on how to go about the job. I have seen
>  hints that I need to take the code over from wine into reactos etc.
>  Do I need to run wine in debug mode and see all the win-api calls that
>  happen
>  and port those calls from wine into react-os ?
>  Is there a hand-holding documents which describes this ? 
Not really, you need to get to know the MSI and RPC source code. I
expect most of the remaining bugs blocking installation fall in to
either a kernel issue related to the Mm and Cc overhaul or given some
of the recent crash reports, the ReactOS RPC server might not be
playing nice with Wine's implementation of DCOM. DCOM is black magic
to me, so I highly suggest targeting the Wine regression tests for
ole32, msi and friends first, get all of the winetests passing on
ReactOS and then try to install Office 2003. You are going to need to
bruteforce it and just focus on fixing one api failure in the tests at
a time. Keep in mind the Wine test code and implementation for these
dlls is mostly sane as the current WineAPI failure rate for win2003 is
only 8% so your most likely going to be fixing bugs at a much lower
level in ReactOS code. If you find a real bug in Wine, talk to us on
IRC before submitting patches to Wine.
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo

[Senthil Kumar]

Steven & Ged,
Thanks for the tips. I will soon drop in the IRC channel.
Senthil
--- Steven Edwards <winehacker(a)gmail.com> wrote:
>   On Fri, May 16, 2008 at 2:57 AM, gedmurphy
> <gedmurphy(a)gmail.com> wrote:
> >   I have so far pulled the source and built it. I
> > decided to target the
> >  successful run of Office 2003 on reactos as my goal. (I have no idea how
> >  realistic this goal is, and perhaps it already runs successfully ?).
> >  At this point, I need some pointers on how to go about the job. I have 
>  seen
> >   hints that I need to take the code over from wine
> > into reactos etc.
> >  Do I need to run wine in debug mode and see all the win-api calls that
> >  happen
> >  and port those calls from wine into react-os ?
> >  Is there a hand-holding documents which describes this ? 
>  Not really, you need to get to know the MSI and RPC source code. I
>  expect most of the remaining bugs blocking installation fall in to
>  either a kernel issue related to the Mm and Cc overhaul or given some
>  of the recent crash reports, the ReactOS RPC server might not be
>  playing nice with Wine's implementation of DCOM. DCOM is black magic
>  to me, so I highly suggest targeting the Wine regression tests for
>  ole32, msi and friends first, get all of the winetests passing on
>  ReactOS and then try to install Office 2003. You are going to need to
>  bruteforce it and just focus on fixing one api failure in the tests at
>  a time. Keep in mind the Wine test code and implementation for these
>  dlls is mostly sane as the current WineAPI failure rate for win2003 is
>  only 8% so your most likely going to be fixing bugs at a much lower
>  level in ReactOS code. If you find a real bug in Wine, talk to us on
>  IRC before submitting patches to Wine.
>  --
>  Steven Edwards
>  "There is one thing stronger than all the armies in the world, and
>  that is an idea whose time has come." - Victor Hugo
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>