
Why do game developers prefer Windows? - siamore
http://programmers.stackexchange.com/questions/60544/why-do-game-developers-prefer-windows
======
netcoyote
As someone who has worked extensively in the PC games industry (programming
lead on Warcraft, Warcraft II, Diablo, StarCraft, Battle.net, Guild Wars) the
reason is quite straightforward: that's where all the users who buy games are.
During my time at Blizzard the Mac versions of our titles sold ~4% of the PC
numbers, though I expect those numbers have changed with the rise of Apple
and, to a much lesser extent so far, desktop Linux.

Even with the rise of Linux -- and my belief is that it will rise very rapidly
with the advent of Steam for Linux -- PC game developers have years and years
of development experience advantage on the Windows platform.

When I and my two co-founders (all of us programmers) started ArenaNet to
build Guild Wars in 2000 we considered *nix vs. Windows for the server
platform and decided that we'd be more productive continuing to build on
Windows based on our previous programming background. All of us had extensive
experience with low-level coding on Windows (device drivers, async coding with
IOCompletion Ports) and knew that it would take time to replicate that
expertise on another platform.

Beyond the learning curve we knew it would be more convenient to be able to
run the game server and game client on the same computer. During development I
ran two copies of the Guild Wars match-making server, and two copies of the
game client, on a single desktop box to test the matching algorithm code.
Having to manage that process across multiple computers would have been more
of a hassle.

On a personal note, I've been spending a lot of time working on building/using
Linux in a virtualized environment (<https://github.com/webcoyote/linux-vm>).
Linux is an awesome development environment! While I much prefer doing C/C++
development using Visual Studio, Linux is better for other programming
languages I use or have tried: Ruby, Python, Go, D, and Erlang. And the
ecosystem, with projects like Redis, ZooKeeper, Postgres and a slew of NoSQL
servers makes it incredibly powerful because it isn't necessary to write
everything from scratch (except SQL), as we did for Guild Wars.

~~~
RobotCaleb
Thanks for your insights, Patrick. I've heard nothing but good things about
working at ArenaNet. Nobody has every mentioned whether that's due to your
guiding hand or the fact that you left

~~~
RobotCaleb
Ugh. I'm getting downvoted for a tongue-in-cheek joke. :(

------
jblow
Being a very experienced game developer who tried to switch to Linux, I have
posted about this before (and gotten flamed heavily by reactionary Linux
people).

The main reason is that debugging is terrible on Linux. gdb is just bad to
use, and all these IDEs that try to interface with gdb to "improve" it do it
badly (mainly because gdb itself is not good at being interfaced with).
Someone needs to nuke this site from orbit and build a new debugger from
scratch, and provide a library-style API that IDEs can use to inspect
executables in rich and subtle ways.

Productivity is crucial. If the lack of a reasonable debugging environment
costs me even 5% of my productivity, that is too much, because games take _so_
much work to make. At the end of a project, I just don't have 5% effort left
any more. It requires everything. (But the current Linux situation is way more
than a 5% productivity drain. I don't know exactly what it is, but if I were
to guess, I would say it is something like 20%.)

That said, Windows / Visual Studio is, itself, not particularly great. There
are lots of problems, and if someone who really understood what large-program
developers really care about were to step in and develop a new system on
Linux, it could be really appealing. But the problem is that this is largely
about (a) user experience, and (b) getting a large number of serious technical
details bang-on correct, both of which are weak spots of the open-source
community.

Secondary reasons are all the flakiness and instability of the operating
system generally. Every time I try to install a popular, supposedly-stable
Linux distribution (e.g. an Ubuntu long-term support distro), I have basic
problems with wifi, or audio, or whatever. Audio on Linux is terrible
(!!!!!!), but is very important for games. I need my network to work, always.
etc, etc. On Windows these things are not a problem.

OpenGL / Direct3D used to be an issue, but now this is sort of a red herring,
and I think the answers in the linked thread about graphics APIs are mostly a
diversion. If you are doing a modern game engine and want to launch on
Windows, Mac, iOS, and next-generation consoles, you are going to be
implementing _both_ Direct3D and OpenGL, most likely. So it wouldn't be too
big a deal to develop primarily on an OpenGL-based platform, if that platform
were conducive to game development in other ways.

I would be very happy to switch to an open-source operating system. I really
dislike what Microsoft does, especially what they are doing now with Windows
8. But today, the cost of switching to Linux is too high. I have a lot of
things to do with the number of years of life I have remaining, and I can't
afford to cut 20% off the number of years in my life.

~~~
green7ea
I'm a linux developer who's had an internship at a game company a few years
ago. I had the opposite experience.

During my internship, there were problems with visual studio. Intelisense made
everything so slow we had to disable it. VS was pretty slow and was hard to
use without being fullscreen on a big monitor.

I use emacs and the gdb intergration is excellent. It's never slowed me down.
I've customized it and find it painful to use another debugger (or an
unconfigured gdb) so please don't have it nuked. When I develop under windows
(without cygwin), I miss many tools I use when programming: valgrind, objdump,
grep, sed. I also miss having more control over the compiler and linker.
Makefiles seem to be much more powerful and flexible although more complicated
then most IDE's projects. SVN and git are more complicated to use without the
command line.

