February 2004 - Posts

• Google Spam

  Is Google an infallible power? Over the past few weeks, I've noticed that some of my Google searches are returning results from spammers.  This has probably been a problem for awhile, but I'm now noticing a sharp increase. For the previous blog post, I wanted to provide a link to a shareware utility for filling up disk space.  I put in "diskhog shareware" as the search. The third result of the set was listed as "diskhog for nt server", but what was stunning was the URL provided: www.coulterroadbaptist.org/teen-non-nude-bikini.htm Now, I doubt that organized religion has gotten involved with internet porn.  Sure enough, choosing that link brought me to a page that contains a couple of links to other search engines.  Ugh.  Looking at the source code for the page, a lot of effort is made to fool the user and record information.  The user agent string is captured, along with the original Google search terms.  When a link is hovered over, the status shows a fake address.  What crap. Google spam is nothing new, but the success that Google has had is will be lost if the present state of affairs continues. FYI, here is the real Coulter Road Baptist church. Posted Feb 06 2004, 04:45 PM by ChuckOp with no comments Filed under: Rants

• Is rebooting a cure all?

  I hate rebooting.  Most people do.  All too often though, it's the only way to get running again.  Think it's a problem only to Microsoft Windows?  Imagine having to do 130 reboots before you could get working again. That’s what NASA’s Mars rover Spirit had to do when it ran out of memory on January 21, 2003.  Is Spirit running on Windows?  No, it’s running VxWorks from Wind River. In the case of Spirit, the problem was due to 289MB of flash memory being filled up, causing various faults with the software.  The software attempted to resolve the problem by rebooting the on-board computer.  But that didn’t fix the underlying problem and eventually the system would again reboot.  The window of opportunity to communicate with the rover, along with the extreme slowness of the connection (11KBps on a good day) meant that it wasn’t “cured” until February 6, 2003. I’ve long been interested in software for spacecraft.  It stems from building a SuperElf computer back in 1980 and using it in various science fair projects.  The Super Elf was based on the RCA 1802 COSMAC microprocessor and flew as the brains of many spacecraft, including Voyager I and II.  The 1802 processor was made using a CMOS technology that made it naturally hardened against radiation in space, but terribly slow by microprocessor standards today. Another side interest of mine is software failures.  Software engineering isn’t the same type of discipline that say, Civil Engineering is.  Anyone can claim to be a programmer, and the relative infancy of the field ensures that many will try. I wrote a side-bar in my first book about a famous software failure on January 15, 1990 that resulted in much of AT&T’s toll-free network being inoperable for several hours.  The cause of this failure was due to a misplaced C-language break statement when the software for the 4ESS switching machines was being updated.  That programming flaw would corrupt data if two calls were received within 1/100th of a second. The software was designed to handle corrupted data – by rebooting.  When restarted, the switch would announce to all the other switches in the network that it was once again available.  Each switch kept track of available switches, and when it got the okay from the rebooted switch, it would have to spend a little time updating its status map.  Thus, it was more likely to get hit at the same time with two or more calls to be processed.  It only took 4 seconds to reboot, so the 4ESS switches were going down, coming back up and overloading the rest of the network.  Thus the cascade began, and as more and more switches went down, and came back up, the greater the problem spread through out the system.  It only took 10 minutes to bring down the entire network. Most software failures are a result of unintended effects.  It’s usually a set of unknown conditions, so the lowest form of repair kicks in – start over from scratch. This brings me back to the Spirit rover.  According to Glenn Reeves, flight software architect at NASA’s Jet Propulsion Laboratory, the flash memory on Spirit became an “incredibly full file system that now contains more information than we ever thought it would.”  That begs a couple of questions that I haven’t seen addressed yet:  How come the memory filled up so quickly?  The rover was only on the surface for a few days.  Presumably it collects data, stores it, and downloads it to Earth.  Secondly, why can’t the system recovery sensibly from what is essentially a “disk full” error. I know that software testers like to use tools to artificially fill up memory in order to see how the software reacts.  I can’t imagine that this kind of testing wasn’t done for the Mars rovers. Now, I’m sure there is plenty of detail here I’m not aware of, and I’m not passing judgment on the quality of someone else’s code.   The rover software is amazing in that it has a lot of redundancy built-in and can update itself with software sent from millions of miles away.  I’d like to know some more of those details. Posted Feb 06 2004, 04:13 PM by ChuckOp with 2 comment(s) Filed under: Programming

