That's a good question. The answer is "yes-ish". We have people on our team dedicated to this very task. The first beta version of 8.0 had significantly worse performance than 7.5 - while the final version of 8.0, has accross the board, slightly
better performance than 7.5, thanks to those folks.
The real issue is that we're getting bigger. As we do so, we continually make performance improvements on every piece, but we have more pieces so it adds up to something that looks like status quo. I guess that's not very comforting if you're hoping for drastic
improvements, but perhaps be comforted in knowing this is an area we take seriously and pay close attention to.
Well, one place to start is to stop drawing your own title bars and use the standard, OS-provided ones. Plus, then you'll get instant glass effects as well.
Sparky, I don't have any experience myself with the history of shell SDK documentation, but I think there are explanations for quality of SDK beyond the two you propose (based on what I saw developing parts of the Sharepoint Portal 1.0 programmability
It all comes down to resources. Every team has finite resources, and Microsoft is no different from any other company -- you can't just assume that you can magically double the size of a team overnight to cover all the work you'd ideally like to do.
Even with a court mandate, shell documentation is still minimalistic, missing important information, and in some cases downright incorrect. With the DOJ settlement, a number of new shell interfaces and functions were "documented." But this documentation is
essentially useless: it basically amounts to function signatures, and leaves any idea of how to use it up to the developers' imaginations.
The shell is very powerful and holds a lot of potential for great integration with other apps. But it means nothing if developers can't use it effectively.
this medical-app is a great example...why NOT to use avalon or even web-services. where is the reason to handle critical patients data /w 3d-animated chart-folpping documents or using the "full power"(=100%cpu-time?) and even popping up
Gotta agree here (except for the web services part--for interoperation between separate health care organizations, web services are the way to go).
I used to work at a health care software company. The majority of users used our application via Citrix, many even running at 256 colors. I don't think that WPF is good for these scenarios.
Plus, this application is such a simplification of what real users need from a health care software package--how would this model app look if it actually had as much functionality as a real app? (The app I used to work on? It makes VS 2005 look barren by comparison.)
Maybe these types of simple apps are ok for practices with 1-5 physicians. But for larger customers or hospitals, it wouldn't cut it.
In all the stuff I've read about Sidebar/gadgets, with people comparing them to Dashboard/Konfabulator, people *never* mention Active Desktop. MS introduced Active Desktop in 1997. However, it never took off and it's gone for good in Vista (and in XP
Conceptually, Active Desktop is virtually the same as Dashboard/Sidebar/etc. "You can create Gadgets in WPF or DHTML". You could create Active Desktop components using Win32 or using DHTML. Seriously, the only thing that's really "new" with gadgets is the
fact that they can be non-rectangular, better looking, and physically located in a bar on the side of your screen. Otherwise, it's just a rehash of existing ideas.
Active Desktop, like many other MS technologies, was simply ahead of its time. Back in 1997, people didn't have always-on internet connections, and PCs' system resources were more limited. (Another example of an MS technology ahead of its time: Channels.
RSS feeds is virtually a clone, albeit a standards-based one, of Microsoft's 1997 Channels technology from IE4.)
Ok, thanks for the clarification. With everything being renamed "Windows ___ Foundation", and with everything losing the .NET moniker (VS 2005, Passport), it would make sense if .NET itself were next...
I'd like to understand the relationship between Jet, WinFS and Vista. My understanding is that Jet is the Microsoft Access database format.
There's two separate Jet database engines: Jet Blue (aka Extensible Storage Engine - ESE) and Jet Red (Access). They are completely separate. The one they're talking about here is Jet Blue.
More info from
http://msdn.microsoft.com/library/en-us/ese/ese/portal.asp: "The Extensible Storage Engine (ESE) was formerly known as JET Blue, and so frequently the term "JET Blue" or "JET" is used interchangeably with ESE. However, there are in fact two completely separate implementations of the Joint Engine Technology (JET) API,
called JET Blue and JET Red. The term "JET" is frequently also used to refer to JET Red, which is the database engine under Microsoft Office Access. The two JET implementations are completely different, are separately maintained, have a vastly different feature
set, and are not interchangeable."
Windows Mail. So close to pre-Outlook Express original name, "Internet Mail and News" (MSIMN -- which OE still has as its EXE file).
But the name isn't the only thing. MSIMN was implemented a shell namespace extension. Hearing about how your emails are stored as normal files in the file system, with full metadata -- it's like a blast from the past.
With the OE folder structure in the file system, there isn't much of a need for a separate Mail app -- it could be just a different shell view. I can understand this being infeasible for the Vista timeframe, but as a long term goal it would be great.
Functionally I think the new UI will work great. But please, make it fit in with the Windows UI standards! Don't draw your own title bar. Use standard XP/Vista visual styles when drawing the ribbon bar. Make Office 12 on Windows XP follow the XP guidelines,
and on Vista follow the Vista guidelines. Make Office 12 an excellent example of a Vista application done right!