Historically, the 64-bit edition of Windows XP hasn't been a runaway hit. It's not really surprising in many ways: the x64 version was a rather specialist product built off the Windows Server 2003 codebase, which traded a loss of support for a number of features (including .NET Framework and DirectX in early releases) in return for the ability to address vast amounts of memory from a single process. Since the AMD64 and Intel EMT64 ranges of processors happen to run 32-bit code extremely quickly, it's not surprising that even though probably the majority of machines sold these days are 64-bit capable, they are running the standard 32-bit version of the Windows XP operating system, with the 64-bit edition used mostly for workstation-class tasks such as engineering and scientific applications.
In Windows Vista, the choice becomes far more pertinent for most people. Gone are the limitations of the 64-bit edition in terms of what software comes shipped with the operating system: a "Longhorn Basic" requirement for any feature to have been accepted into the operating system was to be supported on both 32-bit and 64-bit platforms. But the 64-bit version also takes advantage of the hardware to offer some attractive security features that are exclusive to that platform. On the downside, you'll still see weaker downlevel compatibility on the 64-bit platform: for example, we don't support 16-bit code from the Windows 3.x days (which is a little more of an issue than many people realize due to the inclusion of 16-bit code in the installers for some decidedly 32-bit applications).
The choice is an interesting one, and by far the best article I've seen explaining the differences between the two platforms in detail is from Paul Thurrott's Windows Supersite. It succinctly defines the pitfalls and strengths of each choice. It's also worth checking out the Windows Vista Product Guide for more details. I'm considering holding out for one of the new Merom-based notebooks that will contain dual-core, hyperthreaded 64-bit processors: so much power in one portable machine that it makes me drool!
I've seen a number of instances of this error over the last few days since we released WinFX Runtime Components Beta 2, and wanted to highlight it right here on the blog to ensure people knew about it.
The symptom is that on installing the WinFX Runtime Components on a machine that previously had an earlier release, setup fails to complete during the installation of Windows Communication Foundation, giving a fatal error 1603. This is due to an InfoCard service that we have a problem uninstalling.
It's actually documented in the readme, but I guess I'm not the only one who doesn't pay a blind bit of attention to those! Here's the extract that includes the workaround:
WinFX installation fails with this error:
ERROR_INSTALL_FAILURE 1603 Fatal error during installation
ServiceModelReg [15:48:08:041]: Installing: Microsoft Digital Identity Service (idsvc) ServiceModelReg [15:48:08:073]: Error: System.ComponentModel.Win32Exception: The name is already in use as either a service name or a service display name
To resolve this issue:
Hope this helps out a few folk!
It's great to see how agile the Windows Live Local / Virtual Earth team are - they've just released what is their third or fourth public release in almost as many months, I think. Building on the maps and routing algorithms from the Streets & Trips / Autoroute products, they've created the sine qua non of maps, demonstrating how rich an experience you can get with an expertly-crafted AJAX site these days.
Ten things I love about Windows Live Local:
If you've not tried out this new release, give it a go - I think you'll be impressed...
If you've not noticed that today is a pretty significant day for Microsoft, you've either been offline from the major news sources or we've lost your attention altogether. I can't think of many occasions in my Microsoft career when we've released so many new things simultaneously. Here are a few links:
One resource in particular that I'd like to draw to folks' attention is the Windows Vista product guide - an extremely comprehensive overview of the several thousand new features we shipped in this release. It will hopefully dispel once and for all the myth that Windows Vista is just Windows XP with some tweaks to the user interface. Sure, it's been a rocky ride to this point, but Beta 2 marks a point where I'd say we are now firmly on the glidepath to release.
For those of you who are porting Avalon WPF code forward from our last release (the February CTP), you'll be pleased to know that the changes are mostly fairly trivial. The big new feature is performance - this release shows the benefits of the last three months of intensive efforts to reduce working set and remove redundancies in the code. You should see significant benefits: as an example drawn from my own experience, the Allscripts patient monitoring demo that used to run embarrassingly poorly on my two-year old laptop now runs super-smoothly: enough that I was able to demonstrate it with confidence on the same machine at a CIO summit keynote a week or two ago.
As I've gone through our portfolio of samples, there are a few changes that have stood out, however: I've tried to enumerate most of them here.
Slider / ScrollBar Style ChangesWe've made changes to the Track primitive class that is used in the styles of ScrollBar and Slider to make it simpler for tools like Expression to modify (you no longer need to create a new style to edit a single property on the Thumb or RepeatButton controls that make up a Track). The following sample code shows the new syntax:
<Track Name="PART_Track"> <Track.Thumb> <Thumb Style="{DynamicResource Slider_Thumb}" /> </Track.Thumb> <Track.DecreaseRepeatButton> <RepeatButton> <RepeatButton.Resources> <Style BasedOn="{StaticResource Slider_RepeatButton}" TargetType="{x:Type RepeatButton}"> <Setter Property="Command" Value="Slider.DecreaseLarge" /> </Style> </RepeatButton.Resources> </RepeatButton> </Track.DecreaseRepeatButton> <Track.IncreaseRepeatButton> <RepeatButton> <RepeatButton.Resources> <Style BasedOn="{StaticResource Slider_RepeatButton}" TargetType="{x:Type RepeatButton}"> <Setter Property="Command" Value="Slider.IncreaseLarge" /> </Style> </RepeatButton.Resources> </RepeatButton> </Track.IncreaseRepeatButton> </Track>
Z-Ordering for Panels This is the kind of change I like! We've added an attached property for panels that allows you to control the z-order of elements contained within them. The absence of this feature has been painful for a number of our customers and partners (in the past, z-ordering was determined by the order of objects in a collection, meaning that you had to remove an object from a collection and re-insert it, with all the associated overhead of doing that). It's great that we've been able to fix this in time for the first production release of WPF. Simply check out the Panel.ZIndex attached property.
XAML Syntax Tightening We've tightened up XAML syntax in a few places. One common example where you may start seeing a build error is in code where you use x:Name inside a subclassed container panel if you also use it in the subclassing itself. If a markup subclassed element (defined in one scope, aka the definition scope) was used in another scope (aka the usage scope) and it had names on elements under it in the usage scope, there exists a potential conflict of these names wherein name fields would be created for these in the outer (usage) scope, but the parser would actually register the names in the inner scope (since it would implicitly acquire a namescope dynamically in the definition scope). and give names to because we can't easily detect name clashes of this kind at compile time.
Another XAML change is that resources can no longer be forward referenced. For example, if you have a data template that references a control template with an x:Key of foo, then foo must be declared before the data template.
Windows Forms Integration ElementHost and WindowsFormsHost now contain a Child, rather than a Children property, since they can only have one child (poor things...). A few of the other methods like FirstChild are also removed, since they're no longer necessary. This should be a straightforward fix.
Those are all the changes that I've run into so far - I'll supplement this list if I come across anything else that's worthy of note. Let me know if you're blocked by anything else and I'll do some digging.
There's been some interesting comments on my entry: "The Inside Scoop on Interviewing at Microsoft", and I just wanted to follow up and expand on a couple of points.
Hiring new staff is an incredibly resource intensive project. There's a reason why most senior managers at Microsoft list hiring as one of their top four or five objectives for each year. It's not just an interview: there's work to define a role, "evangelism" to ensure that that open position gets seen by as many talented people with relevant skills as possible, winnowing out resumes to find potential candidates, conducting potentially tens of telephone interviews for each job, organizing a day of interviews for each shortlist candidate, actually interviewing, following up on peer interviews, writing up the interview, following through to an offer or a decline - it all takes an immense amount of effort. The old cliche of "marry in haste, repent at leisure" works almost as well for a job as for a romantic partnership.
I accept the potential criticism that just because someone doesn't answer a question in the expected manner doesn't make them wrong. A good interviewer should definitely be open to evaluate their question and drill deeper or try a different tack if they feel like the interviewee is misunderstanding the question, or indeed being open-minded enough to evaluate their answer on its own merits. A bad interviewer makes their decision in the first few minutes based on how much they click as an individual with the interviewee. I try to reserve judgement on the final hire / no hire decision until the very end of the interview and instead work on identifying potential hire and no hire characteristics that I can verify with further questioning.
Interviewing is one aspect of working at Microsoft that I really love - I think the process that we've adopted is pretty good. Probably the biggest challenge for most Microsoft interviewers is that it's something of an art rather than a science: there's no magic, repeatable formula for a perfect interview. The right question to ask at any given time depends on the personality, the experience, the skills, the seniority and the fit to job of the person being interviewed, yet you can't know the answers to all those things before you interview the candidate (otherwise the interview itself wouldn't be needed!) Any interview is therefore an iterative loop of understanding someone more and therefore being able to ask more targeted questions that reveal more of the true character and abilities of the interviewee.
If you interview and don't get accepted, don't automatically assume it's because you're not of high enough caliber to work at Microsoft. It's quite possible that you just aren't the right fit for the job at hand. I'd expect that if I interviewed for a random 100 jobs at Microsoft, I might get an instant "no hire" for 80 of those jobs, a possible hire (but with no real hope of being a stellar performer) for 15 of those jobs, and find 5 or fewer jobs where I could really make a difference and stand out. Actually, it might be even more dramatic than that. The hidden secret that I wish more job/career books would cover is actually finding the right five jobs in the first place, and then of course to make sure that you communicate well enough that those who interview can see your strengths there.