WoW, er Wine on Windows--Re: Still more fun?

[Augustus Saunders]

I've been avidly following WWN for some time now, and now
that other people have brought up this topic (using WINE
dlls on Windows), I wanted to jump in.  (I'm not subscribed,
so please CC me on any response)  My employer is vaguely
considering pursuing a product idea, depending on 1) how
difficult this is to do, 2) how complete WINE is in the
areas we're interested in, and 3) presuming the licensing
works out.  But that's neither here nor there, so let me
describe what we want to do.

We are interested in creating an "application launcher"
application, where-in you run our application, choose any
other application installed on your system, and it is
executed, but links against any WINE dlls that we provide
instead of system dlls.  So we want to put all of the WINE
dlls (that we care to use) in say, "C:\Program
Files\LauncherApp\WINE" or some such, and injecting that
ahead of WINDOWS and SYSTEM32 directories, but only for apps
run from our launcher.  Anything we don't provide should
just fall back on the system dlls.

As for what we hope to accomplish, well, it might seem like
massive overkill to try using WINE, but it's the only
plausible way I've come up with.  Basically, we want to
substitute all the graphics/windowing/GDI etc so that we can
record all the painting/rendering into some kind of WMF type
thingy.  The idea is to get screen captures as metafiles
that are perfectly screen-accurate.  There are numerous ways
to grab a bitmap rendering of a window/screen, but that's
useless.  Also, you can (sometimes) get an application to
print to your metafile, but that is for printing documents
and does not show the application as it appears on screen.
The end result?  Essentially vector graphic screen shots.

I can imagine some weird interactions caused by using wine
dlls and system dlls at the same time.  I can also imagine
that things might go berzerk when a WINE-linked app's
window's overlapped a regular app--it would probably be
necessary to forward some stuff to the WIN32 system so that
windows would interact and messages get sent properly.  In
fact, for us, it would be ok to forward everything to WIN32
versions, and have WINE maintain a "shadow" copy of all the
windows in memory that we capture from, but aren't
on-screen.  But that could be a huge performance drain.  It
seems like this could be a ton of work, or practically
trivial, and I can't tell which.

Finally, how much is DirectDraw/D3D used outside of games?
We're only interested in desktop/office type apps, and I
presume we can safely ignore trapping anything sent through
DirectX.

I appreciate any feedback anybody has.  Thanks-

Augustus

PS I'm not subscribed (I just read WWN), so please CC me on
any responses.  Thanks.