Re: [ros-dev] [ros-diffs] [fireball] 42000: - Create a branch for upcoming work. "<XXX> people will eat you alive anyway so it doesn't really matter"

[Steven Edwards]

On Fri, Jul 17, 2009 at 8:49 AM, <fireball(a)svn.reactos.org> wrote:
>   Author: fireball
>  Date: Fri Jul 17 14:49:16 2009
>  New Revision: 42000
>
>  URL: http://svn.reactos.org/svn/reactos?rev=42000&view=rev
>  Log:
>  - Create a branch for upcoming work.
>
>  "<XXX> people will eat you alive anyway so it doesn't really matter"
And your going to make children cry when people see what your doing...

-- 
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

[James Tabor]

Hi!

On Fri, Jul 17, 2009 at 3:52 PM, Steven Edwards<winehacker(a)gmail.com> wrote:
>   On Fri, Jul 17, 2009 at 8:49 AM,
> <fireball(a)svn.reactos.org> wrote:
> >   Author: fireball
> >  Date: Fri Jul 17 14:49:16 2009
> >  New Revision: 42000
> >
> >  URL: http://svn.reactos.org/svn/reactos?rev=42000&view=rev
> >  Log:
> >  - Create a branch for upcoming work.
> >
> >  "<XXX> people will eat you alive anyway so it doesn't really matter"
>  And your going to make children cry when people see what your doing...
>
>  --
>  Steven Edwards
>  
I'm for this! With many reasons not to post here. Once I get
somethings I'm working on finished, expect me to start helping!
James

[Aleksey Bragin]

Cool, thanks!


WBR,
Aleksey Bragin.

On Jul 18, 2009, at 1:08 AM, James Tabor wrote:

>   Hi!
>
>  On Fri, Jul 17, 2009 at 3:52 PM, Steven  
>  Edwards<winehacker(a)gmail.com> wrote:
> >   On Fri, Jul 17, 2009 at 8:49 AM,
> > <fireball(a)svn.reactos.org> wrote:
> > >   Author: fireball
> > >  Date: Fri Jul 17 14:49:16 2009
> > >  New Revision: 42000
> > >
> > >  URL: http://svn.reactos.org/svn/reactos?rev=42000&view=rev
> > >  Log:
> > >  - Create a branch for upcoming work.
> > >
> > >  "<XXX> people will eat you alive anyway so it doesn't really matter"
> >  And your going to make children cry when people see what your  
> >  doing...
> >
> >  --
> >  Steven Edwards
> >  
>  I'm for this! With many reasons not to post here. Once I get
>  somethings I'm working on finished, expect me to start helping!
>  James

[Timo Kreuzer]

Yeah it looks promising. I love it. I will join in now, too. Let us all
work on this great idea to get it ready for the next release.
It will finally make our crappy win32k absolete. And it will fix the kernel!
;-P


James Tabor wrote:
>   Hi!
>
>    
>  I'm for this! With many reasons not to post here. Once I get
>  somethings I'm working on finished, expect me to start helping!
>  James
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>
>

[James Tabor]

Hi,

2009/7/17 Timo Kreuzer <timo.kreuzer(a)web.de>de>:
>   Yeah it looks promising. I love it. I will join in
> now, too. Let us all work
>  on this great idea to get it ready for the next release.
>  It will finally make our crappy win32k absolete. And it will fix the kernel!
>  ;-P
>
>  
I wasn't thinking like that, our code is not going away,,, for a
different set of reasons. The argument was setup years ago, the answer
is coming closer.... .. ... .. .. ... . We have the tools now, so~...
.. . .. .. ..
James

[Alex Ionescu]

What are you guys trying to do, btw?
Get Wine's GUI running in ReactOS for better app-compat? (I hope not, for
multiple reasons I can discuss if this is what you're attempting to do).

Or... get Wine's GUI running to see what graphic improvements appear, and
what graphics are still fucked in the same way, so you can remove that part
from the equation (meaning the problem is the driver or kernel or some other
DLL). <--- I hope so

Best regards,
Alex Ionescu