The game I worked on (deus ex human revolution) was being developed for PC,
xbox360 and ps3. Developping for ps3 means that the code goes through gcc.
This caused a few headaches for my colleagues as it is more rigorous with
standards (new line at end of file gives a warning, templates need to have
class or typename, etc). I was used to it and actually like the fact that it
respects standards.

I've had to install windows 7 on a computer recently and was baffled by the
fact the realtek ethernet, USB3, video drivers weren't included in the base
windows 7 CD. Had I used the manufacturer's recovery option it might have
helped but my computer would have been loaded with crapware. Ubuntu longterm
support works like a charm on that computer.

From what I've written so far you might conclude that I'm a FOSS fanboy and
dismiss everything windows has to offer. That's not it, I'm used to my tools
and everything else seems slightly quirky to me. My tools aren't terrible and
don't need to be nuked.

Most game developers have had many years experience developing for windows and
use windows as their primary platform. Programming for linux is different,
strange and possibly frustrating. I don't think the biggest issue with linux
game developement is the quality of the tools available under linux but the
fact that most game developers are used to using tools only available for
windows.

The one thing I think is lacking for linux to be a viable game platform is
quality graphics drivers but this seems to be improving with Valve's recent
efforts.

TLDR: Using windows is just as quirky as using linux. The biggest difference
is that you are used to your quirks as I am to mine. Most game developers are
used to windows and switching to linux is hard and uncomfortable.

~~~
maximilianburke
I've spent the last seven years working on video game middleware and have had
plenty of experience to many development environments. I've spent years
developing for Windows, Linux, and Mac OS, and worked on every console that
has been available on the market in that time.

GDB is different, but it's different in a bad way. Jonathan is completely
correct in that it's a much worse experience because it doesn't easily give
you the information you need to consume in order to find the problem you're
looking to solve. Using the text user interface helps considerably but it
still gets in the way. Sure, seeing source is fine, but what if you want
disassembly too? Mixed source/assembly? Register view? Watches? Switching
between threads easily? Viewing memory? DDD is an improvement but it still
feels like it's 8 years behind. I'm glad to hear you're productive in that
environment, most people (especially most game developers) aren't, and based
on my experience getting people up to speed and fixing problems it's easier to
get them going on Windows than on Linux.

That said, it's not the worst though. Green Hills takes that crown by a
country mile.

The SN Systems debugger for PS3 is the best one I've used, bar none. It gives
you all the data you need, is responsive, and has a few really nice features
(write memory region to disk).

Not quite sure why you used gcc for PS3, SNC is far superior. It's faster at
compiling and generates both faster and smaller code.

