WinFX = Windows Frameworks, now called .NET Framework 3.0.
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.
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.
Guy Recommends: The Orion Network Performance Monitor (NPM) 9.5
Orion's performance monitor is designed for detecting network outages.
This NPM will guide you
through troubleshooting by indicating whether the root cause is a broken link,
faulty equipment or resource overload. Because it produces
network-centric views, it is intuitive to navigate, and as result you can
see easily what's working and what's not.
Perhaps Orion's best feature is the way it suggests solutions. Moreover, if
problems arise out of the blue, then you can configure Orion NPM 9.5 to notify
members of your team what's changed and how to fix it.
Train Signal has
now released their
Windows Server 2008 Training Course. As an MCT
trainer, I am a huge advocate of Train Signal’s products. What particularly
impresses is me is the demonstrations. If
you are looking for a complete DETAILED coverage of Windows Server 2008, then I highly recommend that you give this course a try. I have reviewed their
6 hours plus of videos myself, and I guarantee that you will
not be disappointed!