This is the mail archive of the win32-x11@sources.redhat.com mailing list for the win32-x11 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: Start of plan for XOpenWin


Hi guys,

	I thought that the working plan for this was the following;

- An .EXE call XOpenWin is invoked with the application you want to X-ify
like so -

XOpenWin notepad

- XOpenWin creates the process as a child of itself and hooks all Notepad's
calls into USER and GDI
- XOpenWin then translates those into XFree calls.


This way, only XOpenWin needs to know anything about USER or GDI
replacements.

This approach, which is similar to the way BoundsChecker or other debuggers
operate seems workable.


Am I totally off?


By the way, a Custom DC *could* definitely be something to look into... The
only problem I see with it is that you also need to know about the state of
a window (X-Y Minimized, X-Y Maximized, X-Y Restored), which is something a
DC has no knowledge about.

So hooking USER, and consequently GDI, does seem the way to go.



-----Original Message-----
From: David Fraser [mailto:davidf@sjsoft.com]
Sent: Saturday, September 21, 2002 11:20 AM
To: win32-x11@sources.redhat.com
Subject: Re: Start of plan for XOpenWin

Alexander Gottwald wrote:

>On Sat, 21 Sep 2002, David Fraser wrote:
>
>
>
>>Evaluation of each:
>>1) GDI driver
>>    + could take over whole system locally
>>    - difficult/impossible to X-ify single application
>>
>>
>
>Maybe not. Each drawing in a windows application is done on a device
>context (DC) which can be requested inside the application via GetDC.
>There is also a function CreateDC which uses a drivername
>eg. CreateDC("IBMGRX", "IBM Graphics", "LPT1:", NULL) for an ibm printer.
>If we can start an application with an explicitly given DC (created
>from the gdi-wrapper driver) then the application will use the driver as
>output.
>
>
Aahh.

>>3) Investigate using code from wine x11drv
>>    Basically in Wine there's a lot of code that's relevant
>>    Alexander Gottwald posted on the cygwin list that he got x11drv, the
>>    X11 driver for GDI, to compile but not link
>>    Basically a lot of this code could probably be copied and pasted into
>>    our project to implement functions as we go along.
>>    When we work out how it all works, we may be able to use it straight
>>
>>
>
>Using the code directly is a deadend IMO. The code uses calls to user32
>and gdi32 from wine which use symbols like GDI_GetDC or USER_UnLock.
>Cleaning this is a lot of work.
>But using portions of the code seems to work.
>
>bye
>    ago
>
Thanks for the investigation.
So basically we need a launcher app that will replaced dlls or function
pointers
with our new modified ones, or start the application with an explicitly
given device context.

There's something call Microsoft Detours at
http://www.research.microsoft.com/sn/detours/
Quote from the main page:

Detours is a library for instrumenting arbitrary Win32 functions on x86
machines. Detours intercepts Win32 functions by re-writing target
function images. The Detours package also contains utilities to attach
arbitrary DLLs and data segments (called payloads) to any Win32 binary.

Sounds like exactly what we want to do. The EULA says this:
    * NO TRANSFER RIGHTS:  That you will not copy, sell, rent, lease,
distribute, sublicense, assign, or otherwise transfer (including by loan
or gift) the Software and will not attempt to modify it, or to reverse
engineer or decompile it, except and only to the extent authorized.
    * That you will not use the Software in a live operating environment
where it may be relied upon to perform in the same manner as a
commercially released product, or with data that has not been
sufficiently backed up.
So we can't really use it in our product. But we can
a) use it in the development process
b) take ideas from the source code...

Other approaches mentioned on the codeguru apihijack page include
running the application in debug mode and modifying it when it loads on
a debug event. Unfortunately you can't take it out of debug mode, but
this approach should work for the testing stage.
And then there's the CBT-hook method used by apihijack which
unfortunately only gets called when the process creates a window

David


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