Windows began as an un-networked, single-user operating system. With the advent of the Internet (as a public utility), Windows evolved to expose every connected computer to bad actors. For the sake of "innovation," the Windows security model anticipates
nearly every instance where some administrator in the world would want to prevent a user from doing something. Hence, the security model is overtly complex. Meanwhile, the principle of least action dictated that most computers are logged on as Administrator,
thereby providing an easy target for malware. One cannot rely on a dictate to users that they change habitual behavior: log in as ordinary user except when necessary. Solution: log in as administrator, but limit privileges to those permitted through the
UAC interface. In other words, when a program attempts to do something questionable, query the system operator, as if he/she knows what the hell the question means and what the answer should be.
Well, it should reduce the surface area available for attack. It doesn't make available a comprehensible and comprehensive list of privileges that indicates which ones are enabled/disabled for a given user at any time. It doesn't indicate the proposed change
to privileges because that would be technically very difficult to do. It is a glass half full situation. Better than nothing. Decidedly, better than nothing.
Fantastic video. A C# project that runs a disco floor for the most excellent purpose of getting girls to come visit! Has anyone contacted Marketing? "C#: The programming language that runs your enterprise and improves your love life! At better retailers
everywhere. Oh, and don't forget to see our new Vista OS on display -- now with AEROGLASS technology."
As Windows has evolved from a toy, single-user, not networked computer operating system to an enterprise, multi-user, networked operating system, the nature of managing the operating system has changed. Legacy compatibility requirements have motivated
implementation of a complex security solution that permits users to run as they have always run, as Administrator, yet, through software trickery, they are not actually given permissions until they attempt to do something dangerous. Dangerous things involve
changing operating system components, installed applications, registry entries, time-of-day, some forms of communicating on the Internet, and so forth. Certain well-defined compatibility issues have been resolved with "shims" that permit certain forbidden
actions by converting the forbidden action to a permitted action with the application being none the wiser.
Has anybody published an exhausive list of actions that a program may attempt that will evoke the UAC dialog?
One hopes that, in time, the complexity of this transition solution will be replaced with a much simpler security model that one can keep in one's head as one develops killer apps for Microsoft Windows.
The Session 0-Session N problem, where applications falsely believe there is only one Session active at any given time is absolutely hilarious. What is really needed is a window that incarnates Session 0. The window opens in whatever Session is being viewed
at a given time. This is much better than having dialog boxes open to announce (for example, printer) problems to an invisible Session. On mainframes, there is such a thing as "an operator's console" where system global state messages constantly appear.
Windows doesn't have, yet now requires, something similar.
Well, I think Mr. Holecek's chat about the "shell" was quite interesting. It makes great radio.
The "Story of Vista," as I understand it, is that the vast project went out of control in 2003 because unintended and unanticipated component interactions were occurring and the OS could not be stabilized given time and money constraints. So, it was decided
to ditch, for the time being, one of the major new features, ditch some quantity of new code, and restart development from a stable platform like Windows 2003 Server and/or Windows XP.
An earlier Channel 9 video features a group of people who are working to better understand how all the parts of Windows interact. It is sad but true that complex systems are hard to understand in all their complexity. The market-driven need for backward compatibility
adds to complexity.
Thanks very much to Nar for the excellent discussion. I was thinking how Channel 9 audio could be improved: wireless mic. The interviewee clips on a wireless mic. It is a radio transmitter. Charles runs a radio receiver which plugs into the video
camera. Then, instead of picking up the speaker's voice plus all the ambient noise and echo, we hear the speaker's voice by itself. And the speaker can wander about the room and talk at the same time without losing a syllable. Eh?
Open Source and Closed Source need not conflict, especially in view of the fact that Open Source applications can drive sales of Closed Source products. One reason for the existence of the Close Source marketing model is to protect Intellectual Property.
Another is to thwart the dispersion of multiple unofficial versions of a product with varying quality and responsibility for evolution and correction. Open Source does admit a greater number of people to review, correct, enhance, and learn code and methods.
Ownership of such changes cannot be clearly established without a contract.
Code reuse is a compelling idea. Software componentry would decompose solutions into not only classes and modules, but also into reusable components. So far, in practice, reusable components have not materialized in a big way. It would be nice to see
those fat books of patterns implemented as components and widely reused, if that's even technically possible.
As to COM, it solved a bunch of problems and created more. Like the "Hello, World!" C++ program in Petzold that is some 200 lines long, a COM solution contains many an arcane line that caters to the dainty way COM objects must be approached to get them to
do anything. And using COM objects from across a network is an absolute nightmare. Stubs and proxies indeed. Worst of all, the Registry is highly involved in GUID-to-<anything> mapping. Any mishap in there and the application crashes without hope of repair.
In the end, COM served a very important purpose as a way to deliver versionable software. Microsoft wrote millions of lines using COM. COM's most important function was to serve as an example of how to burden programmers with issues they should not be bothered with
like reference counting and instantiation. The bit level constraints on the design of COM rose up and bit everyone who tried to play nice with it. Out of COM came .NET Framework, which accomplishes most of what COM does without the muss, fuss, or bother.
Hide the wires brother and sister programmers!
I think videos like this one with Rob Short are *GREAT* because they provide context for understanding product and how it got that way and how people think it should evolve. Learning about product in a contextual vacuum is, for me at least, an unrewarding
The "take home" message of the Steve Ballmer video is that the next 10 years, for developers, will be as good as or better than the last 10 years. It is left to the viewer to decide what "better" means. Perhaps it means more interesting work. Perhaps
it means higher volume of work in general. Perhaps it means increased gross receipts for developers. What Mr. Ballmer thinks when he thinks "developer" remains a mystery. What aids to developers Microsoft plans to offer over the next 10 years is unspecified.
I come away from his brief comments with the same confused, "what was THAT all about?" that I used to experience at half-time when coach would give us a pep talk.
Nevertheless, it is extremely good to have the big cheeses honor us with a few comments. I don't think this qualifies as a contribution to the still missing dialogue between Microsoft management and developers, but it is a start. (I know, management believes
there is an ongoing, long-term, in-depth dialogue that makes the world safe for innovation. In my neck of the woods, the means to advise Microsoft management is non-existent.) Good show!
By observation I conclude that decisions made in Redmond are based on the idea that the ENTIRE customer base has the enthusiasm for product churn that dotnetjunkie embraces. The young, enthusiastic lions in Redmond steep in a go-go atmosphere and come
to think that the go-go atmosphere exists everywhere. Well, it doesn't. I love new technology that adds value. New technology that is simply recycled old technology is a marketing trick, not an advancement (e.g. renaming OLE COM and COM ActiveX controls).
It is strange to think .NET is now considered "old" technology. From a teaching and learning and doing point of view, .NET has got COM beat hands down. Now we are to jetison .NET for something bigger, beefier and bouncier. If so, let it be. But first,
figure out how those of us who prefer to take our lessons gradually and systematically can ease into it. It is valuable to see the taxonomy of technologies both from a historical perspective and to arrange one's teaching plan so that the true core technologies
are introduced first. Or not. I could be way off base here.