Hi folks, We currently have a bit of a problem with div()/ldiv() (from msvcrt). Namely, they are defined to return a structure of type div_t/ldiv_t respectively. However, on i386, this is returned in windows in the eax/edx registers (the same as a long long). Now, before I go search for the ABI about returning small structures, can someone tell me if there is any way to maintain both source and binary compatibility? -- Dimi.
Hello, Is it appropriate to write to this list in regards the "Fun Projects" on winehq? I am interested in working on the gimp/photoshop plugin wrapper... and although I'm not so great a programmer, I have good resources (like the P$ 6.0 SDK). I wrote that project's contact a couple months ago, but received no reply. I apologize if this is off-topic Cheers, RobC --r dorothy(a)oz:~> ls lion scarecrow tinman dorothy(a)oz:~> find . -name home There's no place like home.
On November 26, 2003 01:44 pm, dim owner wrote:
Is it appropriate to write to this list in regards the "Fun Projects" on winehq?
Yes, it is.
I am interested in working on the gimp/photoshop plugin wrapper... and although I'm not so great a programmer, I have good resources (like the P$ 6.0 SDK).
That is a bit tricky, but it certainly is an interesting project. I can lend you a hand, I was actually thinking about it myself this morning :) -- Dimi.
Great! Here's some details: Photoshop plugins are DLLs, with all calls from the host using 1 entry point ( main ). But hopefully, we won't have to look at the P$ internals, because: The GIMP for Windows has partial support for P$ plugins; the plugin host being pspi.exe (source is available, but you need the SDK's header files to compile it). My thought is to look into altering pspi to work with the UNIX gimp ... By "partial support", I mean it handles many PiPL filter plugins (.8BF). To my knowledge, it does not support pre-P$ v2.5 plugins (PiKI), nor does it support the Automation, Selection, or Color Picker modules that are sometimes a part of P$ plugins. Also some filter functionality is missing (likely missing the system and Adobe color pickers, for example). Otherwise it works great (at least partial success with Flaming Pear, Xeno's (compiled FilterMeister) filters, Luce, Stroik's Rubber, etc). Notable for not working is Nic's various filters (which work in a checkboard fashion, some regions with filter applied/applied only partially, some without). Based on the date of the pspi source on his webpage, I'd bet he used either the 5.x SDK or the 6.0 SDK. In pspi's README, he says: It might be possible to make it work also on i386 Unixes (Linux, FreeBSD, Solaris), using Wine (www.winehq.org) to aid in running the code in the Photoshop plug-in. (Or some similar commercial software.) (No, I have no idea how this would actually be implemented, it's just my intuition that tells me it might be possible to attach a Windows DLL to a Unix process using Wine.) ... Pspi also now uses g_markup* functionality to parse its settings file. I don't think GLib 1.2.x had that, so if you really intend to run this on Unix through Wine, you have to extract the g_markup* functions from GLib 1.3.x. ... Pspi requires a GIMP that implements the init_proc functionality in the GimpPlugInInfo struct. As of now (2001-12-20), only GIMP 1.2.3 on Windows does that. For the patch to GIMP 1.2.3 to implement it, see http://bugzilla.gnome.org/show_bug.cgi?id=66859. [see that thread; GimpPlugInInfo is documented in /build-dir/devel-docs/libgimp/html/libgimp-gimp.html#GimpPlugInInfo, but it is not the solution Tor used for gimp-pspi-1.0.2, which is the latest I could find] So, a (the) big question is, how can we get this windows app to compunicate with UNIX processes? On Wednesday 26 November 2003 14:12, Dimitrie O. Paun wrote:
On November 26, 2003 01:44 pm, dim owner wrote:
Is it appropriate to write to this list in regards the "Fun Projects" on winehq?
Yes, it is.
I am interested in working on the gimp/photoshop plugin wrapper... and although I'm not so great a programmer, I have good resources (like the P$ 6.0 SDK).
That is a bit tricky, but it certainly is an interesting project. I can lend you a hand, I was actually thinking about it myself this morning :)
-- --r dorothy(a)oz:~> ls scarecrow tinman lion dorothy(a)oz:~> find . -name home There's no place like home.
On November 26, 2003 04:31 pm, dim owner wrote:
So, a (the) big question is, how can we get this windows app to compunicate with UNIX processes?
Well, indeed, this is the $10000 question. I don't much care at this point wether Gimp can work with the Plugins or not, what I care about is to export their interface in a an ELF library so that Unix processes can call them. This is non-trivial, so the first question is: What is the Plugin interface? -- Dimi.
Happy Thanksgiving! On Thursday 27 November 2003 00:10, you wrote:
On November 26, 2003 04:31 pm, dim owner wrote:
So, a (the) big question is, how can we get this windows app to compunicate with UNIX processes?
Well, indeed, this is the $10000 question. I don't much care at this point wether Gimp can work with the Plugins or not, what I care about is to export their interface in a an ELF library so that Unix processes can call them. This is non-trivial, so the first question is:
What is the Plugin interface?
Well! It would do this project no good if I were to break the agreement I made with Adobe in regards these SDKs (I have the AE and Premiere ones too). So, until I get a responce from Adobe or their maillist (I lost that agreement), I won't directly provide any details from the SDK itself. There's still plenty of information available online, though. To answer your question, check out this link: http://partners.adobe.com/asn/tech/plugin/index.jsp The PICA API document is still freely available, and is a pie-in-the-sky review of plugin programming (containing none of the headers, etc, that one needs to actually build a plugin, or investigate specifics). Section 2.3 describes the interface. The actual prototype for the main entry point is not in this section (of course, it is in the API guide in the SDK), but it is a pretty good and basic read. You'll also want to review the gimp-pspi (v1.0.2) source... it's available at Cinepaint's sourceforge downloads page, among other sites. The /pspi-source-root/src/pspi.c has the struct for the entry point. We certainly won't get 100% compatability: some/maybe many P$ filters call other DLLs ... not just windows DLLs but their own ; possibly to extend their functionality, but likely as a part of copy protection. But the idea of implimenting the entirety of interaction between host and plugin first seems a bad way to go about this (don't you think?). I would suggest we build a minimal DLL that is interactive (returns ++integer), and work on the UNIX end and Wine-dows host application from there. Afterwards, we can come back and make the Adobe plugin host... this has some notable advantages: : not quite so dramatically "non-trivial" : we would have all the source code for both the host and the module : we can modularize the interface, for different windows-linux interaction. : this would allow us to 'pitch' a working prototype to other projects' programmers (ie, we could get more resources to attack the problem) Either way, is fine really ... I'll happily follow your lead. Just my 2 cents. cheers, RobC --r dorothy(a)oz:~> ls scarecrow tinman lion dorothy(a)oz:~> find . -name home There's no place like home.
On Wed, 2003-11-26 at 21:31, dim owner wrote:
So, a (the) big question is, how can we get this windows app to compunicate with UNIX processes?
It's tricky. The easiest way is simply to convert the Gimp into a Windows program by compiling it with WineLib. No, I don't know how to do that, Dimi is the expert here. That means that in order to use Photoshop plugins in the Gimp you'd need a special build of the Gimp and Wine installed and setup correctly. That might well be acceptable, I don't know. Longer term it'd be nice to decouple them, maybe using RPC, or maybe by figuring out what stops us loading wine into an already initialized process.
This question comes up a lot. A similar project to below would be the use of windows ODBC drivers under unixODBC. (where/how does one add a "Fun project" suggestion) There are few example projects that do Just that. One is right here at home and for some reason these people do not want to come forward and spill the beans. So please people ... A. How is the Netscape-plugin-to-OCX works in CrossOver-plugin. Is that an out of process plugin embedded inside the browser X-window? What is the out-of-process (RPC) communication between the Netscape-plugin and the wine-OCX-host? What is the X protocol that lets one process host another process drawing? B. MPlayer, and others, are known to host Codec DLLs from windows like divx-avi and other. Do they use wine. or is it a code rip like the ndiswrapper (http://sourceforge.net/projects/ndiswrapper/) I think it looks like a wine derived loader. I have an idea/question: Is the out-off-process COM work complete? (It must be for OLE2 and office to work). What would be the difficulty of implementing Just the out-of-process COM client side as a stand alone library. Then an out-of-process (.EXE) "Control" could be written for any export type of functionality as above. and the COM client library used on the Linux side to interface with that Control. On the Linux side one has to have the: 1. CoCreateInstance( ...) 2. Virtual table stub functions that RPC to the Controls out-of-process object virtual table. 3. Map back of Event Objects (Opposite of 2) I do not see any reason why the same exact COM/wine code (OK with some modifications) could not be encapsulated inside a stand alone Linux library. Does above opens the possibility for a GNOME or KDE universal OCX hosting? Does above opens the possibility for a universal Hosting of KDE-parts and (what is the name of the GNOME Controls) in an OCX host like IE or word? Free life Boaz Mike Hearn wrote:
On Wed, 2003-11-26 at 21:31, dim owner wrote:
So, a (the) big question is, how can we get this windows app to compunicate with UNIX processes?
It's tricky. The easiest way is simply to convert the Gimp into a Windows program by compiling it with WineLib. No, I don't know how to do that, Dimi is the expert here. That means that in order to use Photoshop plugins in the Gimp you'd need a special build of the Gimp and Wine installed and setup correctly. That might well be acceptable, I don't know.
Longer term it'd be nice to decouple them, maybe using RPC, or maybe by figuring out what stops us loading wine into an already initialized process.
On Thu, 2003-11-27 at 17:26, Boaz Harrosh wrote:
A. How is the Netscape-plugin-to-OCX works in CrossOver-plugin. Is that an out of process plugin embedded inside the browser X-window? What is the out-of-process (RPC) communication between the Netscape-plugin and the wine-OCX-host? What is the X protocol that lets one process host another process drawing?
I don't know, but I think it uses out of process embedding with some simple IPC to control it.
B. MPlayer, and others, are known to host Codec DLLs from windows like divx-avi and other. Do they use wine. or is it a code rip like the ndiswrapper (http://sourceforge.net/projects/ndiswrapper/) I think it looks like a wine derived loader.
MPlayer uses a heavily hacked up version of the wine loader. Not sure about ndiswrapper.
I have an idea/question: Is the out-off-process COM work complete?
Partly, but with a few major caveats, like : we don't have the ability to do the full solution without some MS tools. AFAIK widl is not complete enough to replace midl, and it cannot produce TLB files. Maybe widl can spit out the old-style marshaller code, I'm not 100% sure. It's not feature complete. The wire protocol is not DCOM compatible.
(It must be for OLE2 and office to work).
Well, most use of OLE is in process to be honest.
What would be the difficulty of implementing Just the out-of-process COM client side as a stand alone library. Then an out-of-process (.EXE) "Control" could be written for any export type of functionality as above. and the COM client library used on the Linux side to interface with that Control.
Yes, you could use DCOM I guess, but the main problem is that it's really hard to implement using C and WineLib. I've written a COM object for Wine before, it was not much fun. More complex cases would be very verbose. It'd probably be easier to use something like DBUS. More to the point, in order to use DCOM you'd need to link Wine into the client process as well, at which point you'd need to make the app a WineLib app so you might as well just skip it and do it direct.
I do not see any reason why the same exact COM/wine code (OK with some modifications) could not be encapsulated inside a stand alone Linux library.
Our DCOM/OLE implementation uses the Windows API. It's not written to be standalone.
Does above opens the possibility for a GNOME or KDE universal OCX hosting?
If you wanted to do such a thing, something like ReAktivate or whatever it was called would work. I'd use DBUS rather than a hacked up custom RPC protocol though.
Does above opens the possibility for a universal Hosting of KDE-parts and (what is the name of the GNOME Controls) in an OCX host like IE or word?
Doubtful. That'd be quite hard, and depends on how similar KParts and Bonobo controls are. I'm not sure why you'd want to do that anyway - use cases? thanks -mike
On Thursday 27 November 2003 12:26, Boaz Harrosh wrote:
B. MPlayer, and others, are known to host Codec DLLs from windows like divx-avi and other. Do they use wine. or is it a code rip like the ndiswrapper (http://sourceforge.net/projects/ndiswrapper/) I think it looks like a wine derived loader.
I'm looking at the loader section of MPlayer now ... (all docs plus the archive still barely give you any idea what it is they are doing) They have what is called mini-wine (in the list it was referred to as this, at least) Since the documentation is so sparse, I was going to look around in other projects. Xine uses their win32 stuff, so I'll start looking there. In the meantime, any other projects you can think of that do this sort of thing? (ndiswrapper is a kernel module). Just for some basic info ... MPlayer fakes responces to system API on a per-codec-DLL basis, which means, for each new DLL, they add the necessary callbacks. I think this could eventually wind them into trouble if the dlls they want to use grew in the wrong way. But, the advantage, they don't have to process a video stream through a full wine, which gives them speed enough to make the DLLs useful. I don't know if speed will be such an issue for my purposes; I'm not outputting unencoded video ... hopefully this flexability (a full wine) lends enough compatability that I only need .specs for supporting DLLs for the plugins. Since their port includes the interface to the DLLs, it's still another resource to look at. That brings up the second question I have ... I'm not a windows person. Is there some tool that can query a DLL, kinda like objdump? --r dorothy(a)oz:~> ls scarecrow tinman lion dorothy(a)oz:~> find . -name home There's no place like home.
Hi, On Thu, Nov 27, 2003 at 06:04:29PM -0500, dim owner wrote:
On Thursday 27 November 2003 12:26, Boaz Harrosh wrote:
B. MPlayer, and others, are known to host Codec DLLs from windows like divx-avi and other. Do they use wine. or is it a code rip like the ndiswrapper (http://sourceforge.net/projects/ndiswrapper/) I think it looks like a wine derived loader.
I'm looking at the loader section of MPlayer now ... (all docs plus the archive still barely give you any idea what it is they are doing) They have what is called mini-wine (in the list it was referred to as this, at least) Since the documentation is so sparse, I was going to look around in other projects. Xine uses their win32 stuff, so I'll start looking there. In the meantime, any other projects you can think of that do this sort of thing? (ndiswrapper is a kernel module).
Just for some basic info ... MPlayer fakes responces to system API on a per-codec-DLL basis, which means, for each new DLL, they add the necessary callbacks. I think this could eventually wind them into trouble if the dlls they want to use grew in the wrong way. But, the advantage, they don't have to process a video stream through a full wine, which gives them speed enough to make the DLLs useful. Why speed? Maybe loading speed, but I doubt that it has anything to do with execution speed if you have a full Wine environment.
I don't know if speed will be such an issue for my purposes; I'm not outputting unencoded video ... hopefully this flexability (a full wine) lends enough compatability that I only need .specs for supporting DLLs for the plugins. Since their port includes the interface to the DLLs, it's still another resource to look at. That brings up the second question I have ... I'm not a windows person. Is there some tool that can query a DLL, kinda like objdump? Either tools/winedump/ or pedump (someone also ported it to Linux at some time).
Andreas Mohr -- Wir kommen alle als Original zur Welt, aber die meisten von uns sterben als Kopien (Autor unbekannt)
On Friday 28 November 2003 02:33, Andreas Mohr wrote:
On Thu, Nov 27, 2003 at 06:04:29PM -0500, dim owner wrote:
Just for some basic info ... MPlayer fakes responces to system API on a per-codec-DLL basis, which means, for each new DLL, they add the necessary callbacks. I think this could eventually wind them into trouble if the dlls they want to use grew in the wrong way. But, the advantage, they don't have to process a video stream through a full wine, which gives them speed enough to make the DLLs useful.
Why speed? Maybe loading speed, but I doubt that it has anything to do with execution speed if you have a full Wine environment.
hmm... I had read (on MPlayer's dev-eng) that speed was the reason for implimenting a win32 dll loader and mapping the linux functions to the dll's calls... There is possibly some speed benefit; wine has a full loop of processes to control, and if you use a full wine implimentation, you need a dll loader .exe with IPC in the windoze environment, or I guess rather, alter the wine executable and create an IPc mechanism that the dll loader can interface to, no? (ie, which is faster, a wine exe plus a UNIX process, or 2 unix processes, one with a very lightweight wine-like translation?) With their method, the dll win32 wrapper acts as interfaces with individual calls (the dll is modified to this end), so it has the look-and-feel of an .so To use this (MPlayer-esque) method, one would build wrappers individually for each plugin, to link to the interfaces in the dll... (that's not their method, they share the win32 interface ... but this would ensure that 2 plugins' requirements aren't mutually exclusive). Gimp plugins are executable, BTW. Either way, it isn't a good dynamic solution. It's a mess, IMHO.
That brings up the second question I have ... I'm not a windows person. Is there some tool that can query a DLL, kinda like objdump?
Either tools/winedump/ or pedump (someone also ported it to Linux at some time).
Awesome, I'll dig right in. :) --r dorothy(a)oz:~> ls scarecrow tinman lion dorothy(a)oz:~> find . -name home There's no place like home.
"Dimitrie O. Paun" <dpaun(a)rogers.com> writes:
Now, before I go search for the ABI about returning small structures, can someone tell me if there is any way to maintain both source and binary compatibility?
The ABIs are different so you cannot directly use the same function in both cases, but some clever macro hacks should be able to work around that for the source case. -- Alexandre Julliard julliard(a)winehq.com
"Dimitrie O. Paun" <dpaun(a)rogers.com> writes:
If you have any suggestions on how such a macro might look like, I'm all eyers!
I'd suggest something along these lines: Index: include/msvcrt/stdlib.h =================================================================== RCS file: /opt/cvs-commit/wine/include/msvcrt/stdlib.h,v retrieving revision 1.14 diff -u -p -r1.14 stdlib.h --- include/msvcrt/stdlib.h 28 Oct 2003 21:13:13 -0000 1.14 +++ include/msvcrt/stdlib.h 26 Nov 2003 21:03:17 -0000 @@ -242,6 +242,28 @@ static inline _onexit_t onexit(_onexit_t static inline int putenv(const char* str) { return _putenv(str); } static inline void swab(char* src, char* dst, int len) { _swab(src, dst, len); } static inline char* ultoa(unsigned long value, char* str, int radix) { return _ultoa(value, str, radix); } + +#ifdef __i386__ +static inline div_t __wine_msvcrt_div(int num, int denom) +{ + div_t ret; + __int64 res = div(num,denom); + ret.quot = (int)res; + ret.rem = (int)(res >> 32); + return ret; +} +static inline ldiv_t __wine_msvcrt_ldiv(long num, long denom) +{ + ldiv_t ret; + __int64 res = ldiv(num,denom); + ret.quot = (long)res; + ret.rem = (long)(res >> 32); + return ret; +} +#define div(num,denom) __wine_msvcrt_div(num,denom) +#define ldiv(num,denom) __wine_msvcrt_ldiv(num,denom) +#endif + #endif /* USE_MSVCRT_PREFIX */ #endif /* __WINE_STDLIB_H */ -- Alexandre Julliard julliard(a)winehq.com
On November 26, 2003 04:08 pm, Alexandre Julliard wrote:
I'd suggest something along these lines:
Works like a charm Alexandre, please commit it. (Sorry to make you do the work, I had to leave the moment I wrote this, I figured out what I needed to do right away, but you bit me to the punch! Much appreciated!!!) -- Dimi.
participants (6)
-
Alexandre Julliard -
Andreas Mohr -
Boaz Harrosh -
dim owner -
Dimitrie O. Paun -
Mike Hearn