On Fri, Jul 17, 2009 at 6:12 PM, James Tabor &lt;jimtabor.rosdev(a)gmail.com&gt;wrote;wrote:

>   Hi,
>
>  2009/7/17 Timo Kreuzer &lt;timo.kreuzer(a)web.de&gt;de>:
> >   Yeah it looks promising. I love it. I will join
> > in now, too. Let us all 
>  work
> >   on this great idea to get it ready for the next
> > release.
> >  It will finally make our crappy win32k absolete. And it will fix the 
>  kernel!
> >   ;-P
> >
> >  
>  I wasn't thinking like that, our code is not going away,,, for a
>  different set of reasons. The argument was setup years ago, the answer
>  is coming closer.... .. ... .. .. ... . We have the tools now, so~...
>  .. . .. .. ..
>  James
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[James Tabor]

Hi!

On Fri, Jul 17, 2009 at 6:02 PM, Alex Ionescu<ionucu(a)videotron.ca> wrote:
>   What are you guys trying to do, btw?
>  Get Wine's GUI running in ReactOS for better app-compat? (I hope not, for
>  multiple reasons I can discuss if this is what you're attempting to do). 
I don't think wine can draw w/o X so answer is no~ Wine uses those
X->Z(,,,) to driver calls and it would include winex11.drv as a
minimal to be added and adapted to call our driver code so~ for sure
this is a No. ie. [wine, user] create a window, it calls the driver
and that is winex11.drv so a call to X is performed there.

I've added X to our code base to support math needed for drawing, I
guess those could be adapted as well....? The math is sound, but as an
extra layer of code, is not what I wanted to do. But Win32k does have
that kind of math for drawing so.... We can simplify it, rewrite it
and so on~ a side note.

>   Or... get Wine's GUI running to see what graphic
> improvements appear, and
>  what graphics are still fucked in the same way, so you can remove that part
>  from the equation (meaning the problem is the driver or kernel or some other
>  DLL). <--- I hope so
>  Best regards,
>  Alex Ionescu
>  
More I think about it, if it does compile, it will not work, ntoskrnl
needs win32k so how to overcome this? Need to rewrite the kernel? That
is a no. Win32k process and threading issues and kernel callbacks so,
more, no. Someone could do the same with Xp or W7U, rewrite win32k to
support wine, write the callbacks make it interface as it should,
basically making win32k into win32kX11.... Graphic driver issues,,, so
the assumed response is no, why do all that when you can use the same
time writing it the right way. or Keep win32k, rewrite wine server and
winex11.drv to support NtGdi/NtUser calls...... Basically ending up
where you started off since over 80% of our win32k is wine code from
the start. Adapted modified and simplified to interface with drivers
and kernel.

Look at it as a research project. We will answer these questions soon....
James

PS newbies,
FYI: AdvApi, *Gdi, Kernel, Ntdll and *User are the "core 5" dlls that
have direct contact with kernel space.
* Split in two parts one "win32k" kernel space and the other user
space counter parts and uses data packets "known as shared data"
outside the API to transfer data from kernel space to user space and
back from user space to kernel space.

[Timo Kreuzer]

Hi,

I still don't get it. What do you want to research here? How wine works?
Or how windows works? Or how to create a monstrous chimera from reactos
and wine?

I wonder what people would say, if I created a branch called arsentxx,
cleaned out ntoskrnl and imported LUK... ;-P

Well, my current opinion is that this is simply a lot of wasted time and
will most likely end up like nwin32 (which was a much better idea) and
most other branches being left alone and bitrotting.

Anyway, this is just my opinion, based on what I have seen and guesses,
as long as noone states the real goal of this. And of cause everyone is
free to spend his free time with whatever he likes :-)

Regards,
Timo

PS: That world domination thing won't work this way. I tried that
myself. You need more robots!

