[ros-kernel] Re: [ros-cvs] CVS Update: reactos

[Filip Navara]

----- PŮVODNÍ ZPRÁVA -----
Od: "Dmitry Timoshkov" <dmitry at baikal.ru>
Komu: "ReactOS Kernel List" <ros-kernel at reactos.com>
Předmět: Re: [ros-kernel] Re: [ros-cvs] CVS Update:
Datum: 27.5.2004 - 13:14:51

> "Waldo Alvarez Cańizares" <wac at lab.matcom.uh.cu> wrote:
> 
> > On ReactOS the window classes are stored all in a
> > linked list in
> > W32PROCESS structure. Global and local classes are
> > mixed here and
> > they're differenced by a per class 'BOOL Global'
> > variable.
> > On Windows the window classes are stored in two lists
> > in the W32THREAD
> > structure. One for local classes and the second for
> > global classes. This
> > simpilifies the class handling code quite a bit and
> > allows to remove the
> > process locking (since W32THREAD is per thread and we
> > are sure we don't
> > access it from elsewhere at the same time). I don't
> > understand the exect
> > details of this and so I haven't tried to implement
> > it yet. ;-)
> 
> According to my tests (additional to Wine class tests)
> classes in Win2k
> are stored not per thread, but per module. And MSDN
> actually has a good
> description of that. Go read about system, application
> local and global
> classes. If the classes would be stored in the thread
> lists they would be
> thread local and not accessable from other threads of
> the application.

It's a bit harder than this. I'm not trying to say that classes
are thread local. I'm trying to say that there are linked lists
with pointers to class info for each thread and that these lists
maintain the pointers to the window classes accessible from that
thread. In fact I'm almost sure that's not the only way how
Windows keeps track of the window classes, but it's there and
it's used for actual lookup.

> Again: why are you guys inventing a wheel instead of
> using/looking at
> the Wine code?

I looked at the Wine code, read it and found some things that are
not done like in Windows. I'm not at home, so I can't tell you
exactly which thing it were, but here what I recall (might be
incorrect): - GetClassInfo doesn't set hInstance to USER32 module
instance if it's NULL. I think it's provable if you try to call
GetClassInfo with hInstance==NULL and some class from comctl32. -
If you call RegisterClass[Ex][AW] with lpClassInfo that has
lpClassInfo->hInstance==NULL, it's set to the caller's module
handle. (
   WNDCLASSEX WndClass = {...};
   WndClass.hInstance = NULL;
   RegisterClassEx(&WndClass);
   /* Now WndClass.hInstance == GetModuleHandle(NULL) */
)
(Easy to fix in Wine)

AT LEAST I'M TRYING TO REUSE THE WINE CODE, but only if I believe
it's correct. That's about 80%~90% of cases or even more...

Regards,
Filip