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<[email protected]> 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 > [email protected] > http://www.reactos.org/mailman/listinfo/ros-dev > >
_______________________________________________ Ros-dev mailing list [email protected] http://www.reactos.org/mailman/listinfo/ros-dev
