20 Jul
2009
20 Jul
'09
10:16 a.m.
Hello,
I've heard many question about a branch I was working on recently,
arwinss, so I'd like to write some explanation (you may skip the
boring history part of the message)
Arwinss is a rewrite (the most advanced so far out of all previous
attempts) of some parts of the Win32 subsystem, namely the USER32 and
GDI32 API interfaces, along with the kernel counterpart win32k.sys.
The kernel32.dll, csrss, and other parts remain in their present
condition, and getting bugfixes if they come in the way of a rewrite.
[History and reasoning part starts here]
Why rewrite and not fix an existing Win32 subsystem? Timo, James and
all our other great developers were and are doing a great work. I put
a considerable amount of time in it to fix problems too. But, since
our project is a volunteer-driven one, everyone has a real life, real
work to do, and is not able to sit 24 hrs researching Windows
internal structures, inventing new algorithms, trying out thousands
of applications, not to say about graphics drivers.
Time is ticking, Win32 is improving, but most annoying bugs are there
for years - e.g. vmware installer hang, Firefox move the mouse bug,
drawing glitches, concurrency hacks in the code ("if (!a) /* someone
else was faster than us and already freed it */"), probable heap
misusage (relying on our heap implementation for desktop heaps) and
heap memory corruptions (I kept trying to update rtl/heaps to the
newest Wine code - and always failed without any obvious reason),
inability to change video mode on the fly, and the list can go on.
So I thought, that something should be done with it. I would even
want to trade off some speed gain in favor of stability (optimizing
is an enjoyable task which could be done later).
After teaming up with Stefan, we created an nwin32 branch - a totally
stubbed out win23k, user32 and gdi32. They had exactly matched
exports, and win32k had exactly same system calls and Windows 2003
SP1's win32k.sys.
However, due to really huge amount of work, the branch didn't went
farther than trying to boot Windows 2003 with it and see a few
stubbed functions being called.
Since then I started thinking on an alternative design of a Win32
subsystem. The idea turned out to be very simple, and is based on the
following questions:
- Why put so much effort into keeping the internal win32k system
calls interface the same as in Windows, why put so much effort in
converting to internal Windows structures, if we don't have something
working first?
- Why base on a stoneage Wine's code which James and Christoph
occasionally sync, and all my attempts to get more people into this
boring task failed?
- Why not use achievements of our closest project - Wine?
[End of reasoning, fancy stuff starts]
The result came by itself: Try to build up a win32 subsystem based as
much on Wine code as possible, and using Wine's modular design.
Before publicly announcing it, I have spent a month actually trying
all that stuff, and surprisingly it went very well, and a nice
byproduct: support of remote sessions via X Windows.
Proof of concept screenshots are here:
http://www.reactos.org/media/screenshots/2009/arw_xlog1.jpg
http://www.reactos.org/media/screenshots/2009/arw_xlog1.jpg
Noone has ever done this before: This is Windows 2003 inside VMware,
running my custom Win32 subsystem, with an X graphics driver module,
communicating with an X Server running in the host OS (Windows XP,
XMing X windows server), and with ReactOS's winlogon.exe and
msgina.dll (for ease of debugging and source code availability)!
Let's go straight to the architecture:
GDI32.dll and USER32.dll are ported Wine usermode code, with very few
modifications. GDI32 and USER32 depend on two things: Gdi and User
driver, and a server.
Gdi and User driver is a loadable DLL, which provides an abstraction
of a graphics driver in the system through a certain set of APIs. A
typical example of such a driver is winex11.drv, which routes all
drawing to the X Windows "client". However, this is not very useful
for a local system which has a Windows NT architecture, where there
is no need for remote windows displaying.
The server. GDI32 and USER32 rely on the server for managing all
global information. In Wine, the server is run as a usermode
wineserver.exe process, which communicates with gdi32/user32 via
custom RPC, and emulates quite a lof of stuff which Windows NT kernel
provides by default. My decision was to convert the RPC protocol from
a slow interprocess filedescriptors-based unix-specific invocations
to a fast system calls to win32k module. This way, win32k contains
small part (~300 kb vs 1.5Mb+) of wineserver's source code, which
deals with windows, window classes, atoms, windows stations, desktops
and other totally platform/implementation independent stuff. It will
be reduced further, because I even ported their own object manager
for win32 objects, which will be exchange to our native ntoskrnl's
object manager soon, when the testing phase is over.
The graphics driver, kernelmode part. As I said above, it's not very
convinient to fully rely on X Windows for graphics output, because
it's just not possible to run it in an NT-based OS which has no Win32
subsystem. Thus, I decided to create a totally native gdi/user driver
("winent.drv"), which would rely on win32k module to actually perform
all drawing. However, compared to our current implementation, the
drawing would be way more simple. For example, if currently LineTo
operation in win32k involves complex PATHOBJ, maintaining graphics
cursor -- all of that in a strictly windows compatible way because
apps depend on it, in this alternative win32k, LineTo is a simple
line drawing function: RosGdiLineTo(pDc, x1, y1, x2, y2). Same
applies to other functions, including e.g. text output, where all
rendering happens using a usermode freetype.dll, and win32k just
needs to display bitmap glyphs got from gdi32.
Don't be scared if you don't understand all that right away. I will
put up a good short summary, along with a TODO and FIXME lists, and a
HACKING guide.
Just a few cool facts about the new win32 subsystem:
- Based on a solid, very well maintained codebase, used by commercial
vendors.
- Ease of updating from upstream (vendor importing)
- Tested against more than 12 000 Windows applications (http://
appdb.winehq.org)
- ...
I think it's enough for the first introduction.
WBR,
Aleksey Bragin.
20 Jul
20 Jul
10:49 a.m.
"support of remote sessions via X Windows"
what the....
Does it mean some GUI Linux apps would be able to run into ROS with that new
Win32 subsystem??
On Mon, Jul 20, 2009 at 12:16 PM, Aleksey Bragin <aleksey(a)reactos.org>wrote;wrote:
Hello,
I've heard many question about a branch I was working on recently,
arwinss, so I'd like to write some explanation (you may skip the
boring history part of the message)
Arwinss is a rewrite (the most advanced so far out of all previous
attempts) of some parts of the Win32 subsystem, namely the USER32 and
GDI32 API interfaces, along with the kernel counterpart win32k.sys.
The kernel32.dll, csrss, and other parts remain in their present
condition, and getting bugfixes if they come in the way of a rewrite.
[History and reasoning part starts here]
Why rewrite and not fix an existing Win32 subsystem? Timo, James and
all our other great developers were and are doing a great work. I put
a considerable amount of time in it to fix problems too. But, since
our project is a volunteer-driven one, everyone has a real life, real
work to do, and is not able to sit 24 hrs researching Windows
internal structures, inventing new algorithms, trying out thousands
of applications, not to say about graphics drivers.
Time is ticking, Win32 is improving, but most annoying bugs are there
for years - e.g. vmware installer hang, Firefox move the mouse bug,
drawing glitches, concurrency hacks in the code ("if (!a) /* someone
else was faster than us and already freed it */"), probable heap
misusage (relying on our heap implementation for desktop heaps) and
heap memory corruptions (I kept trying to update rtl/heaps to the
newest Wine code - and always failed without any obvious reason),
inability to change video mode on the fly, and the list can go on.
So I thought, that something should be done with it. I would even
want to trade off some speed gain in favor of stability (optimizing
is an enjoyable task which could be done later).
After teaming up with Stefan, we created an nwin32 branch - a totally
stubbed out win23k, user32 and gdi32. They had exactly matched
exports, and win32k had exactly same system calls and Windows 2003
SP1's win32k.sys.
However, due to really huge amount of work, the branch didn't went
farther than trying to boot Windows 2003 with it and see a few
stubbed functions being called.
Since then I started thinking on an alternative design of a Win32
subsystem. The idea turned out to be very simple, and is based on the
following questions:
- Why put so much effort into keeping the internal win32k system
calls interface the same as in Windows, why put so much effort in
converting to internal Windows structures, if we don't have something
working first?
- Why base on a stoneage Wine's code which James and Christoph
occasionally sync, and all my attempts to get more people into this
boring task failed?
- Why not use achievements of our closest project - Wine?
[End of reasoning, fancy stuff starts]
The result came by itself: Try to build up a win32 subsystem based as
much on Wine code as possible, and using Wine's modular design.
Before publicly announcing it, I have spent a month actually trying
all that stuff, and surprisingly it went very well, and a nice
byproduct: support of remote sessions via X Windows.
Proof of concept screenshots are here:
http://www.reactos.org/media/screenshots/2009/arw_xlog1.jpg
http://www.reactos.org/media/screenshots/2009/arw_xlog1.jpg
Noone has ever done this before: This is Windows 2003 inside VMware,
running my custom Win32 subsystem, with an X graphics driver module,
communicating with an X Server running in the host OS (Windows XP,
XMing X windows server), and with ReactOS's winlogon.exe and
msgina.dll (for ease of debugging and source code availability)!
Let's go straight to the architecture:
GDI32.dll and USER32.dll are ported Wine usermode code, with very few
modifications. GDI32 and USER32 depend on two things: Gdi and User
driver, and a server.
Gdi and User driver is a loadable DLL, which provides an abstraction
of a graphics driver in the system through a certain set of APIs. A
typical example of such a driver is winex11.drv, which routes all
drawing to the X Windows "client". However, this is not very useful
for a local system which has a Windows NT architecture, where there
is no need for remote windows displaying.
The server. GDI32 and USER32 rely on the server for managing all
global information. In Wine, the server is run as a usermode
wineserver.exe process, which communicates with gdi32/user32 via
custom RPC, and emulates quite a lof of stuff which Windows NT kernel
provides by default. My decision was to convert the RPC protocol from
a slow interprocess filedescriptors-based unix-specific invocations
to a fast system calls to win32k module. This way, win32k contains
small part (~300 kb vs 1.5Mb+) of wineserver's source code, which
deals with windows, window classes, atoms, windows stations, desktops
and other totally platform/implementation independent stuff. It will
be reduced further, because I even ported their own object manager
for win32 objects, which will be exchange to our native ntoskrnl's
object manager soon, when the testing phase is over.
The graphics driver, kernelmode part. As I said above, it's not very
convinient to fully rely on X Windows for graphics output, because
it's just not possible to run it in an NT-based OS which has no Win32
subsystem. Thus, I decided to create a totally native gdi/user driver
("winent.drv"), which would rely on win32k module to actually perform
all drawing. However, compared to our current implementation, the
drawing would be way more simple. For example, if currently LineTo
operation in win32k involves complex PATHOBJ, maintaining graphics
cursor -- all of that in a strictly windows compatible way because
apps depend on it, in this alternative win32k, LineTo is a simple
line drawing function: RosGdiLineTo(pDc, x1, y1, x2, y2). Same
applies to other functions, including e.g. text output, where all
rendering happens using a usermode freetype.dll, and win32k just
needs to display bitmap glyphs got from gdi32.
Don't be scared if you don't understand all that right away. I will
put up a good short summary, along with a TODO and FIXME lists, and a
HACKING guide.
Just a few cool facts about the new win32 subsystem:
- Based on a solid, very well maintained codebase, used by commercial
vendors.
- Ease of updating from upstream (vendor importing)
- Tested against more than 12 000 Windows applications (http://
appdb.winehq.org)
- ...
I think it's enough for the first introduction.
WBR,
Aleksey Bragin.
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
1:15 p.m.
2009/7/20 Javier Agustìn Fernàndez Arroyo <elhoir(a)gmail.com>om>:
"support of remote sessions via X Windows"
what the....
Does it mean some GUI Linux apps would be able to run into ROS with that new
Win32 subsystem??
No. It means that if we get things like Microsoft Office working under
ReactOS then it will be able to seamlessly display to any client
running a X server. Linux, Solaris, Mac OS X, Windows with Xming, etc.
The immediate commercial applications should be apparent. Combine
ReactOS with a Hypervisor subsystem such as Xen and KVM and you have
the makings of a true Windows subsystem. Think VMware Fusion or
Parallels Coherency but with remote DISPLAY support, etc.
Thanks
--
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
1:31 p.m.
On Mon, Jul 20, 2009 at 8:15 AM, Steven Edwards <winehacker(a)gmail.com>wrote;wrote:
2009/7/20 Javier Agustìn Fernàndez Arroyo
<elhoir(a)gmail.com>om>:
Would it also mean that an X11 API library could be plugged in so that X
based applications can be more easily ported to Windows/ReactOS while still
providing the transparency to view on another machine through X11 protocol?
"support of remote sessions via X
Windows"
what the....
Does it mean some GUI Linux apps would be able to run into ROS with that
new
Win32 subsystem??
No. It means that if we get things like Microsoft Office working under
ReactOS then it will be able to seamlessly display to any client
running a X server. Linux, Solaris, Mac OS X, Windows with Xming, etc.
The immediate commercial applications should be apparent. Combine
ReactOS with a Hypervisor subsystem such as Xen and KVM and you have
the makings of a true Windows subsystem. Think VMware Fusion or
Parallels Coherency but with remote DISPLAY support, etc.
Thanks
--
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
2:09 p.m.
On Mon, Jul 20, 2009 at 9:31 AM, King InuYasha<ngompa13(a)gmail.com> wrote:
Would it also mean that an X11 API library could be
plugged in so that X
based applications can be more easily ported to Windows/ReactOS while still
providing the transparency to view on another machine through X11 protocol?
Such a library already exists. Google for libX11. It is used for the
rxvt port in Mingw and Cygwin. It simply maps the X11 api to mostly
equivalent Win32 calls. In the ancient past I built a gtk that linked
to it.
--
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
2:09 p.m.
On Mon, Jul 20, 2009 at 10:09 AM, Steven Edwards<winehacker(a)gmail.com> wrote:
Such a library already exists. Google for libX11. It
is used for the
rxvt port in Mingw and Cygwin. It simply maps the X11 api to mostly
equivalent Win32 calls. In the ancient past I built a gtk that linked
to it.
Sorry I mean't libW11
--
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
2:58 p.m.
Hi,
Some people might have already noticed that I have a "strong opinion"
regarding this rewrite. So let me explain my point of view here.
Aleksey, thanks for clarification and confirming a lot of what I already
thought. I hope you don't feel offended (at least not more than I was,
when browsing through your recent commits ;-))
I totally agree that we have a very limited number of devs and it takes
quite some time to get the stuff in the win32 subsystem done.
Anyway the "lets just use wine" shortcut won't work.
Any developer who has ever done any serious work on our win32 subsystem
might actually feel offended by this rewrite. It basically says: "Hey,
all your stupid attempts to remove the hacks and to make the win32
subsytem work more like Windows and less like crap, were totally a waste
of time. You should have instead better written a bunch more hacks
around the hacks to make all the wine code work".
Well, that's what we did long time ago, when the goal was "Get stuff
done now, fix bugs later" and that's what got us all the problems in the
first place. But we are past this stage since quite some time now. "No
more hacks!" that's the current deal. We have invested a great amount of
time into testing native api, using the Windows structures, fixing the
gdi handle manager, etc. What for? Doing it like windows does, means
100% chance that the approach will work, if properly implemented, it
allows better testing and analyzation and it helps to keep developers
from doing bs. Doing it like wine or inventing "new standards" will with
a chance of 50% result in great fail, as can be seen over and over again
in win32k.
Wine emulates the kernel through a server. Of cause we don't use it,
because it has a totally different design. We have an NT kernel and
every kernel developer would eat me alive if I tried to put a single
line of wine code into our kernel. It's considered crap there.
Well, Wine also emulates the win32 subsystem though a server. Again the
design isn't anywhere near the real win32 design. And yet you want to
use it? Be prepared to get eaten alive by a win32 developer when you try
to get anything like that into trunk. (I consider it as crap there!)
Fixing issues?
The idea that this rewrite could instantly fix all the issues, because
it works on wine, is a fancy idea. But it won't work. Wine is designed
to work on linux/X11 not on NT and that will come back at you sooner or
later. Also the fact that it was tested with thousands of apps doesn't
mean it works correctly. How do you expect stuff like mode switching to
magically start working when there's no wine code that calls a display
driver to do the job? How do you expect display drivers to work at all?
More hacks on top of the huge pile of hacks? And how do you deal with
missing functionality in wine code? Shove more code in there? Or ignore
it, like if wine doesn't need it, we also don't need it? Or again fork
the code?
Optimization later?
You cannot simply "optimize later". It never works that way. A decent
design is a precondition to optimization. Wine code, which is in this
case designed as a workaround (hack) can never be optimized.
Conclusion:
This rewrite does IMO not have any merit. It will at most create an
ugly, slow something with a ridiculous design.
If it's only some kind of sick joke somewhere between "The price is
right" and the developers edition of "How low can you go", and you
committed it only to share your fun, then.. well, go ahead, make me
laugh, too.
If you actually considered merging it, ... Only over my dead body!
If you want to use more wine code, install linux and wine. You can even
put a new logo on it and sell that if you want money. But keep it out of
our core components.
Also, instead of complaining about old bugs in the win32 subsystem, you
should better take a look at the kernel. Man, there's more than enough
work todo. What about cc? What about fastfat? What about 3rd party
filesystems? What about implementing MmSecureVirtualMemory? What about
usb? What about smp? No, I'm not suggesting to use a linux kernel,
because it works stable since ages and has all the stuff we don't have...
Finishing with a recursive acronym "Wine is not enough!"
Regards,
Timo
Aleksey Bragin wrote:
Hello,
I've heard many question about a branch I was working on recently,
arwinss, so I'd like to write some explanation (you may skip the
boring history part of the message)
Arwinss is a rewrite (the most advanced so far out of all previous
attempts) of some parts of the Win32 subsystem, namely the USER32 and
GDI32 API interfaces, along with the kernel counterpart win32k.sys.
The kernel32.dll, csrss, and other parts remain in their present
condition, and getting bugfixes if they come in the way of a rewrite.
[History and reasoning part starts here]
Why rewrite and not fix an existing Win32 subsystem? Timo, James and
all our other great developers were and are doing a great work. I put
a considerable amount of time in it to fix problems too. But, since
our project is a volunteer-driven one, everyone has a real life, real
work to do, and is not able to sit 24 hrs researching Windows
internal structures, inventing new algorithms, trying out thousands
of applications, not to say about graphics drivers.
Time is ticking, Win32 is improving, but most annoying bugs are there
for years - e.g. vmware installer hang, Firefox move the mouse bug,
drawing glitches, concurrency hacks in the code ("if (!a) /* someone
else was faster than us and already freed it */"), probable heap
misusage (relying on our heap implementation for desktop heaps) and
heap memory corruptions (I kept trying to update rtl/heaps to the
newest Wine code - and always failed without any obvious reason),
inability to change video mode on the fly, and the list can go on.
So I thought, that something should be done with it. I would even
want to trade off some speed gain in favor of stability (optimizing
is an enjoyable task which could be done later).
After teaming up with Stefan, we created an nwin32 branch - a totally
stubbed out win23k, user32 and gdi32. They had exactly matched
exports, and win32k had exactly same system calls and Windows 2003
SP1's win32k.sys.
However, due to really huge amount of work, the branch didn't went
farther than trying to boot Windows 2003 with it and see a few
stubbed functions being called.
Since then I started thinking on an alternative design of a Win32
subsystem. The idea turned out to be very simple, and is based on the
following questions:
- Why put so much effort into keeping the internal win32k system
calls interface the same as in Windows, why put so much effort in
converting to internal Windows structures, if we don't have something
working first?
- Why base on a stoneage Wine's code which James and Christoph
occasionally sync, and all my attempts to get more people into this
boring task failed?
- Why not use achievements of our closest project - Wine?
[End of reasoning, fancy stuff starts]
The result came by itself: Try to build up a win32 subsystem based as
much on Wine code as possible, and using Wine's modular design.
Before publicly announcing it, I have spent a month actually trying
all that stuff, and surprisingly it went very well, and a nice
byproduct: support of remote sessions via X Windows.
Proof of concept screenshots are here:
http://www.reactos.org/media/screenshots/2009/arw_xlog1.jpg
http://www.reactos.org/media/screenshots/2009/arw_xlog1.jpg
Noone has ever done this before: This is Windows 2003 inside VMware,
running my custom Win32 subsystem, with an X graphics driver module,
communicating with an X Server running in the host OS (Windows XP,
XMing X windows server), and with ReactOS's winlogon.exe and
msgina.dll (for ease of debugging and source code availability)!
Let's go straight to the architecture:
GDI32.dll and USER32.dll are ported Wine usermode code, with very few
modifications. GDI32 and USER32 depend on two things: Gdi and User
driver, and a server.
Gdi and User driver is a loadable DLL, which provides an abstraction
of a graphics driver in the system through a certain set of APIs. A
typical example of such a driver is winex11.drv, which routes all
drawing to the X Windows "client". However, this is not very useful
for a local system which has a Windows NT architecture, where there
is no need for remote windows displaying.
The server. GDI32 and USER32 rely on the server for managing all
global information. In Wine, the server is run as a usermode
wineserver.exe process, which communicates with gdi32/user32 via
custom RPC, and emulates quite a lof of stuff which Windows NT kernel
provides by default. My decision was to convert the RPC protocol from
a slow interprocess filedescriptors-based unix-specific invocations
to a fast system calls to win32k module. This way, win32k contains
small part (~300 kb vs 1.5Mb+) of wineserver's source code, which
deals with windows, window classes, atoms, windows stations, desktops
and other totally platform/implementation independent stuff. It will
be reduced further, because I even ported their own object manager
for win32 objects, which will be exchange to our native ntoskrnl's
object manager soon, when the testing phase is over.
The graphics driver, kernelmode part. As I said above, it's not very
convinient to fully rely on X Windows for graphics output, because
it's just not possible to run it in an NT-based OS which has no Win32
subsystem. Thus, I decided to create a totally native gdi/user driver
("winent.drv"), which would rely on win32k module to actually perform
all drawing. However, compared to our current implementation, the
drawing would be way more simple. For example, if currently LineTo
operation in win32k involves complex PATHOBJ, maintaining graphics
cursor -- all of that in a strictly windows compatible way because
apps depend on it, in this alternative win32k, LineTo is a simple
line drawing function: RosGdiLineTo(pDc, x1, y1, x2, y2). Same
applies to other functions, including e.g. text output, where all
rendering happens using a usermode freetype.dll, and win32k just
needs to display bitmap glyphs got from gdi32.
Don't be scared if you don't understand all that right away. I will
put up a good short summary, along with a TODO and FIXME lists, and a
HACKING guide.
Just a few cool facts about the new win32 subsystem:
- Based on a solid, very well maintained codebase, used by commercial
vendors.
- Ease of updating from upstream (vendor importing)
- Tested against more than 12 000 Windows applications (http://
appdb.winehq.org)
- ...
I think it's enough for the first introduction.
WBR,
Aleksey Bragin.
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
3:47 p.m.
Timo Kreuzer wrote:
Wine emulates the kernel through a server. Of cause we
don't use it,
because it has a totally different design.
Says who? So far, and only counting official implementations, Win32 has
been implemented as:
- a shared-memory user mode subsystem (Windows 95, 98)
- a RPC user mode subsystem (Windows NT 3)
- a kernel mode subsystem (Windows NT 4 and later)
- ??? (Windows CE)
We have an NT kernel and
every kernel developer would eat me alive if I tried to put a single
line of wine code into our kernel. It's considered crap there.
Wine code has to pass quality reviews and test suites. ReactOS code only
has to pass the warmth-and-fuzziness test. Wine can prove their code is
right, ReactOS is based on code that feels right
The idea that Wine code is better than ReactOS code really needs to die.
Compared to theirs, our code is sloppy, highly unprofessional and often
inexplicable. We copy the form but tend to completely miss the intent.
Wine development is test-driven and entirely based on intent and end
results, while our development model is, apparently, to dick around in
our spare time pretending we work at Microsoft
How do you expect display drivers to work at all?
NT display drivers used to run in user mode with the same identical API,
and probably the same ABI. I'm sure Aleksey will do just fine
More hacks on top of the huge pile of hacks? And how
do you deal with
missing functionality in wine code? Shove more code in there? Or ignore
it, like if wine doesn't need it, we also don't need it? Or again fork
the code?
I would sell my mother to Carthage for even a fraction of the kind of
application support that Wine enjoys, thank you. My only gripe with
arwinss is that Aleksey beat me to the first landmark controversial side
project
21 Jul
21 Jul
2:56 p.m.
On Mon, Jul 20, 2009 at 10:47 AM, KJK::Hyperion <hackbunny(a)reactos.org>wrote;wrote:
Timo Kreuzer wrote:
Ok, a little more confused now. You said that the idea that Wine code is
better than ReactOS code needs to die, but you turn around and basically
state that Wine code IS better than ReactOS code. Did you mean that the idea
that ReactOS code is better than Wine code? Because if that is what you
meant, then I agree.
The arwinss branch is very interesting. Does this mean that Wine DirectX
code can be shared because more Wine code is being used for the core
components? Or is ReactX still necessary, even with arwinss?
Wine emulates the kernel through a server. Of
cause we don't use it,
because it has a totally different design.
Says who? So far, and only counting official implementations, Win32 has
been implemented as:
- a shared-memory user mode subsystem (Windows 95, 98)
- a RPC user mode subsystem (Windows NT 3)
- a kernel mode subsystem (Windows NT 4 and later)
- ??? (Windows CE)
We have an NT kernel and
every kernel developer would eat me alive if I tried to put a single
line of wine code into our kernel. It's considered crap there.
Wine code has to pass quality reviews and test suites. ReactOS code only
has to pass the warmth-and-fuzziness test. Wine can prove their code is
right, ReactOS is based on code that feels right
The idea that Wine code is better than ReactOS code really needs to die.
Compared to theirs, our code is sloppy, highly unprofessional and often
inexplicable. We copy the form but tend to completely miss the intent.
Wine development is test-driven and entirely based on intent and end
results, while our development model is, apparently, to dick around in
our spare time pretending we work at Microsoft
How do you expect display drivers to work at all?
NT display drivers used to run in user mode with the same identical API,
and probably the same ABI. I'm sure Aleksey will do just fine
More hacks on top of the huge pile of hacks? And
how do you deal with
missing functionality in wine code? Shove more code in there? Or ignore
it, like if wine doesn't need it, we also don't need it? Or again fork
the code?
I would sell my mother to Carthage for even a fraction of the kind of
application support that Wine enjoys, thank you. My only gripe with
arwinss is that Aleksey beat me to the first landmark controversial side
project
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
3:59 p.m.
King InuYasha wrote:
Ok, a little more confused now. You said that the idea
that Wine code is
better than ReactOS code needs to die, but you turn around and basically
state that Wine code IS better than ReactOS code. Did you mean that the
idea that ReactOS code is better than Wine code?
I did
Because if that is what you meant, then I agree.
Super. Have some cheesecake
6:24 p.m.
On Tue, Jul 21, 2009 at 11:59 AM, KJK::Hyperion<hackbunny@reactos.org> wrote:
King InuYasha wrote:
There are many different views on 'better'
There can be:
a is a more technically correct design than b
b is more compatible than a
b is easier to read than a
a is written lang $foo while b is written in lang $bar
I am sure we could go on... Needless to say I don't believe using
wineserver in win32k is more 'correct' for ReactOS's goals. If our
goal is to be fully compatible with Windows its a (general relatively)
short term short solution to the end user problems but not to the
overall design goal.
The correct thing it would seem is IF and this is a big IF, it does
prove to function better than our existing win32k/user32/gdi32 then to
use it and quickly move one piece of our existing win32k.sys and
friends back in at a time to isolate and fix problems while keeping
the same level of compatibly and not allowing regressions in wine
tests and applications. Also it would be nice to carry forward the new
feature we gain which is the remote X display support.
If it gets more people to use ReactOS and brings in more users and
developers there is a case for being pragmatic.
--
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
Ok, a little more confused now. You said that the
idea that Wine code is
better than ReactOS code needs to die, but you turn around and basically
state that Wine code IS better than ReactOS code. Did you mean that the
idea that ReactOS code is better than Wine code?
I did 
4:32 p.m.
Please don't make this debate even more confusing by mentioning DirectX. As
you could have noticed by now, we are actually using wined3d for DX support
now (it's been two years already). The last part ouf our implementation
(ddraw) was disabled in trunk few months ago.
----- Original Message -----
From: King InuYasha
To: ReactOS Development List
Sent: Tuesday, July 21, 2009 4:56 PM
Subject: Re: [ros-dev] Arwinss
On Mon, Jul 20, 2009 at 10:47 AM, KJK::Hyperion <hackbunny(a)reactos.org>
wrote:
Timo Kreuzer wrote:
Wine emulates the kernel through a server. Of cause we
don't use it,
because it has a totally different design.
Says who? So far, and only counting official implementations, Win32 has
been implemented as:
- a shared-memory user mode subsystem (Windows 95, 98)
- a RPC user mode subsystem (Windows NT 3)
- a kernel mode subsystem (Windows NT 4 and later)
- ??? (Windows CE)
We have an NT kernel and
every kernel developer would eat me alive if I tried to put a single
line of wine code into our kernel. It's considered crap there.
Wine code has to pass quality reviews and test suites. ReactOS code only
has to pass the warmth-and-fuzziness test. Wine can prove their code is
right, ReactOS is based on code that feels right
The idea that Wine code is better than ReactOS code really needs to die.
Compared to theirs, our code is sloppy, highly unprofessional and often
inexplicable. We copy the form but tend to completely miss the intent.
Wine development is test-driven and entirely based on intent and end
results, while our development model is, apparently, to dick around in
our spare time pretending we work at Microsoft
How do you expect display drivers to work at all?
NT display drivers used to run in user mode with the same identical API,
and probably the same ABI. I'm sure Aleksey will do just fine
More hacks on top of the huge pile of hacks? And how
do you deal with
missing functionality in wine code? Shove more code in there? Or ignore
it, like if wine doesn't need it, we also don't need it? Or again fork
the code?
I would sell my mother to Carthage for even a fraction of the kind of
application support that Wine enjoys, thank you. My only gripe with
arwinss is that Aleksey beat me to the first landmark controversial side
project
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Ok, a little more confused now. You said that the idea that Wine code is
better than ReactOS code needs to die, but you turn around and basically
state that Wine code IS better than ReactOS code. Did you mean that the idea
that ReactOS code is better than Wine code? Because if that is what you
meant, then I agree.
The arwinss branch is very interesting. Does this mean that Wine DirectX
code can be shared because more Wine code is being used for the core
components? Or is ReactX still necessary, even with arwinss?
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
5539
days inactive
5540
days old
12 comments
7 participants
participants (7)
-
Aleksey Bragin -
Javier Agustìn Fernàndez Arroyo -
Kamil Hornícek -
King InuYasha -
KJK::Hyperion -
Steven Edwards -
Timo Kreuzer