2009/2/15 Dan Kegel <d...@kegel.com>: > On Sat, Feb 14, 2009 at 5:11 PM, Ben Klein <shackl...@gmail.com> wrote: >> You obviously don't understand how Wine works. It's not in win32, nor >> is it in any other API standard Wine has to deal with (such as >> Directx). It won't be shipped with Wine. > > I think that's not quite true. There are a couple supported > wine extensions to win32, aren't there? I think there's > an ioctl to get the unix path, or something...
>From what I understand, they're not accessible to full win32 apps. 2009/2/15 Martin Hinner <mar...@hinner.info>: > I understand this and in my opinion (if there will be any "official" > WINEGATE.DLL) I can't speak for the people who make these decisions in the Wine project, but I don't believe winegate is or will ever be a candidate for inclusion in Wine. If there's a good reason, it's thos: > Yes, the WINEGATE.DLL is not solving any problem on its own, it just > simplifies "porting" process. If it doesn't solve a problem, it doesn't make it much easier. In any case, that's what winelib does too, you know, make porting easier. And from what I understand, you can just as easily use a winelib wrapper around a win32 application. > I don't want to be rude, but I have better things to do than > propagandize my solution. We can live without such library in Wine, it > would just require us to maintain separate libraries for different > libc or wine versions. If you foresee that you will have to maintain different versions of your library for different libc or Wine versions, you have big design flaws. It should "just work" without requiring maintenance. The Linux component may require a recompile on occasion to keep up with a change in libc (more likely frequent recompiling/code maintenance due to changes in the kernel every time you upgrade).