James Tabor schrieb:
>   Hi!
>
>  On Fri, Jul 17, 2009 at 6:02 PM, Alex Ionescu<ionucu(a)videotron.ca> wrote:
>    
> >   What are you guys trying to do, btw?
> >  Get Wine's GUI running in ReactOS for better app-compat? (I hope not, for
> >  multiple reasons I can discuss if this is what you're attempting to do).
> >       
>  I don't think wine can draw w/o X so answer is no~ Wine uses those
>  X->Z(,,,) to driver calls and it would include winex11.drv as a
>  minimal to be added and adapted to call our driver code so~ for sure
>  this is a No. ie. [wine, user] create a window, it calls the driver
>  and that is winex11.drv so a call to X is performed there.
>
>  I've added X to our code base to support math needed for drawing, I
>  guess those could be adapted as well....? The math is sound, but as an
>  extra layer of code, is not what I wanted to do. But Win32k does have
>  that kind of math for drawing so.... We can simplify it, rewrite it
>  and so on~ a side note.
>
>    
> >   Or... get Wine's GUI running to see what
> > graphic improvements appear, and
> >  what graphics are still fucked in the same way, so you can remove that part
> >  from the equation (meaning the problem is the driver or kernel or some other
> >  DLL). <--- I hope so
> >  Best regards,
> >  Alex Ionescu
> >
> >       
>  More I think about it, if it does compile, it will not work, ntoskrnl
>  needs win32k so how to overcome this? Need to rewrite the kernel? That
>  is a no. Win32k process and threading issues and kernel callbacks so,
>  more, no. Someone could do the same with Xp or W7U, rewrite win32k to
>  support wine, write the callbacks make it interface as it should,
>  basically making win32k into win32kX11.... Graphic driver issues,,, so
>  the assumed response is no, why do all that when you can use the same
>  time writing it the right way. or Keep win32k, rewrite wine server and
>  winex11.drv to support NtGdi/NtUser calls...... Basically ending up
>  where you started off since over 80% of our win32k is wine code from
>  the start. Adapted modified and simplified to interface with drivers
>  and kernel.
>
>  Look at it as a research project. We will answer these questions soon....
>  James
>
>  PS newbies,
>  FYI: AdvApi, *Gdi, Kernel, Ntdll and *User are the "core 5" dlls that
>  have direct contact with kernel space.
>  * Split in two parts one "win32k" kernel space and the other user
>  space counter parts and uses data packets "known as shared data"
>  outside the API to transfer data from kernel space to user space and
>  back from user space to kernel space.
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>
>

[Aleksey Bragin]

Don't jump into fast conclusions :-)


I will explain thoroughly and in all details what's being done. Just  
let me commit the remaining of my stuff first.


WBR,
Aleksey Bragin.


On Jul 18, 2009, at 6:34 PM, Timo Kreuzer wrote:

>   Hi,
>
>  I still don't get it. What do you want to research here? How wine  
>  works? Or how windows works? Or how to create a monstrous chimera  
>  from reactos and wine?
>
>  I wonder what people would say, if I created a branch called  
>  arsentxx, cleaned out ntoskrnl and imported LUK... ;-P
>
>  Well, my current opinion is that this is simply a lot of wasted  
>  time and will most likely end up like nwin32 (which was a much  
>  better idea) and most other branches being left alone and bitrotting.
>
>  Anyway, this is just my opinion, based on what I have seen and  
>  guesses, as long as noone states the real goal of this. And of  
>  cause everyone is free to spend his free time with whatever he  
>  likes :-)
>
>  Regards,
>  Timo
>
>  PS: That world domination thing won't work this way. I tried that  
>  myself. You need more robots!
>
>  James Tabor schrieb:
> >   Hi!
> >
> >  On Fri, Jul 17, 2009 at 6:02 PM, Alex Ionescu<ionucu(a)videotron.ca>  
> >  wrote:
> >
> > >   What are you guys trying to do, btw?
> > >  Get Wine's GUI running in ReactOS for better app-compat? (I hope  
> > >  not, for
> > >  multiple reasons I can discuss if this is what you're attempting  
> > >  to do).
> > >  
> >  I don't think wine can draw w/o X so answer is no~ Wine uses those
> >  X->Z(,,,) to driver calls and it would include winex11.drv as a
> >  minimal to be added and adapted to call our driver code so~ for sure
> >  this is a No. ie. [wine, user] create a window, it calls the driver
> >  and that is winex11.drv so a call to X is performed there.
> >
> >  I've added X to our code base to support math needed for drawing, I
> >  guess those could be adapted as well....? The math is sound, but  
> >  as an
> >  extra layer of code, is not what I wanted to do. But Win32k does have
> >  that kind of math for drawing so.... We can simplify it, rewrite it
> >  and so on~ a side note.
> >
> >
> > >   Or... get Wine's GUI running to see what
> > > graphic improvements  
> > >  appear, and
> > >  what graphics are still fucked in the same way, so you can remove  
> > >  that part
> > >  from the equation (meaning the problem is the driver or kernel or  
> > >  some other
> > >  DLL). <--- I hope so
> > >  Best regards,
> > >  Alex Ionescu
> > >
> > >  
> >  More I think about it, if it does compile, it will not work, ntoskrnl
> >  needs win32k so how to overcome this? Need to rewrite the kernel?  
> >  That
> >  is a no. Win32k process and threading issues and kernel callbacks so,
> >  more, no. Someone could do the same with Xp or W7U, rewrite win32k to
> >  support wine, write the callbacks make it interface as it should,
> >  basically making win32k into win32kX11.... Graphic driver  
> >  issues,,, so
> >  the assumed response is no, why do all that when you can use the same
> >  time writing it the right way. or Keep win32k, rewrite wine server  
> >  and
> >  winex11.drv to support NtGdi/NtUser calls...... Basically ending up
> >  where you started off since over 80% of our win32k is wine code from
> >  the start. Adapted modified and simplified to interface with drivers
> >  and kernel.
> >
> >  Look at it as a research project. We will answer these questions  
> >  soon....
> >  James
> >
> >  PS newbies,
> >  FYI: AdvApi, *Gdi, Kernel, Ntdll and *User are the "core 5" dlls that
> >  have direct contact with kernel space.
> >  * Split in two parts one "win32k" kernel space and the other user
> >  space counter parts and uses data packets "known as shared data"
> >  outside the API to transfer data from kernel space to user space and
> >  back from user space to kernel space.
> >  _______________________________________________
> >  Ros-dev mailing list
> >  Ros-dev(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-dev
> >
> >  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev

[Zachary Gorden]

Yay for excuses that let me delay writing the newsletter :D

On Sat, Jul 18, 2009 at 11:16 AM, Aleksey Bragin <aleksey(a)reactos.org>wrote;wrote:

>   Don't jump into fast conclusions :-)
>
>  I will explain thoroughly and in all details what's being done. Just let me
>  commit the remaining of my stuff first.
>
>
>  WBR,
>  Aleksey Bragin.
>
>
>  On Jul 18, 2009, at 6:34 PM, Timo Kreuzer wrote:
>
>  Hi,
>
>  I still don't get it. What do you want to research here? How wine works? Or
>  how windows works? Or how to create a monstrous chimera from reactos and
>  wine?
>
>  I wonder what people would say, if I created a branch called arsentxx,
>  cleaned out ntoskrnl and imported LUK... ;-P
>
>  Well, my current opinion is that this is simply a lot of wasted time and
>  will most likely end up like nwin32 (which was a much better idea) and most
>  other branches being left alone and bitrotting.
>
>  Anyway, this is just my opinion, based on what I have seen and guesses, as
>  long as noone states the real goal of this. And of cause everyone is free to
>  spend his free time with whatever he likes :-)
>
>  Regards,
>  Timo
>
>  PS: That world domination thing won't work this way. I tried that myself.
>  You need more robots!
>
>  James Tabor schrieb:
>
>  Hi!
>
>  On Fri, Jul 17, 2009 at 6:02 PM, Alex Ionescu<ionucu(a)videotron.ca>
> <ionucu(a)videotron.ca> wrote:
>
>
>   What are you guys trying to do, btw?
>  Get Wine's GUI running in ReactOS for better app-compat? (I hope not, for
>  multiple reasons I can discuss if this is what you're attempting to do).
>
>
>   I don't think wine can draw w/o X so answer is no~ Wine uses those
>  X->Z(,,,) to driver calls and it would include winex11.drv as a
>  minimal to be added and adapted to call our driver code so~ for sure
>  this is a No. ie. [wine, user] create a window, it calls the driver
>  and that is winex11.drv so a call to X is performed there.
>
>  I've added X to our code base to support math needed for drawing, I
>  guess those could be adapted as well....? The math is sound, but as an
>  extra layer of code, is not what I wanted to do. But Win32k does have
>  that kind of math for drawing so.... We can simplify it, rewrite it
>  and so on~ a side note.
>
>
>
>   Or... get Wine's GUI running to see what graphic improvements appear, and
>  what graphics are still fucked in the same way, so you can remove that part
>  from the equation (meaning the problem is the driver or kernel or some other
>  DLL). <--- I hope so
>  Best regards,
>  Alex Ionescu
>
>
>
>   More I think about it, if it does compile, it will not work, ntoskrnl
>  needs win32k so how to overcome this? Need to rewrite the kernel? That
>  is a no. Win32k process and threading issues and kernel callbacks so,
>  more, no. Someone could do the same with Xp or W7U, rewrite win32k to
>  support wine, write the callbacks make it interface as it should,
>  basically making win32k into win32kX11.... Graphic driver issues,,, so
>  the assumed response is no, why do all that when you can use the same
>  time writing it the right way. or Keep win32k, rewrite wine server and
>  winex11.drv to support NtGdi/NtUser calls...... Basically ending up
>  where you started off since over 80% of our win32k is wine code from
>  the start. Adapted modified and simplified to interface with drivers
>  and kernel.
>
>  Look at it as a research project. We will answer these questions soon....
>  James
>
>  PS newbies,
>  FYI: AdvApi, *Gdi, Kernel, Ntdll and *User are the "core 5" dlls that
>  have direct contact with kernel space.
>  * Split in two parts one "win32k" kernel space and the other user
>  space counter parts and uses data packets "known as shared data"
>  outside the API to transfer data from kernel space to user space and
>  back from user space to kernel space.
>  _______________________________________________
>  Ros-dev mailing [e-mail]://www.reactos.org/mailman/listinfo/ros-dev
>
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>
>
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[Alex Ionescu]