Both sed and grep are available for Windows and are definitely part of my
toolkit. Visual Studio comes with an objdump substitute (dumpbin). Valgrind
isn't available but DrMemory (<http://code.google.com/p/drmemory/>),
Insure++/Purify (expensive, but useful), Very Sleepy
(<http://www.codersnotes.com/sleepy>), CodeAnalyst
([http://developer.amd.com/tools/heterogeneous-
computing/amd-c...](http://developer.amd.com/tools/heterogeneous-
computing/amd-codeanalyst-performance-analyzer/)), VTune
(<http://software.intel.com/en-us/intel-vtune-amplifier-xe>), XPerf, and for
video games especially, PIX, are all available.

~~~
clhodapp
>Sure, seeing source is fine, but what if you want >disassembly too? Mixed
source/assembly? Register view? >Watches? Switching between threads easily?
Viewing memory?

Disassembly: (gdb) layout asm

Mixed source/assembly: (gdb) layout split

Register view: (gdb) layout regs

Watches: There is no window, which is too bad. You can say "display foo" and
it will print the value of foo each time the execution breaks. You can also
say just "display" and it will print the values of all variables you currently
have set to display.

Switching between threads: Say "info threads" to show all the threads in your
application. Say "thread x" to switch to thread number x.

Viewing memory: Again, there is no window, which is too bad. You can, however,
use the "x" command, which is pretty full-featured and allows you to print the
contents of a given-size chunk of memory, starting at a given point to the
console in pretty much any format you might desire.

You may already be aware of these features, but be discounting for some
reason?

Edit:

Turns out, GDB also supports writing memory regions to disk:

(gdb) dump binary memory <outfile> <startlocation> <stoplocation>

------
ComputerGuru
It's a really stupid question (but this does not take away from the value of
the incredible first answer). It makes a huge, blind assumption (running on
Windows means using DirectX and explicitly not OpenGL) and ends up assuming
correlation implies causation.

There are many Windows-only games written in OpenGL, and the ones that are
written with DirectX is not necessarily because DirectX is better but because
there are more consumers for Windows.

The short and simple answer is that "real," modern games are ridiculously
expensive projects. The highest percentage of PC-gamers can be found (at the
moment) on Windows. Ergo, you will write Windows games and use libraries
(OpenGL, DirectX, or otherwise) that are available on that platform.

~~~
FaceKicker
As someone who's never done any game development at all, can you give me some
sense of the work that would be involved to port a Windows-only OpenGL game to
Mac or Linux? What pieces of it would need to be redone or significantly
overhauled?

I would have expected it would be quite minimal compared to the work involved
in developing the game itself, but I guess I must be wrong if there are "many"
Windows-only OpenGL games.

~~~
kabdib
Sound. Networking. Decent async file I/O. Threading libraries. Dynamic loading
of components. Anti-cheat techniques (or any other security stuff you might
need). Device input. Choosing and supporting a platform (and the follow-on
customer support issues). Diagnosis of customer problems (because they _will_
have them).

~~~
eropple
Sound: OpenAL abstracts this decently. If you're not using it or an
equivalent, you're doing it wrong.

Networking: Most folks building a bespoke networking layer seem to go with
ENET, which is cross-platform.

Async file I/O: yup.

Threading libraries: something wrong with Boost Thread? (Boost gets
coroutines, too, in 1.53, which I'm pretty excited about.)

Honestly, the biggest problem I see in writing a cross-platform game is device
input. Trying to build a joystick/gamepad-based game for Linux and OS X are
pretty painful. Fortunately I've lucked onto GLFW as a windowing toolkit,
which handles the HID Manager boilerplate and other badness for them.

~~~
zanny
You can also just use the sdl, which provides abstractions for network, sound,
graphics, and input. If you hit snags, you could just commit back the fixes to
sdl proper. I've used it a bit and I have had good experiences so far with
successful cross platform builds.

It also supports Android, so in theory you could almost have one code base
with only a UI and input revamp for Android target every PC os.

~~~
eropple
SDL is a thing, I guess, but I personally have little use for it. I mean, I've
tried it, of course; I'm sure most people have. But, and maybe it's just me,
but if I'm going to have to do the legwork of wrapping some C API into a
decent, lifecycle-manageable object model, I'm probably going to use the
lowest-level one I can so I can state with authority that I fully understand
what everything in my stack is doing at all times. Like, OpenGL's C API is
super gross, but only very slightly less so than dealing with SDL. And while,
sure, "you can commit the fixes back to SDL," you first then have to go unwind
their abstraction to actually understand what the hell it's doing--which for
me, given the relatively small feature set I need, is almost as much work, if
not more, than writing it yourself.

Also, SDL 1.x is LGPL (instant dealbreaker, I build with static libraries on a
Mac to avoid dylib hell) and SDL 2.x isn't done. So there's that, too.

In the spirit of abstraction and not having to build the object model I'd get
for free with Direct3D, I used SFML for a while; the general idea of it is
promising, but the abstraction is janky, it's desktop-only, and I still have a
bitter taste in my mouth from the way they handled showstopper bugs in SFML
1.x as far back as three years ago: "Completely reproducible crashes on all
modern ATI cards? Just upgrade to our incompatible 2.x alpha!". (2.0 still
isn't out, which makes it _super_ groovy.)

.

I now use GLFW for windowing/input, ENET for networking, and PhysFS for I/O; I
can pretty easily use each of them in a way that maps pretty well to my own
preferences for an object model and a mental model. Probably not scalable (for
a multi-person project or a 3D game I'd almost certainly use OGRE rather than
doing it myself), but nice for my purposes.

The only part of my codebase that isn't pretty trivially platform-independent
right now, without any special effort, is in "platform.cpp", which does the
tremendously difficult work of finding me the user directory and the appdata
directory. =) I sure haven't done anything special to make it build both in
Xcode (my primary environment) or Visual Studio.

~~~
olego
OTOH, SDL2 is developed by Sam Lantinga, currently an employee at Valve
(IIRC), so this is probably the most promising library of the three you
mentioned.

For one, it [SDL2] uses XInput2 for relative mouse input on X11 (and Raw Input
on Win32), which is soooo much better than the classic WarpPointer mess.

Another thing, it is really preferable to put libSDL shared library next to
your executable, not compile it statically, at least for Linux builds. Quite a
number of problems with old games running improperly on erm...modern Linux
desktops are solved by swapping the bundled libSDL for distro-provided
version.

I'm speaking specifically about windowing/input part of SDL, have zero
experience with other parts.

------
shocks
Because OpenGL is ugly as hell. DirectX is rewritten often (with new versions)
to accommodate new ideas, whereas OpenGL new features/ideas are just "tacked"
onto the existing code base.

OpenGL also has a huge barrier to entry compared to DirectX.

MSND DirectX resources are fantastic, whereas resources on OpenGL are often
out-dated and generally pretty crap.

DirectX requires the DirectX SDK, whereas OpenGL requires GLUT, or GLEW? I
think. Perhaps FreeGLUT? OpenGLUT? Or can you just use SDL? Or none of them?
What? Exactly.

~~~
gte910h
I've heard this same sentiment from numerous programmers, including many who
prefer Linux. I'm thinking this is probably an informed opinion, not an
uninformed one, and should probably not be in the negative in votes.

~~~
BlackAura
Frankly, complaining that developing for Direct3D requires just the DirectX
SDK, and that developing for OpenGL requires some combination of other
libraries is a stupid complaint. It's the kind of complaint that only complete
newbies might have - anyone with any idea about what they're doing will not
have a problem with it.

Not that it's hard, anyway. You don't need any actual libraries to use OpenGL.
You just need up-to-date headers, and a way to link to the system's OpenGL
library. The easiest way to get those is to use an extension loading library,
which provides those headers, links to OpenGL at run-time (same thing that
Direct3D does) and makes all of the available extensions available
automatically.

Complaining about libraries like GLUT, GLFW, or SDL is completely irrelevant.
If you were using Direct3D, you'd be writing windowing code directly on top of
the Win32 API, which you can still do with OpenGL. If you want to use one of
these libraries to handle the platform-specific windowing and OpenGL setup,
you can. You don't have to - even in portable games, you can still just write
your own platform-specific windowing and OpenGL setup code.

So the development setup and libraries are different. So what? It's fairly
simple to work out for anyone but a complete beginner. On platforms like iOS
or Mac OS X, OpenGL is actually trivial - everything you need is included in
the platform's SDK. Same with Android. Same, to an extent, with Linux. OpenGL
is only really awkward on Windows, and you can guess who's to blame for that.

But there are plenty of legitimate complaints about OpenGL.

The API is much more complex than Direct3D. There are dozens of ways to do
things, with no way to tell which is the best way (short of looking at what
Direct3D is doing, and copying that). Behaviour and performance is
inconsistent between driver vendors, versions of driver from the same vendor,
and across platforms. Some OpenGL drivers (Intel's on Windows, until very
recently) are effectively unusable, or don't expose all of the hardware's
functionality that Direct3D does. There are lots of legacy issues to carefully
creep around, and they can still bite you even if you're not using the legacy
features. The shader compilers aren't consistent between different vendors,
and are often incredibly slow. Linking shaders is kind of clumsy. Since the
API and drivers are much more complex, it's more common to run into severe
performance issues caused by the driver than it is with Direct3D (and consoles
are better than Direct3D in this regard, because their graphics drivers are so
thin that they essentially don't exist).

Even picking a decent subset of OpenGL to use is a pain. Do you use OpenGL 2.x
and ignore large chunks of it to get a reasonable API, and broad support? Do
you go for OpenGL 3.x or 4.x instead? Which version? Which set of extensions?
It's dead easy for OpenGL ES, though - 1.x (fixed function) or 2.x (shaders),
neither of which carry around the legacy crap that OpenGL still carries.

Dealing with all of that is the problem with using OpenGL, not working out how
to link to it.

Oh, and documentation. That really is shocking, mostly because the majority of
documentation or guidelines you might find are written for OpenGL 1.x, and are
completely obsolete.

There are some good beginner-level guides to getting started with modern
OpenGL:

<http://www.arcsynthesis.org/gltut/> (OpenGL 3.3)
[http://duriansoftware.com/joe/An-intro-to-modern-
OpenGL.-Tab...](http://duriansoftware.com/joe/An-intro-to-modern-
OpenGL.-Table-of-Contents.html) (OpenGL 2.0, not using the legacy stuff)

~~~
itsuart
I would also add <http://open.gl> (OpenGL 3.2) to the list.

~~~
dualogy
I would also add the other links in the right-hand side bar of the OpenGL sub-
reddit: <http://www.reddit.com/r/opengl> \-- all good resources.

~~~
itsuart
Awesome stuff, thanks!

------
Cushman
> Old John Carmack at Id Software took one look at that trash and said, "Screw
> that!" and decided to write towards another API: OpenGL.

"Old John Carmack" makes me think he's some sort of half-myth crazy coot
mountain man, which made me realize something: There will some day be
mythology about computer programmers.

 _Whoa._

~~~
knome
If you mean one day people will remember the names of programmers in a
mythological manner, I doubt it. If you mean there will exist a mythos of
programmers. Their persons. Their ideals. Their exploits.

There are books: "Dealers of Lightening", "What the Dormouse Said", "Hackers:
Heroes of the Computer Revolution"; and beyond them a large amount of
information available only online ( textfiles.com is fantastic ). Things like
2600 and phrack. All of the old 'zine releases made by various cracking
groups, like "Legion of Doom", where at this point all that remains are
various communiques thanking lists of pseudonyms that will likely never be
linked to actual names. Older stories, like Mel. The Woz's hacks and Gates'
angry letter to early software copiers. The lexical analysis to pin n3td3v as
Gobbles Security ( still unconfirmed afaik ). Some of the older bits by
related groups, such as phreakers, aren't necessarily programming mythos, but
fall into the same crowds and history folders, individuals like Captain
Crunch. There are Torvalds and Tanenbaum's humorous exchanges. The first worm.
utf8's placemat birth. Larry Wall's idiosyncrasies. Well, all programmers
idiosyncrasies. esr. rms. dmr. ken. Anyone else that can be identified by a
tla, plus or minus an underscore prefix. Hacker ethic, free software and open
source manifestos, deconstructions, apologies, rebellions and dismissals
aplenty. Hackers v crackers and demoscene's birth from the latter. Spacewar,
nethack, rogue and a thousand MUDs to idle your time away. Many other things
that haven't popped off the top of my head.

There won't some day be a mythos such as this. It is here now. And it will
only grow further.

------
d0m
One reason is just that since game development is mostly all windows based,
new programmers learn to use windows tools.. and thus become more experienced
with them and not wanting to switch to something completely new which would
require a loss of productivity.

Also, and that's really only based from my experiences, it seemed to me that
game developers aren't that much into "hacking" linux. Things should just
Work. The terminal is a deprecated tool compared to new intuitive IDE. Most of
you won't agree with these statements (And I clearly don't) but that's really
what I've felt every time I'd talk with a game developer friend or colleague.
And, this mentality goes back to when I was an engineering students.. While I
had fun learning linux and Python, friends graduating in video gaming would
laugh of Python for being a "scripting non-performant language" or they would
play around in visual studio with C# and making forms or build some games with
XNA.

So, sometimes I think it's not that much about linux not being "good enough"
but more about video game developers' mentality to not fit with it. Man, I
won't lie, I'm an experienced Linux developer and user and I always have to
lurk in all kind of forums and RTFM on every small things that needs to be
installed (which is not in the standard library). And, it often happens that I
break stuff and spend countless hours trying to fix it. Hell, even last week,
I've upgraded a server on Archlinux and it totally broke my system without any
warning. I really needed help so I went on #archlinux and I've been told that
I should have read the archlinux news before tempting an update. Fair enough,
I guess.. but I can understand that on a extremely tight schedule, games
developers can't waste time on stuff like that. Compared to say, [next] [next]
[finish] windows install where everything just Work.

Please, don't down-vote me if you don't agree with things I've seen from my
experience. I don't agree with it neither, but I thought I'd share it here.
It's really something I see coming again and again from all kind of different
video games programmers.

~~~
NickPollard
As a games programmer with coming up to 5 years experience, I can attest that
this is largely true. At every studio I've worked at, I've been given strange
looks for even opening a terminal, and half of them haven't even heard of Vim.
Regardless of what the actual strengths and weaknesses of the tools are, most
game developers are so heavily wedded to VS and Windows that there is a huge
inertia on that side.

Personally, the mobile game that I'm developing now is being developed
entirely under Linux with GCC and GDB, and although GDB has a bit of a
learning curve I now find it easier and quicker than VS.

------
Tekker
As 2D video game developer with many titles under my belt, I can assure you
it's simply a matter of market share. The general rule (before hybrid CDs) was
write it for Windows and if it sells, then write it for Mac (later we would
release both Windows and Mac on a hybrid CD).

Traditionally Linux was all over the map in terms of graphics, and market
share was nil. Nowadays, Linux is prevalent among computer geeks, but in the
general population (that have the real $) it's effectively nonexistent.

TL;DR - Follow the money.

~~~
PeterisP
Well, most game development happens for consoles - so if the question is "Why
game developers use Windows" not "Why PC game developers use Windows", then it
still is an interesting quesion.

If you're coding for PS3 or Wii, why is Windows better than Linux or Mac?
Marketshare doesn't explain that.

~~~
eropple
The tooling is generally better on Windows, or was. A buddy of mine who does
some pretty intense PS3 work switched to a Mac about a year and a half ago and
said that it was rough going when he'd tried a year or so before that.

------
jpxxx
..and then another decade passed and OpenGL ES won every growth market,
returning PC gaming to its niche status. Massive niche, of course, but niche.
More Temple Run, dears?

~~~
pjmlp
Only on mobiles and we have to thank the iPhone for that.

Before the iPhone there were only crappy 3D apis available, OpenGL done with
software rendering,the J2ME 3D Mobile API and even the PocketPC had brain dead
versions of DirectX.

As for the game consoles, it is a myth in the FOSS that they use OpenGL.

Except for the PS3, which has OpenGL ES + CG, most consoles not from Microsoft
have an OpenGL like API, which is not the same thing.

As for the PS3, most developers actually make use of the proprietary CGM API.

~~~
bsimpson
Browser-based 3d is all going to be WebGL, which is very OpenGL ES inspired.

~~~
pjmlp
With MS-DOS games quality, no thanks.

------
eksith
Game developers target Windows because it's(was?) popular. They'll target
mobile devices more and more alongside consoles more and more (although, that
line is already starting to blur).

Users gravitate toward what's available, what's usable and if possible what
has the most vibrant ecosystem of apps. Games, if the developers want to make
any money, will target that platform. If the apps are common on a specific
platform, then it stands to reason tools for developing other apps/games will
also be common on that platform.

------
Someone
I would think the answer is a mix of "because that's where the money is" and
"because that is the OS they run themselves"

------
godDLL
One of my friends is a gearhead, this is what he had to say:

"...Shader Model 1.1, which basically was "Whatever the 8500 does.""
Correction - it was Shader Model 1.4 The GF3 already did 1.1, and the GF4 Ti
(3 years later) did 1.3.

A very good read though. A decade of drama put into simple words.﻿

------
ramayac
One of the most entertaining/educational answers I've read on programmers SE.
Fantastic!

------
bitL
Mac has outdated OpenGL. Period.

~~~
pjmlp
Full with Apple specific extensions.

------
huherto
They closed the question. It irritates me that the self appointed
stackoverflow police are very quick to close questions. They barely give them
a chance to see if something good or creative comes a long. (Such as the first
comment)

------
tonetheman
its all about the benjamins...

------
meaty
pkg-config and autotools!

~~~
gcr
Just pkg-config for me, thanks.

------
derpmaster
Games are already being ported to other operating systems because of microsoft
greed.

MS wants to copy everybody with an app and game store, which will be the only
authorized way to download and install anything on to windows 8+

They also want to charge 30% to any vendor that wants to sell in their store.
Since game makers like Steam have their own content delivery system which will
be blocked by MS they already panicked and announced a new linux client and
have claimed to be committed to switching everything over the next few years
and dumping windows

~~~
nivla
"which will be the only authorized way to download and install anything on to
windows 8+"

No, you can install any windows application on Windows 8. Windows 8 != Windows
Store. The desktop is only click away from the Start Screen (which can be
completely removed, if needed, using a free application) and remains as
flexible as on Windows 7.

ie. Steam will work fine on windows 8 as on Windows 7.

~~~
derpmaster
The CEO of Steam Gabe Newell disagrees with you. They (and Blizzard) are
moving away from Windows 8 entirely.

Steam is coming out with it's "steam box" which is a linux run gaming and home
entertainment system. You can also run windows on it if you want it's not a
proprietary console device apparently.

There are articles everywhere how Windows 8 completely killed the PC gaming
scene

~~~
nivla
Whether he agrees/disagrees won't change the fact, which is, Steam runs on
Windows 8 and it runs fine. There are a lot of reasons not to support an OS
besides compatibility.

With Steam, it wasn't a compatibility issue, it was more to do with Valve
feeling threatened by the Windows Store Model. Giving away X of every purchase
to the store does undermine their profit model. The same reason why you won't
see subscription based products such as Dropbox/Google Drive/Skydrive with
upgrade options on the Apple Store.

However, I can't see how Windows 8 threatens the traditional form of sale,
that download to desktop and play.

