We need heros like this (NSFW - Written foul language, audio is fine so long as you don't have any right-wing patriots nearby) to help us get through the next century.
You haven't beaten it yet? You're missing out on one of the greatest Japanese RPG endings of all-time (granted that you've played through the game, and understand the story). If you're interested:
Xenogears Full-Ending: Part 1
Xenogears Full-Ending: Part 2
Sorry, it's a little too early for me to be replying to threads here. I was up all night! Let's try that again:
Ever heard of profile-guided optimizing compilers? Many runs of a program, in "profiling" mode, that was generated from such a compiler, produces metrics about how the code is actually executed. Next, the the program is recompiled using this information, producing a much more optimized program.
Many C/C++ compilers today support this feature. Including the latest GCC, Intel's C++ compiler, MSVC++ 8.0, and a bunch of others.
I don't know if IBM's compiler for their Cell architecture supports profile guided optimizations, but if they ever want to take full advantage of the architecture, I forsee that they will build it into their compiler.
Ever heard of profile-guided optimizing compilers? Many runs of a program from such a compiler in "profiling" mode produce metrics about how the code is actually executed. Next, the the program is recompiled using this information, producing a much more optimized compiler.
Many C/C++ compilers today support this feature.
I don't know if IBM's compiler for their Cell architecture supports profile guided optimizations, but if they ever want to take full advantage of the architecture, I forsee they will build it in to their compiler.
If you want to know what is going on behind the scenes, nothing is stopping you from viewing the code behind a control or a form in the visual form designer. You can work both ways... drag-and-drop a control onto the form designer and view/augment the generated code, or write the code from scratch by hand, and then view/modify that code from the form designer. If you want to understand how the classes that you inherit from work, you RTFM for the product, in this case, the MSDN Library.
The IDE is a tool, and as a tool, you need to know how to use it properly, otherwise you'll find yourself being used by the tool. The argument boils essentially down to user laziness.
As a long time user of both MSFT's Visual Studio IDEs, Eclipse, and *nix style (autoconf/automake/emacs/etc.) development and build environments, I have to attest that this article is somewhat misleading. Visual Studio doesn't force you to use drag-and-drop anymore than say Eclipse's Visual Editor plugin. Sure, the marketing people at MSFT spend all of their time talking about how VS let's you do drag-drop-n'-click programming, but that doesn't mean the actual product does solely that alone. You can write everything by hand if you so choose.
I think we've seen this argument before, but in other forms. How many times have I seen hard-core C and/or C++ programmers state that "automatic garbage collection rots the mind?" Sure, you might not need to keep track of all of those allocations anymore with GC, but you still need to understand how a given garbage collector works in order to write efficient code for that garbage collector. Same goes with Visual Studio and managed applications: you need to understand the underlying system (in this case the.NET CLR and class library framework) to get the most out of it.
Professional developers worth their salt understand this.
Indeed, certain types of immunosuppressant drugs can be quite harmful. Many heart and/or lung transplant recievers, (if they live beyond the transplant surgery and have good compatability with the donor), often end up with damaged livers after a few years on the immunosuppressants. They then have to begin recieving liver dialysis treatments, which really complicates things further.
But I would have to say that the extra years of life they had been given due to the transplant were invaluable to that person.
Real didn't remove WMP, they only deleted the thin WMP client (75KB) which wraps the WMP subsystem. They left the rest of WMP installed. They also removed any references to the WMP client from the start menu. If MS copied what Real did, I bet you the someone would tell the EU that WMP was still installed, and the EU would complain. The EU is acting hypocritical and ignorant.
Real just deleted the thin Windows Media Player client which wraps the WMP subsystem. It's only 75KB. They also removed all references of it from the Start Menu and what not. Have a look at my post here, which describes how MS Office is dependent on WMP.
"But for the EU to ask them to rewrite how this all works, and to rewrite all of their software (ie. Office) to work with it overnight, I think it's asking a little too much. Even of MSFT."
Look, I'm not asking you or anyone to be sympathetic, I'm only asking you to consider the logistics of the situation.
Imagine yourself as a developer at MSFT in the WMP division (yes, I know, the horror of it all!), and your manager has just finished holding a meeting concerning the removal of WMP from Windows. Several avenues of attack were considered.
Firstly, it was discussed that the WMP client just be removed. It is a thin wrapper around a bunch of DLLs which do all of the real work. However, If the client is the only thing removed, the EU might complain that WMP wasn't really removed from the system.
It was then determined that the whole thing needs to go out the door. Yes, it would horribly break other applications like Office, but since you're in the WMP division, Office isn't your responsibility. Changes to Office would likely need to be made in the future. Furthermore, Office isn't a part of the OS, and the EU didn't say anything about changing Office, right?
So, after the meeting, you rip out the guts of WMP, and cast it into the wind. You get the stamp of approval, and your changes are committed.
Sounds simple, right? Except for the fact that now Office still needs to be updated, which isn't so simple. Such changes could take months, and to re-release a special version of Office that works with the version of Windows lacking WMP is a little more involved. All of those EU citizens and the companies they work for or run need to "upgrade" to the new versions of software, in addition to "upgrading" to the new version of the OS.
That just compounds the existing problem. Yes, if Office was written better in the first place, it wouldn't be so difficult, but it wasn't, and you can't change the past. You're stuck in the present.
What would you do if you were in a situation like that? As of current, I don't think that the current actions of MS in removing WMP are unreasonable. Yes, Office needs to be fixed, but they haven't had time to do that yet.
Yes, you're right. MS Office, and other software suites, that run on Windows should be a little more pragmatic and adaptable.
But really, this is no different than dependency problems in the FOSS world. Like a previous poster said, take away Gtk/Gnome and then try running a Gtk dependent app on a KDE-only setup, and you're fubared. Why should MSFT be held to such high standards of always re-inventing the wheel for each piece of software they release, when they already have an existing wheel that does the trick?
It would be possible to change MS Office to be less reliant on the WMP SDK, but like I said, it's not going to happen overnight. And for the EU to expect so, that's rather ignorant of thme.
... on development libraries like the Windows Media Player SDK. When MSFT was ordered to remove Windows Media Player (WMP), I bet they went ahead and removed the associated SDK redistributable components and activex controls, not just the Media Player client. This of course has an effect on the registry as well, since it stores certain settings in the registry. I bet Real just removed the Media Player client, and not everything else that is a part of WMP.
MS Office uses the ActiveX component that is a part of WMP to embed media content in documents (Link). This ActiveX component, due to certain design constraints, can't be shipped seperately from the WMP client (link).
The fact that they removed this stuff does indeed mean that MS Office no longer plays media content properly. I find it funny that the EU is complaining about this, as they got exactly what they wanted!
Perhaps in the future, MSFT will expose a framework that allows third party media player development libraries to plug into the desktop environment, allowing other applications to use whatever libraries are currently configured to play media. Kind of similar to how they've exposed anti-virus hooks for AV vendors to plug into.
But for the EU to ask them to rewrite how this all works, and to rewrite all of their software (ie. Office) to work with it overnight, I think it's asking a little too much. Even of MSFT.
Avalon 1.0 will be shipping for 2K/XP/2K3 in november/december. The Avalon that Longhorn will have will be Avalon 2.0, and will have more features.
DRM is just for Windows Media Player formats like ASF and WMV. And the primary use of ASF and WMV right now is through online media stores that let you purchase music and movies. You can still play your MP3s, MPEGs, AVIs, OGGs, OGMs, and FLACs just fine. I think DRM is a bad thing, but people are blowing MS's implementation of it out of proportion. Longhorn has no more support for DRM than does Windows XP.
This makes me wonder regarding the status for System.Windows.Forms in Longhorn. Is System.Windows.Forms still the recommended GUI-framework in Longhorn? Is the release of its replacement post-poned?
System.Windows.Forms and GDI+ (System.Drawing) are still fully supported in Longhorn, and right now are the recommended way to begin transitioning your applications towards Longhorn.
However, Longhorn has an entirely knew API known as WinFX, which is a superset of the.NET Framework.
The new GUI is a vector-based 2D and 3D compositing system known as Avalon. Avalon is built on top of DirectX. Avalon, DirectX, and GDI+ are known collectively as the Windows Graphics Foundation or WGF.
Avalon has a much larger scope over System.Windows.Forms, and if you would like take a glimpse at all of the new stuff (the new namespaces added under System.Windows), then check out the WinFX API Reference. WinFX is a quite a big step up from traditional Win32 programming.
Mono has stated on their roadmap that it is too early to tell if they will support the technologies in Longhorn, but chances are, they eventually will.
Avalon seems to be more hardware and platform agnostic than System.Windows.Forms. Things like HWNDs are now hidden behind a polymorphic class interface, and that's just the beginning. You really need to check it out to understand how it works. Anyway, stuff like that should make it easier to port to things like Mac OS X, Linux, *BSD, and so on.
I don't understand why Microsoft doesn't redesign their product to focus on 3 things: the kernel, the GUI, and the rest of the apps they ship with Windows./cite
Ummm. They did and are doing that. Everything got a complete overhaul. They have a new OS API, known as WinFX (a superset of.NET). WinFX and.NET are integrated into the kernel. The next versions of IE, Office, and even small things like Notepad and Calculator were rewritten using WinFX. And fyi,.NET and WinFX have very strong security models. Do your research before making statements.
You can look at C# as two languages: an "unsafe" and a "safe" language. The safe language is the equivalent of Java. The "unsafe" language is the equivalent of C or C++ linked in through JNI. Linking "unsafe" to "safe" code in C# has the same restrictions on it as does linking native code to pure Java code in Java. So, Gosling's rantings have no technical merit.
You got this wrong too. As Don explained in his blog, if you weren't too busy to have read it, you'd realize that "unsafe" C# is still managed code. It doesn't get "linked" through the CLR's equivalent of a JNI interface. It's still managed code. There isn't any unmanaged code here to speak of. C# code can still interoperate with unmanaged code using the.NET BCL's P/Invoke and COM interop layers, but it has nothing to do with the "unsafe" subset of the C# language. It's a part of the.NET Framework itself, and all managed languages targetting the.NET Framework can utilize those features.
Yeah, right - the same problem as with signed ActiveX - once a buffer overflow in the trusted code is found, your security is a fair game - the attacker has to only persuade e.g. your browser to load the buggy but trusted code. The managed languages like C# and Java were invented exactly with the purpose to prevent this kind of holes.
Well, you should know that in the.NET security model, the only trusted code is safe and verifiable code... code that can be verified by the.NET CLR to be safe. That is, no buffer overflows, full type-safety, etc.
You also have fine grain control over what security access rights you can give an application, particularily one you've downloaded off the net. You can restrict access to the file system (in a fine-grain manner, like which directories or files it has access to), sockets, access to other processes and global resources, unmanaged code-execution, unsafe code-execution, the list just goes on.
Microsoft has actually created new language extensions for C++, and collectively it is called the C++/CLI language, which is a superset of ISO Standard C++ 14882-98. The MSVC++ 2005 (8.0) compiler, which is an implementation of C++/CLI, allows several programming models. You can develop pure managed applications and assemblies in C++/CLI--these are applications that are completely type-safe and have no buffer overflows as they are verifiable. Developing pure managed applications means that you can't use unmanaged code, however, like traditional STL or the standard C++ libraries--instead, you use the.NET base class library. There is also a version of STL that is completely managed using a combination of C++ templates and.NET generics. Next, you can develop mixed managed and unmanaged applications, allowing you to yes, have unsafe code. But you need to have given the application proper security rights to jump into unmanaged code sections before you can execute it. The safety is transfered to the user. And then, finally, theres the traditional unmanaged model that most of use are familiar with, where you write standard C/C++ applications--no use of.NET.
Anyway, the point is is this is much better than ActiveX. Microsoft has really focused a lot on security; although unfortunately, most of it is not going to come to light until people start releasing more managed applications.
It looks like you have an older video card, and since SphereXP uses a 3d GPU, it makes a huge difference. The difference in smoothness in MSN messenger is due to the change in use of mipmaps, but your card probably can't do anistropic filtering very well. Plus it looks like your card doesn't support high-resolution textures. Nor does it support full-screen anti-aliasing. Hence why everything looks like crap. The screenshots on the SphereXP site look way better because they're using better hardware.
Don't blame the software, blame your own hardware.
Don't forget that Windows NT and 2000 have existed on 64-bit Sparc, Alpha, PowerPC, and Itanium processors. These builds weren't generally available to the public, however, as they were made for special orders with business partners.
The only difference now is that 64-bit processors have become available to the general public at an affordable price.
The Windows NT/2K/XP/2K3 kernels and core subsystems are just as portable and CPU-word-size agnostic as say Linux or FreeBSD.
Let me get this straight. First, you say that WinXP 64 won't run your legacy DOS/Win3.1 applications, and then you say that these limitations don't exist for 64-bit Linux? But since when did 16-bit DOS or Windows 3.1 applications run under Linux without an emulator?
Sure Wine will run 16-bit DOS and Windows 3.1 applications on Linux. But guess what? Wine is also available for Windows.
As for the new driver model, I believe they changed it to increase security, stability, and the ease with which developers can create drivers. It's a good thing that they changed it, not a bad one. That does mean that a lot of old hardware won't be supported, and that that good drivers won't exist for other more modern pieces of hardware until the hardware vendors release them. But for one, Windows XP 64 was made for modern hardware, not old machines, and the shortage of some drivers is only temporary.
So sure, you're stuck with using a limited array of hardware to start out with, but Linux still suffers from the same problem. There's unfortunately still a lot of Linux unfriendly hardware out there.
All in all, I think you are being hypocritical, just for the sake of bashing MS. If you're going to bash them, at least do so with some solid facts. You're making the rest of us look bad.
As you suggested, it's primarily because of the drivers and because most games are not compiled natively as 64-bit executables yet. The 64-bit drivers from ATI and nVidia are still beta. No self-respecting person would base a final decision off of benchmarking such drivers.
However, even so, with some applications, I've noticed huge increases in speed when running non-DirectX/non-Opengl 32-bit applications in 32-bit emulation mode on my AMD 64 3500+ (with Windows XP Pro x64 Edition RC1). This is due to the fact that memory bandwidth is now doubled, as the WoW64 emulator is running 64-bit mode simulating an environment for the 32-bit apps.
Anyway, I suspect that shortly after Win XP Pro 64 goes gold, we'll see a lot of updates to 64-bit drivers that are still in beta.
Slashdot Mirror
Eh? Heavy water is used in hundreds of modern fission nuclear reactors around the world--it acts as a moderator for the fission reaction.
We need heros like this (NSFW - Written foul language, audio is fine so long as you don't have any right-wing patriots nearby) to help us get through the next century.
Please ensure that brain is in gear before engaging mouth.
POSIX Threads for Win32 compability layer. 'Nuff Said.
You haven't beaten it yet? You're missing out on one of the greatest Japanese RPG endings of all-time (granted that you've played through the game, and understand the story). If you're interested:
Xenogears Full-Ending: Part 1
Xenogears Full-Ending: Part 2
Ever heard of profile-guided optimizing compilers? Many runs of a program, in "profiling" mode, that was generated from such a compiler, produces metrics about how the code is actually executed. Next, the the program is recompiled using this information, producing a much more optimized program.
Many C/C++ compilers today support this feature. Including the latest GCC, Intel's C++ compiler, MSVC++ 8.0, and a bunch of others.
I don't know if IBM's compiler for their Cell architecture supports profile guided optimizations, but if they ever want to take full advantage of the architecture, I forsee that they will build it into their compiler.
Ever heard of profile-guided optimizing compilers? Many runs of a program from such a compiler in "profiling" mode produce metrics about how the code is actually executed. Next, the the program is recompiled using this information, producing a much more optimized compiler.
Many C/C++ compilers today support this feature.
I don't know if IBM's compiler for their Cell architecture supports profile guided optimizations, but if they ever want to take full advantage of the architecture, I forsee they will build it in to their compiler.
If you want to know what is going on behind the scenes, nothing is stopping you from viewing the code behind a control or a form in the visual form designer. You can work both ways... drag-and-drop a control onto the form designer and view/augment the generated code, or write the code from scratch by hand, and then view/modify that code from the form designer. If you want to understand how the classes that you inherit from work, you RTFM for the product, in this case, the MSDN Library.
The IDE is a tool, and as a tool, you need to know how to use it properly, otherwise you'll find yourself being used by the tool. The argument boils essentially down to user laziness.
As a long time user of both MSFT's Visual Studio IDEs, Eclipse, and *nix style (autoconf/automake/emacs/etc.) development and build environments, I have to attest that this article is somewhat misleading. Visual Studio doesn't force you to use drag-and-drop anymore than say Eclipse's Visual Editor plugin. Sure, the marketing people at MSFT spend all of their time talking about how VS let's you do drag-drop-n'-click programming, but that doesn't mean the actual product does solely that alone. You can write everything by hand if you so choose.
.NET CLR and class library framework) to get the most out of it.
I think we've seen this argument before, but in other forms. How many times have I seen hard-core C and/or C++ programmers state that "automatic garbage collection rots the mind?" Sure, you might not need to keep track of all of those allocations anymore with GC, but you still need to understand how a given garbage collector works in order to write efficient code for that garbage collector. Same goes with Visual Studio and managed applications: you need to understand the underlying system (in this case the
Professional developers worth their salt understand this.
Indeed, certain types of immunosuppressant drugs can be quite harmful. Many heart and/or lung transplant recievers, (if they live beyond the transplant surgery and have good compatability with the donor), often end up with damaged livers after a few years on the immunosuppressants. They then have to begin recieving liver dialysis treatments, which really complicates things further.
But I would have to say that the extra years of life they had been given due to the transplant were invaluable to that person.
Real didn't remove WMP, they only deleted the thin WMP client (75KB) which wraps the WMP subsystem. They left the rest of WMP installed. They also removed any references to the WMP client from the start menu. If MS copied what Real did, I bet you the someone would tell the EU that WMP was still installed, and the EU would complain. The EU is acting hypocritical and ignorant.
Real just deleted the thin Windows Media Player client which wraps the WMP subsystem. It's only 75KB. They also removed all references of it from the Start Menu and what not. Have a look at my post here, which describes how MS Office is dependent on WMP.
I assume you're referring to this line:
"But for the EU to ask them to rewrite how this all works, and to rewrite all of their software (ie. Office) to work with it overnight, I think it's asking a little too much. Even of MSFT."
Look, I'm not asking you or anyone to be sympathetic, I'm only asking you to consider the logistics of the situation.
Imagine yourself as a developer at MSFT in the WMP division (yes, I know, the horror of it all!), and your manager has just finished holding a meeting concerning the removal of WMP from Windows. Several avenues of attack were considered.
Firstly, it was discussed that the WMP client just be removed. It is a thin wrapper around a bunch of DLLs which do all of the real work. However, If the client is the only thing removed, the EU might complain that WMP wasn't really removed from the system.
It was then determined that the whole thing needs to go out the door. Yes, it would horribly break other applications like Office, but since you're in the WMP division, Office isn't your responsibility. Changes to Office would likely need to be made in the future. Furthermore, Office isn't a part of the OS, and the EU didn't say anything about changing Office, right?
So, after the meeting, you rip out the guts of WMP, and cast it into the wind. You get the stamp of approval, and your changes are committed.
Sounds simple, right? Except for the fact that now Office still needs to be updated, which isn't so simple. Such changes could take months, and to re-release a special version of Office that works with the version of Windows lacking WMP is a little more involved. All of those EU citizens and the companies they work for or run need to "upgrade" to the new versions of software, in addition to "upgrading" to the new version of the OS.
That just compounds the existing problem. Yes, if Office was written better in the first place, it wouldn't be so difficult, but it wasn't, and you can't change the past. You're stuck in the present.
What would you do if you were in a situation like that? As of current, I don't think that the current actions of MS in removing WMP are unreasonable. Yes, Office needs to be fixed, but they haven't had time to do that yet.
Yes, you're right. MS Office, and other software suites, that run on Windows should be a little more pragmatic and adaptable.
But really, this is no different than dependency problems in the FOSS world. Like a previous poster said, take away Gtk/Gnome and then try running a Gtk dependent app on a KDE-only setup, and you're fubared. Why should MSFT be held to such high standards of always re-inventing the wheel for each piece of software they release, when they already have an existing wheel that does the trick?
It would be possible to change MS Office to be less reliant on the WMP SDK, but like I said, it's not going to happen overnight. And for the EU to expect so, that's rather ignorant of thme.
I believe the mentality you have imbued your post with is exactly the mentality of some of those EU legislators.
... on development libraries like the Windows Media Player SDK. When MSFT was ordered to remove Windows Media Player (WMP), I bet they went ahead and removed the associated SDK redistributable components and activex controls, not just the Media Player client. This of course has an effect on the registry as well, since it stores certain settings in the registry. I bet Real just removed the Media Player client, and not everything else that is a part of WMP.
MS Office uses the ActiveX component that is a part of WMP to embed media content in documents (Link). This ActiveX component, due to certain design constraints, can't be shipped seperately from the WMP client (link).
The fact that they removed this stuff does indeed mean that MS Office no longer plays media content properly. I find it funny that the EU is complaining about this, as they got exactly what they wanted!
Perhaps in the future, MSFT will expose a framework that allows third party media player development libraries to plug into the desktop environment, allowing other applications to use whatever libraries are currently configured to play media. Kind of similar to how they've exposed anti-virus hooks for AV vendors to plug into.
But for the EU to ask them to rewrite how this all works, and to rewrite all of their software (ie. Office) to work with it overnight, I think it's asking a little too much. Even of MSFT.
Avalon 1.0 will be shipping for 2K/XP/2K3 in november/december. The Avalon that Longhorn will have will be Avalon 2.0, and will have more features. DRM is just for Windows Media Player formats like ASF and WMV. And the primary use of ASF and WMV right now is through online media stores that let you purchase music and movies. You can still play your MP3s, MPEGs, AVIs, OGGs, OGMs, and FLACs just fine. I think DRM is a bad thing, but people are blowing MS's implementation of it out of proportion. Longhorn has no more support for DRM than does Windows XP.
Sorry for the bad formatting. /. stripped my newlines!
This makes me wonder regarding the status for System.Windows.Forms in Longhorn. Is System.Windows.Forms still the recommended GUI-framework in Longhorn? Is the release of its replacement post-poned? System.Windows.Forms and GDI+ (System.Drawing) are still fully supported in Longhorn, and right now are the recommended way to begin transitioning your applications towards Longhorn. However, Longhorn has an entirely knew API known as WinFX, which is a superset of the .NET Framework.
The new GUI is a vector-based 2D and 3D compositing system known as Avalon. Avalon is built on top of DirectX. Avalon, DirectX, and GDI+ are known collectively as the Windows Graphics Foundation or WGF.
Avalon has a much larger scope over System.Windows.Forms, and if you would like take a glimpse at all of the new stuff (the new namespaces added under System.Windows), then check out the WinFX API Reference. WinFX is a quite a big step up from traditional Win32 programming.
Mono has stated on their roadmap that it is too early to tell if they will support the technologies in Longhorn, but chances are, they eventually will.
Avalon seems to be more hardware and platform agnostic than System.Windows.Forms. Things like HWNDs are now hidden behind a polymorphic class interface, and that's just the beginning. You really need to check it out to understand how it works. Anyway, stuff like that should make it easier to port to things like Mac OS X, Linux, *BSD, and so on.
I don't understand why Microsoft doesn't redesign their product to focus on 3 things: the kernel, the GUI, and the rest of the apps they ship with Windows.
Ummm. They did and are doing that. Everything got a complete overhaul. They have a new OS API, known as WinFX (a superset of
You can look at C# as two languages: an "unsafe" and a "safe" language. The safe language is the equivalent of Java. The "unsafe" language is the equivalent of C or C++ linked in through JNI. Linking "unsafe" to "safe" code in C# has the same restrictions on it as does linking native code to pure Java code in Java. So, Gosling's rantings have no technical merit.
.NET BCL's P/Invoke and COM interop layers, but it has nothing to do with the "unsafe" subset of the C# language. It's a part of the .NET Framework itself, and all managed languages targetting the .NET Framework can utilize those features.
You got this wrong too. As Don explained in his blog, if you weren't too busy to have read it, you'd realize that "unsafe" C# is still managed code. It doesn't get "linked" through the CLR's equivalent of a JNI interface. It's still managed code. There isn't any unmanaged code here to speak of. C# code can still interoperate with unmanaged code using the
Yeah, right - the same problem as with signed ActiveX - once a buffer overflow in the trusted code is found, your security is a fair game - the attacker has to only persuade e.g. your browser to load the buggy but trusted code. The managed languages like C# and Java were invented exactly with the purpose to prevent this kind of holes.
Well, you should know that in the
You also have fine grain control over what security access rights you can give an application, particularily one you've downloaded off the net. You can restrict access to the file system (in a fine-grain manner, like which directories or files it has access to), sockets, access to other processes and global resources, unmanaged code-execution, unsafe code-execution, the list just goes on.
Microsoft has actually created new language extensions for C++, and collectively it is called the C++/CLI language, which is a superset of ISO Standard C++ 14882-98. The MSVC++ 2005 (8.0) compiler, which is an implementation of C++/CLI, allows several programming models. You can develop pure managed applications and assemblies in C++/CLI--these are applications that are completely type-safe and have no buffer overflows as they are verifiable. Developing pure managed applications means that you can't use unmanaged code, however, like traditional STL or the standard C++ libraries--instead, you use the
Anyway, the point is is this is much better than ActiveX. Microsoft has really focused a lot on security; although unfortunately, most of it is not going to come to light until people start releasing more managed applications.
It looks like you have an older video card, and since SphereXP uses a 3d GPU, it makes a huge difference. The difference in smoothness in MSN messenger is due to the change in use of mipmaps, but your card probably can't do anistropic filtering very well. Plus it looks like your card doesn't support high-resolution textures. Nor does it support full-screen anti-aliasing. Hence why everything looks like crap. The screenshots on the SphereXP site look way better because they're using better hardware.
Don't blame the software, blame your own hardware.
Don't forget that Windows NT and 2000 have existed on 64-bit Sparc, Alpha, PowerPC, and Itanium processors. These builds weren't generally available to the public, however, as they were made for special orders with business partners. The only difference now is that 64-bit processors have become available to the general public at an affordable price. The Windows NT/2K/XP/2K3 kernels and core subsystems are just as portable and CPU-word-size agnostic as say Linux or FreeBSD.
Let me get this straight. First, you say that WinXP 64 won't run your legacy DOS/Win3.1 applications, and then you say that these limitations don't exist for 64-bit Linux? But since when did 16-bit DOS or Windows 3.1 applications run under Linux without an emulator? Sure Wine will run 16-bit DOS and Windows 3.1 applications on Linux. But guess what? Wine is also available for Windows. As for the new driver model, I believe they changed it to increase security, stability, and the ease with which developers can create drivers. It's a good thing that they changed it, not a bad one. That does mean that a lot of old hardware won't be supported, and that that good drivers won't exist for other more modern pieces of hardware until the hardware vendors release them. But for one, Windows XP 64 was made for modern hardware, not old machines, and the shortage of some drivers is only temporary. So sure, you're stuck with using a limited array of hardware to start out with, but Linux still suffers from the same problem. There's unfortunately still a lot of Linux unfriendly hardware out there. All in all, I think you are being hypocritical, just for the sake of bashing MS. If you're going to bash them, at least do so with some solid facts. You're making the rest of us look bad.
As you suggested, it's primarily because of the drivers and because most games are not compiled natively as 64-bit executables yet. The 64-bit drivers from ATI and nVidia are still beta. No self-respecting person would base a final decision off of benchmarking such drivers.
However, even so, with some applications, I've noticed huge increases in speed when running non-DirectX/non-Opengl 32-bit applications in 32-bit emulation mode on my AMD 64 3500+ (with Windows XP Pro x64 Edition RC1). This is due to the fact that memory bandwidth is now doubled, as the WoW64 emulator is running 64-bit mode simulating an environment for the 32-bit apps.
Anyway, I suspect that shortly after Win XP Pro 64 goes gold, we'll see a lot of updates to 64-bit drivers that are still in beta.