Including windows.h in SDL_atomic.h?

In order to get the Windows atomic operations in SDL_atomic.h, we need to
include windows.h, which can break code that isn’t expecting it.

We have a few options:

  1. Never include windows.h and always use SDL library atomic functions on
    windows
  2. Never include windows.h and transparently use Windows atomic operation
    functions if windows.h has already been included
  3. Include windows.h and move SDL_atomic.h out of SDL.h so it’s not
    automatically included in most games’ source
  4. Conditionally include windows.h, if external code has requested it via
    #define

I think I’m leaning towards #3, but what would other people prefer?

See ya!–
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC

Quoth Sam Lantinga , on 2011-01-16 15:56:40 -0800:

We have a few options:

  1. Never include windows.h and always use SDL library atomic functions on
    windows
  2. Never include windows.h and transparently use Windows atomic operation
    functions if windows.h has already been included
  3. Include windows.h and move SDL_atomic.h out of SDL.h so it’s not
    automatically included in most games’ source
  4. Conditionally include windows.h, if external code has requested it via
    #define

I think I’m leaning towards #3, but what would other people prefer?

I like #3 as well, even aside from the whole header dependency issue;
it seems parallel to at least the 1.2 usage of SDL_opengl.h. Atomic
operations are somewhat specialized, and someone who’s looking for
them should be looking for them specifically, so it makes sense for
them to be a bit out of the way.

A hybrid approach might work, though it’d be more complicated: provide
wrappers inside the SDL library for the Interlocked* operations (which
is what I’m assuming you mean by “Windows atomic operations”), then
use an externally-defined request macro to choose between those and
inline definitions that require windows.h.

—> Drake Wilson

It depends on the extent of what you need from windows.h, but could you
not just copy and paste what you need from the header to the point
where you would have included it, thereby avoiding windows.h pollution?

I know it’s not exactly C programming best practice, but if what you
want is relatively simple and unchanging it might be worth it to
sidestep the issue.

Otherwise, yep, option #3.On Sun, 16 Jan 2011 15:56:40 -0800 Sam wrote:

In order to get the Windows atomic operations in SDL_atomic.h, we
need to include windows.h, which can break code that isn’t expecting
it.

I think I’m leaning towards #3, but what would other people prefer?

I could, but windows.h has some special cases to redirect to compiler
intrinsics that I don’t want to replicate or make assumptions about.On Sun, Jan 16, 2011 at 4:18 PM, Tim Angus wrote:

On Sun, 16 Jan 2011 15:56:40 -0800 Sam wrote:

In order to get the Windows atomic operations in SDL_atomic.h, we
need to include windows.h, which can break code that isn’t expecting
it.

I think I’m leaning towards #3, but what would other people prefer?

It depends on the extent of what you need from windows.h, but could you
not just copy and paste what you need from the header to the point
where you would have included it, thereby avoiding windows.h pollution?

I know it’s not exactly C programming best practice, but if what you
want is relatively simple and unchanging it might be worth it to
sidestep the issue.

Otherwise, yep, option #3.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


-Sam Lantinga, Founder and President, Galaxy Gameworks LLC

Ah, fair enough; probably not a smart move then :).On Sun, 16 Jan 2011 16:23:27 -0800 Sam wrote:

I could, but windows.h has some special cases to redirect to compiler
intrinsics that I don’t want to replicate or make assumptions about.

#3 it is! :)On Sun, Jan 16, 2011 at 3:56 PM, Sam Lantinga <@slouken> wrote:

In order to get the Windows atomic operations in SDL_atomic.h, we need to
include windows.h, which can break code that isn’t expecting it.

We have a few options:

  1. Never include windows.h and always use SDL library atomic functions on
    windows
  2. Never include windows.h and transparently use Windows atomic operation
    functions if windows.h has already been included
  3. Include windows.h and move SDL_atomic.h out of SDL.h so it’s not
    automatically included in most games’ source
  4. Conditionally include windows.h, if external code has requested it via
    #define

I think I’m leaning towards #3, but what would other people prefer?

See ya!

-Sam Lantinga, Founder and President, Galaxy Gameworks LLC


-Sam Lantinga, Founder and President, Galaxy Gameworks LLC

