Archived

This topic is now archived and is closed to further replies.

Longhorn?

This topic is 5148 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Longhorn is coming right around the corner, and I''m wondering what changes it will make to the Gaming Industry. I heard that its backward-compatible with Win32 applications, so (most) games should work on Longhorn. But will it force the Gaming Industry to move on to managed code and C# and DirectX? Primarily, I''m concerned with whether OpenGL will be supported in Longhorn. Can anyone point me in the right direction?

Share this post


Link to post
Share on other sites
quote:
Original post by Skeletal
Longhorn is coming right around the corner, and I''m wondering what changes it will make to the Gaming Industry. I heard that its backward-compatible with Win32 applications, so (most) games should work on Longhorn. But will it force the Gaming Industry to move on to managed code and C# and DirectX? Primarily, I''m concerned with whether OpenGL will be supported in Longhorn.

Can anyone point me in the right direction?



Yes everything will be managed in the future as native applications won''t be able to compare to the speed, performance, productivity, and security of managed applications.

I wouldn''t worry much about OpenGL, due to the fact there is NO WAY OpenGL would ever go away on a Windows platform. Either the managed wrappers that exist today for it will be the standard for OGL, or someone will re-write and release a managed version =]

Share this post


Link to post
Share on other sites
Longhorn will come around 2006, it''s a long time. Personally I don''t think OpenGL will be replaced by D3D, may the two APIs will combine to one, however.

Don''t worry too much, or you will be stagnant all the time. Just learn what you want. If you are accomplished in OpenGL, D3D won''t be a problem to you. New technology won''t come out in spite of the previous one, they always have sth in common.


----------------------------------------------------------------------------------------------------------------------
In history, only steam engine and electromagnetics impelled human beings to make progress......

Share this post


Link to post
Share on other sites
Well, if you care about developing for non-windows platforms, remember that OpenGL is the standard for *nix variants, so GL skills won''t become obsolete just as soon as a new version of windows comes out, actually depending on how Microsoft handles their upgrade path, GL could become more useful for the Gaming Industry.

Share this post


Link to post
Share on other sites
If Microsoft will once only allow managed code, I will definately stop coding programs for their OS, unless off course *nix variants also accept this sort of code.
The idea that code can''t be written cross-platform anymore scares me to hell! I''m currently rewriting about 20.000 lines of code to accomplish a cross-platform model.

"My basic needs in life are food, love and a C++ compiler"
[Project AlterNova] [Novanet]

Share this post


Link to post
Share on other sites
If anything managed code will be MORE portable, assuming projects such as Mono (a version of the Common Language Runtime and the .NET Framework for Linux) mature a bit more, which by 2006 they should have well and truly. You shouldn''t even need to re-compile.

Share this post


Link to post
Share on other sites
quote:
Original post by Vich
If Microsoft will once only allow managed code, I will definately stop coding programs for their OS, unless off course *nix variants also accept this sort of code.
The idea that code can''t be written cross-platform anymore scares me to hell! I''m currently rewriting about 20.000 lines of code to accomplish a cross-platform model.



You''ve been reading too much FUD. There is nothing different here then there was between Windows 3.1 and Windows 95. You can still code with the Windows 3.1 API all you want (as you will be able to do with Win32 API stuff). The idea is that to take advantage of Longhorn only stuff you''ll need to use the Longhorn API (which, like developing native Win32 apps, requires a new compiler), and like Windows 3.1 stuff on 9X, there will be some wrapping of legacy code, resulting in *small* performance losses (benchmarks I''ve seen actually show legacy code running faster on Longhorn then they did running native on XP). And why does .NET integration make it *harder* to write cross-platform code? Which do you want, tons of win32 specific code you have to rewrite, or something you can cross compile with no changes (i.e. the Mono .NET compiler and others based on the .NET open standard).

Share this post


Link to post
Share on other sites
Longhorn will take full advantage of .NET 2, right? I think Longhorn is set for late 04. And a brand new server os codename: ''blackbox'' or somethign like that will be in 07 (The year I graduate!).



Toolbar: [ | My Journal | nMagic | My Profile ]

"Give a man a fish and he will eat for a day. Teach a man how to fish and he will eat for a life time."
-Chinese Proverb

Share this post


Link to post
Share on other sites
quote:
Original post by WiseElben
Longhorn will take full advantage of .NET 2, right? I think Longhorn is set for late 04. And a brand new server os codename: 'blackbox' or somethign like that will be in 07 (The year I graduate!).





Longhorn was actually pushed back to approx. 2006 as per PDC so it's still a little while off.

"Longhorn will take full advantage of .NET 2, right?"

- Longhorn IS .NET
Currently the .NET framework is exactly that.. a framework for running applications in a managed environment.

With Longhorn, native code (unmanaged) is actually now a framework on top of .NET.. while the .NET system is the core architecture.

This is why applications written with Whidbey Beta (VS.NET 2004 with C# 2.0) and Longhorn Alpha written in managed .NET code are actually running FASTER than native code.

Here is a basic rundown:

Today's architecture:
.NET application -> .NET framework -> win32 native -> windows xp

Longhorn's architecture:
.NET application -> .NET framework -> longhorn

OR

unmanaged native application -> win32 backwards compat. -> .NET framework -> Longhorn


The change is a paradigm shift along the very same lines as:

DOS code VS. Windows code

When Windows 95 was released they allowed DOS applications to run in order to provide backwards compatability.

The same thing will be happening with Longhorn, the current unmanaged native code will be allowed to run as a backwards compatability... although the system is optomized for managed code and managed will obviously outperform the "old style" which is only meant for backwards compatability.



[edited by - Imperil on November 12, 2003 8:54:08 PM]

Share this post


Link to post
Share on other sites