RFC: Should the headers remain in near ascii collation order?

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

RFC: Should the headers remain in near ascii collation order?

Earnie Boyd
As I've been reviewing our headers, it is quite obvious to me that if
we segregate the OS, etc specific filters toward the end of the file
rather than leaving them in collated sequence we would have a slimmer
more elegant design.  Needing to #if (_WIN32_WINNT >= 0x0500), etc
more than once in a file is rather hideous, IMO.  Some of our files
have the same filter numerous times making it nearly difficult to
determine what is included.  I'm thinking that one of the following
styles be used and anything that is equal to WIN95 be common and
everything else be moved toward the end of the file with a construct
of one of the following.

#if (_WIN32_WINNT >= _WIN32_WINNT_WIN2K)
...
# if (_WIN32_WINNT >= _WIN32_WINNT_WINXP)
...
#endif
#endif

or

#if (_WIN32_WINNT >= _WIN32_WINNT_WIN2K)
...
#endif

#if (_WIN32_WINNT >= _WIN32_WINNT_WINXP)
...
#endif

Comments?

--
Earnie
-- https://sites.google.com/site/earnieboyd

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Should the headers remain in near ascii collation order?

Charles Wilson-8
On 9/4/2012 4:43 PM, Earnie Boyd wrote:

> I'm thinking that one of the following
> styles be used and anything that is equal to WIN95 be common and
> everything else be moved toward the end of the file with a construct
> of one of the following.
>
> #if (_WIN32_WINNT>= _WIN32_WINNT_WIN2K)
> ...
> # if (_WIN32_WINNT>= _WIN32_WINNT_WINXP)
> ...
> #endif
> #endif
>
> or
>
> #if (_WIN32_WINNT>= _WIN32_WINNT_WIN2K)
> ...
> #endif
>
> #if (_WIN32_WINNT>= _WIN32_WINNT_WINXP)
> ...
> #endif

Both of these styles only work if you never have a situation where: a
definition applies for $oldWindows, but should NOT be supported for
$newWindows.  I *THINK* this requirement is satisfied by the w32api part
of things, given Microsoft's oft-derided backwards-compatibility fetish
when it comes to the *syntax* of their API (the *sematics* of that API
seems to change with the wind, however).

Now, on the mingw-rt side of the fence, I think we probably do have
items that are defined one way for $oldWindows but another way for
$newWindows -- plus there's 32bit vs. any 64bit additions.

--
Chuck

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Should the headers remain in near ascii collation order?

Earnie Boyd
On Wed, Sep 5, 2012 at 12:31 AM, Charles Wilson wrote:

> On 9/4/2012 4:43 PM, Earnie Boyd wrote:
>> I'm thinking that one of the following
>> styles be used and anything that is equal to WIN95 be common and
>> everything else be moved toward the end of the file with a construct
>> of one of the following.
>>
>> #if (_WIN32_WINNT>= _WIN32_WINNT_WIN2K)
>> ...
>> # if (_WIN32_WINNT>= _WIN32_WINNT_WINXP)
>> ...
>> #endif
>> #endif
>>
>> or
>>
>> #if (_WIN32_WINNT>= _WIN32_WINNT_WIN2K)
>> ...
>> #endif
>>
>> #if (_WIN32_WINNT>= _WIN32_WINNT_WINXP)
>> ...
>> #endif
>
> Both of these styles only work if you never have a situation where: a
> definition applies for $oldWindows, but should NOT be supported for
> $newWindows.  I *THINK* this requirement is satisfied by the w32api part
> of things, given Microsoft's oft-derided backwards-compatibility fetish
> when it comes to the *syntax* of their API (the *sematics* of that API
> seems to change with the wind, however).

Out of hundreds of files I only remember two times where there were
#if this #else that #endif scenarios.  I'm thinking even those can be
reworked with an assumption that nothing less than WIN95 will ever use
MinGW GCC.  But is there any objection to moving these filtered
declarations toward the end of the file and which style is preferred?

>
> Now, on the mingw-rt side of the fence, I think we probably do have
> items that are defined one way for $oldWindows but another way for
> $newWindows -- plus there's 32bit vs. any 64bit additions.

Most of the runtime headers are more bound to __MSVCRT_VERSION__.
There are 136 filters for __MSVCRT_VERSION__ in 17 files.  As for
32bit vs 64bit that is yet another RFC.  A big difference with 64bit
is the @BYTE argument is gone for stdcall and the assembler changed.
We already have some #if WIN64 filters.

--
Earnie
-- https://sites.google.com/site/earnieboyd

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Should the headers remain in near ascii collation order?

