Stub implementation of CABINET.DLL

Patrik Stridvall ps at
Tue Nov 19 15:53:16 CST 2002

> >However, when I saw that not much happend despite
> >getting code from cabextrect under LGPL I thought
> >that perhaps people were having trouble on how
> >to create a new DLL in Wine and how to extract
> >the declarations from the Microsoft header without
> >creating a derived work. I have done it many
> >times before so thought why not do it...
> >
> >So I very happy that somebody is intrested in continuing.
> >
> >PS. If anybody have some other DLL that they wish to implement
> >but don't now how to do it, don't hesitate to ask me to
> >create a stub DLL with related headers.
>   If it is not too much effort, could you elaborate on the
> derived work issue.  I have been thinking about trying to
> stub out, then work at implementing, a particular component.
> Rather than have someone else do the work, I am more
> interested in learning about doing it myself, and about
> any issues (legal and technical) involved.
>   I am not asking for a complete howto here, but even a
> summary of the highlights would be quite valuable (to me
> at least).

First of all copyright doesn't protection facts or ideas only
a specific (and unique) expression of facts and ideas. This
is normally called a work.

Specifically it doesn't protect any underlying functionally
inherent or derivable from the work. This is normally called
the implementation of the functionallity.

Even more specifically it doesn't protect the way interaction with
any functionallity, that is possible to derived from the work, is done.
This is normally called the interface to the functionallity.

Header files for the most part defines interfaces; more specifically
constant declarations (read: defines), function declarations,
type declarations and. So all such things are free for taking.

However netherless the less, the header file is not entirely free
of possible protected expression. Specifically:
1. Formatting
3. Inline functions and complex macros

I will address each them in turn.

Formatting is not normally any problem since there are not that
many way to format C declarations, none of which is likely
to be unique to Microsoft, let alone expressive. Still I always
format the new file in a way I personally like, just in case.

Comments are are probably the largest proplem. They are not strictly
part of the interface so if you are unsure you can just remove them.
In most cases, in fact the intresting cases,  however they contains
facts about the interface. Note however I said _contains_ facts not
are facts. Part of them might be protected expression so we have to
be careful here. 

Again, note that in order to be protected an expression have to unique
as well as expressive. Most short sentences are neither unique, nor are
they expressive, they just explain the facts in some straight forward way.
Still if the not formulated in a way I as well would use the express myself
I rewrite them.

As for longer sentences and specificially multi sentence paragraphs.
I usually delete or reformulate and often shorten it using my own words.
The comments are, as I said, not strictly needed in for the header
file to work.

Inline function and complex macros can be a little tricky. However they
are usually rare so rewriting them in a way I would have written it is
not that much work and functinallity in itself is I said explain above
not protected by copyright.

More information about the wine-devel mailing list