June 27, 2008 | Comments: (0)
Why is Excel 2007 so slow to start up from Explorer?
I just hate waiting around for things to happen, especially on my computers. On my fastest Windows XP desktop(1), Excel 2007 takes a painful 30 seconds to display its contents if I click on a simple .XLSX file in Explorer. I find this inexplicable.
I hypothesized that this might be a just-in-time compile pause or a security check, but those probably aren't the cause: if I start Excel without a file, it starts up in one or two seconds. When I load the same .XLSX file from the Excel recent documents list it displays in under a second.
Any ideas, other than the obvious workaround of loading the worksheet from Excel?
(1) The computer in question is a 3.2 GHz Pentium 4 with 2 GB of RAM and NVidia GeForce FX 5200 graphics. It seemed like a fast box several years ago, when it was new.
Posted by Martin Heller on June 27, 2008 07:10 AM
May 15, 2008 | Comments: (0)
InfoWorld recently ran an article by Eric Lai of our sister publication ComputerWorld called Developers explain why they're avoiding Vista. I'm afraid that for me, and probably for most of you, this falls in the "D'oh" department.
The subhead of the article is "Fewer than 1 in 12 programmers is currently writing applications targeting Microsoft's Vista operating system." Again, "D'oh."
If I'm going to develop a product, I want someone to pay for it. That can be the company that wants it, or end users, or both. (OK, I've occasionally been suckered into developing for equity, but the equity never materializes, and I'd better stop here before I say something that would upset IDG's lawyers.)
Here's the current overall Windows market share picture, as tracked by PC Pitstop:
That's not yet a compelling case for writing software that requires Windows Vista: 80% of the total market wouldn't or couldn't run it. I would expect the situation to be worse for business, and it is:
So over 90% of the business market couldn't or wouldn't run a Vista application.
The new technology introduced with Windows Vista is seriously cool, and I'm learning about it all the time. But there has to be a market before I'll devote large chunks of my time to developing for it, unless the technology makes something possible that was previously impossible, or makes something easy that was previously prohibitively time-consuming.
What do you think? Are you developing with Vista technologies?
Posted by Martin Heller on May 15, 2008 11:07 AM
May 13, 2008 | Comments: (0)
Visual Studio 2008 SP1: To beta, or not to beta?
As I mentioned in An old Visual Studio problem rears its ugly head back in February, I've been looking forward to SP1 for Visual Studio 2008 and NET Framework 3.5. Why? These are supposed to fix most of the problems I've been having with Visual Studio, and restore most of the functionality that was cut from the initial 2008 release.
SP1 is out, but only as a first beta-test version. As is true with most beta-test products, there are risks to running it, ranging from a high likelihood of encountering new bugs to a low likelihood of trashing your system to the point where your most effective option is to reinstall Windows from scratch on a newly formatted partition, also known by the woodworking analogy of scraping your drive down to the bare bits.
The list of improvements in this version is impressive. Both Scott Guthrie and Brad Abrams have discussed these in their blogs. Brad does a great job of covering new features; Scott does too, in a slightly different way, and also highlights the known incompatibilities.
Here are the "gotchas", copied from Scott's blog:
1) If you are running Windows Vista you should make sure you have Vista SP1 installed before trying to install .NET 3.5 SP1 Beta. There are some setup issues with .NET 3.5 SP1 when running on the Vista RTM release. These issues will be fixed for the final .NET 3.5 SP1 release - until then please make sure to have Vista SP1 installed before trying to install .NET 3.5 SP1 beta.
2) If you have installed the VS 2008 Tools for Silverlight 2 Beta1 package on your machine, you must uninstall it - as well as uninstall the KB949325 update for VS 2008 - before installing VS 2008 SP1 Beta (otherwise you will get a setup failure). You can find more details on the exact steps to follow here (note: you must uninstall two separate things). It is fine to have the Silverlight 2 runtime on your machine with .NET 3.5 SP1 - the component that needs to be uninstalled is the VS 2008 Tools for Silverlight 2 package. We will release an updated VS 2008 Tools for Silverlight package in a few weeks that works with the VS 2008 SP1 beta.
3) There is a change in behavior in the .NET 3.5 SP1 beta that causes a problem with the shipping versions of Expression Blend. This behavior change is being reverted for the final .NET 3.5 SP1 release, at which time all versions of Blend will have no problems running. Until then, you need to download this recently updated version of Blend 2.5 to work around this issue.
I wouldn't install this version on my primary development system, but I might install it on a secondary development system after doing a full back-up.
To beta, or not to beta? Maybe both.
Posted by Martin Heller on May 13, 2008 11:37 AM
December 03, 2007 | Comments: (0)
Lies, Damned Lies and Benchmarks, Yet Again
I've noticed (well, who wouldn't?) that Randall Kennedy (RCK) is in a kerfuffle about Nick White, a Microsoft Vista Product Manager, who blogged a relatively mild discussion of "The right time to assess Windows Vista's performance." So, at the risk of antagonizing everyone involved for no benefit whatsoever, let me offer another perspective.
RCK wrote the benchmarks used by www.xpnet.com. Recently that organization compared release candidates of Windows XP SP3 and Windows Vista SP1, and found Vista lacking. That shouldn't really come as a surprise to anyone, but I'm not sure that it's the issue here.
Nick White's blog post points out that Microsoft only publicly benchmarks products once they have been released to manufacturing; that has been true to my knowledge for at least 20 years. When beta testers had to sign a non-disclosure agreement to work with pre-release Microsoft products, one of the key terms of the agreement was always a ban on publishing performance numbers prior to product release.
I can remember lots of products that had performance issues right up to the final release candidate that testers got to see, but were fine when released to manufacturing. So Nick has a point: a release candidate is not the right build to benchmark if you want to understand the performance of an OS. You need to wait for the RTM bits.
RCK commented to Nick's blog in high dudgeon, about being attacked. But was he attacked? Nick never mentioned xpnet or OfficeBench or RCK in his post, so I'd say no.
RCK certainly interpreted the post as an attack. I read the posting more as being a little defensive, but hardly an attack.
Nick talked a lot about Principled Technologies, which did some Vista benchmarks for Microsoft last year, and Nick suggested that their benchmarks had been done properly. I'm not so sure about that: when you know the results your client wants to get, it's easy to pick tests that will produce those results, whether you consciously mean to or not. Given the variance in results between the two sets of benchmarks, I'm not surprised that RCK feels defensive.
As a benchmark writer myself (I'm responsible for the WinTune and PC Pitstop benchmarks), I'm here to tell you that no single set of benchmarks can ever tell the whole story. My benchmarks sure can't, and I've really worked at them over the years; I rather suspect that neither OfficeBench nor the Principled Technologies benchmarks can either.
So can everybody please chill?
Posted by Martin Heller on December 3, 2007 02:40 PM
November 21, 2007 | Comments: (0)
After a snipe hunt to determine why the WMI Win32_StartupCommand class would return thousands of entries, most of which look like device drivers, Dave Methvin found a Web page with a fix here.
The problem happens when the Windows registry string value "Startup" located at the key "HKEY_USERS\S-1-5-18\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders" has no value or points to a non-existent folder. Filling the value with "C:\Documents and Settings\Default User\Start Menu\Programs\Startup" fixes the problem on Windows XP.
The next interesting question is why this happens. Currently I suspect a bug in msconfig, but I have no proof.
Posted by Martin Heller on November 21, 2007 02:24 PM
TOP STORIES
ADDITIONAL RESOURCES
- Remote Access: Maintain Security and Decrease the Burden on IT
- Beyond AntiVirus: Symantec Endpoint Protection
- What Every Enterprise Needs to Know About VDI
- Monitor the core and troubleshoot the access layer
- Help Simplify Virtualization
- Solution for Open Virtualization Provides Server Consolidation
