[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"
Aleksey Bragin
aleksey at reactos.org
Sat Jul 18 18:16:27 CEST 2009
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 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
>>
>>
>
> _______________________________________________
> 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/bf8e4853/attachment-0001.html
More information about the Ros-dev
mailing list