Office 2003 Bug Locks Owners Out

I Don't Believe in Imaginary Property writes "A Microsoft Office 2003 bug is locking people out of their own files, specifically those protected with Microsoft's Rights Management Service. Microsoft has a TechNet bulletin on the issue with a fix. It looks like they screwed up and let a certificate expire. There's no information on when the replacement certificate will expire, though, or what will happen when it does."

Comments

Screw Up Or Forced Upgrade?

[Afforess]

I know a LOT of people still using MS Office 2003. Some people dislike the Ribbon System with '07's version. Some people are too cheap to upgrade when the old copy still "works". Now, Microsoft isn't making any money from all those old copies of 2003, so what's stop them from "Programming Obsolescence" into their software?

It sounds a bit sinister, yes; but it's not technically illegal. It might even be in the oft-skimmed EULA. Or maybe it's just similar to the way HP printers always fail a week after the warranty expires.

Re:Screw Up Or Forced Upgrade?

[ozmanjusri]

What did I do today? Well, I didn't like the ribbon bar in the new OpenOffice, so I forked the project.

Wow, that's crazy. Why did you bother going to all that trouble when IBM's already done it for you?

If you don't like Symphony, there's plenty more choices. That's the great thing about being open and having competition, right?

Re:Screw Up Or Forced Upgrade?

[the_womble]

I like Gnumeric too.

Abiword is a good lightweight word-processor, but not as feature rich as OpenOffice.

What exactly is your problem with Latex? If the learning curve is too much, you use Lyx.

Re:Unexpected error?

[AlgorithMan]

this is simple. Error handling basically works like this

try {
command1
command2
command3
}
catch(DiskFullError E) {
messagebox("not enough free disk space\n"+E.ExtendedInformations()); // this is an expected error
}
catch(NoWritePermissionError E) {
messagebox("you don\'t have write permission in that directory\n"+E.ExtendedInformations()); // this is an expected error
}
catch(DirDoesntExistError E) {
messagebox("the directory you chose doesn\'t exist\n"+E.ExtendedInfo()); // this is an expected error
}
catch(...) {
messagebox("an unexpected error occured"); // this is where the unexpected errors are handled
}

you try to do some stuff and if something goes bad, the codes throw an exception, which can be caught by the error-handlers. and if there is no error handler for the error, then this is an unexpected error. this would crash the program, unless you do catch(...), which can also catch unknown exception types
well, in redmond it goes more like this (see MSDN)

if(!command1) {
switch(ERRNO) {
case 1: messagebox("Error code 1, contact your vendor"); break;
case 2: messagebox("Error code 2"); break;
default: messagebox("unexpected error");
}
}else {
if(!command2) {
switch(ERRNO) {
case 2: messagebox("Error code 2"); break;
case 3: messagebox("Error code 3, press F1 to see some useless hexadecimal bytes"); break;
default: messagebox("unexpected error");
}
} else {
if(!command3) {
switch(ERRNO){
case 1: messagebox("Error code 1, contact your vendor"); break;
case 4: messagebox("Error code 4, why don\'t you switch to linux?"); break;
default: messagebox("unexpected error");
}
} else {
// wohoo, nothing went bad!
}
}
}

if something goes bad, a global variable (ERRNO) is set to some error code and the functions return false. the default case takes all the values of ERRNO, that are not handled explicitly Yes, this is prehistoric and non-thread-safe error handling, but what do you expect from the masters of disaster?