[dropped xemacs-patches from recipients]
With your path, I got over that error. Now it is the case with
I feel there are lot of problems with Win32API portability. We should
be more carefully before using those.
I don't think any of those are used in XEmacs - Ben was a little
over-eager in adding functions to intl-encap-win32.c.
I have a suggestion. In the make or configure we should find out
whether those API's are available on the OS. We can have a executable
which will take the function name and DLL name and return TRUE or FALSE
based on whether it is present in the DLL or not. Using this info,
generate the related files (intl-*-encap-win32.*).
I don't think that's necessary in general. XEmacs doesn't really need
the newer functions. The problem lies in the way that we try to get
portability across ANSI and Unicode versions of win32 -
intl-encap-win32.c ends up referencing every function listed, whether or
not XEmacs uses it.
I am in the process of weeding out the unsupported methods. Will get
back later if I have more.
That would be great. Please post a patch to xemacs-patches when you're done.
The whole process is slow as I have to do a make clean after each
modification and make again to reflect my changes.
No you don't. Install perl (if you haven't already) and set DEPEND=1 in
For each function (eg SHInvokePrinterCommand) in intl-encap-win32.c,
change the comment from "yes" to "no ... Win98/2K+ only". Rebuild
nmake -f xemacs.mak unicode-encapsulate
nmake -f xemacs.mak
This should be much faster than a build from clean.
Jonathan Harris | jhar(a)tardis.ed.ac.uk
London, England | Jonathan.Harris(a)symbian.com