Confessions of a Longhorn User

A Computer Says 'Mooooooo!'

  • I don't care about Chinese MBAs - I'm turning off comments

    Filed under:
    After a wonderful morning of deleting a flood of crap posts from spamming bastards, I'm turning off comments for my blog here.  I'm sick of it.  Until it becomes legal to hunt and destroy these people, they're gonna stay off.  If you feel the need to contact me, do so with the Contacts link over on the side.  I do read the e-mail I get, even if I don't respond to it right away.
  • Microsoft needs to accentuate the positive with Longhorn

    Filed under:

    Ok, so by now we've all heard about the changes with Longhorn (Avalon and Indigo and WinFS, oh my!).

    Some people dig it, others hate it.  That's nothing new for Microsoft, really.  Whether it was a good decision or not is irrelevant at this point, so I'm not going to go into that right now.  There is something else I'd like to talk about with regards to this issue:  the seemingly common misconception that all Longhorn is/was was XP + Avalon + Indigo + WinFS.

    I've heard (er... read) lots of people say that there's no reason to upgrade to Longhorn now, since Avalon and Indigo will be available on XP and 2k3, and WinFS won't ship until Later On(tm).  And that misconception is, IMHO, sort of Microsoft's fault.

    The Longhorn pool that we've been wading in since the PDC has primarily been all about developers (insert Steve Balmer joke here), which makes since.  The PDC is geared toward developers.  So is WinHEC... sort of (hardware devs are still devs).  I don't blame Microsoft for this.  If you don't have developers behind you when you roll out a new technology like those introduced at the PDC, you're pretty dead.  So all we've heard about with respect to Longhorn for the last 10 months is 'developers, developers, developers'.  That's great, but that's why people think there's nothing more to Longhorn than what was mentioned at the PDC and WinHEC. 

    I know Longhorn won't be out until 2006, and there's plenty of time to start getting people excited about the non-developer related features in it, but I'd like to see some of that information start coming out of Microsoft now.  This is what I blame Microsoft for.  I've seen at least 10 different employee blogs that were essentially a carbon copy of the press release last Friday.  Sorry guys, I'm not interested.  I already read that - move on.  Why concentrate on the things that were just pulled / altered?  Why not talk about all the cool stuff that's still going to be there?  Talk about the new manageability features.  Talk about the new deployment story.  Talk about... hell, anything.  Just talk about it. 

    There's more to Longhorn than a presentation layer, a message-bus and a database.  I'd like to hear what else Microsoft has planned for Longhorn, besides the developer features.  As an IT Professional, why will I want to make a case for deploying it where I work?  As a home user, why will I want to run it at home, and why would I recommend it to my friends and parents? 

    Microsoft, you lifted the veil off the developer bits at the PDC, and you got the developers' attention.  Now how about a little action for everyone else?

    Originally posted at

  • The Longhorn Driver Model - Will my wish come true?

    DevSource is running a story about the new Longhorn Driver Model.  It looks like it's going to have some really awesome stuff, like boilerplate code libraries, and a split kernel/user mode.  Oh, and driver isolation... that's kinda nice... :)

    I've never written a driver before, and probably never will, so despite how cool this stuff may be for driver authors, I'm probably missing out on most of it.  I'm hoping - however - that this new model will solve one of my biggest peeves with Windows once and for all:  Limited users cannot install a local printer or a digital camera.  I guess limited is the operative word.

    So here's why I hate this.  The company which is nice enough to employ me has tons of remote users with laptops.  We've taken it upon ourselves to “do the right thing” and have all our users running as normal Users (with a few tweaks here and there).  For these mobile users, a simple task like installing a printer is a complete bust, since they need admin rights to do it. 

    I can understand it from a security point of view, but from a user (and technical) point of view, it's not so hot.  The dream of the paperless office hasn't quite gotten here yet (my desk is a prime example...), so printing is pretty important. 

    Am I correct is assuming that this new kernel/user mode split in the driver model could give us this flexibility?

    Giving credit where credit is due - I found this article through Ryan Gregg's Blog, as well as Chris Sells'.

  • Great Minds Think Alike...

    Filed under:

    Adam posted earlier about HE3's new license plates.

    I like mine better...

  • WinHEC Longhorn bits *WILL* be available to MSDN subscribers

    Filed under:

    Chris Sells posted to his blog that MSDN Subscribers will get access to the WinHEC build (Milestone 7.2) of Longhorn.  Though a precise timeline wasn't mentioned, Chris said it will happen Real Soon Now, and Scoble mentioned that it may happen in just a few days.

    Chris also mentioned that Microsoft is intending to make Milestone build drops a more regular thing, so we can stay “in sync” with what they're doing, and provide more feedback earlier in the development process.


    Edit: Michael Swanson posted about it, too!

  • Non-Longhorn post: New worm on the loose. Make sure your systems are patched.

    Filed under:
    There's a new worm on the way, and there's a possibility that it could be a bad one.  It uses the same sort of attack vector that Blaster used, so your machine is at risk by simply being online if you're not patched, or not running a firewall.  This new worm exploits a vulnerability in LSASS and is a nasty little piece of trash.

    How can you tell if you're infected? 

    Well, similar to the Blaster worm, you'll probably get messages about LSASS.EXE failing, and your computer may reboot every few minutes or so without you telling it to.

    What can you do to prevent infection?

    First of all, GET AND USE A FIREWALL!!!  If you're running Windows XP, you can use the built-in firewall.  Here's how to enable it.  If not, you may want to investigate a commercial product like Norton Internet Security, Mcafee Firewall, or ZoneAlarm.

    Secondly, patch your computers against this vulnerability as soon as possible!  See if your operating system in vulnerable and get your patches here.

    Here are some quick links to the patches, if you don't feel like reading:

    Microsoft Windows NT® Workstation 4.0 Service Pack 6a

    Microsoft Windows NT Server 4.0 Service Pack 6a

    Microsoft Windows NT Server 4.0 Terminal Server Edition Service Pack 6

    Microsoft Windows 2000 SP2, SP3, and SP4

    Microsoft Windows XP and Microsoft Windows XP Service Pack 1

    Microsoft Windows XP 64-Bit Edition Service Pack 1

    Microsoft Windows XP 64-Bit Edition Version 2003

    Microsoft Windows Server™ 2003

    Microsoft Windows Server 2003 64-Bit Edition

    Update: Here's a worm removal tool from Microsoft, if you think you're infected.

    Note:  Want more info about how to make sure your computer is secure?  Go here.

  • Herding Cattle - Pulling the 16-bit plug

    Filed under: ,

    Note: I thought I’d start a new little gimmick on my blog here - I’ve got a bunch of feature requests that I’d like the developers at Microsoft to take a look at, and I’m sure a lot of the other bloggers and visitors to this site do as well.  I gave up on trying to think of a catchy name for the series, and settled with “Herding the Cattle.”  Apologies to any Microsoft devs who either don’t want to be herded, aren’t cattle, or both.

    This last year, in October, I was lucky enough to be one of the many developers who attended Microsoft’s PDC conference, at which the covers were finally lifted from this little thing called “Longhorn.”  Out of all the cool things that were discussed and displayed at PDC, one thing stood out in my mind, because my initial reaction was “Why?”

    During the keynote, in one of the first demonstrations of Longhorn, the presenter launched an application that I, for one, don’t believe has any place running on a modern PC.  VisiCalc. 

    What’s wrong with VisiCalc?  I have no problems with VisiCalc itself – I appreciate what VisiCalc did for the computer industry.  What I have a problem with is 16-bit code running on a modern computer.   For those of you who haven’t been keeping track, it’s 2004 now.  Windows 95 was released nearly 9 years ago, along with the ability to both run and write 32-bit code.  So why, almost a decade later, are we still concerning ourselves with running 20 year old software?  We shouldn’t be.

    VisiCalc is, of course, just an example.  What I’m really trying to say is that I believe it’s time to start killing off 16-bit support forever, and here’s why:

    • Security, security, security.  Let’s face it – any programs that require 16-bit support to run were not designed with modern security techniques in mind, so the 16-bit programs themselves could pose a security risk.  According to this page, DOS applications each run in their own Virtual DOS Machine, and each VDM has its own address space, whereas Win16 apps share a common VDM.   Assuming that the VDM is a secure environment, this should be enough isolation to protect the OS from any rogue application, or any application that has an exploitable security vulnerability.

      That, however, is a pretty big assumption. 
      This Microsoft Knowledge Base article explains how “thunking” works between 16 and 32-bit code on Windows.  It lists different methods that 16 and 32-bit applications can use to communicate with each other, and RPC happens to be one of them.  If RPC sounds familiar, it’s because the MSBlaster worm, which struck earlier this year, used a vulnerability in RPC to infect PCs on the Internet.

      Now, to my knowledge, no vulnerability has been discovered that exploits any security holes in the 16-bit compatibility subsystems in Windows, so I’ll be the first to admit that claiming 16-bit compatibility is a security risk is unsubstantiated.  I do know, however, that part of designing a secure system is to reduce attackable surface area.  Removing 16-bit compatibility would, indeed, reduce the attackable surface by removing possibly insecure, legacy code from the operating system.

    • Beating a dead horse.   How long can we continue supporting legacy technology?  Ford no longer offers any support for the Model-T, why should we be stuck with making sure that Quicken for DOS 1.0 can still run?  I understand that a lot of small businesses still use 16-bit applications to do their daily business.  The company I work for is fairly large, and even we have a smattering of 16-bit apps in some departments (which will be corrected in a few months, if I have anything to say about it).  Even so, I believe it’s time that the line be drawn.  As I said earlier, Microsoft development tools have been able to produce 32-bit binaries for 9 years – if you’re a software vendor who is still producing 16-bit code, you’re doing your customers (assuming you even have any customers…) an amazing disservice.

    • Obsolete Design Decisions and Shifting Standards of Quality.  If you look at older software and compare it with modern programs, you can see and feel the difference almost immediately.  Once you start to actually use them, you can tell that something’s a miss as well.

      The company I work for has one very specific piece of third-party 16-bit software (actually, the vendor says it’s a 32-bit/16-bit hybrid – what kind of excuse is that?  Part crap is still crap, guys… sorry to break it to you) that is used for market research.  The software’s setup program is a proprietary 16-bit installer that doesn’t recognize long file names.  It also, by default, installs the program to its own folder off of the root of the C drive.  Updates to the market data are installed by different executables, which are an entirely different 16-bit installer which also doesn’t like long file names.

      The look and feel of the program is almost, but not entirely, completely archaic and foreign compared to the current Windows 2000 / Windows XP interface.

      These are some of the things that are being carried forward by supporting legacy software.  In today’s world, nobody in their right mind would install a program on the root of the C drive.  You just don’t do it, what with having to deal with file-system security, and all.  But whenever the code for this program was written, there wasn’t anything wrong with doing so – in fact, people were probably used to having the root of C being the place where everything goes.  I’m not blaming the developers of this application for making that choice (though I’m a little ticked that they haven’t changed it yet…) – there was nothing wrong with the choice when the made it.  It’s the software world that’s changed, and some apps – this one included – needs to be updated to match.

      Long file names are another thing.  LFN support was added back in 1995 – 9 years later this program still adores the xxxxxx~1 naming scheme.   Try describing file name truncation to a user – just try it.  It’s next to impossible, especially if you have a large amount of similarly named files.

      Now, don’t get me wrong – it’s totally possible to write crappy 32-bit programs as well, with either poorly functioning code, or an interface that would make UI designers wretch.  That’s the development team’s fault, and that’s something we’re going to have to live with (or just don’t purchase the software, which I’m beginning to think isn’t a popular enough option…).  But the older a program gets, the further out of the loop it becomes with relation to what the customer/user is used to.

      Minimally, killing 16-bit support would make an application vendor recompile the old code to get 32-bit binaries, and hopefully use newer components (like common dialogs) when doing so.  Hopefully, app vendors would look at the old code and decide that it would be more cost effective to start over with today’s standards and best practices in mind.

    So what about all those applications that will break?  What about all those business critical applications that will break!?!  That’s an excellent question, and I’ve got a couple of ideas.

    Number one: Ask Apple.

    Dana Epp has written an awesome article which talks about breaking backward compatibility in Longhorn (which I agree with!  I think 16-bit is just the tip of the iceberg), and brings up a great point.  When Apple moved to OSX, it included a way for older applications to run in an OS9 environment.  Microsoft could do the same by leveraging it’s newly acquired virtualization technology.  Simply put, Microsoft should add VirtualPC to Longhorn, and allow legacy applications to run only inside of that virtual sandbox.

    Number two: Let the user decide.

    Longhorn could also be designed so that the 16-bit subsystem could be added or removed, similar to IIS, and as such, the user/administrator would have to explicitly opt to install it.  This would keep 16-bit apps running (for now…), while still allowing those of us who have no need to the compatibility code to rid ourselves of it. 

    This is a perfect time for Microsoft to step up as a market leader and start advancing the industry again.  By eliminating the old code, a whole new era of innovation in the software market will be born.  Old code that’s still hobbling along today will have to be rewritten or refactored, and in doing so, it could take advantage of some of the more amazing pieces of technology available today.  Not only would it be a great thing for software developers, but it would be a great thing for software consumers, and I look forward to being both.

  • "Wronghorn" is just plain wrong - a rational response

    Filed under:

    As has been mentioned previously on LonghornBlogs, and on Scoble’s blog, Tony McCune published an article on ZDNet today that’s slightly unflattering for Longhorn.  Ok, that’s a little inaccurate.  It was more like he put Longhorn into a bag and proceeded to beat it with a stick.  I wanted to take a moment to respond to some of Tony’s comments, and set the record straight, where necessary.  So here I go.

    “Myth #1: The Longhorn suite will be a worthwhile investment.
    Microsoft typically pushes big software bundles that force customers to pay for much more functionality than they actually need, and Longhorn will continue that tradition. Microsoft’s own research shows that 30 percent of PC desktop users don't use the entire Office suite. They only use the word processor. This means that a huge percentage of businesses are made to pay for functionality that they don't use. It's like going for a fully loaded SUV when only one person will be driving the vehicle to the train station. A Ford Focus would do, but you're force to buy a Lincoln Navigator.”

    I don’t think you’ve really made your point here, Tony.  First of all, I’d like to know what features of Longhorn you consider to be superfluous.  While I’m not claiming that there’s no such thing as “bloat” in Windows, I fail to see how Longhorn – even at the pre-alpha stage – is overkill.  Using your own numbers, 30% of people only use Microsoft Word, as opposed to the rest of the apps in Office.  What you’ve neglected to mention is the other 70% who use more than just the word processor. 

    Click here to read the rest...

  • Where the heck am I?

    Filed under: ,

    Well, I'm at the PDC, of course, but that's not really the point.  The point is that a new feature of the Longhorn OS could have told me that.

    Walking around the convention center, I've seen numerous demonstrations of a new service that will ship as part of Longhorn - the Location Awareness service (or something similar to that).

    This service uses any of a combination of data sources, such as WiFi access points, Bluetooth, GPS, and probably others, to make an educated guess as to the location of the computer in question.  In one demonstration (with simulated data), Longhorn used WiFi and Bluetooth access points with known locations (i.e. AP1 is in Conference Room A, and so on) to caculate that the subject was walking down a hallway near a conference room.  Yeah, it knew the user was actually moving.

    In another demonstration, a smartphone running a prerelease of the smartphone OS with the Location service was able to calculate the street address the phone was located at.  Totally cool.

    Now, I know what you're thinking... “That's Big Brother!  I don't want just anybody to be able to find me wherever I am!”  That's cool.   With Longhorn's new integrated Identity Management and Security features, you will be able to specify who is or isn't allowed to know where you are. 

    I'll be posting some more information about this - and other nifty Longhorn features later on.

    Very cool, indeed.

    Update: I'm sitting through a technical session about this service right now, and I thought I'd share a bit more information about it.  First of all, the service is set to Manual startup out-of-the-box.  So, in order to take advantage of the functionality provided by the service, it must be manually started.    Secondly, the service itself doesn't obtain or broadcast any information on it's own - the service is merely a provider that can be used by applications for location-centric information.  The API for the service is entirely managed so that Code-Access level security can be used, and it can only be accessed by strongly-typed languages like C# and VB.NET. 

  • Trick or Treat...

    Yeah... I've got too much time on my hands...
    I've got a few more pictures that I'll be uploading as well, check out my gallery.

    What can I say... I'm excited :)

  • Systems Management Enhancements in Longhorn

    Filed under:

    Over at PDC Bloggers, there's a link to Yet Another Article About Longhorn and the PDC (YAAALP?) which covers the basics about the special PDC Build that will be available to attendees.  It also has some information about some new management features that will apparently be built into Longhorn called SDM (System Definition Model).

    “The first operating system to support the System Definition Model (SDM) for system management, Longhorn should lower the total cost of ownership for a Windows server or Windows-based data center. Longhorn is also expected to help corporations with deployment of collaborative solutions, reduce the cost of the IT infrastructure, and distribute "smart" applications that take advantage of Web services.”

    ComputerWorld also had a story about Longhorn and SDM back in March, which has a broader view of Microsoft's entire System Management strategy. 

    Overall, the concept sounds pretty neat, and should be a dramatic step up from today's System Management arrangement.

  • One for the Longhorn Wishlist...

    Filed under:

    Dylan Greene is asking for OS-level sandboxing of applications in Longhorn on his weblog. 
    Not a bad idea at all.  As one of the comments on Dylan's blog states, a lot of this sort of thing is already a part of the .NET Framework, but only applications using the framework can use it.  It would be nice to expand that to a wider range of applications, including legacy apps.

    The key to doing this, of course, is making sure that it's easy for the home user to do, while making it powerful enough to make power-users happy.  But that should be easy, right?  ;)

    Here's to hoping something like this gets implemented, Dylan.

  • Great to be here

    Hi everybody!  Just wanted to take a quick timeslice to thank Robert McLaws for the introduction, and for putting together a great site like this one!  It's a beautiful site, Robert, and I'm excited to be a part of it.

    As Robert said, my name is Mike Kolitz, and I'm an MVP for Windows Setup and Deployment. 
    So why am I excited to see Longhorn unveiled at PDC?  Well, for one thing, I'm anxious to see how the setup routine may have changed - Paul Thurrott has reported that Longhorn's setup is now image-based, and takes significantly less time to install.  Here's what Paul had to say:

    “Longhorn's new modular architecture will have sweeping ramifications for how Longhorn is created, installed by end users, deployed in corporate settings, and updated over time with service packs and hot-fixes (QFEs). Interestingly, Microsoft actually went the distance with the componentization approach and created a bootable image of the Longhorn base OS. This bootable image will allow users to install Longhorn much more quickly than was possible in the past, as it eliminates a lot of the time-consuming file copy and Registry population phases that were present in previous Windows versions. In Longhorn, the first phase of setup simply copies this single image file--referred to as the WinPE (Windows pre-installation environment)--to the hard drive, and then reboots the system. Then your system boots into WinPE, which is basically a miniature operating system consisting of the core Longhorn features, it boots immediately, because the image ships already "installed." Then, the mini-OS runs a totally rewritten PnP routine that quickly identifies your exact hardware configuration, installs the correct drivers, and ... that's it. You're up and running. Myers says the goal is for an unattended setup of Longhorn to take less than 15 minutes from start to finish. Compared to the 45- to 60-minute install time for Windows XP, that's amazing.”

    Sounds great, if that's how it turns out.  At this point, though, only time will tell...
    See you at the PDC!