> Just a quick question : your program should generate code from an
> existing windows dll if I understand correctly ? I wonder if this fits
> the definition of 'clean room implementation' that is somewhat required
> in some countries to develop a compatible Api.
Well, it simply automates the process you'd go through manually when creating
a Wine dll: run pedump, create a spec file, get any function definitions from
headers or other sources, and create a dummy DLL containing the same
interface. Its only the (public) *interface* of the dll that is interrogated
(exported functions and header declarations). The *implementation* is never
touched, and no dissasembly or reverse engineering takes place.
So, provided the manual method is kosher I can't see any problem with
automating the process. IANAL, but I cant see how anyone can object (legally
speaking) to using prototypes from publicly available headers. How do you
differentiate between programmers calling your interface in their application
code, and programmers calling that interface into their own code?
I could understand it being troublesome if the implementation code of the DLL
was being read. However, its only the exports table. Borlands IMPLIB utility
does the same thing, and that is surely legal; given they compete(ed) in the
compiler space with ms, if it wasn't they would have been sued by now.
In any case, there are only so many DLLs that need to be implemented for Wine
itself. Perhaps more use will be made for Winelib programs that want to use
3rd party libraries only available in dll + header form.
Jon
--
"May their negative actions ripen upon me. And may all my virtues ripen upon
them."
"If it could be talked about, everybody would have told their brother."
[EMAIL PROTECTED] , [EMAIL PROTECTED]