My first vote would be for #3, as well.On Sun, Jan 16, 2011 at 17:56, Sam Lantinga wrote:

In order to get the Windows atomic operations in SDL_atomic.h, we need to
include windows.h, which can break code that isn’t expecting it.

We have a few options:

  1. Never include windows.h and always use SDL library atomic functions on
    windows
  2. Never include windows.h and transparently use Windows atomic operation
    functions if windows.h has already been included
  3. Include windows.h and move SDL_atomic.h out of SDL.h so it’s not
    automatically included in most games’ source
  4. Conditionally include windows.h, if external code has requested it via
    #define

I think I’m leaning towards #3, but what would other people prefer?

See ya!

? ? -Sam Lantinga, Founder and President, Galaxy Gameworks LLC


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


Do what you can, where you are, with what you have. - T. Roosevelt

Wouldn’t it be possible to include it in SDL_atomic.c instead?------------------------
EM3 Nathaniel Fries, U.S. Navy

http://natefries.net/

Wouldn’t it be possible to include it in SDL_atomic.c instead?

I know that this has been decided on #3 already … but… I wanna echo
Nathan’s query.

How much of the existing SDL API has system specific stuff in #include’s
that affect applications ? IE: when I work with mutexes and threads and
stuff, I don’t ever access / work with regular posix mutex stuff… I’m
doing everything entirely through the SDL wrappers. Does SDL.h or
subsequent headers go ahead and #include all the platform specific stuff as
well when building an application ?

-WillOn Sun, Jan 16, 2011 at 9:47 PM, Nathaniel J Fries wrote:

No, the idea is to #define SDL functions as native (often compiler intrinsic
or assembly) functions for speed where possible. Since the atomic
operations are all about fast concurrent programming, this is a case where
you want as much speed as you can possibly get.

I ended up going with #3, but I added a #define that you can enable if you
want to turn that optimization off and go with the standard SDL library
functions. Those are always available for applications that want them,
regardless of what’s happening in the SDL public API header.

See ya!On Sun, Jan 16, 2011 at 7:47 PM, Nathaniel J Fries wrote:

Wouldn’t it be possible to include it in SDL_atomic.c instead?


EM3 Nathaniel Fries, U.S. Navy

http://natefries.net/


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


-Sam Lantinga, Founder and President, Galaxy Gameworks LLC

Sam Lantinga wrote:

No, the idea is to #define SDL functions as native (often compiler intrinsic or assembly) functions for speed where possible.? Since the atomic operations are all about fast concurrent programming, this is a case where you want as much speed as you can possibly get.

In that case, couldn’t you just include the add the prototypes for the intrinsics at the top of the header file?------------------------
EM3 Nathaniel Fries, U.S. Navy

http://natefries.net/

They’re redirected to platform-specific compiler intrinsics under some
circumstances. I’d rather let Microsoft pick the best implementation for
the environment. :)On Sun, Jan 16, 2011 at 8:59 PM, Nathaniel J Fries wrote:

Sam Lantinga wrote:

No, the idea is to #define SDL functions as native (often compiler
intrinsic or assembly) functions for speed where possible. Since the atomic
operations are all about fast concurrent programming, this is a case where
you want as much speed as you can possibly get.

In that case, couldn’t you just include the add the prototypes for the
intrinsics at the top of the header file?


EM3 Nathaniel Fries, U.S. Navy

http://natefries.net/


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


-Sam Lantinga, Founder and President, Galaxy Gameworks LLC

#3 sounds more than reasonable to me. If memory serves, the threading
API was treated similarly in SDL 1.2, so there is precedent.

I could, but windows.h has some special cases to redirect to
compiler intrinsics that I don’t want to replicate or make
assumptions about.

Ah, fair enough; probably not a smart move then :).

However, from the other thread:On Mon, 17 Jan 2011 00:30:14 +0000 Tim wrote:

On Sun, 16 Jan 2011 16:23:27 -0800 Sam wrote:

On Mon, 17 Jan 2011 18:57:25 +0200 M?rti?? wrote:

With Visual Studio C++ compiler you can use #include <intrin.h> to use
InterlockedXYZ API. No need to include <windows.h>. And this
<intrin.h> header doesn’t include <windows.h>!

http://msdn.microsoft.com/en-us/library/51s265a6.aspx