Charles Wilson-8
On 9/5/2012 7:42 AM, Earnie Boyd wrote:

> On Wed, Sep 5, 2012 at 12:31 AM, Charles Wilson wrote:
>
>> Both of these styles only work if you never have a situation where: a
>> definition applies for $oldWindows, but should NOT be supported for
>> $newWindows.  I *THINK* this requirement is satisfied by the w32api part
>> of things, given Microsoft's oft-derided backwards-compatibility fetish
>> when it comes to the *syntax* of their API (the *sematics* of that API
>> seems to change with the wind, however).
> Out of hundreds of files I only remember two times where there were
> #if this #else that #endif scenarios.  I'm thinking even those can be
> reworked with an assumption that nothing less than WIN95 will ever use
> MinGW GCC.  But is there any objection to moving these filtered
> declarations toward the end of the file and which style is preferred?
Fine with me. (and I prefer the second, fully-separated style) -- easier
to add version-specific "only _WIN32_WINNT == _WIN32_WINNT_WINXP"
elements that way, if it ever becomes necessary.
>> Now, on the mingw-rt side of the fence, I think we probably do have
>> items that are defined one way for $oldWindows but another way for
>> $newWindows -- plus there's 32bit vs. any 64bit additions.
> Most of the runtime headers are more bound to __MSVCRT_VERSION__.
> There are 136 filters for __MSVCRT_VERSION__ in 17 files.  As for
> 32bit vs 64bit that is yet another RFC.  A big difference with 64bit
> is the @BYTE argument is gone for stdcall and the assembler changed.
> We already have some #if WIN64 filters.
>
Understood.

--
Chuck


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Should the headers remain in near ascii collation order?

Earnie Boyd
On Wed, Sep 19, 2012 at 2:59 PM, Earnie Boyd wrote:

> On Fri, Sep 7, 2012 at 4:07 PM, Earnie Boyd wrote:
>> FYI, I've pushed a branch named redo-filters to track this to the
>> mingw.org-wsl repository.
>>
>> In this I will ensure to always include _mingw.h.
>> I've created a new macro __AW() to help limit the code for mapping
>> UNICODE versus ASCII symbols to the non-specific symbol.  Yes, I know
>> I said I was dropping it in the RFC but I realized I could keep part
>> of what I was doing to get a bigger bang for my efforts on the review.
>>
>> So if we have fooA and fooW we can
>>
>> #define foo __AW(foo)
>> typedef __AW(foo) foo;
>>
>> Instead of
>>
>> #if defined(UNICODE) || defined(_UNICODE)
>> #define foo fooW
>> typedef fooW foo;
>> #else
>> #define foo fooA
>> typedef fooA foo;
>> #endif
>>
>> Note: I know it is one or the other (#define or typedef), I'm just
>> giving an textual example of each.
>
> I've just pushed the last of the changes for redo-filters branch to
> the repository.  Here is a list of items accomplished.
>
> * Ensure to include _mingw.h and that the statement follows the
> #pragma GCC system_header statement.
> * Ensure that the file contains the #pragma GCC system_header statement.
> * Add an include of sdkddkver.h to _mingw.h so that its defines are
> ensured to be present.
> * Define a macro __AW() in _mingw.h to be used for UNICODE mapping of
> ANSI versus UNICODE symbols to the non specific symbol when both an *A
> version and a *W version of the symbol exists.
> * Define a macro __STR() in _mingw.h to be used for mapping UNICODE
> versus ANSI strings to non specific symbols.
> * Use _WIN32_WINNT in all cases for filters replacing _WIN32_WINDOWS and WINVER.
> * Remove the use of __MSVCRT_VERSION__ throughout the files as needless filters.
> * Use named constant macros for the filter comparison of OS version,
> e.g #if (_WIN32_WINNT >= _WIN32_WINNT_WIN2K).
> * Move the filters for OS version comparisons to the end of the file.
> * Invent _WIN32_WINNT_WIN95, _WIN32_WINNT_WIN98 and _WIN32_WINNT_WINME
> in sdkddkver.h. (By invent I mean that these are not defined by
> Microsoft).
> * Miscellaneous cleanup of some items in a few files.

* In windows.h, removed inclusion of winsock2.h to be more Windows compatible.
* In winsock.h, warn that it is included instead of winsock2.h.

--
Earnie
-- https://sites.google.com/site/earnieboyd

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://ad.doubleclick.net/clk;258768047;13503038;j?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Should the headers remain in near ascii collation order?

Earnie Boyd
On Thu, Sep 20, 2012 at 8:33 AM, Earnie Boyd wrote:

> On Wed, Sep 19, 2012 at 2:59 PM, Earnie Boyd wrote:
>> On Fri, Sep 7, 2012 at 4:07 PM, Earnie Boyd wrote:
>>> FYI, I've pushed a branch named redo-filters to track this to the
>>> mingw.org-wsl repository.
>>>
>>> In this I will ensure to always include _mingw.h.
>>> I've created a new macro __AW() to help limit the code for mapping
>>> UNICODE versus ASCII symbols to the non-specific symbol.  Yes, I know
>>> I said I was dropping it in the RFC but I realized I could keep part
>>> of what I was doing to get a bigger bang for my efforts on the review.
>>>
>>> So if we have fooA and fooW we can
>>>
>>> #define foo __AW(foo)
>>> typedef __AW(foo) foo;
>>>
>>> Instead of
>>>
>>> #if defined(UNICODE) || defined(_UNICODE)
>>> #define foo fooW
>>> typedef fooW foo;
>>> #else
>>> #define foo fooA
>>> typedef fooA foo;
>>> #endif
>>>
>>> Note: I know it is one or the other (#define or typedef), I'm just
>>> giving an textual example of each.
>>
>> I've just pushed the last of the changes for redo-filters branch to
>> the repository.  Here is a list of items accomplished.
>>
>> * Ensure to include _mingw.h and that the statement follows the
>> #pragma GCC system_header statement.
>> * Ensure that the file contains the #pragma GCC system_header statement.
>> * Add an include of sdkddkver.h to _mingw.h so that its defines are
>> ensured to be present.
>> * Define a macro __AW() in _mingw.h to be used for UNICODE mapping of
>> ANSI versus UNICODE symbols to the non specific symbol when both an *A
>> version and a *W version of the symbol exists.
>> * Define a macro __STR() in _mingw.h to be used for mapping UNICODE
>> versus ANSI strings to non specific symbols.
>> * Use _WIN32_WINNT in all cases for filters replacing _WIN32_WINDOWS and WINVER.
>> * Remove the use of __MSVCRT_VERSION__ throughout the files as needless filters.
>> * Use named constant macros for the filter comparison of OS version,
>> e.g #if (_WIN32_WINNT >= _WIN32_WINNT_WIN2K).
>> * Move the filters for OS version comparisons to the end of the file.
>> * Invent _WIN32_WINNT_WIN95, _WIN32_WINNT_WIN98 and _WIN32_WINNT_WINME
>> in sdkddkver.h. (By invent I mean that these are not defined by
>> Microsoft).
>> * Miscellaneous cleanup of some items in a few files.
>
> * In windows.h, removed inclusion of winsock2.h to be more Windows compatible.
> * In winsock.h, warn that it is included instead of winsock2.h.

Round 1 test was to build binutils.  It went rather smoothly but I had
to quiet some warnings I included in sdkddkver.h and winsock.h.  I
also needed to rework include/sys/stat.h, you might want to review it.

View the changed file in whole at
http://mingw.git.sourceforge.net/git/gitweb.cgi?p=mingw/mingw.org-wsl;a=blob;f=include/sys/stat.h;h=75e84d7d06de2706de6ffae12b71d83c09e4f111;hb=refs/heads/redo-filters

View the diff at
http://mingw.git.sourceforge.net/git/gitweb.cgi?p=mingw/mingw.org-wsl;a=commitdiff;h=b6a947ede19da18e2cf8841b1283db350d7e64a6#patch4

Those are some long URL so watch the line breaks if any.

--
Earnie
-- https://sites.google.com/site/earnieboyd

------------------------------------------------------------------------------
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Should the headers remain in near ascii collation order?

Earnie Boyd
On Fri, Sep 21, 2012 at 2:07 PM, Earnie Boyd wrote:
>
> Round 1 test was to build binutils.  It went rather smoothly but I had
> to quiet some warnings I included in sdkddkver.h and winsock.h.  I
> also needed to rework include/sys/stat.h, you might want to review it.

I've now completed a build of GCC-4.7.0 (all compilers except ada and
java), a build of tcl/tk, a build of the fox-toolkit and a build of
GLIB using our new libraries.  I will merge the redo-filters branch to
the master branch tomorrow.

--
Earnie
-- https://sites.google.com/site/earnieboyd

------------------------------------------------------------------------------
How fast is your code?
3 out of 4 devs don\\\'t know how their code performs in production.
Find out how slow your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219672;13503038;z?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr