WinFX = Windows Frameworks.
In late 2006, WinFX is now called .NET Framework 3.0.
WinFX is a developers tool that ordinary mortals just take for granted. In evolutionary terms, WinFX has evolved from Win 16 and Win 32 APIs.
So what is WinFX really? Well, WinFX is an object-oriented API that builds on the .NET framework and shows the breadth of Longhorn. So if you’re familiar with the .NET frameworks forms, you’re going to be right at home with WinFX.
Longhorn will make a clean split with the Win32 APIs of legacy Windows operating systems. One such API, Avalon, forms the basis for the new Desktop Compositing Engine (DCE) in Longhorn that replaces GDI and GDI+. These and other new Longhorn APIs will utilize the XML Application markup language (XAML) to make Longhorn more accessible to developers than ever before.
Another significant change in Longhorn involves device drivers. In the past, Microsoft allowed customers to use non-signed drivers, which helped compatibility, but caused stability problems. No more: In Longhorn, users hoping to take advantage of the system’s exciting new capabilities will only be able to use signed drivers.
Extract from a Microsoft Presentation on WinFX.
This resume will give you an overview of the namespaces and the key types that are available in WinFX.
First we have the three pillars, presentation, data and communications. Next we have the fundamental block containing all the infrastructure that’s available, ubiquitously. So first thing, the client application model. If you’re building an application that runs on the client and leverages the power of the client operating systems, we have the Windows Forms functionality that you know and love today from the .NET framework.
In addition, for building Longhorn applications, we have the Avalon functionality, and it’s in the system.windows namespace. Then for Web and Services applications, we have ASP.net and a new technology for our Web Services called Indigo. They both share the same underlying application model in the system.web namespace. Next we have the data systems. With the work that we’re doing in Yukon to enable you to write store procedures, manage code in the database with UDTs.
Microsoft are introducing a new abstraction for storage of data in the file system called WinFS, which gives you access to your everyday information right out of the database in DOS. And then there’s the mobile and devices application model.
Okay, so now let’s drill into the heart of the namespaces and see what’s here. The first thing you’ll notice is the system.windows namespace. This contains the sub-namespaces and core types of Avalon, which is the new presentation subsystem for Windows. It’s available on the Longhorn operating system and is the primary way to build these first-class client applications for Longhorn.
And of course we have the other parts of the presentation that you know and love from the .NET framework today. System Windows Forms, which is for building client applications that have to run on the full range of Windows operating systems. System Web UI gives you the ASP.net projected UI view.
Next let’s roll over to data and we’ll talk about System.data is the ADO.NET stack and that’s the ADO.NET stack that you know and love today, and I’m happy to announce that even in WinFX we have not changed the data model. And then we are introducing a new namespace in Whidbey called Object Spaces which gives you an objective view of data so that you can access the rows and columns of the database in terms of objects and methods on those objects, rather than having to understand the schema of the database.
The next thing we want to look at is WinFS. Now WinFS is represented in this namespace, and as I mentioned earlier, WinFS is a really modernizing of the Windows File System. And what it gives you is we have taken the relational asset of SQL Server and we’ve put it into the operating system so that it’s available for a broad range of applications to use.
SolarWinds’ Network Performance Monitor will help you discover what’s happening on your network. This utility will also guide you through troubleshooting; the dashboard will indicate whether the root cause is a broken link, faulty equipment or resource overload.
Perhaps the NPM’s best feature is the way it suggests solutions to network problems. Its second best feature is the ability to monitor the health of individual VMware virtual machines. If you are interested in troubleshooting, and creating network maps, then I recommend that you give this Network Performance Monitor a try.
And then we’ll look over at the Communications stack. You can see we have a wide variety of functionality available for you to use for communications from one node on the network to another node on the network. The first thing you’ll recognize or that will capture your attention is System.Collaboration. This is where we’re adding collaborative support into the core parts of the operating system.
Then I’ll highlight System.Message Bus, and System.Message Bus is the functionality for Indigo, and it’s for building service-oriented applications, that is applications that share contracts over the Net. And then we have System.Net, which is the core functionality for accessing network resources at a much lower level. Well that gives you a very high level overview of WinFX. Over the next few weeks you’re going to see lots more information on each one of these areas.
But if you’re a .NET Framework developer you’re probably interested in understanding how the .NET Framework relates to WinFX that we just talked about. The important thing to realize is that WinFX embraces and extends the .NET Framework. One hundred percent of the .NET Framework is included in WinFX and we’re carrying that forward in Longhorn. So just like your existing Win 32 applications will work great on Longhorn, your .NET Framework apps will work great on Longhorn with WinFX as well.
So you can think of the .NET Framework as being the redistributable subset of WinFX. Think of WinFX as being closely tied with the Longhorn operating systems and future operating systems, and the .NET Framework as being that subset of WinFX that can go down a level.
So, just to summarize where we are, WinFX gives developers a broad new developer surface for all of Windows. It’s a modern, object-oriented API that we’ve spent literally thousands of hours all ready designing to ensure that it fits in nicely with the .NET Framework and is very easy to use. And the best way to prepare for Longhorn and to prepare for WinFX going forward is to build on the .NET Framework today. Thank you.
If you have used Remote Desktop then you will have been disappointed with the graphics experience compared with running Windows 7 locally. SP1 introduces an updated client to supply RDP (Remote Desktop Protocol) connections with RemoteFX.
With Windows 7 SP1, RemoteFX improves the Remote Desktop experience by supporting Windows Aero, full-motion video, and 3D graphics. To reap these benefits make sure the Windows 2008 Server has a DirectX 10.0 graphics card to support the Windows 7 SP1 guest operating system.
Incidentally, this technology has undergone more re-naming than any other Windows component, what used to be called Terminal Services is now Session Virtualization.
If you like this page then please share it with your friends