So are you interested in helping to implement this? The WINE project
has started a uxtheme.dll It would be nice if we could agree on a
common theme system for both projects.
Thanks
Steven
Note: forwarded message attached.
__
Do you Yahoo!?
The New Yahoo! Shopping
--- "Dimitrie O. Paun" <[EMAIL PROTECTED]> wrote:
> Well, this is nice generic metaphore, but it says nothing about
> _what_ is wrong with Wine's headers :) I mean, how else can we
> fix the problems, if we don't know what's broken?
I agree 100%. Pick a DLL and try to compile it with MS_VC and the
On Thu, 16 Oct 2003, Steven Edwards wrote:
> I have rebuilt a few engines in my day and this has been like trying to
> take parts from a BMW and use them on a Honda. It just doesnt work most
> of the time. Dont get me wrong it should "just work". All of the
> interfaces should be the same but
--- "Dimitrie O. Paun" <[EMAIL PROTECTED]> wrote:
> Well, I don't know why the w32api guys create their own headers
> instead of using ours, that is their business. However, I don't
> understand why the ReactOS folks have yet another set! Why not
> work with the Wine headers? If there are problems
On Thu, 16 Oct 2003, Steven Edwards wrote:
> I dont know if better is the right word. WINE has more compleate
> headers but they are not the most correct. The w32api people are very
> anal (No Offence Danny) about getting changes in to the package. I have
> almost never found where something is wr
--- Dmitry Timoshkov <[EMAIL PROTECTED]> wrote:
> But for simple things which use pure Win32 APIs like USER controls,
> message
> boxes you have to be able to share code with Wine without any
> significant
> effort.
>
> By "porting" that code to reactos you gain nothing except bugs. Have
> a look
--- "Dimitrie O. Paun" <[EMAIL PROTECTED]> wrote:
> For my info, what's the problem with the headers? What headers are
> you using? If not Wine's, why not? It seems we have better headers
> than then w32api guys...
I dont know if better is the right word. WINE has more compleate
headers but they a
On October 15, 2003 11:21 am, Jason Filby wrote:
> This sounds good to me. As you said, it seems like headers are the
> big blocker here.
For my info, what's the problem with the headers? What headers are
you using? If not Wine's, why not? It seems we have better headers
than then w32api guys...
"Steven Edwards" <[EMAIL PROTECTED]> wrote:
> Wines user32 depends on a few direct Wineserver calls and has quite a
> bit of old design issues from the Win16 days that will need to be fixed
> first. Not to mention Unixisms in a few places and of course ReactOS
> Win32k-User32 commuincation system
On Wed, 2003-10-15 at 10:57, Eric Kohl wrote:
> "Jason Filby" <[EMAIL PROTECTED]> wrote:
>
> > User32 and gdi32 are likely to be a problem as the bulk of our
> > implementation is in kernel mode win32k.sys.
>
> More problems will be caused by advapi32 and rpcrt4 because ReactOS will use
> LPC ins
On Wed, 2003-10-15 at 13:45, Steven Edwards wrote:
> Hello All,
> Jason is right I think. I spoke with Alexandre the other night about
> implementing a Win32k.sys driver for WINE so we could use GDI32/User32
> and it might be do-able it wont be somthing that is possible for at
> least another year
Hello All,
Jason is right I think. I spoke with Alexandre the other night about
implementing a Win32k.sys driver for WINE so we could use GDI32/User32
and it might be do-able it wont be somthing that is possible for at
least another year at the rate we are sharing code.
Wines user32 depends on a f
Hi Vizzini
This sounds good to me. As you said, it seems like headers are the
big blocker here.
Regards
Jason
--- Vizzini <[EMAIL PROTECTED]> wrote:
> Steven and I spoke about this the other day, and I am in agreement
> with
> you, Dimitrie. I don't want to fork. We can use CVS to manage the
>
Hi Dimitrie
User32 and gdi32 are likely to be a problem as the bulk of our
implementation is in kernel mode win32k.sys.
Regards
Jason
--- "Dimitrie O. Paun" <[EMAIL PROTECTED]> wrote:
> On October 14, 2003 03:11 pm, Jason Filby wrote:
>
> > I agree that forking should be avoided at all costs. O
"Jason Filby" <[EMAIL PROTECTED]> wrote:
> User32 and gdi32 are likely to be a problem as the bulk of our
> implementation is in kernel mode win32k.sys.
More problems will be caused by advapi32 and rpcrt4 because ReactOS will use
LPC instead of Unix-Sockets for local IPC.
Regards
Eric
On October 14, 2003 03:11 pm, Jason Filby wrote:
> I agree that forking should be avoided at all costs. Of course it
> will be unavoidable for lower level DLLs such as user32.
You are right, ReactOS will probably need it's own ntdll, and
maybe kernel. But for user32 and gdi32, I am hoping you ca
Hi all
I agree that forking should be avoided at all costs. Of course it
will be unavoidable for lower level DLLs such as user32. I'm getting
the tail end of this discussion so someone please fill me in if I'm
missing some big issues. The big deal with be source control
differences between the two
17 matches
Mail list logo
