Weird problem with eMachines DVD-RW drive solved

I've been stumped by this problem with my eMachines M6809 laptop for a couple of years, ever since I first bought the beast. The problem was with the Slimtype SDW-431s DVD-RW drive when run under Windows XP. It would read the contents of the CD/DVD OK, but when I tried to launch a program from it, I'd get an error similar to this:

The procedure entry point blahblahblah could not be located in the dynamic link library blah blah blah.

Notice the weird casing in the procedure name MsgWaitForMultIpleObjects. It should have been MsgWaitForMultipleObjects.

For a long time, I couldn't figure out what the heck that error was about, and had dismissed it as a defective DVD drive and left it at that...At least until this weekend.

Last Friday, at approximately 9:30AM Eastern Standard Time, the hard drive on my lovely eMachine decided to pull a head-crash stunt, sending 5 years worth of my life into /dev/null (a long and painful story for another day), and once again I was motivated to get this damned DVD drive working so that I can do backups with.

This time, I stumbled onto this discussion thread on cdfreaks.com, and figured out what the cause was: it had to do with the Secondary IDE Channel setting used by the DVD device driver on XP. This setting is accessible through the Control Panel Device Manager. By default, the Transfer Mode for Device 0 on this channel property was set to "use DMA if available". I changed it to "use PIO only", and voilà! Everything started working like a charm. Now it can read and run programs off the DVD with no problem.


Prior to finding the solution, I had tried googling like nobody's business, hoping to find some other people who might have experienced similar symptoms, to no avail. So now I thought I'd post my findings here, in hope that it could help some other poor souls out there who might have the misfortune of owning an eMachines laptop and have managed to bump into the same problem.

Mashing up the desktop?

Hey, have you tried out the new 3.0 release of Google Desktop? I've only begun trying it out for a few days now, but I must say that I really like it. Google Desktop can index everything from individual files, to emails stored within Microsoft Outlook or Mozilla Thunderbird.

This is great! Suddenly, my local hard drives have become one huge database that is easily and quickly searchable using one common interface, and the desktop becoming one integrated application.

From a technical level, I'm intrigued that the Google Desktop Bar is able to:

• monitor new emails from my Microsoft Outlook accounts,
  
• monitor new emails from my Mozilla Thunderbird accounts,
  
• detect that the web page I'm viewing is a blog page, and monitor that blog for new entries (via its Web Clips feature),
  
• notify me of new items from all of those sources using one common notification popup interface.
  

And then, when I click on the notification popup, it brings up the item in the native application: if it's an Outlook email, GD opens it up in Outlook; new Thunderbird emails get opened using Thunderbird; and new blog entries are brought up in the default browser.

It seems to me that this is an example of what Gavin called "mashing up the desktop".

It also seems to me that AppConnector is well on its way to be considered as a desktop mash-up tool, for the following reasons:

1. It treats the desktop as one single integrated application.
   
2. It is able to re-use and leverage existing applications' GUI as-is, without the need embellish them into its own GUI, thereby avoiding legal implications involving copyleft, copyright, and what-have-you.
   
3. It mashes up two otherwise disparate functions (e.g. entering A/P invoices and maintaining electronic copies of PO's), normally provided by two different desktop applications, into one integrated (and more complete) solution.
   

Desktop, the final frontier. These are the voyages of the toolship "AppConnector". Its continuing mission: to explore new desktop environments, to seek out new ways to mash up new desktop applications, to boldly go where no mash-up tool has gone before.
(Star Trek theme music begins...)

And let the mash-up begin.

Google and China

In the past several weeks, The People's Army of Geeks has slash-dotted the heck out of recent news that Google began censoring searches on google.com.cn.

Give it a break, folks! Google makes it easier for people to access information on the global scale. My prediction: Google's presence is one of the catalysts that will bring about a new kind of cultural revolution, one which will see the end of communism in China without bloodshed.

The voice of democracy cannot be silenced forever. And there will be democracy when the people of China (or Vietnam for that matter) want it so much that their government will have no choice but to give it to them.

REST and the principle of encapsulation

I was playing around with my new Outlook Web Access (OWA) installation last night and it struck me that OWA appears to be a RESTful application. Good on Microsoft!

One of the main concepts in REST is the idea that all resources (in a general sense, not technical sense) in the system are uniquely addressable via a URL. It implies that the URL only contains the business end of the feature (e.g. viewing my inbox) and should have no technology association whatsoever (e.g. this feature was implemented using ASP.NET, which, by the way, OWA was).

In my simple-minded view, I think this encapsulation is very important for the following reasons.

As a (somewhat) alert software user, I couldn't care less if you implemented your software using ASP, ASP.Net, Java, Python, Perl, PHP version 4 as opposed to version 5, or what-have-you. Having a URL containing a tail of .asp, .aspx, .jsp, or .py immediately clues me into what technology you're implementing your software in, which may not be a good thing (see next paragraph). Plus, having technically specific parameters in the URL that has nothing to do with what I'm trying to do, like whether it should use UTF-8 or ISO-8859-1 encoding, is simply annoying.

As a developer, I would want to abstract the underlying implementation language away from my users for many reasons, security being one. If there's a security bug found in the current version of PHP, how do you think the hackers are going to target PHP sites? Yep, you guessed it: crawl the web searchhing for URLs with .php or .php4 extensions. Additionally, if later on, requirements change and it turns out that PHP just can't handle the scalability (sorry for the cheapshot, PHP fans), I can always pull the rug and re-implement the whole system using, oh I don't know, Ruby for instance, and do it without breaking any hyperlink that my users may have bookmarked.

Web URLs should be treated as public interfaces, and if you could change the underlying implementation without changing the interface, that would be ideal.