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"
On Fri, Jul 17, 2009 at 8:49 AM, fireball@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...
Hi!
On Fri, Jul 17, 2009 at 3:52 PM, Steven Edwardswinehacker@gmail.com wrote:
On Fri, Jul 17, 2009 at 8:49 AM, fireball@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
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 Edwardswinehacker@gmail.com wrote:
On Fri, Jul 17, 2009 at 8:49 AM, fireball@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
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@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Hi,
2009/7/17 Timo Kreuzer timo.kreuzer@web.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
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 jimtabor.rosdev@gmail.comwrote:
Hi,
2009/7/17 Timo Kreuzer timo.kreuzer@web.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@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Hi!
On Fri, Jul 17, 2009 at 6:02 PM, Alex Ionescuionucu@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.
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 Ionescuionucu@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@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
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 Ionescuionucu@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@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
Yay for excuses that let me delay writing the newsletter :D
On Sat, Jul 18, 2009 at 11:16 AM, Aleksey Bragin aleksey@reactos.orgwrote:
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 Ionescuionucu@videotron.ca ionucu@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 listRos-dev@reactos.orghttp://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
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@reactos.orgwrote:
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 Ionescuionucu@videotron.ca ionucu@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 listRos-dev@reactos.orghttp://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
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@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@reactos.orgwrote:
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 Ionescuionucu@videotron.ca ionucu@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 listRos-dev@reactos.orghttp://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
On Sat, Jul 18, 2009 at 3:47 PM, Alex Ionescuionucu@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 ;)
-
Aleksey Bragin -
Alex Ionescu -
Alexandru Lovin -
James Tabor -
Steven Edwards -
Timo Kreuzer -
Zachary Gorden