The Windows Perl Blog

Картинииконитрапезни масиRecently I have been using ASP.NET on our servers to manage internal processes. As part of this effort I needed to chart out certain process values. To accomodate this
I decided to use Microsoft’s charting controls.

These controls are pretty nice. They offer nearly the same charting options as you would expect from Excel; it is pretty rich in functionality. After a quick
wiring in the control in a web page and installing the control on our server it was up and running. Very fast; very cool.

However, our Macintosh computers could not display the chart in the Safari browser. They would render the page correctly but would display the graphic chart.
Annoyed by this I researched and found that others were having similar problems.

To avoid boring you with the long and drawn out story this is what worked for our setup:

The fixes were in the web.config file:
1) We decided to use session based image processing:
<appSettings>
    <add key="ChartImageHandler" value="storage=session;timeout=20;" />
    ...other stuff...
</appSettings>

2) We use postbacks for a variety of reasons on our web pages. Apparently the default installation of the charting controls do not bind ot the POST
verb. This needs to be changed:

Recently I have been working on some iPhone applications. I have strong opinions on the process of developing in the XCode environment, using Interface Builder, the poor development Mac tools and the general coding pain I have been going through, but that is a post for another day. What I wanted to focus on here is a problem I just resolved with the UITableViewController class.

For those not familiar with Mac’s Cocoa programming, a standard way of displaying lists of information is to use the ubiquitous UITableViewController class. It is a controller class provides support for displaying data in a table. It seems pretty straight forward, but alas, it has its pitfalls.

The UITableViewController class allows you to add items and (optionally) sections to the table. For example if you wanted to add the names of your friends, you could add them one at a time. You would then have a 0 based index of your friends. And if you wanted to group them (let’s say into male and female) you would have a 0 based index of gender types, each with a 0 based list of friend names.

I have been using the Windows Media Center Edition (MCE) for several years and have had great success with it. My home built Home Theater PC (HTPC) was beefy and decked out (for the time). All in all it was nice. Then came our plasma HDTV which changed everything. I had to upgrade from 2 internal video capture cards to use 2 Comcast HD set top boxes. But to get HD out of it I had to use 1394, bubble gum and baling wire. It was as hacky as it got, but it worked — usually.

Several years later I finally broke down and purchased a Vista MCE. It’s a very nice Velocity Micro box and decked out with 2 internal cablecard tuners and a beefy video card. Again, it is very nice. Very nice, until I tried using my XBox 360 as a Media Extender.Long ago I purchased a Linksys media center extender so that I could watch news, movies and, of course, Law & Order while on the elliptical machine. The problem was that once we started recording HD I was screwed. The Linksys not only could not handle the bandwidth required for HD over its wireless network, but the machine itself couldn’t handle it even if it was wired directly with a cat 5 cable. Sad, very, very sad.

This is not really a Win32 Perl related blog entry, but a problem that my team recently experienced. I am adding this to our blog site with the hope that someone else experiencing the same problem may find it useful and (hopefully) save them some time troubleshooting.

Recently I ran into quite the system administrator emergency. Our Active Directory network started acting flaky. How odd it was that our servers were unable to talk with each other. Client machines were not able to boot onto the network. Attempts to access resources were confronted with ungodly long blocking wait times only to eventually fail.

Applications and services that normally execute flawlessly were suddenly cast into a bottomless pit of error massages such as:

There are currently no logon servers available to service the logon request

and

The system detected a possible attempt to compromise security. Please ensure that you can contact the server that authenticated you.

Of course the big question was why were there no logon servers available and why was there an attempt to compromise security? Needless to say it took several hours until my team could locate the root cause of the problem. Of course finding the cause is one thing, fixing it and understanding how the problem occurred is another.

Today I was debugging a problem with a script I was writing when I stumbled upon an interesting problem. The script takes data from my clipboard, processes it, formats an HTML report then creates an Outlook email message which it inserts the formatted report and sends it out to a list of recipients.

The script did everything that it should but ran into a problem when it called into the Outlook object model using COM. The standard way to instantiate a COM object is to first attempt to connect with Outlook if it is already running, otherwise run Outlook specifically for the sake of the script:

