Bertho Stultiens <[EMAIL PROTECTED]> writes:
> I am not suggesting to build libunicode.so, but I do suggest to build
> libunicode.a, which can be linked against. This should not require a
> special API if it only concerns tables. The point is that libunicode.a
> should be selfsufficient so that you can take it out of wine's context
> just far enough so that it becomes usable in a wider sense.
Agreed, we need something like that to solve the bootstrap issue
anyway. But I think it would be quite wasteful for a Winelib
environment to have copies of the Unicode tables inside libwine, wrc
and wmc; it seems it would be useful at least as an option to link the
installed tools with libwine.so instead.
> I agree that we shouldn't extend the private API (too much), but merely
> say that we should consider it to be with enough generality to be used
> in a wider context. This is by no means a limitation, nor bloat, but
> "foresight". Code-reusability (especially static data-reusability) is a
> big advantage in this context and IMHO a good idea not to enforce large
> chunks of code upon "mere utilities". The Windows API, unfortunately,
> has the side-effect of dragging in a lot of unwanted code as well.
True; OTOH it is convenient to be able to use small basic functions
like SetLastError or critical sections even in functions that are
otherwise quite independent of the Windows API. I think ultimately
libwine.so should be just that: a collection of the small basic
functions that are used everywhere, plus a dll loader. All the rest
should be moved off to separate dlls.
--
Alexandre Julliard
[EMAIL PROTECTED]
