include <windows.h> to ensure that sentry.h is modularized correctly

[hyp]

This makes it possible to use this header in Swift

Fixes #934

[hyp]

@Swatinem What do you think about this change? I see you previously dropped the use of windows.h in favor of wtypes.h, can we bring it back instead?

[Swatinem]

The problem is that windows.h includes the whole world, and you need a bunch of other defines to contain the blast radius a bit. We previously had some problems related to including windows.h, thats why it was removed.

@supervacuus hopefully knows more about this, and can also guide us to a solution here. Lets wait a bunch more days for people to return from winter break :-)

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (164da79) 82.65% compared to head (b2c450a) 82.65%.
Report is 1 commits behind head on master.

❗ Current head b2c450a differs from pull request most recent head 3a89a13. Consider uploading reports for the commit 3a89a13 to get more accurate results

Additional details and impacted files

@@           Coverage Diff           @@
##           master     #935   +/-   ##
=======================================
  Coverage   82.65%   82.65%           
=======================================
  Files          53       53           
  Lines        7376     7376           
  Branches     1186     1186           
=======================================
  Hits         6097     6097           
  Misses       1171     1171           
  Partials      108      108           

[compnerd]

@Swatinem totally understandable that Windows.h is pretty broad

I think that the documentation does clearly state that you should use Windows.h most of the time (there are a few headers which can be imported without Windows.h). Adding a wrapping header to define all the control macros locally is an option that you might consider. The other possible alternative might be to start pulling in random headers in addition to this particular header (in some aspects re-creating a Windows.h as if you had defined the other macros). Unfortunately, many of the headers are not standalone nor do they include what they use.

[supervacuus]

A short check with /showIncludes reveals that we indirectly include windows.h via rpc.h anyway, so I see no reason to block this. This change is not only relevant to making the Native SDK work with clang modules but also makes explicit that we depend on windows.h.

There is currently no way around this without hiding the platform-specific context types in the header via some abstraction, and this is not a priority given that we still need to expose and track machine- and platform-dependent interfaces somewhere (but it might be the right choice down the road).

So, LGTM, but please add a changelog entry. Thanks!

[hyp]

Thanks, I updated the release notes!