• Programming Directory Services with Microsoft .NET and XML

  As many of you know, I wrote a popular developers book on Active Directory for Microsoft Press titled Microsoft Windows 2000 Active Directory Programming.  When it was published in April 2001, I pleaded with Microsoft Press to not put “Windows 2000” into the title of the book, as it would seem obsolete when the next version of the Windows Server came out. In June of 2002, I was approached by the Directory Services documentation team and contracted to write the follow up book, focusing on the .NET platform and DSML.  At the time, I was in the process of managing the Flight Across America, so authoring didn't start until November 2002.  Working as a vendor to Microsoft - as opposed to a independent author - was challenging and unique.  The "NetDS" folks are great and have made huge strides improving the developer documentation for Windows directory services. Progress was slow the first half of 2003 due to a series of set-backs.  I traveled often to be with my father who had taken ill in January.  On May 23, he passed on.  In June, my mother developed lung cancer and I eventually brought her out to the Pacific Northwest in August to live with me and help me manage her care. With two-thirds of the book complete, Microsoft Press reevaluated the potential sales and decided against publication.  The window of opportunity was closing and the book was looking like it wouldn't hit stores until the end of the year.  Like the rest of the industry, MSP is under serious pressure to produce revenue and is focusing on sure-fire titles.  I can't blame them for canceling publication.  At least I got paid for each finished chapter, not like many of the WROX authors who didn't receive anything for their efforts. The work I completed is owned by Microsoft and I'm told that it may make it into doc set in the form of white papers or such.  I hope so, because I believe that there is lack of good programming texts on Active Directory.  While there are some excellent titles by good authors, too often they focus on a particular programming language or don't take into account the latest technology. I liked writing programming books, although it was slow going.  Crafting words and arranging thoughts into actionable sentences is a rewarding challenge.  Writing the sample code was equally as fun.  I'm sure I'll do more authoring in the future. I have dozens of source code samples, most written in C# that demonstrate the classes of the System.DirectoryServices namespace.  If there is interest, I'll figure out a way to put them on-line.  Contact me. Posted Feb 03 2004, 12:55 PM by ChuckOp with 5 comment(s) Filed under: Microsoft, Programming, Personal, Directory Services

• History of keyboard access in Windows

  This is a response to a posting on the Windows Off-Topic Tech mailing list concerning keyboard access to the taskbar... If you go back in time far enough, it doesn't.  When the NT4 team first had the 95 shell forced on them, keyboard access to the systray was a detail that fell through the cracks... I forget how many SPs it took for them to get that fixed. This was part of the infamous stress between the Win95-era shell team and the NT team...  NT has always had a higher bar for accessibility, as part of reliability (thinking: if your user accidentally cuts his mouse cable, he'd still better have a way to shut down the nuclear reactor, or whatever). In terms of functionality, Windows NT 4.0 shipped essentially the same shell as Windows 95, albeit with changes to support NT features and security infrastructure.  The only keyboard access to the notification icons in NT4 was via the MouseKeys feature which emulated a mouse pointer. The real shell changes occurred in "Nashville" which started out as the next version of Windows 95, but became part of IE4 that was called "Windows Desktop Update."  This was a re-write of the much of the shell, introducing Coolbars and Active Desktop. The Windows Desktop Update was part of Windows 98 and eventually Windows 2000. The reason Windows has good keyboard access is two-fold.  First, when Windows came out in 1986, mice were rare on PC's.  Apple shipped a mouse with the Macintosh, but you couldn't depend on the PC having one.  Thus, Windows 1.0 was fully keyboard accessible. Secondly, in the early 1990's, people inside and outside of Microsoft were recognizing the importance of keyboard access in a GUI world for people with physical and sensory disabilities.  As a corporate leader, Microsoft was expected to set standards and set an example for accessibility.  One of the Windows 3.x and Cairo Program Managers, Greg Lowney, started working on disability access fulltime and others, including myself, joined in shortly afterwards.  This was the beginning of what's now called the Accessible Technology Group. I wouldn't characterize NT as having "a higher bar for accessibility" necessarily.  After all a keyboard is more prone to failure than a mouse IMHO. However, Windows NT/2000/XP is sold in large quantities to organizations that often demand accessibility for people with disabilities.  In the United States, the Federal Government mandates that software purposed by the government be accessible.  That ensures effort is put into accessibility in various forms when it would be easier for software companies to drop it. Of course, there are many good reasons to provide accessibility in software - not to mention it's the right thing to do.  Just today, Microsoft announced broad plans to help employers with an aging workforce benefit from the accessibility features in Windows.  After all, do you know anyone over 55 years old who can read default fonts at 1280 x 1024?  Aging is a disability we will all acquire. Posted Feb 02 2004, 08:07 PM by ChuckOp with 1 comment(s) Filed under: Microsoft, Accessibility, UI

• More taskbar/tray keyboard access

  Apparently, the shell team at Microsoft threw in another keyboard shortcut to get focus to the tray notification area.  This is the section of the taskbar that contains the clock and various status icons.  For example, if updates are available on Windows Update, the Volume control (if enabled), and network status. Press WIN+B to place keyboard focus on the first icon in the notification area.  If the “hide inactive icons“ feature is enabled, the first icon might be the left-facing cheveron ( < ) that toggles inactive icons into view. Interestingly, when using WIN+B, no focus rectangle is shown.  Thus, it's difficult to tell where the focus is.  When using the Tab key to focus the taskbar, a small focus rectangle is shown around the selected icon. One way to tell what has keyboard focus is to use the Context Menu key (or SHIFT+F10). Also, when each icon gets focused, the tool tip associated with it appears. WIN+B is undocumented in the standard Windows help.  Thanks to a poster on the Windows Off-Topic Tech mailing list for brining it to my attention. Posted Feb 02 2004, 06:36 PM by ChuckOp with 2 comment(s) Filed under: Microsoft, Tip, UI