Since the windows kernels are based on 2 phases; place an assembler (code not a compiler) capture layer under the win codec and a translator to mac based replies from win apps. It has been years since I coded in assembler but the basics, even in 64 bit translation should be the same. JJEK
Already this is partly done. jjek this shows you have not really been through the wine wiki. Particular codecs ie the ones wine provides normally use the system provided libraries. Opengl is also done this way. In wine they are called wrappers. Issue is going the otherway. There is the wiki.winehq.org/WinePluginApi horrid complex problem. Since Apple and Posix based systems have complete different ideas how things should operate compared to a Windows system. So yes it has to be a specialist embedding API. Its basically not possible to recycle any of the normal embed windows in windows because messages the windows parts will send will not be mappable in OS X or Posix systems. We know it can be done because xine and mplayerhq have pulled it off in a hacky way using there own custom versions of wine. Yes windows direct show codecs use different messaging system to gstreamer and apple QuickTime codecs and that far different you cannot map. So perfect integration is basically up the creak past any option of doing. New cross platform API/ABI will be required to be able to use windows codecs from native applications. And applications would have to specially support Windows codecs. We are looking for a coder to take on this nightmare. jjek basically sounds simple until you start looking at the fine details and find the huge amounts of incompatibility.