Hi...
> > The utf-8 support for Windows was my idea and my patch, so I feel
> > responsible for the problems
> > [...]
> > > > OS (bug #346367).
> > Ok.. I will adress that, too. Did not know that there is a bug report.
> >
> > At present I am awfully busy, but I hope I can supply my revised patch
> > (based
> > on libxml 2.6.26) by beginning of next week.
> >
> > I hope this will solve all problems with win9x and non utf-8 encoding
> > without
> > adding new api. Would this be ok for everyone?
>
> That sounds excellent to me. I didn't expect a new release within a
> couple of weeks so even if it takes a bit of time it is not a big deal,
>
> Daniel
Here comes my revised/extended patch.
What is the state now:
In the case that a path cannot be accessed on disk asuming the path to be in
utf-8 on windows, it is also tried with native encoding now as fallback. That should
fix the first part.
Because of win9x compatibility it is now decided on runtime whether a system
is capable of calling _wstat()/_wfopen(). If the system is not capable doing it,
my utf-8 part is invisible. This should also fix bug #346367. But well, I do not
have a win9x installation so I implemented it blind but it *should*really* work.
(OT: Is win9x nowadays really of any relevance for professional applications?
We dropped support for it several years ago, and nobody really complained. But this
is a different discussion, but someday libxml2 should IMO also declare End-Of-Life
for win9x.)
When doing the patch I found 2 static functions in xmlIO.c doing quite the same thing.
xmlSysIDExists() and xmlNoNetExists(). In favour of simplicity I decided to discard xmlSysIDExists().
So I hope this resolves all pending issues. Feel free to reply in case of any problems.
Roland
PS: Now with patch attached... Sorry...
xmlIO.c.patch
Description: Binary data
_______________________________________________ xml mailing list, project page http://xmlsoft.org/ [email protected] http://mail.gnome.org/mailman/listinfo/xml
