Issues raised by the red windows build
matsl at xemacs.org
Sun Dec 11 04:47:52 EST 2011
I thought it was time to turn the last red build into a green one. We
have had that one for a very long time. I thought it would be a simple
type mismatch that possibly could be handled with a cast. But...
When I looked into it I realized it was much harder and that it raises
a number of questions.
- First of all the problem is the same with the other windows builds
but these are built with gcc and the one that fails is built with
g++. c++ is a bit harder on type mismatch causing errors instead of
Conclusion: All windows builds ought to be fixed.
- Fixing it is both easy and hard.
- Fixing it is hard because unicode support on windows seems to be
a can of worms.
If I get it right we are also trying hard to build one binary
that will work on all windows flavors going back to Windows-98
(or even further?) This doesn't make things easier.
The current cygwin version has dropped support for the old
versions of windows. This raises the question.
Q: Can we drop that support to?
Since I don't understand the code fully I'm not sure but it feels
like that your code will be simpler if we could drop the runtime
check on Windows version. Later versions of Windows might have
more stable APIs making our code even simpler?
- Fixing it is easy because these functions that causes the error
We could simply remove them. If I get it right there is in
intl-auto-encap-win32.c and intl-encap-win32.c a small framework
for supporting windows APIs that could potentially be used. So
they are ready to be used once we need them. It also has trip
wires to alert you when using the wrong function names.
Am I missing something here? Are they maybe useful for users
writing there own modules so removing them would be a bad idea?
Is the framework really paying of? It seems strange to me to have
a bunch of loose functions hanging around. (If I fix the error
how would I know that I did it right?) But I guess once I would
need a function in the framework I would be grateful that it was
already provided (if it was implemented right that is!)
More information about the XEmacs-Beta