This is the mail archive of the cygwin-xfree@cygwin.com mailing list for the Cygwin XFree86 project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: X client wrapper for Win apps?


Hi guys,

	Not to contradict anyone, but I thought I might share my understanding of
the Windows API.

	USER32 is the library for creating the window objects, yes, but it only
manages their data structures and I don't think it does any actual drawing.
It relies on GDI for that I think.
	GDI32 is the module USER32 and your own code uses to do rendering. This is
the one we'd have to emulate.

	This presupposes that we only want to hook GDI output, which to me seems
incomplete, because (I might be wrong here) some applications might use
DirectDraw to do output. Games mostly I would think. It's just that if we
want ubiquitous support, we'd have to address that too.


-----Original Message-----
From: cygwin-xfree-owner@cygwin.com [mailto:cygwin-xfree-owner@cygwin.com]On
Behalf Of David Fraser
Sent: Friday, September 20, 2002 8:53 AM
To: cygwin-xfree@cygwin.com
Subject: Re: X client wrapper for Win apps?

 Stuart Adamson wrote:

>>From: Jehan [mailto:nahor@bravobrava.com]
>>Stuart Adamson wrote:
>>
>>
>>>Maybe the way forward is to filter calls to user32.dll (where most of
thebasic
>>>windowing functions end up).  By filtering I mean renaming user32.dll to
>>>user32-real.dll and writing your own user32.dll which either sends
requests to
>>>X11 or to user32-real.dll, depending on the process id of the requesting
process.
>>>
>>>
>>Oh nice! I'll then look forward to the new Windows service
>>pack and the
>>number of new posts in the mailing about XFree being broken after the
>>upgrade.
>>
>>
>
>But it won't. The interface to user32.dll of existing apps will remain the
>same
>(the service pack doesn't change apps code does it) hence any service packs
>shouldn't break this filtering.
>
>Take a look a feszer from l0pft with filters msvcrt.dll. This works on
winnt
>sp4,winnt sp5, winnt sp6a and win2000sp2sr1.
>
>
>I see something like
>
>    A small cygwin X program which you invoke with the win32 program as its
argument.
>    The cygwin program executes the win32 program, registers itself and the
id of the
>    win32 program with our user32.dll filter.
>    When the win32 app makes GDI calls to user32.dll, these get forwarded
to our cygwin
>    program which converts them into X calls and sends them to your X
server.
>
>    So, the start outlook you would do something like "wrapX11 outlook.exe"
>
>
>
I agree, we should hook user32.dll.
I have some code that does the following:
1) Uses Windows Hooks (designed for Computer-Based Training etc) to get
loaded
into program as soon as the program creates a window, then calls 2)
2) Updates the address table to redirect certain functions from desired dlls
Basically we want to replace 1) with a program that loads the program
and then does 2)
This would then be "wrapX11"
This way we don't have to rename user32.dll to user32-real.dll and
replace it with our own,
we just add user32-X11.dll in and make it replace certain functions.
We could even make wrapX11 automatically attach to everything and decide
whether
to wrap it not based on the process ID but environment variables...


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]