It was very Tron.

With the advent of minicomputers, computers became much more useful to people. The economics of cheaper processors and storage meant that a department level manager could buy a computer rather than waiting for access to corporate iron. Multi-tasking operating systems, in conjunction with terminals – the precursors to networks, began to move from a technology designed to keep the machine busy to a technology that was enabling interactivity in the human computing experience. The economics still required people to share a processor and storage (and experts).

Workstations were an early version of what would eventually become the personal computer. The workstation was designed exclusively to make the individuals using them as personally productive as possible, by supplying them with processing, graphics, local storage and then network storage. The magic of the workstation was that the era of optimizing for the machine was coming to an end. I believe that is was the productivity of the workstation that enabled developers to experiment and refine networking and its associated metaphors and practices (virtualized peripherals, remote shells, RPC, collaborative / distributed development, etc.) that paved the way for the Internet itself.

The personal computer again fundamentally changed the economics of computing. While the first PCs were a step backwards in functionality relative to the workstation, the price was right and getting more right with each passing year. The first 10 years of the personal computer were driven by the novelty of rapidly cheaper computing and the search for uses for it. Later the PC would combine workstation class operating system sophistication with a TCP/IP stack and affordability and give birth to the modern Internet.

It’s interesting to consider that it was roughly 15 years ago that we were debating the merits of adding, or not adding, TCP/IP and Winsock to Windows 95.

The next opportunity that affordable personal computing created was access to information. The industry got a few years out of enabling people to type their recipes in WYSIWYG and then print them on newly affordable “graphics” printers. But we wanted more. We wanted to know things. We didn’t know it at the time, but there was a pent up demand to publish. Encyclopedias, universities, newspapers and television were still in control of knowledge and its distribution.

The next economic constraint was the cost of storage. I remember when we were generally happy when a new operating system install took less than one quarter of the hard drive, and data loss due to drive failure was an ordinary part of the personal computing experience. Thankfully the term head crash has disappeared from our jargon completely.

CD-ROMs started to show the promise of cheap storage. Usenet was showing us that people really wanted to be heard. And email, the power of communication and collaboration within an intimate group controlled by individuals.

For 10 years between 1990 and 2000, the capacity and reliability of everything associated with the PC increased at an amazing and increasing rate, even as it got cheaper at an increasing rate. By 1998 I had so much affordable, fast local storage and dirt cheap processor cycles that I could render digital video in real time. At the time it wasn’t obvious, exactly, why this was better than an analog tape but damn it was way cool. PVRs came later and showed us one reason it was cool.

“Overnight”, the default directions of everything in the industry started to change.

By 2002, we were beginning to take high capacity, small and mechanically robust laptop hard drives for granted. Affordable desktop PCs had storage capacity and reliability undreamed of by workstations in their prime. Video games could assume large amounts of space. Solid state storage was enabling portable devices to store music, photos and video. Indeed the storage wave just kept going even as the clock speed wave crested and began to roll back. This was not conventional wisdom 10 years ago.

Of course the biggest trend of the last 10 years has been the browser. The web march has been stunning: from simple access to a huge, barely “administrated” and human friendly namespace; to forms, catalogs and ecommerce; simple publishing via hosted services and rich client authoring; even more simple (if less rich) publishing via blogs and wikis; to highly interactive (but still not very rich) sites that are the anchor point of sharing, collaboration, publishing and discussion.

The web has received a lot of well deserved focus on ease of use enabled by a simple and clever networking layer and presentation layer. Indeed the browser sets a new standard for it just works experiences, and technology that doesn’t meet that bar will not be adopted. As is often the case, the reality is that considerable effort on the part of developers goes into making the experience work and feel great on top of a platform that has, as we say, evolved over time.

The evolution of (cheap) storage has had an equally important impact on the web. The combination of the natural partitioning flexibility of the URL space, racks of (cheap) PCs and simple software redundancy have enabled the creation of immense reliable enough stores. Because these stores are “centralized” it is feasible to do data mining, indexing and transformations on them. This is the engine behind search engines. As this technology becomes more approachable to more developers, it is powering more experiences on the web.

It’s tempting to assume that web client server wins everything. But I don’t think so.