use Win32::OLE;
my $Class = "Outlook.Application";
my $Outlook = Win32::OLE->GetActiveObject( $Class ) || new Win32::OLE( $Class );
die if ! defined( $Outlook );

This is exactly where my script was failing. The calls into Win32::OLE would pause for several seconds but always return undef. How odd. Calling into Win32::OLE->LastError() to determine the error yielded an equally confusing error message:

0x80080005: "Server execution failed"

Of course there was no easy way to learn why the COM server execution had failed. Needless to say, after tinkering around a bit I discovered that if I first quit Outlook the script executed perfectly. It was only if I was running Outlook that the script failed. How odd.

So this entry isn’t about Perl but it is about a distant cousin, PHP, and the WordPress blogging software (v2.1+) spell checking bug that results in the notorious message:

Could not execute AJAX call, server didn’t return valid a XML

First let me start by saying that WordPress is a tremendous piece of software. I only have good things to say about it. Now that that is out of the way…

In WordPress v2.1+ there is a WYSIWYG option for writing posts, pages and comments. It isn’t full featured, but it is easy to use and provides the basics. It even includes a spell checker (which I am using as I write this). It is this spell checker that is causing so many people problems. When many people try to use the spell checker they receive the error message cited above. WordPress.org has a thread on this: http://wordpress.org/support/topic/101689

Having run into the same problem I decided to spend a couple of hours tracking down the problem and I can say that I have fixed it (on my system at least). My platform is running Windows Server 2003 with IIS and WordPress v2.2. I have patched my system and spell checker is working like a champ.

Along with Vista’s UAC security infrastructure Microsoft implemented something very clever, but has caused administrators and Perl coders frustration: User File and Registry Virtualization.

The concept of UAC (http://www.roth.net/blog/index.php/2007/04/02/vista-and-user-account-control-uac/)  is useful since it places finer control over what non-administrators can and cannot do. One of the core tenets of UAC is that a non-administrator should not be able to make changes that impact other users. For example if I make changes to an application’s settings they should only impact me, not other users of the computer. To accommodate this non-administrative access Vista virtualizes access by creating an alternate location for files and registry keys. The OS tries very hard to make this seamless so when an application tries to access a file or registry key it is redirected to the user’s virtual storage area.

In general this virtualization works, however for technical folk who want to access files directly they may be surprised to find the files are “missing”. Let say, for example, you want to manually edit an application’s configuration file. If the application was installed in the “Program Files” directory you may expect to find the file at C:\Program Files\MyApp\MyApp.cfg. But the file is really located in the path C:\Users\userID\AppData\Local\VirtualStore\Program Files\MyApp\MyApp.cfg.

Say what you will about Windows Vista but don’t think that it isn’t a big deal. Regardless of how you may feel about Microsoft, they put a lot of work into the Vista operating system. Sure the UI may not be as snazzy as Apple’s OS X and it is barren of some features from the promised land like WinFS. But there is an awful lot under the hood. Yes it is true that a Vista box really should have a recently upgraded machine to afford the resource costs the OS takes. But if you can afford the machine that runs the OS well rest assured that there are changes worth having. The problem that Microsoft faces is that these changes are not easy to quantify for the average consumer. How would you explain to your Mother about the benefits of the new media APIs? Or try convincing your boss to upgrade the entire IT department so that your machines could leverage PnP-X and Function Discovery. No, the innovations that underline the OS are not obvious to the layman. However there is one exception: security. 

Among the various annoying aspects of running x64 versions of Windows (XP or Vista) is that the registry is split into two sections: x64 and x86. When 64 bit applications access the registry they do so directly, as you would expect. However if a 32 bit application access the registry it is mapped into a special 32 bit section.

Scripts that interact directly with the registry may yield unexpected results if you are running a 32 bit version of PERL.EXE on a 64 bit version of the operating system. More details can be found in Microsoft’s KB article 896459: http://support.microsoft.com/kb/896459

For those not following Seattle news, we had the biggest wind storm since 1993–most argue it was stronger than that. Winds were clocked up to 90 MPH. Needless to say it knocked over trees and power line poles. Over 750,000 people were left in the dark for several days.

The Roth Consulting labs were offline 6 days. During this time the forum, blog, web, ftp and email services were down. We apologize for the inconvenience, but just like code, life has bugs.