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

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 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....
> 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 at reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.reactos.org/pipermail/ros-dev/attachments/20090718/1e8a351b/attachment.html