Alexandre Julliard wrote:
> > I am currently implementing the Wine Message Compiler (wmc: as an
> > alternative to mc.exe). I need to implement quite a bit unicode support
> > for it to function correctly. Unicode requires a lot of tables for
> > conversion and I did just that for nearly all codepages (from
> > ftp.unicode.org).
>
> I have been working on that with Dmitry Timoshkov, so it sounds like
> we may be doing duplicate work here...
Eh, what are you implementing? Message compiler or Unicode support?
My version of the message compiler is 90% done at the moment and lacks
generation of output (shouln't be too hard anymore to get the rest in).
This work was an extension to the implementation of nearly all other
resource types in wrc.
The unicode support is done w.r.t. the needs of the message compiler,
but then I started thinking of wrc and wine (and the size of the
tables).
[snip]
> I'd prefer to have all of that inside libwine.so, and use the standard
> APIs to access them; now of course if we need the message compiler to
> build libwine we have a problem. It may be possible to link a
> temporary message compiler with only the unicode objects, and then
> build the final version once libwine.so is built.
That is exactly the problem. You mention bootstrapping, but I don't like
that option at all because wrc also needs unicode support (ultimately).
I want to keep wrc absolutely free of wine-requirements (other than a
header or so) because it is used outside the scope of wine and I don't
see any reason for adding libwine.
So, three modules want to use unicode support, which leads to the
obvious conclusion to make it a separate loadable (or simply linkable)
module (be it in one or in separate parts). Both wine and others would
benefit from it, as I see more uses for a good implementation then the
three here. Keeping unicode tables in a separate module will be easy
considering that you already would require a bootstrap version. Why
rebuild at all?
[snip]
> I don't think we want to rely on libc at this point; maybe in a few
> years most systems will have proper Unicode support in libc, but this
> is not the case yet.
Just my thought.
> > Another thing that I noticed was that a lot of the NLS data (ole/nls/*)
> > is plain wrong. I need the language/codepage identification for wmc. A
> > lot of different countries have exactly the same language-id, which is
> > not possible in real life... Are these files used? Is anybody
> > maintaining them? Are there plans for changing the
> > location/content/interpretation? And, shouldn't they also be runtime
> > loadable, instead of occupying memory?
>
> They could do with some amount of bug fixing yes, and maybe with a
> more efficient storage structure. I don't think they need to be
> runtime loadable, demand-loading does that for us.
Also here I would suggest that we build a substructure that is usable as
a module for the same reason as above.
Greetings Bertho
