18 Jul
2009
18 Jul
'09
4:16 p.m.
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:
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev 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