Ah, good catch. It looks like these work in both x86 and x64 environments.

I switched SDL_atomic.h to use intrin.h instead of windows.h and put it back
in SDL.h.

Thanks!On Mon, Jan 17, 2011 at 12:58 PM, Tim Angus wrote:

On Mon, 17 Jan 2011 00:30:14 +0000 Tim wrote:

On Sun, 16 Jan 2011 16:23:27 -0800 Sam wrote:

I could, but windows.h has some special cases to redirect to
compiler intrinsics that I don’t want to replicate or make
assumptions about.

Ah, fair enough; probably not a smart move then :).

However, from the other thread:

On Mon, 17 Jan 2011 18:57:25 +0200 M?rti?? wrote:

With Visual Studio C++ compiler you can use #include <intrin.h> to use
InterlockedXYZ API. No need to include <windows.h>. And this
<intrin.h> header doesn’t include <windows.h>!

http://msdn.microsoft.com/en-us/library/51s265a6.aspx


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


-Sam Lantinga, Founder and President, Galaxy Gameworks LLC

Quoth Sam Lantinga , on 2011-01-17 14:08:58 -0800:

Ah, good catch. It looks like these work in both x86 and x64 environments.

I switched SDL_atomic.h to use intrin.h instead of windows.h and put it back
in SDL.h.

I’m curious whether this will make it difficult to build SDL programs
on MinGW (and indeed whether that’s considered a target platform at
all), since the previous poster mentioned Visual C++ directly. Would
GCC intrinsics be used instead in the case of MinGW, or such?

Thanks!

—> Drake Wilson

No, I just tested it with the mingw cross-compiler environment. MinGW
provides intrin.h that supports the necessary functions.On Mon, Jan 17, 2011 at 2:18 PM, Drake Wilson wrote:

Quoth Sam Lantinga <@slouken>, on 2011-01-17 14:08:58 -0800:

Ah, good catch. It looks like these work in both x86 and x64
environments.

I switched SDL_atomic.h to use intrin.h instead of windows.h and put it
back
in SDL.h.

I’m curious whether this will make it difficult to build SDL programs
on MinGW (and indeed whether that’s considered a target platform at
all), since the previous poster mentioned Visual C++ directly. Would
GCC intrinsics be used instead in the case of MinGW, or such?

Thanks!

—> Drake Wilson


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


-Sam Lantinga, Founder and President, Galaxy Gameworks LLC

Hm. Well, with current MinGW32, I’m not seeing that header, and my
build (obviously) fails, which sucks.

I’m guessing you’re using the MinGW-W64 distribution.

Bummer, as MinGW-W64 is kind of a mess if you want a simple 32-bit
Windows compiler. I tend to stick with MinGW32 when at all possible.

For the record, I DO hope we can keep some distribution of MinGW as
a supported platform. Anything else would be really unfortunate. VC++,
while not a bad C90 compiler, simply isn’t a C99 compiler, and
that’s how I prefer to work, when at all possible.

I’ll try building using MinGW-W32 when I get a chance (assuming no one
else does it first). It does have intrin.h, so it will likely build
OK.On Mon, Jan 17, 2011 at 16:22, Sam Lantinga wrote:

No, I just tested it with the mingw cross-compiler environment.? MinGW
provides intrin.h that supports the necessary functions.


Do what you can, where you are, with what you have. - T. Roosevelt

I also lack intrin.h
My MinGW installation is a recent one from the official sourceforge page.

Perhaps the solution here is to just always use the SDL library functions on MinGW? Certainly not ideal, but…------------------------
EM3 Nathaniel Fries, U.S. Navy

http://natefries.net/

I’d upgrade that from “unfortunate” to “disastrous”. Most of the software I
write these days has to run on Linux, Mac, and Windows (in that order of
preference). Currently I compile for Linux and Windows on my Linux machine,
using mingw32 for the Windows cross-compile. Someday I hope to figure out how
to cross-compile for OSX on Linux (might be trivially easy but I’ve not had
time to look into it).

JeffOn Monday 17 January 2011 15:07, Greg Jandl wrote:

For the record, I DO hope we can keep some distribution of MinGW as
a supported platform. Anything else would be really unfortunate.