Sign in to follow this  
rohde

C++ on Longhorn

Recommended Posts

I was browsing the Longhorn Developer FAQ and stumbled over this: "Can I use C++ to develop for Longhorn?" "If you mean the C++ that targets the MS CLR by producing IL, then the program model is the same for C++ as it is for any .NET language and you can find a set of C++ samples on the LHSDK samples page. If you mean Standard C++ that targets a specific chip by producing assembly code, you're going to be doing a lot of .NET interop to make it work. I recommend the other thing." (Longhorn Developer FAQ.) Very interesting - not sure how I feel about it tho'. I guess it has its pros and cons.

Share this post


Link to post
Share on other sites
Quote:
Very interesting - not sure how I feel about it tho'. I guess it has its pros and cons.
Can't say I'm too bothered about it to be honest!

Microsoft are on a big virtual-machine/high-level language drive it seems, fair play to them. But they wouldn't be stupid enough to "block out" or make it too difficult for native-code programs (and progammers) to develop. That alone would probably kill Longhorn before it is born!

Maybe the FAQ is referring to using Interop so you can use whatever the replacement for Win32 is (is that actually called .Net?) as opposed to the "pure language" components...

Jack

Share this post


Link to post
Share on other sites
Well,

I have given this thought and to be honest as long as i can program C++ in exactly the same way on Longhorn as i can now, ill be happy.

Will DX9b be apps be completely compatible.

ace

Share this post


Link to post
Share on other sites
Quote:
as long as i can program C++ in exactly the same way on Longhorn
For the most part you'll probably be happy, but I'd at least be expecting a few changes. It wouldn't be a very important new OS if nothing changed, if the API's remained constant and so on...

Quote:
Will DX9b be apps be completely compatible.
Again, probably, simply because DirectX is backwards compatable. However, they've also announced in various ways that DirectX is at least changing with Longhorn. You won't know what software/API/libraries are compatible until release.

Jack

Share this post


Link to post
Share on other sites
Quote:
Original post by jollyjeffers
Quote:
as long as i can program C++ in exactly the same way on Longhorn
For the most part you'll probably be happy, but I'd at least be expecting a few changes. It wouldn't be a very important new OS if nothing changed, if the API's remained constant and so on...

Quote:
Will DX9b be apps be completely compatible.
Again, probably, simply because DirectX is backwards compatable. However, they've also announced in various ways that DirectX is at least changing with Longhorn. You won't know what software/API/libraries are compatible until release.

Jack


They're trying to make current programs still work on Longhorn, so you shouldn't have to change it. However, they're writing new APIs to replace Win32 and Win32 will eventually go the way of DOS.

Share this post


Link to post
Share on other sites
Quote:
they're writing new APIs to replace Win32 and Win32 will eventually go the way of DOS.
I suppose Win32 must be heading towards 10yrs old now (it was premiered in Win95 right?). Granted, that's still a baby by comparison to the software I work on, but for commercial stuff I suppose it's getting on a bit [wink].

Does anyone here know, by comparison, how Long DOS was kicking around before the whole 2k/XP thing got rid of them? more than 10yrs?

Jack

Share this post


Link to post
Share on other sites
Quote:
Original post by jollyjeffers
I suppose Win32 must be heading towards 10yrs old now (it was premiered in Win95 right?).
Win32 premiered in Windows NT 3.1, and was an extension/modification of Win16. Given that legacy, there are parts of the Win32 codebase that are about 20 years old.

Quote:
Does anyone here know, by comparison, how Long DOS was kicking around before the whole 2k/XP thing got rid of them? more than 10yrs?
DOS is a "clone" of sorts of CP/M, which has its roots in the 70s. Considering that DOS wasn't fully eradicated from Windows until Windows 2000, we're looking at about a 25-year lifespan.

Slightly more info.

Share this post


Link to post
Share on other sites
I know that Longhorn will treat self-modifying code as a security problem, so if you use self-modifying code in your game, you'd better get a workaround before Longhorn comes out. Otherwise your code will not run, unless the user is capable of setting their security settings for that particular application (most users will just get fed up and blame your game, not Longhorn).

Share this post


