Re: [Whisper2-develop] Macros in whisper

[Miro J. <me...@me...>]

>>    1 NOIME
>>    1 NOMCX
>>    1 WIN32_LEAN_AND_MEAN
>
>The original Windows SDK had a lot of stupidities. One of these was 
>that MS dumped *everything* into <Windows.h>. Over time including 
>this header, which every Windows app had to, became a bottleneck. 
>So, MS defined some macros that you can define to minimize the 
>amount of extra crap included via <Windows.h>. That's what the above 
>macros do: they #ifdef out some infrequently used declarations.
>
>>    1 NOMINMAX
>
>Yet another sin of Microsoft's headers is that they #define a *ton* 
>of lower case macros. This includes macros for min and max which 
>conflict with STL. This macro disables those defines.
>
>>    1 NOSERVICE
>
>I think this is the same as the NOIME and NOMCX macros
>
>>    1 REPLACEFILE_IGNORE_MERGE_ERRORS
>>    1 REPLACEFILE_WRITE_THROUGH
>
>These two are defined in newer versions of Microsoft's headers. 
>XDocument.cpp defines them under older versions of the headers 
>because ReplaceFile can still work if the OS is newer than the 
>headers.
>
>>    1 STRICT
>
>The original Windows headers used void*'s for the many different 
>HANDLE objects in the API (HWND, HMENU, etc). This was obviously 
>brain-dead and lead to a lot of type errors so Microsoft added the 
>STRICT macro which you can set to make stuff like HMENU and HWND 
>distinct types.

Ok, so all of those occur precisely once, where they are defined in 
the precompiled header, and given your explanation, it sounds like 
they should stay they way they are.


>>   10 _WIN32_DCOM
>>   17 _WIN32_WINNT
>
>These two are defined in Microsoft's headers. I don't remember the 
>details, but _WIN32_WINNT is a version number for the headers. I 
>think _WIN32_DCOM is defined if you're building a distributed COM 
>app.

We have over 10 places where we use:
#if (_WIN32_WINNT >= 0x0400) || defined(_WIN32_DCOM)
... CoInitializeEx ...
...

Basically, one in each app. If this has to be written in each app, we 
should abstract it in some way -- perhaps Whisper::CoInitialize needs 
to be thrown in? -- but I have no clue what the right thing is, and 
nobody has picked up the task of maintaining the Windows targets yet. 
My recommendation is that we mark these somehow and revisit them 
later, unless you or someone else has a suggestion for abstracting 
them.

>>    2 UNICODE
>
>This is defined by Microsoft's headers if you are building a Unicode 
>version of your app. If this is the case all of the Window's API 
>routines that take char*'s will want to take Unicode char*'s instead.

Do we actually support using Whisper with UNICODE not defined?

>>// Misc
>>    2 INFINITY                       // Huh?
>>    2 NAN                            // Huh?
>
>I think these are now standard, but they weren't defined in MSVC. So 
>Whisper defines them on Windows.

Ok. I don't know if they are standard now, and I suppose we'll find 
out if there's a conflict when we get around to trying to bring the 
Intel targets up.

>>    1 MSIPL_MEMBER_TEMPLATE          // Huh?
>>    1 MSIPL_TEMPL_NEWSPEC            // Huh?
>>    3 MSIPL_DEBUG_MODE               // Huh?
>>    2 MSIPL_DEF_EXPLICIT             // Huh?
>
>These were used with the Metrowerks std library. Most of them are 
>obsolete now I think.

Oh, yes. I remember now. According to the headers they were 
eliminated in Jan 99, so Whisper should not use them any longer. I 
don't think we'll be supporting CW Pro 4 :-)

>>    3 QUESA_SUPPORT_QUICKTIME        // huh?
>
>This is mostly for Windows where you might want to build a Quesa app 
>without requiring that QuickTime be installed.

Would its definition come from Quesa SDK? I don't see a definition, 
only use, in ours.

meeroh
-- 

<http://web.meeroh.org/> | KB1FMP

A: Because it reverses the logical flow of conversation.
Q: Why is top posting frowned upon?