[mdlug] Interesting information about Windows "7"

[Aaron Kulkis]

Jeff Hanson wrote:
> On Jan 24, 2008 12:18 AM, Aaron Kulkis <akulkis3 at hotpop.com> wrote:
>> It has to do with MARKETS.
>>
>> Windows games are written for Windows, not the
>> hardware it's running on.
> 
> Not entirely correct.  The developers must take into account the
> end-user's hardware else it won't run.


That's just about processing capabilities (as in,
millions of triangles/second processing SPEED of
a graphics card...not the architecture of the
graphics card itself.

When was the last time you had to select a sound card
or video card as the first step to starting a game?

Back int the DOS and Windows 3.1 days, you had to
tell the program what sound card and/or graphics card
you were using.

And if your sound or graphics card wasn't one of those
on the list, and didn't emulate one on the list, then
you couldn't play the game.

For some reason, most of the game writers developed
for the SoundBlaster card from Creative as one of
their first-supported sound cards, and soon all of
the other sound card manufacturers ALL designed
their cards to have a "SoundBlaster emulation mode"

Why?

Because there was no standard way of doing sound
at that time.

There was no "Windows" way of making sound...there
was the ABC Card way, and the XYZ Card way, and
thousands of others.


 >                                       The PC world is full of
> millions of combinations of video cards, bioses, and drivers, which
> makes it a lot more difficult to troubleshoot.

Wrong.  That's what DirectX takes care of.

The programmer only writes code against the DirectX ABI,
and then DirectX and the drivers handle all the rest.

Take a windows machine, swap out an ATI for an nVidea
card, install the nVidia driver and remove the ATI
driver, and your game will play just like it did before,
subject to the memory and processing speeds of the
respective cards and their GPUs.

But the game writer doesn't know (and doesn't need
to know) the difference between an ATI graphics
card and an nVidea graphics card, like they did
when games asked if you had a Hercules graphics
adapter or not.


 >                                                  Consoles are very
> predictable and very easy for the end user to determine if a game they
> are planning on purchasing will operate or not.

And the purpose of an operating system is to make everything
just as predictable REGARDLESS of whether the hardware
changes or not.

I can take source code for the "cat" command, recompile
it on my machine, and it will work on one of today's
Unix computers, despite the fact that disk drive technology
(and therefore, any file-access mechanism) is three
or four major technology generations removed from the
disk drives of the late 1970's....we're talking code
from 10 years before RLL and MFM drives were introduced.

When's the last time you saw an RLL drive or an MFM drive?

Do you even know what one looks like?

[Hint, they're both have a 5-1/4 x 3-drive-bays tall
form factor, and they're as heavy as bowling balls]

 >                                                 Closed source
> developers are entirely on their own for dealing with hardware
> variations on any particular OS unless they outsource to porting
> firms.  If the market size on those platforms is not large enough for
> them to bother with then they don't.
> 
>> Linux games are written for Linux, not the hardware
>> it's sitting on top of, and games port very easily
>> from one hardware collection to another.
> 
> Mostly, but it depends on if it's open source or not.  Open source
> apps can be ported to any platform that someone wants to port it to.
> Closed source apps again rely on the original developer.  PPC versions
> of Linux apps are often not available or buggy because the differences
> in the architecture require more work and the required hardware
> (cross-compiling is not enough IIRC).

That's a standard porting issue that happens pretty
much every time you port code across CPU lines.

But the rest of the hardware (like I/O ports, etc) are
abstracted enough by the OS that the only hardware which
the programmer has to account for the CPU.