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.