I love the web. I’m using it now. But I still spend more time using Windows applications. At the moment I’m listening to very high quality glitch free music being streamed from my hard drive, through an iTunes client and into my headphones. I have a few folders open where I did some photo editing with Photoshop earlier today. I’m using Office to author this blog and enjoying best in class spelling and grammar checking. Messenger is open. I routinely use Premier, Lightroom, Dreamweaver, Nero, and various scanning programs.

The industry’s newest, coolest, ease of use standard setting, cleverest mobile browser ever powered device, the iPhone, has a local application for text messaging, calendar, photo album, camera, YouTube, stocks, maps, weather, clock, calculator, notes, mail, music, the phone itself and of course, the shell. The reason for this is that local applications can have experiences that are highly tuned to the device capabilities and the preferences of the customers using them.

Of course what is really happening it that the industry is moving toward the best of both worlds. Many of the local applications I describe above are invisibility connected to the web. This is nature of what we’ve been calling this Software + Services.

What doesn’t seem to have happened yet is much coherency when I want an experience that spans mobile, web and PC. Mobile and (typically one) PC work together over USB sync, and Facebook has done a decent job with their iPhone targeted (browser) client but for the most part, I have to “pick” an app or a site or an operator,  use it and accept another silo of (my) information. But since lots of them are truly unique and useful, I use lots of them. And I learn to context switch. A lot. I am forced to maintain a complex mental map of where my data is, how I get to it and how to move it around.

Even the web, “the alternative to complexity”, is becoming complex. Sites are competing to store your information and as a side effect they aren’t motivated to allow you to store it across sites.  I don’t think I could find all of the photos I have uploaded to the web if I wanted to.

I think that the Live Desktop and Windows Mesh client experience (and more, coming …) are a visceral demonstration of the power of having a coherent (synchronized) view of all of your information from every endpoint. Of course, these are just the initial experiences we have built on Live Mesh Platform. I can imagine many more.

The success of Live Mesh depends in large part on the core platform and the developers being successful, in the real world, to build “it just works” experiences.

Live Mesh was my first deep exposure to REST. I have to admit that the power of simple operations against an URL space has impressed me. We have tackled very complex problems using the model and it has held up very well. I’m happy to tell you that this elegance will extend to the developer model (soon).

I’m looking forward to it.

Mike Zintel

Product Unit Manager, Mesh and Storage Platform

Still pretty bad.

So, let me fix this by sharing a photo of Chris Muench, at GDC, showing off his game, written using the Microsoft® XNA Framework®.

We're going to give an internal demo of these games at an upcoming "all hands" Developer Division meeting. It's cool.

We're getting ready to release NET CF V2 SP1 to beta. We're finally close to making good on our commitments to support for Windows CE 4.2, performance tools and headless support. Thanks for your patience.

In other news, the SQL folks are going to announce today a product called Microsoft® SQL Everywhere®. This is a compact local database for use on PCs and Windows Mobile devices. It will enable developers to use the same database and APIs to develop occasionally-connected applications that sync with SQL Server 2005 across all Microsoft client platforms. The database will have similar install footprint as SQL-Mobile does today. Very similar. Very familiar.

Some folks have been asking about this for a long time.

The NET CF team is working on WCF support for the next release, with some interesting support for transiently connected networks.

I got an interesting answer to an interview question a few weeks ago. "Why do you want to work at Microsoft?" The candidate described the anti-Microsoft buzz on campus. He then said he listened to a presentation that a Microsoft employee gave at campus, and decided to "put some independent thought into this". I have to admit a certain guilty pleasure to reading mini-microsoft; it’s like an accident scene. But I hope people can see through this stuff. There are a lot of great folks who care here. I've been here 11 years and I think it's a better company now then during the "good old days

Mike.

This posting is provided "AS IS" with no warranties, and confers no rights.

One good solution to the art problem is Photoshop, and for the game problem to build tools and entice the folks who "got it" to use them. Frankly seeing people with different/better skills than you build very cool stuff on your tools in the best part about working on developer tools.

About 2 years ago I challenged my team to make sure that as D3DM (DX for Windows Mobile) got rolled out on devices, NET CF was the best choice for writing a game app on the platform. Success would be measured by adoption and great customer feedback. At last year's MEDC, D3DM was highlighted in a keynote with the game, Pocket-Jongg, written by Chris Muench. Chris also gave a talk at that event on the details of writing D3DM games in managed code.

That was fun to watch.

Now the challenge is to make sure that once hard core C++ game developers try .NET, that they leave delighted. This will be a learning experience for all of us.

I've been working on operating system level stuff for long enough that I can get excited by seeing the right text on a screen (although, never by a single light, even if it blinks; can't do hardware). So I thought I was really excited when I saw a NET CF team home brew game, "Racer", running on Windows Mobile, Xbox and a Windows PC.

But then I saw Chris's game, with some help from artists in the Xbox team, on Xbox.

It was cool.

And then I saw this.

And it was cool.

Accounts payable never looked this good.

Check out the news from our embedded reporter, Rob.

IrDA is a success. It continues to be useful as simple way to transfer files and contacts between devices and PCs, and to use phones as modems.

That said, the thing I was most passionate about failed. I wanted to create the most seamless experience for moving photos between digital cameras and PCs. Keep in mind that 8 years ago, it was trivial to draw a crowd by taking a digital camera to the zoo. And my internal demo of a pre-production digital camera beaming images to Windows NT5 was very cool indeed.

There was a “competing” internal technology called Windows Image Acquisition (WIA) architecture. WIA abstracted various lower level buses, normalized the command and data transfer, and exposed the camera photos through a standard API that can be used by many different programs. In theory, WIA and IrDA would coexist, but I disliked it. A WIA camera was installed via the PnP system as a new device, and controlled via APIs and control panel.

I argued that we had created an essentially new model of connectivity, completely free of state and configuration and completely ad-hoc. No drivers to install, no settings to get wrong, and wrapping this in PnP was ugly from an engineering perspective and bad for ease of use.

I was quite passionate about this, and the company empowered me to ship it in Windows 2000. I even lined up some camera vendors to support it. And I was sure I would win in the marketplace because of the fundamental beauty of what we had built.

It was beautiful.

I don’t know for sure, but I suspect that, today, if my one unit of the one camera model that I know actually shipped with this feature wasn’t broken, I could point it at my XP laptop, hit send, and all of my photos would be transferred to a folder. The folder would then automatically open to an Explorer photo preview model. This might even still work in Vista.

Slick as can be.

But it failed. Worse, partners who bet on me failed. I didn’t make life easier for consumers. I left Windows with legacy (but good quality) code to support. And I now am a regular and happy user of WIA to import images from one of my two scanners into any number of image editing tools that I use on a regular basis

Why am I telling you this story?

The software platform business is fundamentally different from an innovation and marketplace perspective than, say, the 3M model of product incubation, entrance, success or failure and withdrawal (at least as it’s taught to me by B-School types; I’ve never worked at 3M and one thing I’ve learned is that you never quite get it from looking outside in).

First, you can’t really withdraw things. At the scale of Windows, even if a small percentage of folks take a dependency on a technology, then you want to continue to support them.

For a long time.

DOS apps I wrote in 1980 continue to run on XP today. I’m sure if the folks writing DOS knew this at the time, they would have made this task a bit easier.

.MODEL LARGE ; large model

.CODE

PUBLIC _TestForKey ; BOOLEAN TestForKey(void)

_TestForKey PROC

mov ah, 1 ; Key waiting check

int 16h ; Keyboard BIOS service

mov ax, 0 ; Assume no key waiting

jz Return ; correct, return(FALSE)

mov ax, 1 ; Key waiting, return(TRUE)

Return:

ret

_TestForKey ENDP

It's important to get things right for the long term.

Second, the net value to people of a feature is not measured in isolation. Frankly I don’t want to choose between 10 different ways to do the same task and decide which one I like best. I want one way to discover and start programs, one way to cut and paste, one way to organize things, one way to add and manage devices and administrate my machine, etc. Once I’ve learned how to do things, I want to do them the same way in as many places as possible. Perhaps most importantly, I want programs and hardware I buy anywhere to work anywhere.

You might think we could have done a better job on some of these things, and I’d agree, but it’s not for lack of trying. Our software is used, literally, by hundreds of millions of people, in every country in the world, to do an incomprehensibly large number of different things. An interesting consequence of listening and acting on a huge number of feature requests, each that make sense in a scenario, is that you can accidentally end up doing a bunch of overlapping things. Frankly the search for the fully normalized horizontal, discoverable and easy to learn and live with solution to problems is not an easy task.

Some of use who have been around for a while remember a simple happy time when you wrote some code, put in on floppy, took out an ad in Byte, and made a fortune. Personally, I’m going to ignore the fact that this wasn’t at all my experience trying to bootstrap a software company, and remember it this way.

Why am I telling you this story?

I’ve been spending the last few months doing “cross group” work, to get something new lined up and right for the long term.

We spend a lot of energy and time at Microsoft these days doing cross group work. On a great day, this can be an enlightening and enjoyable process, as we have an amazingly diverse, talented, curious and interesting group of folks here. I can’t imagine a faster way to gain rich insights into technology, customers and the marketplace. On a grumpy day, cross group work feels like a game of whack-a-mole that has gone on too long, as the shear number of opinions and innate complexity can be overwhelming.

And this work has been “secret”. Not so much because we want to save the surprise, but because we want to make sure that we don’t announce things until we have very high confidence that we will be able to build, ship and support them, that they are the right solutions and that we understand how they sit relative to other potentially overlapping efforts.

I once wrote about what we knew Vs what we didn’t know when we designed the .NET Compact Framework.

I’d like to tell you now what I know about the game space. I know that very high end games are written in C++ , with a significant art component, and are getting more expensive to build. I know that C# improves programmer productivity substantially and has very solid adoption and customer loyalty. I know that at the low end, various technologies are making “casual” game authoring much easier, and that devices are a high volume target for these games. I know that the set of technologies used to write games varies significantly across platforms, and that it’s hard to migrate code and skills between consoles, PC and devices.

I also know that working with the Xbox team has been among the most enjoyable and productive cross group work that I’ve done. I know that my team and the XNA team within Xbox, have been burning the midnight oil to allow us to demonstrate the feasibility of games written in managed code running on a .NET CLR on a final 360 dev kit. And I know that we’ve demonstrated the same game binary (almost the same; oh so close) running on the 360 kit, Windows and on Windows Mobile.

In HD.

Fast.

Stay tuned.

For the record, the right solution to the photo exchange problem proved to be tiny solid state drives that are PnP’d as a local filesystem.

Mike.

This posting is provided "AS IS" with no warranties, and confers no rights.

My job: blogging.

These folks: real work (ie setup, versioning, JIT, GC, loader, reflection, debugging, type system, interop, BCL, globalization, Windows Forms, DirectX, networking, crypto, ADO.NET, XML, etc).

Mike.

This posting is provided "AS IS" with no warranties, and confers no rights.

I'd like to share some insight into what we've been doing for the last 3 years, and why.

The first half of the project cycle is divided into milestones, each about 3 months long, split between a coding and a stabilization phase. Like most of the techniques used to manage multi-person software projects, the goal of milestones is to find and fix bugs early and keep the code in good health.

If I check in a code change that introduces a subtle bug (pretend that the team would actually let me check in code these days) on Monday, and on Wednesday I get a bug report on an apparently different bug, there's a decent chance I'll be able to remember what I did, and make the mental connection, and correctly fix the root cause. The probability of a correct diagnosis is far lower two months later. And if other folks have "fixed" the side effects in the interim, possibly by unknowingly taking a dependency on the incorrect behavior caused by my bug, fixing the root cause then creates a bug ripple through the system. When you work on systems with 10s, 100s or even 1000s of developers, you have to pay attention to this.

Small projects tend to behave like clay models. Changes are predictable and visible. Large systems behave more like a building or even a living organism. Each step of building construction establishes a quality baseline for the next one. A crooked foundation ripples through the process until the kitchen cabinets can't be installed without a gap on one side or the other. The cost of moving water pipes during a remodel vastly exceeds the cost to run them initially, it's often to impossible to move things like chimneys and drains and you can add only so many new plugs to a circuit.

I think about the code of a complex software project in terms of its "health" at any given point in time. It's much cheaper to keep it healthy than is it is to cure it, and after recovery from a major illness, accident or surgery, it often doesn't come back to optimal health.

There's also a team efficiency and morale reason to keep the system healthy. If you are trying to debug complex behavior in your code, and the components that you are running on and with are also unstable, the amount of complexity soon becomes overwhelming. If this continues for very long, folks tend to give up on the really hard bugs, since they can't find them and there's a good chance they might just "go away" in some future build anyway. This phenomena extends to external customer satisfaction too. It only takes a handful of memory leaks, unexplained crashes and hangs, incorrect program execution or data corruption before folks assume that all of their bugs are really system bugs. We hold ourselves to high standard around these kinds of things.

So milestones are a simple tool to make sure if the code goes on a bad drinking binge, we can send it to rehab.

Sometime around the middle of the cycle, the system becomes stable and complete enough that you can start to collect feedback. If you do this too early, the feedback tends to be obsolete and customers get frustrated because the system is still churning. If you wait too long, you can't act on it. We collect feedback through our early adopter programs, beta tests, MVPs, newsgroups, internal app building exercises, MSDN forums and bug reporting, industry events, web searches and formal industry research.

During the second half of the multi-year cycle we start to pay a great deal more attention to our automation harnesses and associated dashboards. In terms of automation, we run a continuous build, with a "nag auto-mailer" that catches build breaks and sends email, ideally in time to fix them before the nightly automated build. Every day, a new build is created and minimal set of automated tests, called build verification tests, are run against a matrix of hardware and operating systems. The failures are logged, analyzed by engineers that day, and bugs filed. The entire test suite and automation needs the same kind of health program as the code under test. If the suite generates too many false positives it will be ignored, yet the coverage needs to be as good as possible to find bugs early.

We also have suites, automation and dashboards around stress and performance. The coverage on these needs to be broad, to prevent ongoing performance tuning (and the occasional foundation wall move) from "training" to a small set of benchmarks that don't translate to real world gains, and to squash nasty stress bugs early.

We have ship criteria around these dashboards and we watch these and bug trends to help figure out when we're ready to ship.

At the end of every milestone, and prior to final builds, we run what's called a full test pass. That is a process that runs all the tests on as many combinations of hardware and operating systems as we can muster. This is a multi-week process.

The thing we have been working hard on for the last few months is compatibility. We want customers to deploy the next version widely, and key here is to provide both enough new value and to make sure they have a pleasant upgrade experience. I think our performance gains alone will be reason to upgrade, in addition to the new APIs we expose. We have an automation harness that uses reflection against our assemblies to validate that we are in sync with the .NET Framework on Windows. We also run a compatibility test suite to validate that our behavior is compatible. Both of these are necessary starting points, but the only way to really succeed is to test real world applications.

To that end, we have assembled, with your help, a catalog of about 600 application. We've manually tested about half of them, covering a wide range of application types and complexity, and have fixed all but a handful of really tough problems. This has been the last dashboard that we've been watching closely and I'm happy that it says we're ready.

And you've been telling us that we're ready too. Thanks.

A few V2 stats:

Bugs opened, reviewed and fixed or closed : 11,831

Test executables run in final test pass: 546,940

Test cases run in final test pass: 3,548,056

Devices used in final test pass: 94

Global versions tested: CHS, CHT, ESP, FRA, ITA, JPN, KOR, PTB, USA

Apps tested for app compat: 326

Performance scenarous tested: 230

This is what we've been doing, with your help, for the last 3 years. I hope it delights you.

Mike.

I'd like to share some thoughts on integrating WPF/e, announced at the PDC, and the .NET Compact Framework.

WPF/e is a C++, cross platform implementation of a subset of WPF (Avalon). It will be able to execute XAML, in addition to exposing dual mode COM interfaces that make it programmable from COM and script languages.

This makes perfect sense for deployment in browsers, but less so for .NET developers on devices.

I've been struggling for a while trying to understand how to add a great, easy to author, graphics animation infrastructure to the .NET Compact Framework. We made good progress on enabling games with the DX object model in V2 (Whidbey), but there's still considerable investment needed with this approach to build a game. I'm equally concerned about the "disjoint silos" between Windows Forms apps and full screen only DX apps.

The implementation of WPF on the PC was too large to port to devices.

I'm optimistic that WPF/e is the solution to this. The next step for the team is to investigate the feasibility of integrating this technology deeply into the .NET Compact Framework. Ideally, this would enable the hosting of a control built in WPF/e in a Windows Forms application, in addition to enabling full screen WPF/e applications. In both cases, the programming experience would be .NET.

Mike.

This posting is provided "AS IS" with no warranties, and confers no rights.

I built this thing on the weekend from parts I bought at the local Radio Shack.

At least I was excited, until Mark Prentice, who works with me on the .NET Compact Framework, basically told me that my design point was lame ...

I bet using http://www.seetron.com/ssc.htm and a couple of hobby servos at http://www.hobby-lobby.com/servos.htm,  a bit of wood and nails for a simple peg board switch, a PPC with serial out, one could use NETCF to write the fireworks scheduling app…

Mark

If you're very lucky, you know a place that feels like it's the calm in the center of the universe. For me, Little River Lake, in White Rock, Nova Scotia is just such a place. We've spent time there every summer for about 20 years.

The highlight this year, beyond seeing friends and family again, was fireworks. The key to this was the discovery of  Fireworks F/X, a few miles km down the road. Every summer I search for fireworks. And I've usually been able to find small, single shot units at the local hardware store. And for quite a few years, the locals have told me that I need to go to Grand Pre for the good stuff.

I stole this description of Grand Pre from a tourist site:

Adjacent to the town of Wolfville is Grand Pre, or "Great Meadow", stretches east from the Acadian dykes which excluded the tides of the Minas Basin. Grand Pre National Historic Park marks the site of the expulsion of the Acadians in 1755, and it has become a symbol of the preservation of the Acadian People.

For over three hundred years, the village of Grand Pre has provided a home for immigrant farmers and artisans. The first Acadian settlers traveled east from Champlain's original settlement in Annapolis Royal in 1680. This group of industrious farmers engineered the complex system of dykes along the shores of the Minas Basin and nurtured what would become the agricultural heartlands of Nova Scotia.

Today, Grand Pre is the home of a growing number of artisans as well as a National Park and a variety of tourist facilities.

Not the first place I expected to find a great selection of the "good stuff". Besides, I could never get more information than "it's in Grand Pre".

But this year Bob gave me a web site and a phone number. Soon, I had directions: "Turn right at the intersection and look for the sign." The place looks like a farm. And the folks there seem like typically friendly and helpful Nova Scotians, but their sentences are peppered with words like aerials, shock tubes, batteries, bomblettes, fountains, cones, strobes, firing system and cakes. And they have the good stuff.

And the more good stuff you buy, the cheaper it gets, so you can load up.

Cool.

So here was the plan. First, find a suitable rock in the center of the lake. In the daytime, take a big tub full of dirt and leave it there. Shuttle a  cardboard box full of explosives, a "BernzOMatic ignition system", a fire extinguisher, a few flashlights and a camera and tripod to the rock.

.

At dusk, head back out ...

.

and wait for darkness.

Doug1 was in charge of ignition.

Doug2 was in charge of fire safety. In particular, he was responsible for ensuring that any burning pieces of space junk didn't fall into our rubber boat or cardboard box of fireworks.

Here he is, keeping a close watch on the boat and box of fireworks.

It took us a couple of tries to really get the logistics right. On the first night, we didn't even start until dark. That was the first mistake we corrected. Then we changed rocks from a small round one to a medium sized flat one. We also figured out a way to secure the boat line to a medium sized flat rock. Finally, after firing the first set of fireworks, we debated the need to soak the spent carcasses in water prior to loading them into the gasoline powered rubber boat. We debated this over a beer, on the far side of rock. When we turned around to leave, the pile of junk had spontaneously burst into a nice, but slightly smelly campfire. Clearly this was just another example of a scenario with watercraft, the darkness of night and explosives, made safer by beer.

The view up close is different, but very good.

In most of these photos, it looks reasonably bright on the rock. That's a result of the fact that I was using a combination of time exposures and a flash in the same image. It was pitch dark. In the photo below, the camera self timer tripped the flash just as Doug was putting some distance between himself and the fuse he had just lit. A second later we heard Doug hit the rock and mumble something about a blinding light (paraphrasing from Doug's exact words). Fortunately, Doug, the Maglight and the torch were not damaged.