Ok, I'll take a shot. According to the rumors, the Vista release has been pushed back due to many problems encountered and some of the executives in charge of this release have been fired. One rumor has it that Vista is not very backward compatible with many hardware and software solutions. So, I am hoping that MS gets their act together and expends the necessary resources to completely test out backward compatibility so that we don't all have to rush out and buy new hardware and software.Visual Studio .NET is MS latest platform to develop code for the Windows enviroment. I believe that this includes Vista as well as XP. A better question is probably:What changes would you make in the next version of Visual Studio .NET to make it a better environment to write code?Before I answer this, let me provide some background on how MS handles memory in .NET. Right now, there are 2 different ways of handling memory allocation. One way is to allocate the memory on the stack. This is very efficient and is used for the built-in types like int, float, double, String, DateTime, etc. and structures defined with the Stuct keyword. The other way is to allocate the memory on the heap. This is done for all objects defined with the Class keyword. A structure can be created using either the Class keyword or the Struct keyword. If the Struct keyword is used, then the structure can only be used within the function that defines it. If the structure is passed to another function, then a "boxing" operation occurs where the structure is copied to the heap and a reference to the object on the heap is then passed to the called function. It is my belief that MS implemented it this way so that it could avoid some of the pitfalls of COM's reference counting scheme. Since boxing is a very inefficient operation, most .NET houses would be well advised to avoid using Structs entirely.In C++, the developer has control over whether a class or variable is instantiated on the heap or the stack. In C++ objects declared on the stack call the object's destructor when the function exits. If a reference to this object is stored in a table or passed to another thread, then this reference becomes invalidated when the function exits. This is a major source of bugs in C++ programs. For C++ objects defined on the heap, it is the developer's responsibility to delete the object at the appropriate time. This is also another major source of bugs. Mostly because the developer forgets to delete the object which results in memory leaks that eventually force a reboot of the computer. But there are also times when the developer deletes the object too soon and when some forgotten little used function tries to access the reference, it crashes the program. So, the .NET platform uses a fairly efficient garbage collector that keeps track of all memory created on the heap and collects it when all references to that memory have gone out of scope. Java also uses a garbage collector and the garbage collector is probably the most significant improvement for developing more reliable code because it reliably releases memory when it no longer is used and all of the C++ pitfalls dealing with memory deletion are avoided.Now, the one thing that I would really like to see in the next version of Visual Studio .NET is the capability to treat the built-in types as references. Why is that? When a reference to an object is passed from function to function, the entire memory behind that object is on the heap. All that is being passed around is the address to the object on the heap. When the object is stored in a table, the address is all that is stored. So, if some other fucntion modifies that object and later down the road another function that has the reference to that object needs the latest values for the object - no problem because the object is stored on the heap and the function has the reference (address) to it. However, lets say that you want to do the same thing with a built-in type like an int. Can it be done? Well, since built-in types are always using the value and not the address - there is no way to do this gracefully. However, it can be done in another way, but its somewhat of a headache. There is no way to specify that the address of an int be used instead of its value (without using pointers and using unsafe code in C#; for VB, I don't think it can be done at all). However, the int can be wrapped in a class of its own and then accessed and set with get/set functions. But, this is an ugly kluge. Hopefully MS will take a clue from Java. Java has a duplicate list of built-in types that can be used to treat built-in types as references.