This is such an awesome russian response :)
"Let me finish the political upheveal first, "restructure" the parliament,
rebuild the economy and then my vision will become clear".

Best regards,
Alex Ionescu


On Sat, Jul 18, 2009 at 12:16 PM, Aleksey Bragin <aleksey(a)reactos.org>wrote;wrote:

>   Don't jump into fast conclusions :-)
>
>  I will explain thoroughly and in all details what's being done. Just let me
>  commit the remaining of my stuff first.
>
>
>  WBR,
>  Aleksey Bragin.
>
>
>  On Jul 18, 2009, at 6:34 PM, Timo Kreuzer wrote:
>
>  Hi,
>
>  I still don't get it. What do you want to research here? How wine works? Or
>  how windows works? Or how to create a monstrous chimera from reactos and
>  wine?
>
>  I wonder what people would say, if I created a branch called arsentxx,
>  cleaned out ntoskrnl and imported LUK... ;-P
>
>  Well, my current opinion is that this is simply a lot of wasted time and
>  will most likely end up like nwin32 (which was a much better idea) and most
>  other branches being left alone and bitrotting.
>
>  Anyway, this is just my opinion, based on what I have seen and guesses, as
>  long as noone states the real goal of this. And of cause everyone is free to
>  spend his free time with whatever he likes :-)
>
>  Regards,
>  Timo
>
>  PS: That world domination thing won't work this way. I tried that myself.
>  You need more robots!
>
>  James Tabor schrieb:
>
>  Hi!
>
>  On Fri, Jul 17, 2009 at 6:02 PM, Alex Ionescu<ionucu(a)videotron.ca>
> <ionucu(a)videotron.ca> wrote:
>
>
>   What are you guys trying to do, btw?
>  Get Wine's GUI running in ReactOS for better app-compat? (I hope not, for
>  multiple reasons I can discuss if this is what you're attempting to do).
>
>
>   I don't think wine can draw w/o X so answer is no~ Wine uses those
>  X->Z(,,,) to driver calls and it would include winex11.drv as a
>  minimal to be added and adapted to call our driver code so~ for sure
>  this is a No. ie. [wine, user] create a window, it calls the driver
>  and that is winex11.drv so a call to X is performed there.
>
>  I've added X to our code base to support math needed for drawing, I
>  guess those could be adapted as well....? The math is sound, but as an
>  extra layer of code, is not what I wanted to do. But Win32k does have
>  that kind of math for drawing so.... We can simplify it, rewrite it
>  and so on~ a side note.
>
>
>
>   Or... get Wine's GUI running to see what graphic improvements appear, and
>  what graphics are still fucked in the same way, so you can remove that part
>  from the equation (meaning the problem is the driver or kernel or some other
>  DLL). <--- I hope so
>  Best regards,
>  Alex Ionescu
>
>
>
>   More I think about it, if it does compile, it will not work, ntoskrnl
>  needs win32k so how to overcome this? Need to rewrite the kernel? That
>  is a no. Win32k process and threading issues and kernel callbacks so,
>  more, no. Someone could do the same with Xp or W7U, rewrite win32k to
>  support wine, write the callbacks make it interface as it should,
>  basically making win32k into win32kX11.... Graphic driver issues,,, so
>  the assumed response is no, why do all that when you can use the same
>  time writing it the right way. or Keep win32k, rewrite wine server and
>  winex11.drv to support NtGdi/NtUser calls...... Basically ending up
>  where you started off since over 80% of our win32k is wine code from
>  the start. Adapted modified and simplified to interface with drivers
>  and kernel.
>
>  Look at it as a research project. We will answer these questions soon....
>  James
>
>  PS newbies,
>  FYI: AdvApi, *Gdi, Kernel, Ntdll and *User are the "core 5" dlls that
>  have direct contact with kernel space.
>  * Split in two parts one "win32k" kernel space and the other user
>  space counter parts and uses data packets "known as shared data"
>  outside the API to transfer data from kernel space to user space and
>  back from user space to kernel space.
>  _______________________________________________
>  Ros-dev mailing [e-mail]://www.reactos.org/mailman/listinfo/ros-dev
>
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>
>
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>
>

