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.
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?
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.
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.
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.
