Eli Zaretskii <[EMAIL PROTECTED]> writes: >> From: David Abrahams <[EMAIL PROTECTED]> >> Cc: emacs-devel@gnu.org >> Date: Wed, 08 Jun 2005 11:46:58 -0400 >> >> Sorry, but I have a lot on my plate, so once I start waiting a few >> more days it's likely to drop off my radar screen. > > We all need to cope with this.
I know. If it drops off my radar and off your radar, it's really gone, isn't it? ;-> Look, I wasn't rude (I don't think) and everyone is free to ignore me if they need to. >> Agreed, but I think the use of -D_WIN32_WINNT=0x0400 on the compiler >> command-line may be similarly bad (and is the reason I transcribed >> those constants). > > Jason, could you perhaps tell why this compiler switch is used? If > that is because we don't want to use features that are unavailable in > older versions of Windows, we could replace that with run-time checks, > like the one I suggest below, can't we? Seems like a good idea to get a compiler error if possible. OTOH it does make using more advanced features, even when protected by runtime checks, unreasonably difficult and messy. Also the name _WIN32_WINNT is reserved to the implementation and unless we're given specific permission to #define it, doing so is ill. FWIW. I don't know whether that permission is granted for _WIN32_WINNT. >> SPI_GETFONTSMOOTHING >> >> This one is in fact available for _WIN32_WINNT == 0x400; I should >> have used it directly. >> >> SPI_GETFONTSMOOTHINGTYPE >> FE_FONTSMOOTHINGCLEARTYPE >> >> These two are only enabled for _WIN32_WINNT >= 0x0501 >> >> >> > where they are defined, >> >> WinUser.h, IIRC > > The MinGW version of winuser.h doesn't have them; perhaps that's a > MinGW bug. So I think we need to condition the code on > SPI_GETFONTSMOOTHINGTYPE being defined, or perhaps provide a fallback > definition in src/s/ms-w32.h for MinGW. The latter seems better. Why should people who get a MinGW-compiled executable suffer ugly characters? >> > Finally, MSDN seems to indicate that SPI_GETFONTSMOOTHINGTYPE is >> > unsupported on Windows 9x, so it sounds like your code should be >> > disabled for those versions of Windows. >> >> Right, I should use an #ifdef _WIN32_WINNT >= 0x0501 ... except of >> course that the build process subverts that by forcing _WIN32_WINNT to >> 0x400. > > I meant a run-time check, not a compile-time check (because Emacs > built on XP could then be run on Windows 98, for example: think binary > releases). Ah, of course. But on second thought, I considered this question when I wrote the code. The calls will return an error on Win98 anyway because the constants are unsupported, and most of the code will be skipped. Unless you're concerned about optimizing away the call into Windows altogether (which I'm guessing is not worth the complication), you don't need an explicit check. > We have a global variable os_subtype which can be used for such a > run-time test, I think. When we settle what to do about the #defines I will submit a new patch... >> > A ChangeLog entry for the patches would also be nice, btw. >> >> I will be happy to write one. I assume the format to follow is used >> in the ChangeLog file at the top of emacs' CVS tree? > > Yes. And in addition, the GNU Coding Standards (standards.texi) which > you can find on the GNU Web site, has a section about writing > ChangeLog entries. ...including one for the ChangeLog -- Dave Abrahams Boost Consulting www.boost-consulting.com _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
