The Old Joel on Software Forum: Part 3 (of 5)

Longhorn as a "blank page"

Joel's been at some pains to point out that scrapping an existing code base is rarely (if ever) a reasonable idea, and I don't know to what extent Longhorn represents such an approach, but from what little I've seen it looks like there's an awful lot of new stuff involved - and certainly no one seems to believe that mooted schedules will be met.

Is this the Microsoft equivalent of Netscape's mistake?

bob bechtel
Monday, December 22, 2003

I doubt that Longhorn will be a blank page, I just think Microsoft want to sell it as such.

They are pushing for the idea that this is a brand new windows, revolutionarily different from the old. I'm sure that the internals will be less dramatic.

The last few releases have all been aimed at consilidating the NT and 9x codebases into a single base for home and business users. It would be foolish to throw all that hard work away.

The dramatic differences in Longhorn are probably the fruits of that labour. Given the microkernal architecture they now have the OS is far more flexible.

Ged Byrne
Monday, December 22, 2003

"I doubt that Longhorn will be a blank page, I just think Microsoft want to sell it as such."

Exactly. Just like they did with Windows 95, where they claimed that "DOS is gone" when it really wasn't.

Mayor McCheese
Monday, December 22, 2003

They've already said (don't remember where I read this, though) that the indexed-and-structured WinFS is not really a new file system at the kernel level, but rather an NTFS overlay that, at the application level, can look like a different file system.

If that's true, then WinFS will probably be able to run as a Samba overlay, or even as an ext3 overlay through Wine :)

Definitely not a blank page - sacrificing compatibility would be a very foolish thing to do, and starting from a blank page when compatibility is a priority is also foolish.

And say what you will about Microsoft, fools they are not.

Ori Berger
Monday, December 22, 2003

Its not a blank page but in QA terms its probably as bad. The security changes alone, the default conditions to eliminate buffer exploits and the like all mean that whatever the automated testing every path has to be treated as new.

I wouldn't like to be responsible for the code coverage report on the whole thing that's for sure.

Simon Lucy
Monday, December 22, 2003

If WinFS is only an evolutionary step up from NTFS, then the only huuuuge infastructure change in Longhorn I can think of looks like the display engine. There might be others, though... I'm not sure how integrated new DRM stuff might be with Longhorn, I haven't kept up with my reading.

I'm really excited about WinFS, though.

John Rose
Monday, December 22, 2003

It's the beginning of a blank page. All of the old Win32 system will be there, but rather than having to futz around with low-level calls and MFC and such, .net is the API Microsoft will be promoting. And this is good, as .net finally brings Windows programming past the level previously known by users of Visual Basic and Delphi.

So we're really looking at a split system: all of the old stuff, plus the new stuff that's built on top of. But as time goes by--and it will be a decade or more before this is possible--the old Win32 system can start to fade away and .net will essentially become Windows. Longer term, this gives Microsoft some big wins, such as not being reliant on x86 CPUs, and not having to deal with 32-bit vs. 64-bit issues.

Junkster
Monday, December 22, 2003

Regarding WinFS:

I don't have a link handy, but Longhorn WinFS will only apply to files and data in the (equivalent of) Documents and Settings directory. This means that Longhorn WinFS will really only be an appetizer for all of the things that a real super-EA/resource fork FS with a DBMS behind it could be. If you think about that for a second, you could implement that completely in a FS hook driver today.

There are some exciting things in Longhorn, but I'm afraid that it's oversold a bit. It looks like XAML, WinFS, etc... will follow Microsoft's typical development cycle: it will take several iterative versions before they match what's really being touted and what's being touted will probably be mitigated over time (think Active Directory).

Mark Smith
Monday, December 22, 2003

In what sense was Active Directory mitigated?

Ori Berger
Monday, December 22, 2003

At least to large corporate IT shops, MS was initially touting AD as a generic corporate data store for object data with replication, distributed caching, etc... MS was touting all the illed Exchange as being fixed in Exchage 2000 because of its tight integration with AD. For a time, the idea was that you would build corporate applications around AD as a kind of metadata store. I remember attending a MS presention (early 1999?) that actually positioned AD as an important answer to Lotus Notes and other object database technology.

The reality was that MS only exposed the LDAP interface into AD and not a richer API set. This affects everything from using AD in applications to administration to disaster recovery. It is possible to get structure inside of AD and have no way to get rid of it (even if you get rid of all the data that conformed to the structure). As a result, it's important to guard what ends up in your AD setup or you can have strange performance. Worse yet, if you load AD up with a lot of data (GBs), then you can start to get into stability and scalability issues.

Over time, MS kept tweaking the message around AD until we have what we have today: AD is a great place to store user data and metadata. You don't build applications around. The Exchange team is supposed to be moving some things away from AD (i.e. public folders, anything not strictly user related) to SQL Server.

My expectation is that we'll see the same thing with WinFS (i.e. it will end up only making sense for personal e-mail storage a la .PST files) and some of the advanced UI stuff.

Mark Smith
Monday, December 22, 2003

Oh, OK.

I never fell for the AD propaganda in the first place :) It just looked like an inefficient version of Novell's directory server.

Ori Berger
Tuesday, December 23, 2003