> Perhaps it is Vader-style evil, after all. Today I've had the "intense
>pleasure" of spending about three hours trying to understand why was I
>able to do a MinGW build on one computer and GNU make ab-so-lu-te-ly
>refused to work on another, identically set-up machine... till it
>finally dawned on my that I had forgotten the "cvs update -kb"
>incantation on nt/ (I don't usually read nt/INSTALL because I'm quite
>familiar with its contents).
>Great. Just great.
Perhaps it is not evil. Perhaps it helps us think (more). Maybe someone
with big knowledge can add a test to makfile.w32-in that will found out
whether the file is converted or not and tell those that dare to use it.
> Jason Rumney wrote:
> > Rather than patch the source, can you please try to debug the startup
> > code at the bottom of w32menu.c that decides whether to use Unicode
> > menu names. Does Windows ME have a stubbed out version of
> > unicode_append_menu (AppendMenuW) that does nothing? The code assumes
> > that if its not supported, that function is not present.
> The last time I debugged C was more than a decade ago. If you told me
> exactly what and how to do I could try.
Set a breakpoint at the start of the function globals_of_w32menu() in w32menu.c
(currently line 2541).
Step through the function, taking note of the value that is assigned to
unicode_append_menu. If it is NULL at the end of the function, then that is
what I would have expected and the bug is elsewhere. If it is not NULL, then we
need to find some other method of finding out if unicode menus are supported.