Hello, I will be thoroughly explaining the arwinss architecture, and the very first start is the general flow diagram which could be seen here: http://www.reactos.org/wiki/Arwinss_architecture
This page will also get more updates with regard to architecture and design of all modules, but most attention will be paid to win32k.sys internals and native gdi/user driver (so-called winent.drv).
With the best regards, Aleksey bragn.
Loks awesome Hope you are right, and ROS will be actually *better* than Windows!
On Tue, Jul 28, 2009 at 8:41 PM, Aleksey Bragin aleksey@reactos.org wrote:
Hello,I will be thoroughly explaining the arwinss architecture, and the very first start is the general flow diagram which could be seen here: http://www.reactos.org/wiki/Arwinss_architecture
This page will also get more updates with regard to architecture and design of all modules, but most attention will be paid to win32k.sys internals and native gdi/user driver (so-called winent.drv).
With the best regards, Aleksey bragn.
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
This architecture makes it possible to do headless instances of Windows. ReactOS might actually make some headway with this architecture. People that have to use Windows for their server platform would probably appreciate being able to run Windows totally headless and remotely connecting and using their regular tools as if they were sitting right at the server console.
2009/7/28 Javier Agustìn Fernàndez Arroyo elhoir@gmail.com
Loks awesome Hope you are right, and ROS will be actually *better* than Windows!
On Tue, Jul 28, 2009 at 8:41 PM, Aleksey Bragin aleksey@reactos.orgwrote:
Hello,I will be thoroughly explaining the arwinss architecture, and the very first start is the general flow diagram which could be seen here: http://www.reactos.org/wiki/Arwinss_architecture
This page will also get more updates with regard to architecture and design of all modules, but most attention will be paid to win32k.sys internals and native gdi/user driver (so-called winent.drv).
With the best regards, Aleksey bragn.
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
i cant help but feel that is how it should have been done in the first place by the way the diagram looks
Oh, c'mon, people.
This diagram says nothing. Has anyone of you even a clue of how it would look like for Windows? The only difference to Windows design that can be seen from this diagram is the addition of the NT driver and X11 driver. What it doesn't show is where which parts of the subsystem are located. And that would probably show compatibility problems and bad performace.
Regards, Timo
Brian schrieb:
i cant help but feel that is how it should have been done in the first place by the way the diagram looks
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
What people should also know is that if this branch ever does make it into trunk it will only be used as a temporary solution until the correct implementation is ready. This is by no means a permanent solution!
What it will do is act as a temp replacement which will hold things together and allow work on the real subsystem to accelerate.
At the moment the current subsystem must be kept stable as it's our main component and needs to stay regression free whilst rewriting major parts to make it more compatible. Not an easy task!
If the Arwinss model can take over for a while it will gives the win32 subsystem developers breathing space to rewrite / hack / break / fight / kill / molest and eventually improve the real implementation without worrying about breaking reactos for everyone else.
In the long run this may be a great solution to improve the compatibility and stability of the real reactos win32 subsystem.
Ged.
From: Timo Kreuzer [mailto:timo.kreuzer@web.de] Sent: 29 July 2009 11:33 To: ReactOS Development List Subject: Re: [ros-dev] Arwinss architecture
Oh, c'mon, people.
This diagram says nothing. Has anyone of you even a clue of how it would look like for Windows? The only difference to Windows design that can be seen from this diagram is the addition of the NT driver and X11 driver. What it doesn't show is where which parts of the subsystem are located. And that would probably show compatibility problems and bad performace.
Regards, Timo
Brian schrieb:
i cant help but feel that is how it should have been done in the first place by the way the diagram looks
_____
_______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Absolutely, this is exactly what I had in mind. The project needs a solidly working solution right now, even at some expense of speed (though it's arguable). It is very hard to properly rewrite our existing win32 subsystem without introducing regressions, and by the time this is done, the world may forget Win32 exists.
Arwinss gives key advantages to this: 1. It is possible to start a win32 subsystem with the proper, better design without dooming the project for 10 more years (existing win32k started in 1999) of work without any realworld useful result. 2. It is possible too make a new win32 subsystem aiming at future, not at present (e.g. use C++ if that fits better, use more modern architecture if needed, etc). 3. It is possible to gain new developers to do this task because with Arwinss ReactOS is going to get real usage, and come to a new height. Just imagine all good from Wine (compatibility) without all bad parts (Linux/XWindows related). 4. It allows to fix problems in other parts of the system (arwinss already uncovered bugs in csrss for example, more to come). Developing a new win32 susbsystem against bad users will result only in more pain (James knows how fun was it to see desktop class becoming local).
WBR, Aleksey Bragin.
On Jul 29, 2009, at 3:38 PM, Ged wrote:
What people should also know is that if this branch ever does make it into trunk it will only be used as a temporary solution until the correct implementation is ready. This is by no means a permanent solution!
What it will do is act as a temp replacement which will hold things together and allow work on the real subsystem to accelerate.
At the moment the current subsystem must be kept stable as it’s our main component and needs to stay regression free whilst rewriting major parts to make it more compatible. Not an easy task!
If the Arwinss model can take over for a while it will gives the win32 subsystem developers breathing space to rewrite / hack / break / fight / kill / molest and eventually improve the real implementation without worrying about breaking reactos for everyone else.
In the long run this may be a great solution to improve the compatibility and stability of the real reactos win32 subsystem.
Ged.
From: Timo Kreuzer [mailto:timo.kreuzer@web.de] Sent: 29 July 2009 11:33 To: ReactOS Development List Subject: Re: [ros-dev] Arwinss architecture
Oh, c'mon, people.
This diagram says nothing. Has anyone of you even a clue of how it would look like for Windows? The only difference to Windows design that can be seen from this diagram is the addition of the NT driver and X11 driver. What it doesn't show is where which parts of the subsystem are located. And that would probably show compatibility problems and bad performace.
Regards, Timo
Brian schrieb:
i cant help but feel that is how it should have been done in the first place by the way the diagram looks
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
No, not even, not in the light of day, shall this ever be part of trunk!
Separate project maybe, perhaps or will be a new project altogether!
Leave our trunk alone and keep working on ArWinSS where it is or make it's own home on ReactOS.org.
I'm @ wk and had to comment on this, James
On Wed, Jul 29, 2009 at 6:38 AM, Gedgedmurphy@gmail.com wrote:
What people should also know is that if this branch ever does make it into trunk it will only be used as a temporary solution until the correct implementation is ready. This is by no means a permanent solution!
What it will do is act as a temp replacement which will hold things together and allow work on the real subsystem to accelerate.
At the moment the current subsystem must be kept stable as it’s our main component and needs to stay regression free whilst rewriting major parts to make it more compatible. Not an easy task!
If the Arwinss model can take over for a while it will gives the win32 subsystem developers breathing space to rewrite / hack / break / fight / kill / molest and eventually improve the real implementation without worrying about breaking reactos for everyone else.
In the long run this may be a great solution to improve the compatibility and stability of the real reactos win32 subsystem.
Ged.
war is here 3:>
On Wed, Jul 29, 2009 at 7:30 PM, James Tabor jimtabor.rosdev@gmail.comwrote:
No, not even, not in the light of day, shall this ever be part of trunk!
Separate project maybe, perhaps or will be a new project altogether!
Leave our trunk alone and keep working on ArWinSS where it is or make it's own home on ReactOS.org.
I'm @ wk and had to comment on this, James
On Wed, Jul 29, 2009 at 6:38 AM, Gedgedmurphy@gmail.com wrote:
What people should also know is that if this branch ever does make it
into
trunk it will only be used as a temporary solution until the correct implementation is ready. This is by no means a permanent solution!
What it will do is act as a temp replacement which will hold things
together
and allow work on the real subsystem to accelerate.
At the moment the current subsystem must be kept stable as it’s our main component and needs to stay regression free whilst rewriting major parts
to
make it more compatible. Not an easy task!
If the Arwinss model can take over for a while it will gives the win32 subsystem developers breathing space to rewrite / hack / break / fight / kill / molest and eventually improve the real implementation without worrying about breaking reactos for everyone else.
In the long run this may be a great solution to improve the compatibility and stability of the real reactos win32 subsystem.
Ged.
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
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.
If we have a drop in replacement which is much more compatible and stable then the current one, then I think it's wise to use that whilst the real implementation is continued alongside.
Surely this will give you the freedom to get architecture done without worrying about breaking things?
Ged.
-----Original Message----- From: James Tabor [mailto:jimtabor.rosdev@gmail.com] Sent: 29 July 2009 18:30 To: ReactOS Development List Subject: Re: [ros-dev] Arwinss architecture
No, not even, not in the light of day, shall this ever be part of trunk!
Separate project maybe, perhaps or will be a new project altogether!
Leave our trunk alone and keep working on ArWinSS where it is or make it's own home on ReactOS.org.
I'm @ wk and had to comment on this, James
On Wed, Jul 29, 2009 at 6:38 AM, Gedgedmurphy@gmail.com wrote:
What people should also know is that if this branch ever does make it into trunk it will only be used as a temporary solution until the correct implementation is ready. This is by no means a permanent solution!
What it will do is act as a temp replacement which will hold things
together
and allow work on the real subsystem to accelerate.
At the moment the current subsystem must be kept stable as it's our main component and needs to stay regression free whilst rewriting major parts
to
make it more compatible. Not an easy task!
If the Arwinss model can take over for a while it will gives the win32 subsystem developers breathing space to rewrite / hack / break / fight / kill / molest and eventually improve the real implementation without worrying about breaking reactos for everyone else.
In the long run this may be a great solution to improve the compatibility and stability of the real reactos win32 subsystem.
Ged.
_______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Makes sense. And once the real subsystems are compatible and stable enough, then the arwinss branch could be relegated to an addon. An addon that could be used on both ReactOS and Windows. It's a stopgap solution, but one that would have uses after it is replaced.
On Wed, Jul 29, 2009 at 1:10 PM, Ged gedmurphy@gmail.com wrote:
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.
If we have a drop in replacement which is much more compatible and stable then the current one, then I think it's wise to use that whilst the real implementation is continued alongside.
Surely this will give you the freedom to get architecture done without worrying about breaking things?
Ged.
-----Original Message----- From: James Tabor [mailto:jimtabor.rosdev@gmail.com] Sent: 29 July 2009 18:30 To: ReactOS Development List Subject: Re: [ros-dev] Arwinss architecture
No, not even, not in the light of day, shall this ever be part of trunk!
Separate project maybe, perhaps or will be a new project altogether!
Leave our trunk alone and keep working on ArWinSS where it is or make it's own home on ReactOS.org.
I'm @ wk and had to comment on this, James
On Wed, Jul 29, 2009 at 6:38 AM, Gedgedmurphy@gmail.com wrote:
What people should also know is that if this branch ever does make it
into
trunk it will only be used as a temporary solution until the correct implementation is ready. This is by no means a permanent solution!
What it will do is act as a temp replacement which will hold things
together
and allow work on the real subsystem to accelerate.
At the moment the current subsystem must be kept stable as it's our main component and needs to stay regression free whilst rewriting major parts
to
make it more compatible. Not an easy task!
If the Arwinss model can take over for a while it will gives the win32 subsystem developers breathing space to rewrite / hack / break / fight / kill / molest and eventually improve the real implementation without worrying about breaking reactos for everyone else.
In the long run this may be a great solution to improve the compatibility and stability of the real reactos win32 subsystem.
Ged.
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Personally i like the idea of being able to access remotely using an X Server.. Could this feature be ported to current Win32k implementation after Arwinss is deprecated?
On Wed, Jul 29, 2009 at 8:42 PM, King InuYasha ngompa13@gmail.com wrote:
Makes sense. And once the real subsystems are compatible and stable enough, then the arwinss branch could be relegated to an addon. An addon that could be used on both ReactOS and Windows. It's a stopgap solution, but one that would have uses after it is replaced.
On Wed, Jul 29, 2009 at 1:10 PM, Ged gedmurphy@gmail.com wrote:
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.
If we have a drop in replacement which is much more compatible and stable then the current one, then I think it's wise to use that whilst the real implementation is continued alongside.
Surely this will give you the freedom to get architecture done without worrying about breaking things?
Ged.
-----Original Message----- From: James Tabor [mailto:jimtabor.rosdev@gmail.com] Sent: 29 July 2009 18:30 To: ReactOS Development List Subject: Re: [ros-dev] Arwinss architecture
No, not even, not in the light of day, shall this ever be part of trunk!
Separate project maybe, perhaps or will be a new project altogether!
Leave our trunk alone and keep working on ArWinSS where it is or make it's own home on ReactOS.org.
I'm @ wk and had to comment on this, James
On Wed, Jul 29, 2009 at 6:38 AM, Gedgedmurphy@gmail.com wrote:
What people should also know is that if this branch ever does make it
into
trunk it will only be used as a temporary solution until the correct implementation is ready. This is by no means a permanent solution!
What it will do is act as a temp replacement which will hold things
together
and allow work on the real subsystem to accelerate.
At the moment the current subsystem must be kept stable as it's our main component and needs to stay regression free whilst rewriting major parts
to
make it more compatible. Not an easy task!
If the Arwinss model can take over for a while it will gives the win32 subsystem developers breathing space to rewrite / hack / break / fight / kill / molest and eventually improve the real implementation without worrying about breaking reactos for everyone else.
In the long run this may be a great solution to improve the
compatibility
and stability of the real reactos win32 subsystem.
Ged.
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
On Wed, Jul 29, 2009 at 3:09 PM, Zachary Gordendrakekaizer666@gmail.com wrote:
Why would we need the X server for remote access if we have terminal services?
We don't have terminal services though. I mean we should of course, and I should also have a pony. I'm not saying it should go in trunk or not, just pointing out that its kind of a neat feature that has many uses. And besides, if you've ever tried to do rootless RDP to a Linux or Mac host, you would know it makes kittens cry...
Hello, I'm here to tell you about what the not-so-bright user thinks. I have been in contact with them.
They say "well...ReactOS is Linux, right?"
Because it's open source. I don't know who, but the world as we see it glued the idea of open-source to Linux. Any OS who is open source is somehow based on Linux.
Of course some people know that can't be 100% true. But these people are the users, the developers and the enthusiasts of these projects who are not based on Linux. It doesn't matter how many newsletters you write saying it's not Linux, or how many presentations at events you have, saying it's not Linux but aims to be a completely compatible Windows clone.
This is a major "security hole" for ReactOS. The moment someone says "well, now we're based on Wine until we can finish a proper implementation of our cloned-after-Windows subsystems," that's when these users will say "well, that's still Linux so I'll take Vista/XP/whatever Windows version, thank you very much." They know what Wine is (although many think it's an emulator) and they know that's Linux. No one can change their minds.
Meanwhile, this change sounds very helpful and useful. But this is probably why some developers are so against it.
Yes, maybe James Tabor is right - Download ReactOS Wine-based, Download ReactOS Windows-based (but if you write that, everyone will jump and say you copied Windows code after looking at the leaked sources). Release and Debug for each.
I'm sorry about this, but it's the way the users were fooled. And these people were Ubuntu users, very happy about it. One of them pointed out that *gasp* YOU HAVE MORE DESKTOPS, JUST LIKE IN LINUX!!! He was, of course, talking about the taskbar, where you can select which desktop you want to use.
So, whatever the decision, BE CAREFUL!!!
2009/7/29 Javier Agustìn Fernàndez Arroyo elhoir@gmail.com
Personally i like the idea of being able to access remotely using an X Server.. Could this feature be ported to current Win32k implementation after Arwinss is deprecated?
On Wed, Jul 29, 2009 at 8:42 PM, King InuYasha ngompa13@gmail.com wrote:
Makes sense. And once the real subsystems are compatible and stable enough, then the arwinss branch could be relegated to an addon. An addon that could be used on both ReactOS and Windows. It's a stopgap solution, but one that would have uses after it is replaced.
On Wed, Jul 29, 2009 at 1:10 PM, Ged gedmurphy@gmail.com wrote:
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.
If we have a drop in replacement which is much more compatible and stable then the current one, then I think it's wise to use that whilst the real implementation is continued alongside.
Surely this will give you the freedom to get architecture done without worrying about breaking things?
Ged.
-----Original Message----- From: James Tabor [mailto:jimtabor.rosdev@gmail.com] Sent: 29 July 2009 18:30 To: ReactOS Development List Subject: Re: [ros-dev] Arwinss architecture
No, not even, not in the light of day, shall this ever be part of trunk!
Separate project maybe, perhaps or will be a new project altogether!
Leave our trunk alone and keep working on ArWinSS where it is or make it's own home on ReactOS.org.
I'm @ wk and had to comment on this, James
On Wed, Jul 29, 2009 at 6:38 AM, Gedgedmurphy@gmail.com wrote:
What people should also know is that if this branch ever does make it
into
trunk it will only be used as a temporary solution until the correct implementation is ready. This is by no means a permanent solution!
What it will do is act as a temp replacement which will hold things
together
and allow work on the real subsystem to accelerate.
At the moment the current subsystem must be kept stable as it's our
main
component and needs to stay regression free whilst rewriting major
parts to
make it more compatible. Not an easy task!
If the Arwinss model can take over for a while it will gives the win32 subsystem developers breathing space to rewrite / hack / break / fight
/
kill / molest and eventually improve the real implementation without worrying about breaking reactos for everyone else.
In the long run this may be a great solution to improve the
compatibility
and stability of the real reactos win32 subsystem.
Ged.
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
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, Gedgedmurphy@gmail.com wrote:
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.
If we have a drop in replacement which is much more compatible and stable then the current one, then I think it's wise to use that whilst the real implementation is continued alongside.
Surely this will give you the freedom to get architecture done without worrying about breaking things?
Ged.
Read all of my previous emails, so I do not have to paint this again.... James
On Jul 30, 2009, at 12:49 AM, James Tabor wrote:
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, Gedgedmurphy@gmail.com wrote:
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.
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).
If we have a drop in replacement which is much more compatible and stable then the current one, then I think it's wise to use that whilst the real implementation is continued alongside.
Surely this will give you the freedom to get architecture done without worrying about breaking things?
Ged.
Read all of my previous emails, so I do not have to paint this again.... James
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.
WBR, Aleksey Bragin.
Arwinss resembles the NT3/Vista/7 architecture for Win32k, while the implementation that some people are saying is "right" is more in line with the NT4-WinXP. In the strictest sense of the definition, both arwinss and the current default implementation styles are "correct." Both implementations work and allow Windows NT drivers to work with it, so that's not the problem. It also adds in RDP-esque support through X, which is pretty cool too. I guess some of these people don't like Wine code. The problem with that is that without Wine code, ReactOS would probably take ten times as long to actually get to a usable state. Using Wine code for win32k seems to cross some sort of line for them. I heard some of them saying the Wine code for win32k is "ugly." What does ugliness have to do with it? Being able to share more with Wine saves a lot of hard work from ReactOS devs. They can focus more on bringing the NT kernel up to scratch, rather than spending more time with the Win32k code. They could even work on adding in other subsystems, if they wanted to.
On Thu, Jul 30, 2009 at 3:25 AM, Aleksey Bragin aleksey@reactos.org wrote:
On Jul 30, 2009, at 12:49 AM, James Tabor wrote:
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, Gedgedmurphy@gmail.com wrote:
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.
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).
If we have a drop in replacement which is much more compatible and stable then the current one, then I think it's wise to use that whilst the real implementation is continued alongside.
Surely this will give you the freedom to get architecture done without worrying about breaking things?
Ged.
Read all of my previous emails, so I do not have to paint this again.... James
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.
WBR, Aleksey Bragin.
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
King InuYasha schrieb:
Arwinss resembles the NT3/Vista/7 architecture for Win32k, while the implementation that some people are saying is "right" is more in line with the NT4-WinXP.
You obviously have no clue what you're talking about. arwinss has no more in common with NT3 or Vista/7 than with NT4/XP/2003 architecture. Also Vista/Win7 architecture is following XP/2003 architecture much more than NT3.
In the strictest sense of the definition, both arwinss and the current default implementation styles are "correct." Both implementations work and allow Windows NT drivers to work with it, so that's not the problem. It also adds in RDP-esque support through X, which is pretty cool too. I guess some of these people don't like Wine code. The problem with that is that without Wine code, ReactOS would probably take ten times as long to actually get to a usable state.
That's just bs. The win32 subsystem has a bunch of bugs yes, but don't expect them to go away by using more wine code.
Using Wine code for win32k seems to cross some sort of line for them. I heard some of them saying the Wine code for win32k is "ugly."
When you talk about "them" and "these people" you talk about us, don't you? It's win32k devs you talk about, right? If you can do the coding for us, ...
What does ugliness have to do with it? Being able to share more with Wine saves a lot of hard work from ReactOS devs. They can focus more on bringing the NT kernel up to scratch, rather than spending more time with the Win32k code.
And this is exactly what is *not* happening. Aleksey currentlty spends his time with this win32k rewrite instead of something useful, like fixing the kernel or fixing the real win32k or fixing fat or usb or porting reactos to mips.
They could even work on adding in other subsystems, if they wanted to.
Yes everyone is free to code what he likes, it just won't lead us anywhere.
Sorry for sounding rude, but I just hate when people with no understanding about the topic are spreading misinformation.
Thanks, Timo
I love you.
On Thu, Jul 30, 2009 at 10:00 AM, Timo Kreuzer timo.kreuzer@web.de wrote:
King InuYasha schrieb:
Arwinss resembles the NT3/Vista/7 architecture for Win32k, while the implementation that some people are saying is "right" is more in line
with
the NT4-WinXP.
You obviously have no clue what you're talking about. arwinss has no more in common with NT3 or Vista/7 than with NT4/XP/2003 architecture. Also Vista/Win7 architecture is following XP/2003 architecture much more than NT3.
In the strictest sense of the definition, both arwinss and the current default implementation styles are "correct." Both implementations work and allow Windows NT drivers to work with it, so
that's
not the problem. It also adds in RDP-esque support through X, which is pretty cool too. I guess some of these people don't like Wine code. The problem with that
is
that without Wine code, ReactOS would probably take ten times as long to actually get to a usable state.
That's just bs. The win32 subsystem has a bunch of bugs yes, but don't expect them to go away by using more wine code.
Using Wine code for win32k seems to cross some sort of line for them. I heard some of them saying the Wine code for win32k is "ugly."
When you talk about "them" and "these people" you talk about us, don't you? It's win32k devs you talk about, right? If you can do the coding for us, ...
What does ugliness have to do with it? Being able to share more with Wine saves a lot of hard work from ReactOS devs. They can focus more on bringing the NT kernel up to scratch, rather than spending more
time
with the Win32k code.
And this is exactly what is *not* happening. Aleksey currentlty spends his time with this win32k rewrite instead of something useful, like fixing the kernel or fixing the real win32k or fixing fat or usb or porting reactos to mips.
They could even work on adding in other subsystems, if they wanted to.
Yes everyone is free to code what he likes, it just won't lead us anywhere.
Sorry for sounding rude, but I just hate when people with no understanding about the topic are spreading misinformation.
Thanks, Timo
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
What you guys need is some way to convince the ARM Ninjas that rewriting the memory manager won't make the ARM port easier -- but that rewriting win32k/gdi32/user32 will! Best regards, Alex Ionescu
On Thu, Jul 30, 2009 at 1:32 PM, Samuel serapion samdwise51@gmail.comwrote:
I love you.
On Thu, Jul 30, 2009 at 10:00 AM, Timo Kreuzer timo.kreuzer@web.dewrote:
King InuYasha schrieb:
Arwinss resembles the NT3/Vista/7 architecture for Win32k, while the implementation that some people are saying is "right" is more in line
with
the NT4-WinXP.
You obviously have no clue what you're talking about. arwinss has no more in common with NT3 or Vista/7 than with NT4/XP/2003 architecture. Also Vista/Win7 architecture is following XP/2003 architecture much more than NT3.
In the strictest sense of the definition, both arwinss and the current default implementation styles are "correct." Both implementations work and allow Windows NT drivers to work with it, so
that's
not the problem. It also adds in RDP-esque support through X, which is pretty cool too. I guess some of these people don't like Wine code. The problem with that
is
that without Wine code, ReactOS would probably take ten times as long to actually get to a usable state.
That's just bs. The win32 subsystem has a bunch of bugs yes, but don't expect them to go away by using more wine code.
Using Wine code for win32k seems to cross some sort of line for them. I heard some of them saying the Wine code
for
win32k is "ugly."
When you talk about "them" and "these people" you talk about us, don't you? It's win32k devs you talk about, right? If you can do the coding for us, ...
What does ugliness have to do with it? Being able to share more with Wine saves a lot of hard work from ReactOS devs. They can
focus
more on bringing the NT kernel up to scratch, rather than spending more
time
with the Win32k code.
And this is exactly what is *not* happening. Aleksey currentlty spends his time with this win32k rewrite instead of something useful, like fixing the kernel or fixing the real win32k or fixing fat or usb or porting reactos to mips.
They could even work on adding in other subsystems, if they wanted to.
Yes everyone is free to code what he likes, it just won't lead us anywhere.
Sorry for sounding rude, but I just hate when people with no understanding about the topic are spreading misinformation.
Thanks, Timo
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Hi!
On Thu, Jul 30, 2009 at 7:51 AM, King InuYashangompa13@gmail.com wrote:
Arwinss resembles the NT3/Vista/7 architecture for Win32k, while the implementation that some people are saying is "right" is more in line with the NT4-WinXP. In the strictest sense of the definition, both arwinss and the current default implementation styles are "correct." Both implementations work and allow Windows NT drivers to work with it, so that's not the problem. It also adds in RDP-esque support through X, which is pretty cool too.
Nothing close at all~ We have a list of books for you to read, media/doc/books.txt, but that list looks very short, someone removed some book about win32k in there.....
I guess some of these people don't like Wine code. The problem with that is that without Wine code, ReactOS would probably take ten times as long to actually get to a usable state. Using Wine code for win32k seems to cross some sort of line for them. I heard some of them saying the Wine code for win32k is "ugly." What does ugliness have to do with it? Being able to share more with Wine saves a lot of hard work from ReactOS devs. They can focus more on bringing the NT kernel up to scratch, rather than spending more time with the Win32k code. They could even work on adding in other subsystems, if they wanted to.
Do some research with our project, go back and read our emails and correlate them with our commit logs to get a more precise picture on what happen and why and where. Understanding our history will help you understand where we are today. Thanks, James
Aleksey Bragin schrieb:
On Jul 30, 2009, at 12:49 AM, James Tabor wrote:
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, Gedgedmurphy@gmail.com wrote:
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.
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).
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.
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
2009/7/30 Timo Kreuzer timo.kreuzer@web.de:
Aleksey Bragin schrieb:
On Jul 30, 2009, at 12:49 AM, James Tabor wrote:
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, Gedgedmurphy@gmail.com wrote:
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.
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).
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.
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.
FYI, SMWP has started, once I get menu/item converted after class/windows.
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
I agree! If anyone (Also the Orig Devs) bothered to do the proper research and read the books published and some are available online, you will "GET IT". I wrote this into the code so anyone with good programming skills can pick this up. Read my code it's there and it's getting better since we started placing comments in there. Reason, some do not know how to read music.
The only way a nebie can get their feet wet is to dig into the code and read. Hooking a wire to your head at night will not help you "GET IT".
Class work: Kernel space and User space, why? Compare the number of callbacks, advantages and disadvantages, why ReactOS is faster in this relation. James
Hi,
On Thu, Jul 30, 2009 at 3:25 AM, Aleksey Braginaleksey@reactos.org wrote:
On Jul 30, 2009, at 12:49 AM, James Tabor wrote:
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, Gedgedmurphy@gmail.com wrote:
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.
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).
LOL, which Alex, the one I know, knows the rewrite already started back in 2006. Yes I know about breakage, and I wish someone will bring up the fact about the whole rewrite work I started and how it moved the project past a level of a hacky POS. Including the other developers that had time to KILL working on win32k. I guess in this instance we can not complain about coding styles or bad grammar.
If we have a drop in replacement which is much more compatible and stable then the current one, then I think it's wise to use that whilst the real implementation is continued alongside.
Surely this will give you the freedom to get architecture done without worrying about breaking things?
Ged.
Read all of my previous emails, so I do not have to paint this again.... James
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.
Paint is already drying, if you haven't noticed.
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.
WBR, Aleksey Bragin.
I'm to busy working on real problems right now to sit here a write a book for you when you should have been reading all the commit logs in the first place. FYI, I'm fixing windowing class issues, if you did not notice..... Small fixes have been known to fix big problems. Read the logs.
In away, I'm still a part time body builder, but now days it's for heath reasons. If you start lifting heavy weights with arms and legs first with out building up your back, what is going to happen when you start deadlifting? You are going to blow your back out!
Stay out of ReactOS! Go ahead and work on ArWinSS, James
LOL!
On Thu, Jul 30, 2009 at 10:37 AM, Aleksey Braginaleksey@reactos.org wrote:
Stay out of ReactOS! Go ahead and work on ArWinSS, James
Man, why so scared? :) Arwinss doesn't even run Firefox2 yet and everyone went crazy.
I'm getting PM'ed out the ass! I'm not the one scared, you scared everyone else! The impression is, we are replacing our win32k system with something else.
So far Timo provided an extensive answer to my questions, thanks.
WBR, Aleksey Bragin.
Read my email closer, you have your class assignment, no less than 10 pages too....... papers are due in December so you have more than enough time. James
On Jul 30, 2009, at 8:03 PM, James Tabor wrote:
LOL!
On Thu, Jul 30, 2009 at 10:37 AM, Aleksey Braginaleksey@reactos.org wrote:
Stay out of ReactOS! Go ahead and work on ArWinSS, James
Man, why so scared? :) Arwinss doesn't even run Firefox2 yet and everyone went crazy.
I'm getting PM'ed out the ass! I'm not the one scared, you scared everyone else! The impression is, we are replacing our win32k system with something else.
Obviously we aren't! It just can't happen without approval of other developers, so don't panic. Everything is under control.
WBR, Aleksey Bragin.
How much time do you need to make existing trunk's win32 subsystem to have at least Wine's compatibility and usability level? I'm speaking of gdi32/user32/win32k mostly, don't account other parts for now.
On Jul 30, 2009, at 8:03 PM, James Tabor wrote:
LOL!
On Thu, Jul 30, 2009 at 10:37 AM, Aleksey Braginaleksey@reactos.org wrote:
Stay out of ReactOS! Go ahead and work on ArWinSS, James
Man, why so scared? :) Arwinss doesn't even run Firefox2 yet and everyone went crazy.
I'm getting PM'ed out the ass! I'm not the one scared, you scared everyone else! The impression is, we are replacing our win32k system with something else.
So far Timo provided an extensive answer to my questions, thanks.
WBR, Aleksey Bragin.
Read my email closer, you have your class assignment, no less than 10 pages too....... papers are due in December so you have more than enough time. James
-
Aleksey Bragin -
Alex Ionescu -
Alexandru Lovin -
Brian -
Ged -
James Tabor -
Javier Agustìn Fernàndez Arroyo -
King InuYasha -
Samuel serapion -
Steven Edwards -
Timo Kreuzer -
Zachary Gorden