C++ on Longhorn
Author
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.
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
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
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
Quote:as long as i can program C++ in exactly the same way on LonghornFor 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
Quote:Original post by jollyjeffersQuote:as long as i can program C++ in exactly the same way on LonghornFor 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.
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
Quote:Original post by jollyjeffersWin32 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.
I suppose Win32 must be heading towards 10yrs old now (it was premiered in Win95 right?).
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.
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).
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++)
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++)
Search the forums, this has been discussed to death.
Your unmanaged C++ will suffer a speed hit from the interop when running under Longhorn, which brings about seething anathema.
Your unmanaged C++ will suffer a speed hit from the interop when running under Longhorn, which brings about seething anathema.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement