phaqphaq

“a geeks daily life”

Archive for October, 2009

Resurrecting Insignia SoftWindows95 for SGI IRIX

Tuesday, October 20th, 2009

Well, well, I just feel like 14 years ago, playing around with my rather aged SGI O2, which I didnt touch for years, doing a fresh reinstall of IRIX and some apps.

While flipping through my CDs I stumbled accross SoftWindows95 for IRIX. I just couldn’t resist and put the flipper in, having the software installed just minutes later, only to see that I didn’t have the license any more :-(

After some searching I found a Usenet article with a valid license of SoftWindows95. Well, I think it’s fair enough to republish this, as for one, Insignia has sold-off SoftWindows about 10 years ago, and the successor company FWB Software stopped development in 2001, furthermore that company doesn’t exist anymore as it has been sold-off, too. Well, not even SGI is able to provide a license key for a software, which is 14 years old … hm…. Well, I _think_ it’s ok, otherwise let me know …

To activate SoftWindows95 just place this text into /usr/lib/SoftWindows95/FLEXlm/license.dat:

FEATURE Insignia_SoftWindows95 insignia 4.000 01-jan-0 0 \
ECE41259D5BE4700DC27 VENDOR_STRING=”5100 0100 0000 0001″ \
HOSTID=ANY vendor_info=SOFTWINDOWS95 ISSUER=”Silicon Graphics, \
Inc.”

The license won’t show up from the GUI _but_ SoftWindows95 will work.

Considering the age of the O2 and it’s dated 200 MHz MIPS CPU the emulation speed isnt’t too bad.
I remembered it being worse than thaz, but maybe that’s just the “geekness” of having gotten something very old to work again ;-)

SoftWindows95onIRIX

Recognize invalid/unexpected characters with Perl

Tuesday, October 20th, 2009

Today a colleague of mine faced a very weird problem.
While parsing XML output from an HP ILO into Perl, his code constantly broke with the message:

FILE.XML:123 parser error : PCDATA invalid Char value 1

While the message itself states clearly that there is an unexpected character value (Char value 1, ASCII SOH) on one hand, it doesn’t tell the character position on the other.

Looking at the input string itself on the console, it wasn’t obvious either:

<EVENT SEVERITY=”Caution” LAST_UPDATE=”08/03/2009 22:20″ INITIAL_UPDATE=”08/03/2009 22:20″ COUNT=”1″ DESCRIPTION=”POST Error: ” />

So I proposed to add some lines to help identify the character position on the given input string, which was basically this:

@array = unpack(”C*”, $_my_input_var);
foreach (@array) {
printf(”char \”%s\” is ord %s\n”, chr($_), $_);
}

This led to the following output:

char “<" is ord 60
char "E" is ord 69
char "V" is ord 86
--- some output omitted ---
char ":" is ord 58
char " " is ord 32
char "" is ord 1
char """ is ord 34
char " " is ord 32
char "/" is ord 47
char ">” is ord 62

So looking at this we saw that ASCII char 1 (which is an unprintable character, it will be represented as ^A in some editors like vi) was the fifth character before the end of the string.

Well, basically the solution to this is to apply an additional input filter to remove ASCII char 1 like this:

$_my_input_var =~ s/\x01//g;

While this solves just _this_ problem, a more solid solution is to remove all non-printable characters as well, given the list of ASCII characters at http://www.asciitable.com/.

So a filter like this may apply, removing all non-printable characters, leaving just a few control characters 1×08 to 1×1F (Tab, Carriage Return, Line Feed and a few others) and the printable characters in it.

$_my_input_var =~ s/[\x00-\x08\x0B-\x1F\x7F-\xFF]//g;