[ros-kernel] Questions about recent commits to code in User32/Win32k/Gdi

[Thomas Weidenmueller]

Steven Edwards wrote:

>anonymous: for instance his CreateWindowEx code has many small
>differences with Wine code:
>if(!(WindowObject->Style & (WS_POPUP | WS_CHILD)))
>{
> /* clip siblings for overlapped windows. */
> WindowObject->Style |= (WS_CAPTION | WS_BORDER | WS_CLIPSIBLINGS);
>}
>
>  
>
i found out, that windows always applies this styles for overlapped 
windows. Write a simple app with 0 as window style and run it, then use 
e.g. WinSpy and lookup the style bits windows has set. As you see, it's 
so simple to prove this behavior. I don't always port stuff from wine 
(especially not for user32/gdi32), i often just use the wine code for 
inspiration how things could be implemented. I don't have the time to 
always lookup, if the wine implementation (that is often pretty weird) 
is correct. This fix for example is based on personal investigation (see 
above), besides, many of our stuff differs from wine. Since we mainly 
use user32/gdi32 to call our subsystem that is quite different from 
WINE's server, it's not possible to easily port things back and forth, 
although we are able to use usermode code from wine in some cases 
(dialogs, mdi, ...).

>anonymous: Wine does not have his. And I don't see how any real app
>could depend on it, therefore it can't be a simple bug fix
>
>  
>
As said above, windows applies these styles automatically for overlapped 
windows, so does ros now. Just pass 0 as a window style and see what 
windows does.

>anonymous: one of his gdi patches blatantly claims that Wine's code for
>FrameRect is wrong. How did he find it? How that could effect real word
>applications?
>
>anonymous: FrameRect -> FrameRgn
>
>  
>
A simple test app showes that windows obviously creates a region for the 
*inner* border of a region. The wine implementation is simple but does 
exactly the opposite - it creates one for the outer border. Now, if one 
tries to draw the border of a region of a window, one won't see 
anything, because it's clipped out. Balloon hints e.g. use this function 
to draw the border. They wouldn't work with the implementation of wine. 
I successfully tested our implementation, if you like, i can provide a 
simple test app that proves this behavior. A test app would create a 
region, apply it to a window. Then create the Frame region when 
processing WM_PAINT messages and basically fill this region with a solid 
color. if this function created a outer border, one wouldn't see any 
changes. if you run the app in windows, you'll see that it draws the 
inner border. Conclusion: wine's implementation is wrong, ours is right.

>I am not trying to accuse anyone of anything, its just we have to be
>careful of our sources even more so now that the Windows source code
>has leaked. Could we see a regression test or some documentation that
>shows how these changes are more "correct"?
>
>  
>
I don't use the windows sources, i don't even have them. All these 
things are obvious to me and can be tested within a few minutes with 
basic test apps. I like reactos to be working as it is supposed to work. 
I would never ever want to danger ReactOS or WINE.

You need to understand, that we cannot sync all changes with wine, 
there's lots of stuff that had been developed independently and so may 
differ in virtually all aspects.

Regards
Thomas