Link to post
Share on other sites
I think I heard somewhere that the idea is that while the win32 apis will still be availlable, they are largely going to become interop wrappers for managed code in longhorn.

In any case, I've heard this a while ago, Longhorn is still a while to come, and things change :).
I wouldn't be surprised that if they run out of time duplicating already existing functionality they will take a step back (i.e., the more short on time they become, the more api's will stay directly linked to the OS instead of going through the managed layer).

On the other hand, the new stuff (like Avalon, of WinFS) is almost certainly going to be managed only, and require users to do interop if not accessed from a .Net language. (VB, C#, MC++)

Share this post


Link to post
Share on other sites
Quote:
Original post by andrewk3652
I know that Longhorn will treat self-modifying code as a security problem, so if you use self-modifying code in your game, you'd better get a workaround before Longhorn comes out. Otherwise your code will not run, unless the user is capable of setting their security settings for that particular application (most users will just get fed up and blame your game, not Longhorn).

Eh?

Longhorn is definitly going to support the NX page flag on the latest processors. Which means if you do self-modifying code without setting the page flags properly then the thing will probably barf.

But outright banning self-modifying code would break the .NET framework and a host of MS apps, never mind the countless 3rd party apps.

But the real thing which cemented the impressiong that you didnt know what the hell you were talking about was the "users will just get fed up and blame your game, not Longhorn". The users are always blaming the new OS for "breaking" existing stuff.

Share this post


Link to post
Share on other sites
Quote:
Original post by ggs
But the real thing which cemented the impressiong that you didnt know what the hell you were talking about


well aren't we full of ourselves

Quote:
was the "users will just get fed up and blame your game, not Longhorn". The users are always blaming the new OS for "breaking" existing stuff.


This is assuming that the user A: has trust in the game already, B: has been using the game on a version of windows prior to Longhorn. Say you develop your game and test it on XP - then Longhorn comes out. Someone buys a PC with Longhorn on it, and goes out and buys your game, never having played it - do you follow me now?

What a jerk.

Share this post


Link to post
Share on other sites
Native code will still work in Longhorn, with Windows in general though there has been a push to make users more security conscious. Currently in order to deploy .Net applications they need to register how much access to the user's system they require and then the user needs to accept the amount of trust that they have for the application in order to run it. The degree of trust requested by managed apps can be verified by the JIT, because they're not writing to potentially random address spaces, and so there are varying degrees of access for them. Native apps can't be verified, so they'll implicitly require full trust of the user. You see some of this in XP SP2 because it warns you whenever you try to open an Executable from an untrusted source and you need to click that additional "I understand" button. In Longhorn it would make sense to extend this security consciousness further. Right now most people run their Windows boxes as Administrator, that should go away in the future. If you're writing native code for Longhorn it will work but you may need to make your users jump through unnatural hoops to run your code.

Your native applications will run fine in the future. The deal with Avalon is that it should be entirely managed and so to work with it you're better off using .Net for ease of interop. Anything that you're doing that's really performance critical you may want to drop to native code anyways, but that's true in managed apps currently already, those rules don't change. For writing anything that isn't tied to .Net, such as GDI/Native-DirectX/OpenGL, you'll probably see better performance writing it entirely native.

Share this post


Link to post
Share on other sites
Quote:
was the "users will just get fed up and blame your game, not Longhorn". The users are always blaming the new OS for "breaking" existing stuff.


this is not an important issue to discuss, but i think this statement is "more" true, because, if a user can see his game on "any" version of windows, then the windows version that does not run it, is always to blame. so even if the user buys a new pc with longhorn, and the system requirements say that it works on xp, then longhorn will be to blame.

Share this post


Link to post
Share on other sites
In that faq they also state that avalon uses some win32 functionality and some .net as far as I remember. Win32 programs will continue to work without problems on longhorn as the faq stated. MFC and dos apps will also be supported. There are just too many varied legacy apps that matter to folks. This backward compatibility is the best thing about windows, imo. I still run my win3.1 encyclopedia on my win98 w/o problems.

Forgot to mention that win32 gdi will be software only and MS says that it should be fine as current hw accel. gdi features are slower than done by cpu if you believe that.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this