On Thu, Feb 11, 2010 at 6:55 PM, Ozkan Sezer <[email protected]> wrote: > On Thu, Feb 11, 2010 at 11:21 PM, Kai Tietz <[email protected]> wrote: >> 2010/2/11 Ozkan Sezer <[email protected]>: >>> Regarding this thread from today: >>> http://sourceforge.net/projects/mingw-w64/forums/forum/723798/topic/3550908 >>> >>> Our dshow.h (seems to be based on an old wine version) >>> is broken due to missing extra headers that it depends >>> on. >>> >>> I included the lastest versions from wine-1.1.38 here >>> (see the attached wine_version.zip: includes the missing >>> *.h files, as well as the latest dshow.h as it is in wine >>> project.) (A note about our old version of dshow: For >>> who know whatever reason, we seem to include dmdls.h and >>> then define VIDEOINFOHEADER...) >>> >>> There is also the version in w32api of mingw/cygwin, for >>> that, well, get the latest w32api package. >>> >>> The two versions are different, though. One version depends >>> on one header, the other depends on another, and the >>> difference is not just in the names of the headers, also >>> in their contents, too. For example, Wine version doesn't >>> include these ones, but mingw version does: >>> amaudio.h (commented out with a fixme) >>> dvdevcod.h (wine doesn't have one, ) >>> vidcap.h (we can use ks.h instead) >>> vptype.h (we have ksmedia.h instead, it has the struct names >>> prefixed with KS_ ) >>> bdatypes.h (neither wine nor we have this one) >>> il21dec.h (neither wine nor we have this one) >>> dvdmedia.h (we dont have this. wine does, but doesnt include) >>> >>> Among this mess, I don't know which set is reliable, because >>> I don't know a thing about dshow, and I don't know what good >>> can result from blindly adding the attached wine version, so >>> please advise. >>> >> >> Well, in general I would say that Wine headers are more trustable >> here. The w32api I distrust in some points pretty strongly. Bad side >> here is, that a lot of projects possible adjusted their code in >> direction of w32api here. But IMHO we should trust in Wine headers >> here. >> >> For the missing headers you see, we should do some research on msdn >> for them and find out, if they are part of standard, and if so, what >> they really contain. Information for this should be possible (at least >> in most cases) by the direct-x API shown on msdn. >> >> Kai > > Ok, updated the svn using the wine version of the headers: > r1895, r1897 for the trunk, and r1896, 1898 for the 1.0 branch. > Let's see how this turns out (can't be more broken than how > it already is ;) Also notified rubenv about the update. > > As for the extra headers only present in the cygwin/mingw > repo, I may wrestle with the msdn site for it, although not > immediately.
Ideally, we can have one common set between our project and wine. Perhaps if we can get a very good set of headers (via msdn or otherwise) we can work with the wine folks to have one set. I'm always pushing for getting rid of repository duplication, as it only creates cacaphony. ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
