winnt.h causes issues post-update - windows

Question

EDIT:
I gave up on making the SDK work properly and instead am using MinGW's provided Windows headers. As for the issue with SDL, I just commented out some lines about Windows RT, which in my case is probably fine as I never plan to compile for mobile devices.
I recently went and grabbed the Windows SDK 8.1 to replace 7.1, which I had to do because I went and grabbed SDL 2.0.3 to replace 2.0.1, and SDL now depends on a file "winapifamily.h" which is only in the 8.x SDK and not 7.x, and it wasn't that big a deal... until I went over to a networking project I've been working on. My code is not the problem, it's my environment. Now that the newer SDK is set up, winnt.h is causing massive problems.
C:\Program Files (x86)\Windows Kits\8.1\Include\um\winnt.h|940|error: #error Must define a target architecture.|
C:\Program Files (x86)\Windows Kits\8.1\Include\um\winnt.h|1311|error: 'EXCEPTION_DISPOSITION' does not name a type|
C:\Program Files (x86)\Windows Kits\8.1\Include\um\winnt.h|1320|error: 'EXCEPTION_ROUTINE' does not name a type|
C:\Program Files (x86)\Windows Kits\8.1\Include\um\winnt.h||In function 'BYTE ReadUCharAcquire(const volatile BYTE*)':|
C:\Program Files (x86)\Windows Kits\8.1\Include\um\winnt.h|8287|error: 'ReadAcquire8' was not declared in this scope|
C:\Program Files (x86)\Windows Kits\8.1\Include\um\winnt.h||In function 'BYTE ReadUCharNoFence(const volatile BYTE*)':|
C:\Program Files (x86)\Windows Kits\8.1\Include\um\winnt.h|8298|error: 'ReadNoFence8' was not declared in this scope|
C:\Program Files (x86)\Windows Kits\8.1\Include\um\winnt.h||In function 'void WriteUCharRelease(volatile BYTE*, BYTE)':|
C:\Program Files (x86)\Windows Kits\8.1\Include\um\winnt.h|8321|error: 'WriteRelease8' was not declared in this scope|
C:\Program Files (x86)\Windows Kits\8.1\Include\um\winnt.h||In function 'void WriteUCharNoFence(volatile BYTE*, BYTE)':|
C:\Program Files (x86)\Windows Kits\8.1\Include\um\winnt.h|8334|error: 'WriteNoFence8' was not declared in this scope|
C:\Program Files (x86)\Windows Kits\8.1\Include\um\winnt.h||In function 'WORD ReadUShortAcquire(const volatile WORD*)':|
C:\Program Files (x86)\Windows Kits\8.1\Include\um\winnt.h|8359|error: 'ReadAcquire16' was not declared in this scope|
C:\Program Files (x86)\Windows Kits\8.1\Include\um\winnt.h||In function 'WORD ReadUShortNoFence(const volatile WORD*)':|
C:\Program Files (x86)\Windows Kits\8.1\Include\um\winnt.h|8370|error: 'ReadNoFence16' was not declared in this scope|
C:\Program Files (x86)\Windows Kits\8.1\Include\um\winnt.h||In function 'void WriteUShortRelease(volatile WORD*, WORD)':|
C:\Program Files (x86)\Windows Kits\8.1\Include\um\winnt.h|8393|error: 'WriteRelease16' was not declared in this scope|
||More errors follow but not being shown.|
||Edit the max errors limit in compiler options...|
||=== Build finished: 10 errors, 0 warnings (0 minutes, 39 seconds) ===|
I have been tampering with my environment for about eight hours now and even re-installed MinGW thinking that perhaps it had some outdated headers or libs or something. It is probably something very simple I'm missing, if anyone has any idea what could be causing these issues I would appreciate any help.
Does Microsoft just write unreliable headers? Is the SDK only for Visual Studio compilers, and if so why are there many instances of the letters 'GNU' and 'GCC' in many Windows headers, even winnt.h?

Answer 1

I know this is a bit too late, but for those with still the same problem.
The problem indeed stems from the environment. Particularly, from the include directories pointing to 2 different versions of winnt.h and in your case, probably also winsock2.h given that you say it is a network app you're dealing with.
Background: there are 2 lists of include files in your proyect. One comes from your proyect settings, the second one comes from the global includes defined in the compiler settings, in that order.
Perhaps, in your previous configuration, winnt.h, winsock2.h etc. were taken from the global settings, which pointed to the Mingw provided files, but now, for sure, they are in the include paths of the SDK (that happend to me as well).
Your problem is one of precedence. The "windows" files from the SDK don't work with Mingw, so much that Mingw includes those files, but modified.
What you have to do is, put on top of the list, in your proyect settings' include directories, the same directory that you find in the global settings that point to the Mingw provided files, in such a way that these windows files are taken from the ones included in Mingw and not the SDK.
Hope this helps.