A November 2009 post on the Visual C++ Team Blog by Raman Sharma delved into the improvements Visual Studio 2010 was purported to have made to the “Find All References” feature of Visual Studio. This feature is a must-have for any developer in almost any language. As a project grows in size and complexity, it becomes a real chore to remember and locate exactly where a particular variable was defined – which is something that’s quite useful to know.
According to the VC++ blog post, VS2010 now uses a “speed-mode” by default to locate these references. It’s a bit less accurate in that it generates a lot of false positives, searching by name rather than by usage, but that this reduced accuracy comes with greater speed. And the option remains to further filter out results by having the compiler and the intellisense databases resolve the actual results and determine whether or not they indeed reference the search term.
Except that’s the way it’s supposed to work. In truth, that’s not what happens:
1) Visual Studio 2010’s “Speed Mode” of Find All References is slower than it was in Visual Studio 2005.
2) Visual Studio 2010’s “Speed Mode” not only generates extraneous false positives, it also fails to show items that do match the search term.
For the past several months, our support forums have been plagued on and off with a number of weird and inexplicable failed attempts at installing Ubuntu by many users. We’ve finally pinned down the cause of the problem, and it isn’t pretty. Ubuntu (ever since version 5.04 Hoary Hedgehog) will not install properly on a filesystem other than ext2fs or ext3fs.
Unfortunately if you attempt to install Ubuntu with the “/” partition formatted as ReiserFS, JFS, XFS or any other non-standard filesystem, Ubuntu installation will begin like normal and tick merrily along its way until it attempts to install GRUB. At that point, you’ll get a fairly inexplicable and non-verbose “fatal error” message about “grub-install()” failing.
We’ve all heard of (and, quite unfortunately, experienced) the infamous Blue Screen of Death. Some of us who tested the earlier Windows Vista beta builds had the unique experience of trying out the Red of Screen Death, which occurred when the bootloader experienced an un-handled exception (we experienced more than our fair share of these during the early days of EasyBCD development!). And then there’s Vista’s Purple Screen of Death, which few have seen.
1&1, popular website hosting service and domain name registrar, have a very serious problem with their nameserver configuration web interface.
We’re hosting our own domains with 1and1 (pointing to our dedicated servers hosted with the excellent and much-recommended Lunarpages), and were attempting to reconfigure our nameservers to point to a different IP address. We went into the 1&1 admin interface and attempted to re-configure the neosmart.net nameservers to point to the new IP – a week later, the DNS hadn’t yet propogated and we couldn’t find a good explanation.
This was how we had originally set up our nameserver entries in the 1and1 web administration center:
For all the Windows-bound PHP users out there, consider yourselves warned: even if you’re running the (supposedly) thread-safe PHP Win32 binary redistribution, you’re still susceptible to PHP Access Violation Errors, race problems, heap corruption, and much worse if you use the popular eAccelerator opcode-caching extension.
We did our testing with the binaries compiled by SiteBuddy using the latest versions of both PHP and eAccelerator. Almost immediately after initiating a stress test on our test servers we experienced the dreaded “PHP Access Violation” error – which brings down the entire IIS Worker Process to its heels.
Windows Vista has a new color-management/profiling format called Windows Color Systems. It purports to offer advanced color management and better results than the age-old (and forever dying) ICC/ICM color system. ICC has been buggy the whole way, with both political and technical issues plaguing its colorful history.
Windows Color Systems is a step in the right direction, but it comes at a very heavy price: Windows Vista no longer properly interfaces with ICC/ICM color profiles!
Anyone using the ATi Catalyst Control Center, BasicColor, ColorEye, Spyder, or any of dozen other color-management and gamma-correction programs available will have noticed the bug we’re talking about: once you lock your PC (winkey+L) the gamma LUT on your graphics card is reset.
(UPDATE: ToolTipFixer 1.0.1 released with fixes for some bugs)
Press Start | Programs; and right-click on “Accessories,” then press “Open.” Close the window that opens up, then go to your taskbar (next to the system clock) and hover over an icon, what do you see?
Ever since Microsoft invented the Windows Shell with explorer.exe back in the days of Windows 95, there’s been a bug that’s gone from one version of Windows to the next; and with each upgrade it became worse and worse – until Vista where it only rears its ugly head every once in a while instead.
Everyone that has used a Windows PC must have seen this bug before – it’s that ubiquitous (not that Microsoft would admit it for 10 long years):
These driver problems with Windows Vista and various manufacturers just keep going from bad to worse. Whether it’s a graphics card, printer, or mouse; Vista seems to BSOD right, left, and center at the slightest provocation.
If you’re using Windows Vista and you’ve been getting a ton of blank blue screens (more on that later), and you just happen to have a Logitech USB mouse or keyboard with Logitech’s “Vista Compatible” SetPoint 4.00 installed, then that’s most likely to blame.
Not having written drivers ourselves, we can’t honestly and fairly point the finger of blame at any party in particular. It’s very possible that either Microsoft or Logitech is to blame for this, but you never know.
If you know how to analyze BSOD dumps (btw, blank BSODs won’t create kernel memory dumps, make sure you have “small memory dump” selected); you’ll find that the WinDBG (or whatever debugging tool you choose) points its stubby little fingers at USBPort.sys and Win32k.sys – both stock Vista components.
SharpDevelop, for those of you that haven’t heard of it, is a very light-weight open source alternative to Visual Studio 2005. It doesn’t have all the frills and features that Microsoft’s professional IDE does, but in exchange it gives you much less bloat, faster speeds, and quite a few nifty built-in tools like SVN integration, FxCop auto-checking, code profiling, language conversion (C# <-> VB.NET <-> Boo#), and a bit more – but it has its drawbacks, too.
SharpDevelop is intended to be a 100% open source drop-in replacement for the Visual Studio IDE on Windows (there’s MonoDevelop for Linux if you like), and for the most part, it works just fine. But once in a while, an odd quirk pops up that’s rather obvious & common… yet unsolved and makes us wonder.
Apparently Windows Vista saw our last post – it’s trying to get even! What kind of crazy sociapath of an operating system is this!?!
Not even minutes after we blogged about WGA giving us trouble, explorer.exe crashed. After some CPR, a bit of mouth-to-mouth (it was disgusting!), and plenty of swearing, explorer.exe was successfully revived… Until we minimized Visual Studio to grab a file off the desktop and saw this: