Use "_WIN32" macro

[ghost]

PHP_WIN32 can be replaced, as it was introduced as a duplicate of
ZEND_WIN32 [1]:

#define PHP_WIN32 ZEND_WIN32

ZEND_WIN32 can be replaced, as it was introduced as a concise way to check for
Windows [2]:

#define ZEND_WIN32 ((defined(WINNT) && WINNT) || (defined(WIN32) && WIN32))

WINNT was introduced as a way to check for Windows NT [3]:

#if WIN32|WINNT
  // Get build numbers for Windows NT or Win95
  if (dwVersion < 0x80000000){
    php3_os="WINNT";
  } else {
    php3_os="WIN32";
  }
#else
  php3_os=PHP_OS;
#endif

Windows NT [4] is no longer supported by PHP. "_WIN32" [5] is the documented
macro for Windows. Also I removed "_WINDOWS" because it was defined but never
used, and replaced WINDOWS as well because it is also not documented.

[1] http://github.com/php/php-src/commit/f452c77
[2] http://github.com/php/php-src/commit/bc5c9d8
[3] http://github.com/php/php-src/commit/573b460
[4] http://wikipedia.org/wiki/Windows_NT_4.0
[5] http://docs.microsoft.com/cpp/preprocessor/predefined-macros

[weltling]

The most of concern I have that this change can affect merging from lower branches also for unrelated platforms. At least, PHP_WIN32 and co. definitions should not've been removed. There's a lot of code outside core that would become invalid immediately without these defs. Sometimes these macros are used also in the patched dependencies, fe see the AppVeyor failing on snmp headers. Of course nowadays _WIN32 were enough otherwise, to tell the common platform, lets see what the future brings.

All in all, I'd be reluctant on this patch. While the change is pure cosmetic, the troubles it can cause are something no one would need.

Thanks

[KalleZ]

I'm in the same boat here as @weltling, its a purely cosmetic change. While I do understand that it will help with the mingw64 support we're working on in the bug report, this will however just be a slight annoyance to change for anyone working on the core and extensions

[ghost]

AppVeyor working now - I left the other changes but did not change win32/build/confutils.js

[weltling]

@svpenn i'd really advise against this patch, as mentioned above, until there are strong arguments besides macro naming.

Thanks.

[Sebbyastian]

Apologies if this seems out of place, but I feel the need to offer some input. I don't think this is merely cosmetic, but also a semantically sound suggestion.

According to a number of official sources, _WIN32 is used to select x86 and amd64. I only searched briefly, but I couldn't find any official mention at all of WINNT. That's not good!

One of my biggest reasons to pick on PHP is that the implementation makes subtle (probably mistaken) use of implementation-defined (and undefined) behaviours which might result in variations between behaviour from configuration to configuration, perhaps even when the same OS is being used.

It might be wise to use those preprocessor macros which the Microsoft website documents for Microsoft systems, as the others have no guarantee at all regarding functionality and could (theoretically, however unlikely the probability) change overnight without a word.

[krakjoe]

This cannot be merged: we cannot break the expectations of hundreds of extension developers, and our workflow, just for the sake of "correctness". The argument that non standard definitions may be removed would be more powerful if we hadn't been using them forever; They will not be changed for exactly the same reason we cannot merge this patch.

…

On 26 Nov 2017 9:17 am, "Sebastian Ramadan" ***@***.***> wrote: Apologies if this seems out of place, but I feel the need to offer some input. I don't think this is merely cosmetic, but also a semantically sound suggestion. According to a number of sources, _WIN32 <https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/64-bit-compiler> is used to select x86 and amd64. I only searched briefly, but I couldn't find any official mention at all of WINNT. That's not good! One of my biggest reasons to pick on PHP is that the implementation makes subtle (probably mistaken) use of implementation-defined (and undefined) behaviours which might result in variations between behaviour from configuration to configuration, perhaps even when the same OS is being used. It might be wise to use those preprocessor macros which the Microsoft website documents for Microsoft systems, as the others have no guarantee at all regarding functionality and could (theoretically, however unlikely the probability) change overnight without a word. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2905 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACIe6toJFvpQ2GeG96Ms5rSZQrPyRkEsks5s6R6xgaJpZM4QSdvl> .

[Sebbyastian]

__MINGW32__ appears to target a compiler infrastructure, including standard library and headers which may or may not (probably not) contain <sys/ioctl.h>, where-as my Windows 7 system with MSYS2 installed reports the presense of <sys/ioctl.h>. Is it possible that you might have confused a compiler-related macro with an OS-related macro?

[Sebbyastian]

The argument that non standard definitions may be removed would be more powerful if we hadn't been using them forever

Your own line of reasoning would also be more powerful if you weren't using a standardised language.

They will not be changed for exactly the same reason we cannot merge this patch.

If that's your only issue, it seems like it could be a few simple fixes to get this patch merging. I'll finish identifying the syntax errors that the changes caused. I'm fairly confident the semantic differences between the unofficial WINNT and the official _WIN32 will be minimal, if anything, once these syntax errors are fixed.

[Sebbyastian]

@svnpenn I've left a number of comments for you to check out. I think you should add the mingw check back in, as I'm pretty sure that ancient thing will still be used by anyone who hasn't found more up-to-date, greener pastures. You might also be interested in analysing the difference between the definition of _WIN32 on various systems, such as here, where it becomes obvious that some systems indeed will render code such as #if _WIN32 as a constraint violation (hence the CI fails?). It should be pretty straight forward what might need to be done, but nonetheless I'm happy to help if you have any questions.

[Sebbyastian]

I also note a boolean-compatible value specified for ZEND_WIN32, whilst just a blank macro from _WIN32 (and WIN32)... Did you miss this file as you were hunting down and eliminating ZEND_WIN32, perhaps?

[Sebbyastian]

@svnpenn Ownership is stubborn, but will accept this commit when he sees better portability. Don't give up... or do... whatever, I don't care. PHP's nothing special, anyway.

[ghost]

@Sebbyastian not sure where you are getting that information - the other comments in this thread have made it clear that this patch wont be accepted even with passing tests - because of extensions

[weltling]

@svnpenn for historical reasons, it's preferable to keep the existing macros. I'm closing this PR therefore. Thanks for your work!