Is a shame that a lot of discussions on wine-devel has to end like this.
A new people propose something that he things is the solution to a problem he has in wine.
And all the 'established'  developers try to find as much

   
It is unfortunate that many discussions here on wine-devel to end this way.
A new developer thinks he has solved a problem he has in wine, and wants to share the solution with the rest of the community.
And 'the established'  developers try to find as much issues they can find with the implementation to prove that what they have written has no problem but is so by design  

Maybe it would be better to to have a more constructive respond and to thank the developer for his attempt to share his work with the community

And after that then to see if:

- it is the right solution.
- needs a better implementation
- already has a implementation but needs better documentation.
- other.......


kind regard,

Marco

 

Martin Hinner schreef: 
On Mon, Feb 16, 2009 at 12:14 PM, Francois Gouget <fgouget@free.fr> wrote:
  
From what I understand, they're not accessible to full win32 apps.
      
FWIW, it's kernel32.wine_get_unix_file_name(). So it's available to any
Win32 application that knows about it. Just LoadLibrary()+GetProcAddress().
    

This is really nice end of our conversation,  giving new dimension to
all sharp statements (hack, not going into wine, etc) :-).

Just to add few comments at once, the problem is solved for us
(libwinegate.dll.so is shipped with the software, we'll have to
recompile it when libwine/libc changes...), so there is no need for
other argumentation. I have already given up.

Regarding to maintenance of linux library, I meant to have different
BINARY versions (because of other dependencies), not source code.

And finally regarding putting WINEGATE to some wiki: Feel free to do
it, consider it public domain. But I think the point of this library
was that if it is compiled WITH wine package, it would smoothly solve
dependency problems (i.e. no need to carry separate
WINEGATE-libcX-OSy-platformZ libraries).

Martin