JOB REFERRALS
    ON THIS PAGE
    ARCHIVES
    CATEGORIES
    BLOGROLL
    LINKS
    SEARCH
    MY BOOKS
    DISCLAIMER
 
 Sunday, May 31, 2009
A eulogy: DevelopMentor, RIP

Update: See below, but I wanted to include the text Mike Abercrombie (DM's owner) posted as a comment to this post, in the body of the blog post itself. "Ted - All of us at DevelopMentor greatly appreciate your admiration. We're also grateful for your contributions to DevelopMentor when you were part of our staff. However, all of us that work here, especially our technical staff that write and delivery our courses today, would appreciate it if you would check your sources before writing our eulogy. DevelopMentor is open for business and delivering courses this week and we intend to remain doing so." Duly noted, Mike. Apology offered (and hopefully accepted).

An email crossed my desk today, announcing that DevelopMentor, home to so many good people and fond memories, has (at least temporarily) closed its doors.

I admit to a small, carefully-cushioned place in my heart where I mourn over this.

DevelopMentor was such a transcendent place for me. Much, if not most or all, of the acceleration that came in my career came not only while I was there, but because I was there.

So much of my speaking persona and skill I owe to Ron Sumida, who took a half-baked neophyte of intermediate speaking skill, and in an eight-hour marathon session still referred to in my mental memoirs as my "Night with Scary Ron", shaped me and taught me tricks about speaking that I continue to use to this day. That I got to know him as a friend and confidant later still to this day ranks as one of my greatest blessings.

I remember my first DM Instructor Retreat, where I met so many of the names I'd read about or heard about, and feeling "Oh, my God" fanboy-ish. I remember Tim Ewald giving a talk on transactions at that retreat that left me agape—I seriously didn't understand half of what he was saying, and rather than feeling overwhelmed or ashamed, I remember distinctly thinking, "Wow—I have found a home where I can learn SO much more." It was like waking up one morning to find that your writing workshop group suddenly included Neal Stephenson, Stephen Pinker, C.S. Lewis and Ernest Hemingway. (Yes, I know those last two are dead. Work with me here.)

I remember the day that Lorie (the ops manager at the time) called me to say that Don Box wanted me to work with him on the C# course. I was convinced that she'd called the wrong Ted, meaning instead to reach for Ted Pattison in her Rolodex and coming up a few letters shy. She tartly informed me, "No, I know exactly who I'm talking to, and are you interested or not?" How could I refuse? Help the Diety of COM write DM's flagship course on Microsoft's flagship technology for the next decade? "Hmm...", I say out loud, not because I needed time to think about it, but because a thread in the back of my head says, "Is there any scenario here where I say no?"

I still fondly recall doing a Guerilla .NET at the Torrance Hilton shortly after the .NET 1.0 release, and having a conversation with Don in my hotel room later that night; that was when he told me "Microsoft is working on an open-source version of the CLR". I was stunned—I had no idea that said version would factor pretty largely in my life later. But it opened my eyes, in a very practical way, to how deeply-connected DevelopMentor was to Microsoft, and how that could play out in a direct fashion.

When Peter Drayton joined, he asked me to do a quick review pass on the reference section of his C# in a Nutshell, and I agreed because Peter was a good guy (and somebody I'd hoped would become a friend), and wanted to see the book do well. That went from informal review to formal review to "well, could you maybe make it an editing pass?" to "Would you like to write a few chapters?" to "Well, let's sign you up as a co-author...". That project is what introduced me to John Osborn, which in turn led him to call me one day and say, "Some guys at Microsoft are working on an open-source version of the CLR, and would like to have a 'professional writer' help them write a book on it. Interested?" That led to SSCLI Internals, working with David Stutz, and wow, did I learn a helluvalot from that project, too.

Effective Enterprise Java came through DevelopMentor, thanks again to Don Box, who introduced me to the folks at Addison-Wesley that put the contract (and Scott Meyers, another blessing) in front of me.

DM got me my start in the conference circuit, as well. In 2002, John Lam pinged me over email—he'd recently become track chair for Connections down in Orlando, and was I interested in speaking there? I was such a newbie to the whole idea, but having taught classes roughly twice every month, I wasn't worried about the speaking part, but the rest of the process. John walked me through the process, and in doing so, set me down a path that would almost completely redefine my career within a year or so.

Even my Java chops got built up—the head of our Java curriculum was Stu Halloway (recently of Clojure fame), and between him, Kevin Jones, Si Horrell, Brian Maso and Owen Tallman, man, did I feel simultaneously like a small child among giants and like a kid in a candy store. Every time I turned around, they'd discovered something new about the Java platform that floored me. Bob Beauchemin has forgotten more about databases in general than I will ever learn, and he had some insights on the intersection of Java + databases that still hang with me today.

And my start with No Fluff Just Stuff came through DevelopMentor, too. Jason Whittington heard through a mutual friend (Erik Hatcher, of Ant fame) about this cool little conference being held in Denver, and maybe I should look into it. That led to an email intro to Jay Zimmerman, a dinner together while I was teaching in Denver a few weeks later, and before I knew it, I was on the Denver NFJS schedule, including the speaker panel, where I uttered the then-infamous line, "Swing sucks. Get over it."

DevelopMentor, you shaped my career—and my life—in so many ways, you will always be a source of pleasant memories and a group of friends and acquaintances that I would never have had otherwise. Thank you so much.

Rest in peace.

Update: Well, as it turns out, I have to rescind at least part of my eulogy, as the post itself generated quite a stir—the folks at DevelopMentor were pretty quick to email me, pointing out that they're still alive and well. In fact, as one of them (a friend of mine still working there) put it, "We were all kinda surprised when we came to work this morning and discovered that we could go home." Fortunately, the DevelopMentor folks were pretty gracious about what could've been a very ugly situation, and I apologize for to them for the misunderstanding—all I can say is that my "source" must've also been mistaken, and I'm glad that we're all still good. And lest it need to be said out loud, I heartily want nothing but the best for DM, and hope that I never have to write this message again.


.NET | C# | C++ | Conferences | F# | Flash | Industry | Java/J2EE | Languages | Reading | Scala | Security | Visual Basic | WCF | Windows | XML Services

Sunday, May 31, 2009 11:32:07 PM (Pacific Daylight Time, UTC-07:00)
Comments [6]  | 
 Tuesday, May 26, 2009
SSCLI 2.0 Internals

Joel's weblog appears to be down, so in response to some emails I've posted my draft copy of SSCLI 2.0 Internals here. I think it's the same PDF that Joel had on his weblog, but I haven't made absolutely certain of the fact. :-/

If you've not checked out the first version of SSCLI Internals, it's cool—the second edition is basically everything that the first edition is, plus a new chapter on Generics (and how they changed the internals of the CLR to reflect generics all the way through the system), so you're good. And if you're not sure where to get the codebase for Rotor 2.0 (the SSCLI), well, here, I'll make it easy for you. ;-)

Gotta say, this is almost without question my favorite book to have written. Just wish Microsoft would've kept Rotor up with the successive CLR releases (3.5 SP 1 and now the forthcoming 4.0). Maybe, if I can find that wishing ring....


.NET | C# | C++ | F# | Languages | Reading | Visual Basic | Windows

Tuesday, May 26, 2009 6:42:49 PM (Pacific Daylight Time, UTC-07:00)
Comments [0]  | 
 Saturday, May 23, 2009
He was Aaron Erickson... Now he's Aaron Erickson, ThoughtWorker

Yep, you heard that right—Aaron Erickson, author of The Nomadic Developer, is now a ThoughtWorker.

For those of who you don't know Aaron, he's been a consultant at another consulting company for a while, and has been exploring a number of different topics in the .NET space for a few years now, not least of which is one of my favorites (F#) and one of THoughtWorks' favorites (agile). He's been speaking at a number of events, including the Connections conferences, and he's going to bring some serious market-development potential to our Chicago office, something that's obviously of concern right now in these current economic conditions.

He also cooks a mean bacon-wrapped scallop, but that's another story for another day.

I'm looking forward to having him be a part of the growing collection of .NET rock stars at ThoughtWorks. Wanna come join us? Always room for a few more....


.NET | C++ | Conferences | F# | Languages | Visual Basic | WCF | Windows | XML Services

Saturday, May 23, 2009 7:05:09 PM (Pacific Daylight Time, UTC-07:00)
Comments [3]  | 
Of Tomcat 6, native services, Windows 2008R2, and pain...

So I'm putting together a Windows 2008 R2 x64 RC Java image for a client (more on that later), and everything's breezing along fine. Install the OS, check. Install JDK 1.6 (u13) into the machine, check. Install Tomcat 6 into the machine, running as a native Windows service, check. Open localhost on port 8080, and... not check. Times out, no response, not good.

Naturally, the first thing to check is the logs, and I get the strangest error I've seen in a while. "Cannot create Java". This is odd—what's happening, in the aggregate, is easy enough to understand, in that the native Windows .exe launcher (ProcRun, a generic service launcher from Apache) is using JNI to create the JVM inside the launched service process and, for some reason, failing; what's not clear is why. Unfortunately, the error codes offered up by the two players involved (Tomcat/ProcRun and the Windows OS) are not helpful—the Windows Event Log basically says "Service failed to start. Check the error code", which reports 0 (not helpful, thanks), and the Tomcat "jakarta_service_date.log" file reports something along the lines of...

[2009-05-23 17:33:41] [1343 prunsrv.c] [debug] Procrun log initialized
[2009-05-23 17:33:41] [info] Procrun (2.0.4.0) started
[2009-05-23 17:33:41] [1166 prunsrv.c] [debug] Inside ServiceMain...
[2009-05-23 17:33:41] [info] Starting service...
[2009-05-23 17:33:41] [174 javajni.c] [error] The specified module could not be found.
[2009-05-23 17:33:41] [994 prunsrv.c] [error] Failed creating java C:\Java\Tomcat6.0\jre64\bin\server\jvm.dll
[2009-05-23 17:33:41] [1269 prunsrv.c] [error] ServiceStart returned 1
[2009-05-23 17:33:41] [info] Procrun finished.

... which is not really all that helpful, either.

Hmm.

The fact that it can't create Java is not a really strong clue, so I start searching the Web for some solutions. Several people report running into this same problem, but solutions are not easily found—one web page reports that there's a missing "msvcr71.dll" file from the Windows installer installation script, and that copying the file into C:\WINDOWS\System32 fixes it, but when I go look in that directory, no dice—the DLL's there, and a quick "DUMPBIN" on the file reveals it looks good, no accidental file corruption or anything. Rats.

Maybe the problem's somewhere in the service configuration—it's possible that the Tomcat installer put the wrong configuration in or something. So I fire up the Tomcat configuration (tomcat6w.exe) from the "bin" directory, and just to be sure, I go hunting up the Service entry in the Registry (on the off-chance that the configuration utility is the source of the bug). Granted, this is kind of a stretch, but unfortunately, like I said, there's not much to go on. Sure enough, make a few changes (one of which is to tell the Tomcat native launcher to use the "server" VM, instead of the "client" VM, by default—why, oh why, hasn't Apache changed that yet?!?), verify that the changes are percolating all the way through into the Registry, and try kicking off the service. Still no luck. Still the same error.

While I'm rooting around in the Registry, I notice that there's another node in there that I'm not familiar with—the Wow6432Node. And buried underneath it (thank you, Registry Search, for finding this!) is a node for Apache Software Foundation/ProcRun2.0/Tomcat6, and a whole slew of configuration options under there, as well. Hmm. Errors in the ProcRun configuration perhaps? Sure enough... no, everything's working fine.

But now the synapses are firing in a different direction—the ProcRun bits are underneath the "Wow6432Node", and the "Wow" part of that name has me wondering—in the old 16-bit-to-32-bit transition Windows went through once before, "Wow" was an acronym for "Windows-on-Windows", meaning that the 32-bit version of Windows was opening up an emulation layer to run 16-bit programs. Given that this is an x64 image that I'm working with... is it that the service wants to be using the x64 version of Java rather than the 32-bit version I downloaded out of pure habit? Hmm. Go grab the x64 image, install it, and... still no love.

The WoW64 thing is still tickling at the back of my brain, though, and suddenly a new synapse fires off. If this is a 64-bit version of Windows, then there has to be.... Yep, sure enough, underneath the C:\WINDOWS directory there are not two, but three, "system" directories—the "C:\WINDOWS\System" directory that used to be the hangout place for 16-bit DLLs, the "C:\WINDOWS\System32" directory where 32-bit DLLs were encouraged to reside, and, just as pretty as you please, there it is, a "C:\WINDOWS\SysWOW64" directory, and inside there... no "msvcr71.dll". Copy the "msvcr71.dll" over from System32 into SysWOW64, and.... Voila. Service starts, log file looks good, and "localhost:8080" comes back with the Tomcat home page.

What have we learned from this little experience? A couple of things, some personal, some observational about the state of the universe and the industry:

  • Tomcat still installs itself to depend on a JRE found elsewhere on the system. This isn't a problem, per se, but the Windows installer for Tomcat tries to discover the JRE to use to run the Tomcat bits, and usually comes up with the "public" JRE installed underneath C:\Windows\Java\... . Fact is, I would really prefer if Tomcat made use of a private JRE (one inside the Tomcat directory) rather than the "public" one—too many times an installer will take liberties with the public JRE, and as a general rule, I really don't want installers messing around with those settings or deployment picture (contents of jre/lib/ext, for example).
  • I feel a little out-of-touch with x64 operating systems. Fact is, I have gotten a bit rusty on my operating system operation with respect to the 64-bit operating systems (Windows in particular), as highlighted by the fact that I really don't know what, if any, differences there are between the 64-bit version of a native executable and it's 32-bit cousin, or what the 32/64-bit transition story is. Anybody got any good book recommendations on the 64-bit Windows story?
  • I feel a little out-of-touch with the Java 64-bit story. Same thing—anybody have a good overview of what's different between 32-bit and 64-bit Java on Windows, and more importantly, why, even now, when I switch back and try to run the 64-bit version of Java via the service, it fails (this time with a "not a valid Win32 image" error in the log file)? Is it worth it enough to try and diagnose/debug/develop a solution to let Tomcat run with the 64-bit version of Java instead of the 32-bit it's now using?
  • The fact that this was harder to unearth via Google than usual bothers me a bit. Google usually helps with troubleshooting a lot more than it did, usually because commonly-hit errors and their fixes are reported all over the place, in blogs and forums and so on. The fact that there was relatively few hits (with potential solutions, anyway) makes me wonder: Are people not running Tomcat on Windows, not running Tomcat as a service on Windows, not running Tomcat on 64-bit Windows, or just not generally having problems? If you're running Tomcat on Windows, I'd love to hear your story.
  • Diagnosing Windows services is still a pain. I was a heartbeat away from trying to debug the native parts of the Tomcat service, using either SysInternals' Process Explorer or Visual Studio itself, and really wished there was some better error-logging to indicate what the problem was so I didn't have to. Granted, from my time writing Windows services way back when, I remember there not being a lot that a service author can do to make that a more transparent experience, so I can't necessarily fault the authors of ProcRun, since they're (probably) faithfully reporting the return value of CreateProcess or LoadLibrary, but it's still frustrating and I think more information (maybe the return value of GetLastError?) might have helped out here a bit.

Meanwhile, my installations continue....


C++ | Java/J2EE | Windows

Saturday, May 23, 2009 6:37:23 PM (Pacific Daylight Time, UTC-07:00)
Comments [3]  | 
 Friday, May 15, 2009
TechEd 2009 Thoughts

These are the things I think as I wing my way out of LA fresh from this year's TechEd 2009 conference:

  • I think I owe the attendees at DTL309 ("Busy .NET Developer's Guide to F#") an explanation. It's always embarrassing when your brain freezes during a presentation, and that's precisely what happened during the F# talk—I completely spaced on the syntax for implementing an interface on a class in F#. (To the attendees who commented "consider preparing a bit better so you dont forget the sintax :)" and "Not remembering the language syntax sorta comes across bad doesn't it?", you're absolutely right, which prompts this next sentence.) I apologize profusely to those who were there—I just blew it. For the record, the missing syntax looks like this:
    #light

    type IStudy =
    abstract Study: string -> unit

    type Person(firstName : string, lastName : string, age : int) =
    member p.FirstName = firstName
    member p.LastName = lastName
    member p.Age = age
    override p.ToString() =
    System.String.Format("[Person: firstName={0}, lastName={1}, age={2}]",
    p.FirstName, p.LastName, p.Age);

    type Student(firstName : string, lastName : string, age : int, subject : string) =
    inherit Person(firstName, lastName, age)
    interface IStudy with
    member s.Study(sub : string) =
    System.Console.WriteLine("Hey, Ma, I'm studying {0}!", sub)
    member s.Subject = subject
    override s.ToString() =
    System.String.Format("[Student: " + base.ToString() + " subject={0}]", s.Subject);

    Truth is, though, right now not a lot of people (myself included) are writing types that formally implement a given interface—the current common practice appears to be an object expression instead, something along these lines:
    let monkey =
    { new IStudy with
    member p.Study(subject : string) =
    System.Console.WriteLine("Oook eeek aah aah {0}!", subject) }
    monkey.Study("Visual Basic")

    In this way, the object handed back still implements the interface type that the client wants to call through, but the defined type remains anonymous (and thus provides an extra layer of encapsulation against implementation details leaking out). The most frustrating part about that particular snafu? I had a Notepad window open with some prepared code snippets waiting for me (a fully-defined Person type, a fully-defined Student type inheriting from Person, and so on) if I needed to grab that code because typing it out was taking too long. Why didn't I use it? I just forgot. Oy.....
  • Clearly Microsoft is thinking big things about Azure. There were a lot of sessions around Azure and cloud computing, far more than I'd honestly expected, given how new (and unreleased) the Azure bits are. This is a subject I would have expected to see covered this deeply at PDC, not TechEd.
  • TechEd Speaker Idol is a definite win, to me. I watched the final round of Speaker Idol on Thursday night (before catching the redeye out to Atlanta for the NFJS show there this weekend), and quite honestly, I was blown away by the quality of the presentations—they were all of them better than some of the TechEd speakers I'd seen, and it was great to hear that not only will the winner, who did a great presentation on legacy application support in Windows7 (and whose name I didn't catch, sorry) be guaranteed a slot at TechEd, but I overheard that the runner-up, a Polish security expert who demoed how to break Process Explorer (in front of Mark Russinovich, no less!), will also be speaking at TechEd Berlin this year.
  • As always, the parties at TechEd were where the real value lay. This may seem like an odd statement to those whose heads are a bit full right now from five days' worth of material (six, if you attended a pre-con), but remember that I'm a speaker, so the sessions aren't always as useful as they are to people who've not seen this content before (or have the kind of easy access to the people building it and/or presenting it that I'm fortunate and privileged to have). Any future attendees should take serious note, though: networking is a serious part of this business, and if you're not going out to the parties (or creating a few of your own while you're there) and handing out business cards left and right, you're missing a valuable opportunity.
  • I'm looking forward to TechEd 2010. Particularly because, thanks to a few technical snafus, I had the chance to sit down with the folks who organize and run TechEd and vent for a little bit about everything I found annoying (as a speaker). Not only were my comments not blown off, but it started a really productive discussion about how to make the behind-the-scenes experience for the TechEd speakers a more pleasant and streamlined one. What's more, we're planning to revisit some of these discussions in the months to come as they start their preparations for TechEd 2010 (in New Orleans). I'm looking forward to those conversations and (hopefully) helping them eliminate some of the awkwardness that I've seethed over in the past.

New Orleans in the summer will not be an entirely wonderful experience (I'm told it gets monstrously humid there in the summers, but it can't be any worse than Orlando is/was), but I'm honestly very curious to get back there to see what post-Katrina New Orleans looks and feels like, and to maybe do my (very little) part to help the area claw its way back by maybe staying an extra day or two and taking in some of the sights. (I'm hoping that Sara Ford will be willing to act as tour guide.....)

In the meantime, thanks to all of you who came, and remember—if you attended a talk and you want to say "thanks" to the speaker who gave it, the best way is to take the five minutes to fill out the evals for that talk. (Speaking personally, I don't even care so much about the scores you give me, but the comments are absolutely invaluable.)

See y'all next year!


.NET | C# | Conferences | F# | Languages | Review | Visual Basic | WCF | Windows | XML Services

Friday, May 15, 2009 8:18:19 PM (Pacific Daylight Time, UTC-07:00)
Comments [5]  | 
 Saturday, May 02, 2009
Windows 7 RC install experience

Since a number of people have been connecting to my blog via my last post on installing Windows 7 into a VMWare image, I thought since the Windows7 RC is now available, I'd update my experiences with installing it.

I downloaded the Windows7 RC ISO image (a freakishly hideous name containing every character on my US keyboard, plus a few in Klingon, I think.... if you can stand it, the full name of the ISO is 7100.0.090421-1700_x86fre_client_en-us_Retail_Ultimate-GRC1CULFRER_EN_DVD) from the Microsoft CONNECT website, not bothering with any of the other images (x64, ia64, and a "server" image I've not explored yet), using Microsoft's File Transfer Manager. (I know, I know, somebody's going to complain again about the ISOs not being available via a straight HTTP download or Torrent, but this is just an RC release, folks, and this is ostensibly to Microsoft-friendly customers who already have the FTM utility installed.) Took about 3+ hours to download on my home connection... or so it claimed. I went to bed after starting it last night. It was done when I woke up. What more do you want from me?

I created a new VMWare image, as a "Windows Vista" VM with 1GB RAM, a 60GB IDE hard disk (by default Fusion wants to create a 40 GB SCSI disk, but IDE seems to play nicer with the early betas of Microsoft OS'es, and I made it all one file rather than Fusion's default "Split into 2GB files" option), with the experimental 3D graphics turned on, battery status turned off, and (this is HUGE) the "Allow your Mac to open applications in the virtual machine" option turned OFF. Can't repeat this enough, for ANY VMWare VM containing Windows inside of it, turn off that option—leaving it on sucks up HUGE amounts of CPU time. (It's barely documented, and only determined Googling found that this was what was rendering my VMWare Fusion 2 images all but unusable.)

I attached the ISO to the VMWare CD and turned the thing loose. It takes a while, but so long as the ISO file and the VMWare VMDK disk file are on separate drives, the perf isn't too bad—roughly twenty minutes later (or, as I measure things, one randomly-generated map game of Pax Galaxia later), the image had installed all the core files on the VM disk, restarted itself, finished the installation, and restarted itself again. (I have no idea why Win7 wants to reboot itself twice during the install—if I remember the Vista installs correctly, it only restarts once). As I write this, I'm starting at the "Setup is preparing your computer for first use" screen with the funky Cylon-like flashing bar underneath the text (I'm serious, it really looks like the graphic artists at Microsoft are paying homage to BSG during that Setup screen). Whoops, I take it back—got through that screen rather quickly, and now we're into the username/password/product key stage. Plug that in, set the Update policy, the date and time, the network defaults (Public Location for all my VMs, just because), and.... "Welcome".

There's no Step Four. Although, according to Windows Update, there's already an update for Windows7 that should be downloaded and installed. *grin* Actually, it seems like the driver it installed was for the VMWare virtual sound device, which normally doesn't kick in until I install the VMWare Tools. It tells me that this is an "Unsupported Creative Sound Device", however, so maybe it's an older driver. *shrug* Not sure, don't care, because my next step is....

Install the VMWare Tools. I install VMWare Tools in the image, after the Update is complete. (No restart was required, so why not?) Actually, let me rephrase that—I tried to install the VMWare tools, but when I selected it from the Fusion menu bar... nothing happened. Hmm. OK, let's do the restart and see what happens. VM shuts down quickly enough (no having to wait for updates to finish, which was somewhat annoying with Vista), and when I restart, it seems to restart quickly enough (again, no obvious updates to be installed), so I get to a working desktop (640x480, how did we ever think this was reasonable?!?), and try the Install VMWare Tools option from the Fusion menubar again. It thinks for a bit, and the cursor flashes to the "pointer-with-CD" icon for a second before flashing back, but after a few seconds, the "What do you want to do?" (Autoplay) menu pops up as if I'd slipped the CD into the drive, so all looks good. Go through the UAC "Continue/Cancel" dialog (see below), choose "Complete" for the VMWare Tools install options, and let 'er rip. Disks spin, lights flicker, and a "VMWare Shared Tools" network folder shows up on the Win7 desktop, indicating that it's suddenly discovered the Shared Folder (to my MacOS user account) is there. But now we're back to the Windows-display-exercise program, which leads me to believe that it's the VMWare driver that's doing the exercise, not Windows itself. (VMWare? Anybody listening and care to comment?)

And now I'm into Win7 desktop customization steps, things like display sizing and desktop icon selection, background image, and all that other jazz that you probably don't care about. (If you do, then I'm a bit worried about you—be an individual! Choose your own settings!) All in all, pretty flawless and smooth.

Thoughts on the process:

  • It feels like we're getting away from the "minimal install" process that Vista tried to create. For a while, there was a meme that said that installing Windows was too hard for the average person, and Microsoft promised to reduce the number of steps it had to go through to install the OS. Take the date/time screen, for example: it picked up the defaults from the underlying (virtual) hardware, why not just assume those and skip that step? Users can always change it later.
  • I still have to set a Administrator password. I know that Microsoft is trying to find that sweet-spot balance between "too secure" and "unsecure" for desktop operating systems, but I have to hand it to the Ubuntu folks here—the "passwordless root" idea that they use is pretty slick. MacOS uses it (for the most part) in places, as well. I like the balance that approach achieves: it forces the user to enter "superuser" mode to do something sensitive, but it isn't challenging for a password (unless the superuser installs one) every time.
  • It's not going through display-screen calesthenics on each startup with this build. My previous Win7 image, every time I restart the VM, goes through every possible video/monitor size combination before settling in on the resolution I established in the last session. That was a bit disconcerting, until I realized that it's Windows trying to get some exercise in to be less overweight. *grin*
  • What, no PowerShell installed by default? Either it's not there, or it's buried pretty deeply. Command Prompt (cmd.exe) is right where it's always been, under Accessories, but no PowerShell.... Whoops, no, I take it back, it's in a folder underneath Accessories, forcing one more click to get to it. Hey Microsoft: do me a favor and pin that guy to the Start Menu. Make it easy for me to use, if you really want me to believe that this is supposed to replace Command Prompt someday.
  • On that note, though, the PowerShell "ISE" (Interactive Scripting Environment) is an interesting and new toy to play with.
  • "Pin to Taskbar" is an interesting option that I'm going to have to play around with. Not being a huge MacOS Dock fan (which is pretty clearly the inspiration for the new Taskbar), I'm not sure how well I'll like the new "it's the QuickLaunch and the Taskbar combined" idea.

Overall, I'm looking forward to putting a few things into this image (VS 2008, VS 2010, Office, and so on) and seeing how it reacts. As always, your mileage may vary, no implied warranties with this blog post, blah blah blah, but if you do anything with the Windows OS, you really should get hold of the RC (build 7100) and put it into a Virtual PC, VMWare, VirtualBox, Xen or some other virtualized box to play with. Like it or not, it's entirely reasonable to believe that Windows7 is going to win a few folks back from the Vista "less-than-I-expected" crowd.

As always, caveat emptor, and feel free to comment....


.NET | C# | F# | Industry | Review | Windows

Saturday, May 02, 2009 12:18:20 AM (Pacific Daylight Time, UTC-07:00)
Comments [2]  |