It's hard to miss the irony in the fact that the Visual Studio debuggers
are riddled with bugs. As one of the most widely-used programming tools I'd
expect it to be polished beyond reproach, however even in the managed world the
debugger is - to put it mildly - not perfect.
The VS2003/.NET 1.1 debugger is particularly susceptible to threading issues.
It stalls, it barfs, it
lies, and now it even triggers exceptions in your code that aren't even
documented in MSDN - I was getting ThreadStopExceptions on some of my threads
while stepping over instructions. There was no way to know when it might happen
and no way to reproduce it consistently. I was reluctant to blame the debugger
at first, but this thread
provided both the culprit and the solution: close all locals, autos and watch
windows and you should be right as
rain.
Part of a very large project we're working on stopped working oh-so-suddenly
for one of my colleagues. An exception would be thrown on initializing .NET
Remoting - specifically when instantiating a TCP port. Here's part of the
exception content:
System.Net.Sockets.SocketException: Only
one usage of each socket address (protocol/network address/port) is normally
permitted
at
System.Runtime.Remoting.Channels.Tcp.TcpServerChannel.StartListening(Object
data) at
System.Runtime.Remoting.Channels.Tcp.TcpServerChannel.SetupChannel() at
System.Runtime.Remoting.Channels.Tcp.TcpServerChannel..ctor(IDictionary
properties, IServerChannelSinkProvider sinkProvider) at
System.Runtime.Remoting.Channels.Tcp.TcpChannel..ctor(IDictionary properties,
IClientChannelSinkProvider clientSinkProvider, IServerChannelSinkProvider
serverSinkProvider)
... (deleted)
Running netstat -b proved that some process or
another was indeed listening on that particular port, however it failed to say
which process is responsible (just said "System".) Running the excellent SysInternals utility TCPView also
proved futile, as it displayed a prominent <non-existent
process> in the Process column.
As usual, at this point I turned to the 'net; a quick search provided a hypothesis
that IIS was somehow responsible for hogging the port; this didn't seem to make
sense because IIS was not involved (the channel was not hosted in IIS, nor was
it an HTTP channel to begin with) and shutting the IIS services down didn't help
any either. Listing the active services via tasklist
/svc proved useless as well, as did a reboot.
After some serious searching I picked up this
thread in the pgsql.hackers newsgroup; apparently they had similar issues
with broken security (AV, firewall) software not uninstalling properly; a lot of
security-related software products (called Layered Service Providers, or LSPs)
install their own TCP/IP handlers into an appropriate chain in the Windows
TCP/IP stack. Although that wasn't the case here, we figured it can't hurt to
try the solution pointed to by the newsgroup participants; LSP-Fix is a utility that rebuilds the
appropriate registry entries in an effort to restore the handler chain to a
working condition. One reboot later and everything was back to normal.
I'm still not clear on the cause of the issue, but this information might
prove useful up ahead...
The immediately good news: the 2.0.1 version of Hebrew OpenOffice.org is out - go and
download it! It features a whole bunch of bugfixes, primarily fixes to the way
tables in Word files are imported. I don't use Word much - particularly not
for Hebrew files - so I can't righly comment on it, however I've been told
by friends and peers that this bug was one of the biggest issues they had with
the 2.0 Writer.
Also, a tip: it's not obvious nor exactly trivial, however it IS possible to
do regression analysis and include trend lines in Calc sheets and charts; check
this
tutorial out (via xslf on the OOo.il
forum).
Although I enjoy using GAIM, it has
several issues - most notably a very poor UI experience, which is being worked
on in the 2.0 betas (which are perfectly usable, by the way). The second most
obvious problem I've been having is to get GAIM to receive Hebrew messages from
buddies on ICQ. This issue can be easily fixed by accessing the ICQ account
properties and changing the Encoding field:
The default encoding is ISO Western (ISO-8859-1); to get Hebrew properly just
disable the account, change the encoding to Windows
Hebrew (Windows-1255) and re-enable it. Although not technically correct,
ISO Visual Hebrew (ISO-8859-8) seems to work too.
I'm not sure if the Western encoding is indeed the default - I've been
importing my account settings since GAIM 1.3 or so - but I'll look into it and
file the appropriate bug report (encoding should be set to what is appropriate
according to the current locale, at least in Windows).
Check this
out, then stop wasting our collective time and send a supportive e-mail to
alexness at toysforbob dot com.
GET ON WITH IT!
The other day my laptop started acting up - it slowed down to a crawl then
barfed on burning a disc (which I originally attributed to irregular
I/O behavior on the side of µTorrent); that in itself was annoying, but
it only raised warning signs when another burn (this time without any active
background applications) failed in the exact same spot.
I decided to run scandisk (which, being that I'm running only one
partition, would not run until the next reboot), and over the next three hours I
could do nothing but stare at what any seasoned computer professional will
sadly tell you is one of the most horrible sights in existence:
Three hours later I have a fully-functional laptop with over 5MB of bad
sectors (and, as the same seasoned computer professional will tell you, the
problem is only exacerbated with time) that runs somewhat slower than it ought
to on I/O operations. Luckily the warrantee is still in effect, but invoking it
means having to spend days without my laptop.
Almost makes me wish I bought an HP (unless I'm mistaken, they have a "if it
breaks we'll replace it for you at home within 24 hours" kind of policy), but
then I remembered that my laptop has been customized by the shop in which I
bought it (with a 7200RPM Hitachi drive instead of the standard 5400RPM one).
Since I'm not even (remotely) new to hard drive crashes I knew what this meant -
a trip to the store, which sends the drive to the local importer, waiting for
days while it's being "examined" and then another trip to the store to get it
back. What makes it even worse is that the shop where I bought the laptop (Lamir) is situated in another part of the
country.
Luckily the lab guys were kind enough to allow me to remove the hard drive
and send it to them via courier, which should save me a couple of unnecessary
trips to the centre of Israel. I'm not sure how support services work in other
countries, but this is quite unusual here - normally warrantee on branded
products is voided if you tamper with them (even if it's something as trivial
as removing or installing a hard drive yourself), so in that I have to
thank them. I just hope the rest of the experience is as pleasant.
Now I'm off to get myself a NAS device to back up my stuff
on.
There's a recent fashion among blog-savvy developers in looking for the
"ultimate programming font." This has been around as long as programmers, but
the discussion has recently been sparked again by the impending
release of Microsoft's Windows Vista along with its slew of new
fonts. I'm not the early adopter type so I couldn't really be bothered and
stuck with the default fonts, until I got a new monitor at work and figured it
was about time to ditch good ole Courier New try for something with a little
more panache.
A good couple hours later I had a large selection of fonts; the selection is
actually quite overwhelming, however there are very few actually
good fonts (for example, the Proggy fonts are
generally considered some of the best around, but I can't stand looking at them)
and fewer still could actually dethrone the aging but solid Courier New.
At first I actually considered using Consolas, although it's not easily
obtainable. A quick Google Images search provided me with the necessary visual
example of what the font would look like (screenshot courtesy of Jeff
Atwood):
Honestly? The font looks horrible. I find the fuzziness introduced by the
ClearType rendering very hard to swallow (the font looks as though it's
suffering from colour-bleeding, even though it's not). I couldn't be
bothered to even try installing the font.
A casual comment from a reader in one of the blog posts I've read struck me
as brilliantly simple: I've been using OpenOffice.org for quite a while now (give
it a try!), and the default font for Writer is a relatively new font from
Bitstream (via GNOME) called Bitstream
Vera. It originally struck me as an impressively neutral font -
pleasing to both eyes and mind. Apparently a monospace version of the Bitstream
Vera Sans font is included with OOo (and additionally available via the previous
link); it's professional, it's free and it looks great (screenshot shamelessly
stolen from this
place):
I heartily recommend the Bitstream Vera Sans Mono font for programmers (note
that it takes a bit
of hacking for it to work with Visual Studio 2003, although it works just
fine with 2005).
Finally, if neither of the above fonts suits you, there's a huge list of
programmer fonts here; one
alternatives you should look into is Andale
Mono, which is very slick and functional.
Windows is anything but user-friendly if you're not a local
administrator, or so I learned when my dad asked to be able to convert CDs to
MP3s so he can listen to them on his PDA. A simple enough task, I figured I'll
just configure Exact Audio Copy to
"dumb mode" and leave instructions on how to use it (basically, double-click the
icon; select the appropriate drive; Alt+G to get the information from freedb;
select relevant songs; F5).
For some reason my dad (whose user is not a local admin so as to keep
spyware and other crud off our system) couldn't access any but the generic
(Daemon Tools and other emulation layers) CD drives. It took me two hours (!) to
figure out that:
- Windows 2000 and on does not come with an ASPI layer installed
- Most software (including EAC) has been updated to use the native API calls
instead and do not require ASPI
- The native calls fail for non-administrative users (!)
Installing an ASPI layer is supposed to remedy the situation; I've opted to
use ForceASPI 1.8 (instead of
the default Adaptec installer) but that did not have any effect. To make a
(very) long story short, the way to handle this is to use Frog Rights, which
finally solved the problem.
To add to my frustration, however, after screwing around with ASPI drivers
for hours Nero would no longer recognize my DVD-RW; I figured I'll just intsall
the latest Adaptec ASPI drivers which completely screwed up my
system - Windows XP would no longer boot and the only clue a logged
boot would provide is that something goes very wrong loading the fastfat.sys driver. Nothing I did over the next four
hours would allow the computer to boot; oddly enough, my brother managed to boot
the machine by simply removing the empty DVD-R media in the DVD burner (a major
WTF). We're still not clear on the problem.
Update: Apparently Nero has its own tool for this purpose called Nero BurnRights, which works like a charm.
I've been playing around with Leonard Maltin's Movie
Guide for the PocketPC for a couple of days now, trying to find a useful
program for cataloguing and keeping track of my DVD collection. I couldn't find
any free software that didn't outright suck, so I turned to commercial software
instead; LMMG seemed to fit the bill - mini-database of DVD releases, the
ability to easily categorize and keep track of my DVDs and all sorts of nice
features.
I did find out, though, that I'm sorely missing an import/export feature. It
would be cool to be able to post my movie list somewhere, or send reminders to
friends to whom I"ve lent movies that those movies are due back and all sorts of
neat stuff that you can only do if you have access to the movie list.
Not even a customer yet, I've fired an e-mail to LandWare's support
department:
I'm seriously considering
purchasing the Movie Guide (I've been testing it thoroughly for the last hour
or so), but have one serious qualm with it: my movie collection can not be
imported/exported (preferably to a well-documented CSV or XML-based file
format). Additionally, although my PDA does not feature internet connectivity
it would be great if movies could link to IMDB/some other online movie
repository (either directly or via title search).
Are either of these features likely to be included in the software? The
import/export feature is practically a show-stopper for me (I'd like to be
able to e-mail my DVD list to friends and that sort of thing).
A day or so later I get the following reply:
Hi Tomer,
As of last night, Movie Guide for Pocket PC now provides an import/export
feature, using tab-delimited files.
Product info: http://www.landware.com/movieguide/ppc/ Conduit
Documentation: http://www.landware.com/movieguide/conduit/ppc/
I'll log your other comments for our developers; what exactly are you
looking for with regard to online connectivity?
Josh
If that isn't good service, I don't know what is. I'm
sold.
Reading a couple of posts on The
Old New Thing (Raymond Chen's blog) made me realize that compatibility
issues, except for being a general headache, have a lot of nontrivial
repercussions. Take this example of a network
interoperability issue: Samba, the standard Linux implementation of an SMB
server, supports a feature called fast directory queries. Apparently the feature
had been (until recently) broken, and because Windows XP never made use of the
feature this was a non-issue until internal tests with Vista brought it to
light.
A naïve developer would, at this point, assume that Microsoft would let the
responsible party know that they have a bug and move on. Things are obviously
not that simple, but for reasons you wouldn't expect: exactly because
Samba is such a widespread product, any user encountering the bug (assuming
he/she'd even notice something was wrong - the bug in question is not easy to
spot) for the first time would automatically assume a bug in Windows Vista (a
fairly reasonable assumption considering you could never hit that bug with older
versions of Windows). Worse still, although the bug was fixed quickly there is
no guarantee that the fix will actually be installed on the problematic devices.
For starters, there is a chain of responsibility which starts with the
administrator of the offensive device and ends in the product vendor; this means
that in some cases the vendor will not install the bugfix by default and will
void the support contract if a "vigilante" administrator installs it locally.
Second, Samba is often used in embedded devices (such as network attached
storage [NAS] devices) which may or may not be firmware-upgradable by the
user.
Regardless of the solution Microsoft decides on (Raymond is
actively seeking ideas - if you have any, make sure to drop a
comment), some of the proposed solutions have even subtler repercussions
that need to be considered. For example, one of the proposed solutions is to
detect and maintain a list of "bad" servers for which fast queries will be
disabled. Apparently this is a potential security hazard, because a malicious
user can make use of this feature to launch denial of service-like attacks on
the client (it's not obvious how this can be done, so Raymond elaborates
on this point in a follow-up).
One of the disadvantages of working on relatively low-profile software is
that you hardly ever get to tackle security issues such as these, so you
only get food-for-thought by reading articles and blogs. But I guess that's what
the blogosphere is for in the first place, no?
|