[Alexandru Lovin]

Oh, that sounds like Vladimir Putin. I have another two:

"Trust me. Give me absolute power and I will fix the Russian democracy."
"I've decided to retain my power. Those in favor, say aye. Those opposed,
say nothing."

On Sat, Jul 18, 2009 at 10:47 PM, Alex Ionescu <ionucu(a)videotron.ca> wrote:

>   This is such an awesome russian response :)
>  "Let me finish the political upheveal first, "restructure" the
> parliament,
>  rebuild the economy and then my vision will become clear".
>
>  Best regards,
>  Alex Ionescu
>
>
>
>  On Sat, Jul 18, 2009 at 12:16 PM, Aleksey Bragin <aleksey(a)reactos.org>wrote;wrote:
>
> >   Don't jump into fast conclusions :-)
> >
> >  I will explain thoroughly and in all details what's being done. Just let
> >  me commit the remaining of my stuff first.
> >
> >
> >  WBR,
> >  Aleksey Bragin.
> >
> >
> >   On Jul 18, 2009, at 6:34 PM, Timo Kreuzer wrote:
> >
> >  Hi,
> >
> >  I still don't get it. What do you want to research here? How wine works?
> >  Or how windows works? Or how to create a monstrous chimera from reactos and
> >  wine?
> >
> >  I wonder what people would say, if I created a branch called arsentxx,
> >  cleaned out ntoskrnl and imported LUK... ;-P
> >
> >  Well, my current opinion is that this is simply a lot of wasted time and
> >  will most likely end up like nwin32 (which was a much better idea) and most
> >  other branches being left alone and bitrotting.
> >
> >  Anyway, this is just my opinion, based on what I have seen and guesses, as
> >  long as noone states the real goal of this. And of cause everyone is free to
> >  spend his free time with whatever he likes :-)
> >
> >  Regards,
> >  Timo
> >
> >  PS: That world domination thing won't work this way. I tried that myself.
> >  You need more robots!
> >
> >  James Tabor schrieb:
> >
> >  Hi!
> >
> >  On Fri, Jul 17, 2009 at 6:02 PM, Alex Ionescu<ionucu(a)videotron.ca>
> > <ionucu(a)videotron.ca> wrote:
> >
> >
> >  What are you guys trying to do, btw?
> >  Get Wine's GUI running in ReactOS for better app-compat? (I hope not, for
> >  multiple reasons I can discuss if this is what you're attempting to do).
> >
> >
> >  I don't think wine can draw w/o X so answer is no~ Wine uses those
> >  X->Z(,,,) to driver calls and it would include winex11.drv as a
> >  minimal to be added and adapted to call our driver code so~ for sure
> >  this is a No. ie. [wine, user] create a window, it calls the driver
> >  and that is winex11.drv so a call to X is performed there.
> >
> >  I've added X to our code base to support math needed for drawing, I
> >  guess those could be adapted as well....? The math is sound, but as an
> >  extra layer of code, is not what I wanted to do. But Win32k does have
> >  that kind of math for drawing so.... We can simplify it, rewrite it
> >  and so on~ a side note.
> >
> >
> >
> >  Or... get Wine's GUI running to see what graphic improvements appear, and
> >  what graphics are still fucked in the same way, so you can remove that part
> >  from the equation (meaning the problem is the driver or kernel or some other
> >  DLL). <--- I hope so
> >  Best regards,
> >  Alex Ionescu
> >
> >
> >
> >  More I think about it, if it does compile, it will not work, ntoskrnl
> >  needs win32k so how to overcome this? Need to rewrite the kernel? That
> >  is a no. Win32k process and threading issues and kernel callbacks so,
> >  more, no. Someone could do the same with Xp or W7U, rewrite win32k to
> >  support wine, write the callbacks make it interface as it should,
> >  basically making win32k into win32kX11.... Graphic driver issues,,, so
> >  the assumed response is no, why do all that when you can use the same
> >  time writing it the right way. or Keep win32k, rewrite wine server and
> >  winex11.drv to support NtGdi/NtUser calls...... Basically ending up
> >  where you started off since over 80% of our win32k is wine code from
> >  the start. Adapted modified and simplified to interface with drivers
> >  and kernel.
> >
> >  Look at it as a research project. We will answer these questions soon....
> >  James
> >
> >  PS newbies,
> >  FYI: AdvApi, *Gdi, Kernel, Ntdll and *User are the "core 5" dlls that
> >  have direct contact with kernel space.
> >  * Split in two parts one "win32k" kernel space and the other user
> >  space counter parts and uses data packets "known as shared data"
> >  outside the API to transfer data from kernel space to user space and
> >  back from user space to kernel space.
> >  _______________________________________________
> >  Ros-dev mailing [e-mail]://www.reactos.org/mailman/listinfo/ros-dev
> >
> >
> >  _______________________________________________
> >  Ros-dev mailing list
> >  Ros-dev(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-dev
> >
> >
> >
> >  _______________________________________________
> >  Ros-dev mailing list
> >  Ros-dev(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-dev
> >
> >  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>  


-- 
Alex Lovin - www.erasereality.3x.ro

[Steven Edwards]

On Sat, Jul 18, 2009 at 3:47 PM, Alex Ionescu<ionucu(a)videotron.ca> wrote:
>   This is such an awesome russian response :)
>  "Let me finish the political upheveal first, "restructure" the
> parliament,
>  rebuild the economy and then my vision will become clear". 
What Fireball does in his own oblast will not effect the stability of
the empire ;)

-- 
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