Yay for excuses that let me delay writing the newsletter :D

On Sat, Jul 18, 2009 at 11:16 AM, Aleksey Bragin <aleksey@reactos.org> wrote:
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@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 mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev