30 Jul
2009
30 Jul
'09
1:14 p.m.
Aleksey Bragin schrieb:
On Jul 30, 2009, at 12:49 AM, James Tabor wrote:
Ripping our win32k out from trunk will not help with it's development.
Do you think we will get more developers that say "yay there's 2 win32
subsystems, that's exactly what I was looking for"? Ripping it apart
won't help. And if there's something that can break trunk, we can do it
in a temprary branch and merge it back as soon as it's ready and tested.
Proper testing is obligatory. But how do you expect probems to be
detected when you don't even have that code in trunk? How do you expect
people will fix bugs in it when the code is somewhere outside trunk?
Please stop telling it's an advantage for win32k devs, cause it's not.
Also: I still don't see where you want to get more stability and
compatibility with that new subsystem. We have some bugs yes, but the
major buggers are still in the kernel. How often does win32k crash and
how often does the kernel crash. Don't blame win32k for everything,
instead put your own house in order first.
If I'm not mistaken, we already imported wine
code at the beginning
did we not? I'm looking at the commit logs and it does look we
started with wine. We need to keep it separated before it is too late.
Oh it's already too late. Ah, we missed that one.
On Wed, Jul 29, 2009 at 1:10 PM, Ged<gedmurphy(a)gmail.com> wrote:
That's what being suggested. However Alex said a different opinion,
that the rewrite could happen in-place. But apriori that takes more
effort, because one needs to take into account compatibility, prevent
breakages (Jim knows how hard it is).
Current win32 subsystem progress is too slow. We
need something
now before
it's too late.
One of the main things that's holing us back and stopping new devs
from
getting involved is out lack of compatibility and stability.
Good reason to keep it separated.
Though still I don't see what a "proper"
win32 subsystem architecture
means. I know the crystal clear, well thought through, not changed
much over years design of an NT kernel. But with win32 subsystem,
there is no such crystal clearness.
Timo, James - please, tell me your opinions about that. So far, the
only "proper" things from a real win32 subsystem are the win32k
syscall interface (ros still uses its own variant of it, with similar
function names, but different parameters, etc - but that's what being
fixed) and internal structures documented by Timo (great work indeed).
It's fine so far, but having NT API and NDK is not all what's needed
to build a good and proper kernel. There is something called internal
architecture. What do we have of a proper internal architecture in
gdi32, user32 and win32k.sys now in trunk?
P.S. no flamewars please, those are fully valid question, fully
serious, and no offence to anyone is intended.
There's a lot more. The structures and syscall interfaces are just the
bottom. You can use the syscall interfaces for native api testing to
make sure you know what is the kernel's part is and what is gdi/user's
part. Then you can use the structures together with WinDbg and memory
dumps and back traces to do very detailed analysis of the inner workings
of functions without disassembling anything. It tells you where objects
are allcoated from, where objects come from and where they point to.
Looking at the symbol names tells you a great detail of the inner
workings, too. I have added backtraces from font drivers to the wiki.
That probably tells you more about the internal font driver architecture
than all books. Combine all these methods and you get a lot more
detailed knowledge about the inner architecture. The rest is reasoning
and extrapolation.
Now let's look at design compared to windows (XP/2003)
There's the gdi handle manager, which is is now working almost identical
to the Windows one. There's shared locks and references that work like
on Windows (not everywhere but getting there). There are still problems
but it's already quite good. It allows us to use the gdi handle viewer
tool in reactos. It also allows loading reactos gdi32 in windows
(although it fails for most things)
There's brushes. The interface between the usermode brushes and the
kernel brushobj and DCs and XLATEOBJs is quite complicated. Just
slapping something together that kinda does it's job for now and
improving on it later is what has been done in our win32k in earlier
times. Everone just adds his 5 lines of fix upon the existing code
instead of fixing the implementation architecture. But that leeds to
code that gets more and more bloated and complicated and slow. I've
spend some time fixing it and it should be much more Windows like now.
As a side effect we now have support for DC pen/brush and for the first
time allows display drivers to use their own brushes instead of failing
miserably.
Let's look at the Window structures. We use a combination of a kernel
structure and a usermode structure. This result of "let's do it our own
way" is leading to null pointer dereferences, memory leaks and whatever.
Jim currently makes good progress in this area so that I expect this
mess to be cleaned up soon. This will be a premise to do proper fixing
of the Winpos code that is very buggy.
Let's look at the sysparams: Our earlier implementation was huge,
bloated, incomplete and it would have been simply impossible to fix it.
So I spent quite some time in analyzing how it works on windows and
rewriting it. It turned out that we were storing certain variables in
absurd locations. It's still not 100% right, but I'm quite certain that
the current design is good enough to work out in the future.
What is the advantage of this?
Doing it "your own way", ignoring everything you know about the Win32
subsystem, hacking hacks upon hacks, reusing large portions of 3rd party
code without understanding the inner workings might actually get you
some working subsystem in the short run (although this still remains to
be seen). But it will most likely also result in duplicated work later.
At some point you'll notice: Ohh crap, this all doesn't work out like it
should. Why that? Rewrite #7!
On the other hand, using all pieces of knowledge about how it works on
Windows will help to make sure that the code will work correctly even
later with parts and details you didn't yet take care of. As soon as you
know how something works on Windows especially how things are
interrelated, you're free to change whatever detail is
neccessary/useful. But you shouldn't think you're smarter than all the
ms devs if you don't understand how that stuff works on windows.
Regards,
Timo