[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"
timo.kreuzer at web.de
Sat Jul 18 16:34:22 CEST 2009
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
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 :-)
PS: That world domination thing won't work this way. I tried that
myself. You need more robots!
James Tabor schrieb:
> On Fri, Jul 17, 2009 at 6:02 PM, Alex Ionescu<ionucu at 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....
> 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 at reactos.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Ros-dev