Re: WoW, er Wine on Windows--Re: Still more fun?
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
Re: WoW, er Wine on Windows--Re: Still more fun?
Mike McCormack 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. Sounds like a modified screen driver would do a better job at what you want. I don't know whether a modified graphic driver will capture EVERYTHING he's trying to catch, but using Wine does not sound like the right solution either. I'd use the same injection technique Wine uses to inject my own DLLs that just forward everything on to native, and then use that to record whatever is interesting to me. It sounds like what Wine is doing will only hurt what Augustus is trying to do, not help. There are also more Traditional ways to inject your code into a process's import table. Mike Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html
RE: WoW, er Wine on Windows--Re: Still more fun?
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
WoW, er Wine on Windows--Re: Still more fun?
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.
Re: WoW, er Wine on Windows--Re: Still more fun?
--- Augustus Saunders [EMAIL PROTECTED] wrote: I appreciate any feedback anybody has. Thanks- It wont work for DirectX. Wine directX structures and implementation is incompatible with Windows currently. Normal Win32 dlls work fine. Thanks Steven __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: WoW, er Wine on Windows--Re: Still more fun?
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. Sounds like a modified screen driver would do a better job at what you want. Mike
Re: Still more fun?
Hi Rolf, --- Rolf Kalbermatter [EMAIL PROTECTED] wrote: Why would you need the .local file? Has there anything changed in XP or 2003 which would prefer Windows or system DLLs over local DLLs in the same directory as the calling executable? I always was under the impression that the executable directory was the first to be searched by LoadLibrary() for a DLL and it has worked that way for me in the past, too. The behavior of LoadLibrary has changed at least once that I know of for Windows 2003. The default search order can be set per application in the registry as well. Microsoft even does the programname.exe.local trick with the IE5 setup wizard. Extract the IE5 wizard in to a temp folder and lauch IE5 setup and you will see the *.exe.local file. iTunes even does it. Thanks Steven __ Do you Yahoo!? Make Yahoo! your home page http://www.yahoo.com/r/hs
Re: Still more fun?
Steven Edwards [EMAIL PROTECTED] wrote: I think it would be good in testing Wine/ReactOS vs Windows for Winelib applications developers. You can make a dummy file in your application directory called application.exe.local to force Windows to use the dlls in the local directory. So say you have IEXPLORE.EXE you would create IEXPLORE.EXE.LOCAL and drop the Mingw compiled dlls in to the application folder and see how it runs. Why would you need the .local file? Has there anything changed in XP or 2003 which would prefer Windows or system DLLs over local DLLs in the same directory as the calling executable? I always was under the impression that the executable directory was the first to be searched by LoadLibrary() for a DLL and it has worked that way for me in the past, too. Rolf Kalbermatter
Still more fun?
Has anybody else thought of using DLLs (like ReactOS' dlls) as a compatibility layer to different Windows versions? I.e. when you distribute your Windows app, you also throw in a bunch of DLLs that implement lots of functionality you aren't sure exists on your target otherwise. (Windows 2003 functionality on Windows XP, 2000 and NT for instance.) It would be a way to avoid upgrading Windows. This would be good for developers, users and the Open Source community. The longer it takes for Microsoft to shove out a new version of their OS, the more time Open Source has to infiltrate. :-) I first had the idea when a program of mine refused to run on Windows 95 when it was compiled with Visual C++ .NET. It needed some XP functionality in a DLL not present on Windows 95. Well, I created a dll with the same name and distributed it with my program. //Jakob
Re: Still more fun?
Hi, --- Jakob Eriksson [EMAIL PROTECTED] wrote: Has anybody else thought of using DLLs (like ReactOS' dlls) as a compatibility layer to different Windows versions? I think it would be good in testing Wine/ReactOS vs Windows for Winelib applications developers. You can make a dummy file in your application directory called application.exe.local to force Windows to use the dlls in the local directory. So say you have IEXPLORE.EXE you would create IEXPLORE.EXE.LOCAL and drop the Mingw compiled dlls in to the application folder and see how it runs. Thanks Steven __ Do you Yahoo!? Plan great trips with Yahoo! Travel: Now over 17,000 guides! http://travel.yahoo.com/p-travelguide
