bug#8562: Emacs 23.1 and later don't work in windows 98

[oslsachem]

>> So I'm going to put calls to the function GetLastError after each call
>> to each of these unicode functions to see what happens.

I have only observed that:
- Emacs chooses the ansi versions of the functions LookupAccountSid
and GetFileSecurity.
- The next problematic unicode function is GetGlyphOutlineW which,
like GetOutlineTextMetricsW and GetTextMetricsW, is just a stub.

The breakpoints I have set for the calls to the other unicode
functions are never reached before the Emacs window is opened and is
"operative" and then, after a while, I simply quit.

http://www.speedyshare.com/files/28808320/Emacs-23.3GDBGetErrors.txt

> An alternative would be to download and install libunicows from here:
>
>  http://libunicows.sourceforge.net/
>
> and then manually add "-lunicows" before all the other -lFOO libraries
> on the link command line in src/makefile, and rebuild Emacs.  If that
> binary works, then we at least will know that the linking against
> unicows.dll is the root cause of all these problems.

I have compiled the unmodified officially released source code of
Emacs-23.3 with assertions enabled and libunicows. And the binary
works.

http://www.speedyshare.com/files/28808321/Emacs-23.3Working.png

http://www.speedyshare.com/files/28808322/Emacs-23.3ToolTip.png

However, Emacs still chooses the ansi versions of the functions
LookupAccountSid and GetFileSecurity, presumably because it bases the
decision on checking the version of Windows and not on whether the
functions are actually available.

http://www.speedyshare.com/files/28808323/Emacs-23.3GDBlibunicows.txt

> Whether to switch to linking Emacs with libunicows or manually load it
> on Windows 9X and call the Unicode functions through function
> pointers, is a different issue.  Given the small number of affected
> functions, I'm not sure what's best.

IMHO, using function pointers would mean increasing the number of
lines of explicit code, whereas using the unicows loader would open up
the possibility of decreasing the number of lines of explicit code by
unifying w9x/Me and NT/XP branches of code which handle cases of
unicode support.
On the other hand, I can imagine that the introduction of the
libunicows dependency may be an annoyance to users/developers who
don't actually need to make use of it on their systems. Perhaps this
could be addressed with a new configure option?

Greetings,
                 Osl