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

Augustus Saunders augustus.saunders at verilogix.net
Mon Apr 25 15:03:59 CDT 2005


All, thanks for your responses.  There's an important point that I 
forgot in my first email which explains what I hope to get from WINE.  
We don't just want to grab static screenshots, we ultimately want to do 
appsharing in Flash, almost like X Windows or terminal server type 
stuff, except over the web with no client install (sorry, my employer 
deals in the world of ubiquitous Flash players).  In particular, we 
don't want to just grab static screenshots X times per second, we need 
to maintain a kind of Flash-ized mirror of the window manager state in 
real-time where remote users actions can be mapped back to the local 
host.  If there was an open source X windows that injected itself into 
the WIN32 subsystem so it could work with WIN32 apps not built for X, 
then I would start there.  But Cygwin/X, while open source, is no such 
beast.  Coincidently, actually making windows act like an X server 
transparently would be cool too :)  (I realize everyone here runs WINE 
on a system with X, making this moot, but still...).

Anyway, taking shortcuts on this kind of thing just never seems to work, 
so the fact that WINE has it figured out gives me a lot of confidence 
that it can be made to work.  Obviously, I'll have to trick it out, but 
that's a whole lot better than re-discovering stuff people here know.  
The fact that the WINE window manager has been revamped recently (this 
late in WINE's life cycle) tells me it's a tricky area.  But crawling 
through WINE and adding Flash coordinates, Flash pseudo window handles, 
Flash rendering hooks etc, shouldn't be Difficult (with a captial D), 
just tedious. 

I know my way around Flash (I write the SWF export for OpenOffice.org, 
btw), so that part I'm comfortable with.  The API hooking stuff looks 
like it can solve the linking/injection problem, so now that I've 
explained things a bit better, what do people think?  Am I still barking 
up the wrong tree?  Is this just-crazy-it'll-never-work?

Thanks again for all your feedback.

Augustus


Rolf Kalbermatter wrote:

>Augustus Saunders wrote:
>
>  
>
>>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 think what you are trying to do is actually API hooking. There are
>ways to do that as
>explained in older MS System Journals and most probably also on
>www.sysinternals.com. 
>Alternatively I'm quite sure there is already some mechanisme built into
>Windows to do
>that. Two possible things come to my mind. If you make a screen capture
>with the "Print
>Screen" key, Windows seems to place a WMF or EMF format onto the
>clipboard already. And
>WMF/EMF is basically nothing more than a stream of GDI opcodes and its
>parameters as
>they are passed to the according GDI function.
>Alternatively you might want to look at how some of the recorder
>application do their
>work. I believe that there used to be a MSDN sample screen recorder
>application which
>might give you a start on how to do these things.
>
>Using Wine for this is most probably not very effective. You don't want
>to have DLLs
>reimplementing GDI and other low level Windows systems, and only
>forwarding all calls
>to the real system DLLs would mean modifying the Wine code to such an
>amount that
>Writing that code from scratch might be actually simpler.  
>
>Rolf Kalbermatter
>
>
>  
>



More information about the wine-devel mailing list