Longhorn, C++, DirectX?

Discussion in 'Game Development (Technical)' started by 20thCenturyBoy, Sep 29, 2004.

  1. 20thCenturyBoy

    Original Member

    Joined:
    Sep 23, 2004
    Messages:
    178
    Likes Received:
    0
    Do you guys think it will still be viable to write C++ (or even straight C) games under Longhorn, considering that it will have the latest .Net runtime installed and most of Win32 will be "upgraded" to a managed API? I admit I am not familiar with managed C++ but it sounds like a kludge. How difficult is it to use? Will Longhorn allow unmanaged DirectX access? I guess so for backward compatibility. What do you guys think?
     
  2. kerchen

    Indie Author

    Joined:
    Jul 29, 2004
    Messages:
    119
    Likes Received:
    0
    I would expect Microsoft to slowly nudge developers toward the managed API, but they'll probably support the Win32 API for several years (as they did with the 16 bit Windows API, as I recall). If they tried to force the managed API on the world in a short time frame, everyone would just switch over to Linux or Mac. :) Okay, maybe not, but it would probably slow adoption of Longhorn to a standstill.
     
  3. wazoo

    Original Member

    Joined:
    Jul 27, 2004
    Messages:
    519
    Likes Received:
    0
    Personally, I can't WAIT...

    After working with DirectX9 and C#, all I can say about Longhorn is BRING IT ON.

    Seriously, as ANY of the C# threads going on here will attest to, development time is halfed on nearly anything I'm doing in C/C++...

    I'd even release .NET games right NOW if it wasn't for the slow penetration of the runtime...

    *sigh*

    I *guess* one could start on those projects now to sort of "be in place" for when the .NET wave hits...



     
  4. EpicBoy

    Original Member

    Joined:
    Jul 27, 2004
    Messages:
    624
    Likes Received:
    0
    I'm sure Microsoft will support a C/C++ pipeline for Longhorn and possibly the next OS after that. But eventually, they will phase it out, probably in the same way they've done for MFC. It becomes officially unsupported at some point, and shortly after they stop updating it.
     
  5. Nemesis

    Original Member

    Joined:
    Jul 27, 2004
    Messages:
    273
    Likes Received:
    0
    Microsoft phased out MFC? Well.. it is definitely supported in VS.NET 2003 as MFC 7.x! What's the replacement?I really cannot see C++ being phased out.. what are they going to write their OS's with?
     
  6. princec

    Indie Author

    Joined:
    Jul 27, 2004
    Messages:
    4,873
    Likes Received:
    0
    It is probable that parts of the O/S will start to migrate into managed code, and eventually it'll just leave the kernel just written in C and assembly. At least, that's what I'd be trying to do, if I were Microsoft.

    Cas :)
     
  7. EpicBoy

    Original Member

    Joined:
    Jul 27, 2004
    Messages:
    624
    Likes Received:
    0
    .NET

    Forms are the way of the future and they are pushing it heavily. They essentially stopped supporting MFC a while ago. Yeah, they update it, but are they adding anything of major substance? Have they added anything really radical in the last few years or has it been mainly bug fixes?
     
  8. nalenb

    Original Member

    Joined:
    Sep 8, 2004
    Messages:
    29
    Likes Received:
    0
    I admit that I don't know much about WinForms, but I did read this:

    "And if you're developing a Windows GUI app today using Microsoft's "official" latest-and-greatest Windows programming environment, WinForms, you're going to have to start over again in two years to support Longhorn and Avalon."

    http://www.joelonsoftware.com/articles/APIWar.html

    It's interesting that there's a shift every couple of years. Win32, MFC, WinForms, Avalon, ... but perhaps that's more of thing with application developers than game developers.
     
  9. EpicBoy

    Original Member

    Joined:
    Jul 27, 2004
    Messages:
    624
    Likes Received:
    0
    Well, I was referring to the Form class inside of .NET more than an API of some kind.
     
  10. tolik

    Original Member

    Joined:
    Sep 20, 2004
    Messages:
    1,407
    Likes Received:
    0
    I was participating in couple of MS meetings and conferences, but that was last year. There were discussions regarding future WinAPI (not MFC!) implementation. I'm not sure if it will be left or not, but it will be replaced by something new, can't remember how it's called. You will be able to use any language to write software, there will be no difference between VB, C++, C#, I don't remember about J#. They have showed huge core of this new WinAPI replacement, availability of features accessed through current .Net nowadays and the plans of further migration, they want to give all the languages same functionality.

    DirectX will migrate to XNA. The plan was to include in in Longhorn, I suspected they wanted to draw even the Explorer using it to look like Macs (cool effects - read D3D windows).
    Further announces have showed that XNA will maintain Live PC compatibility with Xbox 2. I'm not sure what they are up to, but their plans are ruined this year with all the announces of db-like filesystem removal and other core features postponed/abandoned. There are really much analytical news about these things on theregister.com, you can dig there to know more, my brain doesn't store _all_ the info you know ;)
     
  11. Bluecat

    Original Member

    Joined:
    Jul 27, 2004
    Messages:
    330
    Likes Received:
    0
    It seems that replacing the WinAPI will have a major effect on maintaining backwards compatibility will applications developed for older versions of Windows. I'm not sure that this is something that MS would do. After all they have always taken the view that maintaining a high level of backwards compatibility removes a roadblock to getting customers to upgrade. How many Doom 3 players would upgrade if D3 didn't run on Longhorn?
     
  12. Nemesis

    Original Member

    Joined:
    Jul 27, 2004
    Messages:
    273
    Likes Received:
    0
    Well.. the major MFC releases generally include new controls and look & feel functionality as per the latest MS O/S's. I think MFC is quite a mature API now.. there isn't much scope for radical additions.

    I have experienced WinForms and WebForms, with the latter working just like the former, which is a cool thing. However at present, I cannot imagine a high-performance application written in a completely non-native language.. but I stand to be corrected :)

    @emuLynx
    Windows API that works with all .NET languages.. isn't that WinForms? Or perhaps they're working on a second generation .NET win api?

    @cas
    I fail to see the benefit of rewriting parts of the o/s with managed code. I'm confident MS has sufficient resources to keep the o/s efficient with purely native code. What I do anticipate is that the .NET framework will somehow be more tightly integrated with the core and with the emergence of more applications written using managed code.
     
  13. EpicBoy

    Original Member

    Joined:
    Jul 27, 2004
    Messages:
    624
    Likes Received:
    0
    Well, this is a misconception that seems quite common ... Managed languages like C# are native. They do the final compilation stage the first time the user runs them. Every time after that, you're running a native EXE. There shouldn't be any real speed issues...
     
  14. nalenb

    Original Member

    Joined:
    Sep 8, 2004
    Messages:
    29
    Likes Received:
    0
    EpicBoy, really? I was under the understanding it compiled to native code as it needed to, so that the first time through a loop it used jit to compile to native code so each successive iteration through the loop was native. It's my understanding that when you leave the app, all the jit stuff is released and it is compiled to native again when it's run.

    I think the performance could be the same in some areas and worse in others, depends on what the code is doing.

    There are linkers that take msil and produce native code too.
     
  15. tentons

    Indie Author

    Joined:
    Mar 1, 2004
    Messages:
    664
    Likes Received:
    0
    It wouldn't actually be a "rewrite," technically, since it's a new OS. :)

    With processing power, RAM, etc all constantly escalating, performance is less of an issue than productivity. That's a good reason to use higher level tools and languages (which compiles to native code, mind you). This is exactly why I'll probably be doing exclusively C# development (Mono) after one or two game releases using C++.
     
  16. EpicBoy

    Original Member

    Joined:
    Jul 27, 2004
    Messages:
    624
    Likes Received:
    0
    It's possible that you're right. I just read an interview with C#'s lead architect and he alluded to the fact that code is compiled as it is executed. He said generics (aka templates) are compiled as they are instantiated so that might mean that all code works that way...
     
  17. Valen

    Indie Author

    Joined:
    Jul 27, 2004
    Messages:
    133
    Likes Received:
    0
    Let's hope so. As long as SDL supports whatever madness Microsoft creates, I'm fine with it. :) I try to stay the hell away from Windows specific code as much as possible. With SDL, the only Windows code I had to write for my game was a call to ShellExecute() to open a browser when Buy Now is clicked.
     
  18. tentons

    Indie Author

    Joined:
    Mar 1, 2004
    Messages:
    664
    Likes Received:
    0
    That makes sense, because if you upgrade the VM you get enhancements without "recompiling" explicitly each run.
     
  19. Bluecat

    Original Member

    Joined:
    Jul 27, 2004
    Messages:
    330
    Likes Received:
    0
    Although it wouldn't be particulary difficult to cache the 'compiled' code and recompile only when an upgrade of the VM or core libraries occurs.
     
  20. James C. Smith

    Moderator Original Member

    Joined:
    Aug 21, 2004
    Messages:
    1,768
    Likes Received:
    0
    You will be able to use C++, Win32 and unmanaged DirectX to write Windows Applications a many, many years to come. Eventually there may come a point when you can’t access new OS features unless you are using Managed C++ or some other .NET enabled language. But the OS will continue to run unmanaged applications writing in C++ and calling Win32. Heck, even Windows XP still run Win16 application and many DOS applications.

    The sky is not falling. You can still program in any language you want and the Win32 API will continue to be supported for a very, very, very long time.
     

Share This Page

  • About Indie Gamer

    When the original Dexterity Forums closed in 2004, Indie Gamer was born and a diverse community has grown out of a passion for creating great games. Here you will find over 10 years of in-depth discussion on game design, the business of game development, and marketing/sales. Indie Gamer also provides a friendly place to meet up with other Developers, Artists, Composers and Writers.
  • Buy us a beer!

    Indie Gamer is delicately held together by a single poor bastard who thankfully gets help from various community volunteers. If you frequent this site or have found value in something you've learned here, help keep the site running by donating a few dollars (for beer of course)!

    Sure, I'll Buy You a Beer