Stupid BHP trick

BHP = Bozo Helpdesk Personnel

I had a problem with an install proggie the other day from Sun, so I fired off an email to their support team, making quite clear (IMO) that I'd worked around it and didn't need support; just an FYI. My note:

Hello,

I'm installing J2EE 1.2.1 (on J2SE 1.4.0) on a Windows NT 4.0 SP6 box. The
J2SE installed quickly and easily, but the J2EE does not. It unpacks the
setup program into C:\\temp\\pftB84B~tmp\\disk1\\ (as an example, the actual
directory name changes) and then shows an error dialog box saying that it
could not execute the setup.exe file in that directory.

I worked around the problem by leaving that dialog box on-screen (so the
temp directory is not erased when the loader closes), then renamed the setup
directory as C:\\temp\\pft\\disk1\\ (I took out the ~ and shortened it), then
ran setup.exe from Windows Explorer, and it installed perfectly. So *I*
don't need a fix at this point, but others might.

Thought I'd let you know. Thanks for all your hard work on J2EE!

Robert Brewer
MIS

Their reply:

Have you tried J2EE 1.3.1?

Tony

Bah. That'll teach me to act personably toward a megalith like Sun.

The problem you're describing sounds a lot like an insidious problem we had at a customer site that burned-up hours of troubleshooting time.

Most of the machines at this site had an enforced policy that disabled the automatic generation of 8.3 filenames. Various installation programs (including the one for the JRE) would fail because the path to the temporary set-up directory would include filenames that exceeded 8.3. I think the SETUP.EXE (or .COM) file is an older, 16-bit version.

This sounds as if it should not be a problem with such a simple work-around available, but there was a not-directly-related something else: As part of an IE update, the "Updating User Settings" part (the stuff each account gets on log-in following an IE upgrade) was silently failing on the registration of a Microsoft DLL whose name exceeded 8.3 (I think its name was 9 chars long). REGSVR32.EXE could not handle the DLL's filename. This failure resulted in broken ActiveX. Broken ActiveX resulted in bizarre and seemingly unrelated errors here and there. There was no discernable pattern to these errors, but they were consistent (something really odd for Windows): Certain dialogs failed to display, certain application screens would not display, etc. Each failure was reproducible.

The fix we found was to enable the 8.3 filename generation (a registry entry) and then to register the DLL by hand. I'm sorry I cannot remember more of the details about this or about how we got to the solution.

I think you can quickly test for this condition if you can get COMMAND.COM running (not CMD.EXE) and try to EDIT a file with too long a name. Or maybe a straight DIR will tell you right-off. The 8.3 names should appear somewhere in the DIR list done from COMMAND.COM (you know, the ones with the '~1' in them).

It turned-out that the 8.3 stuff was turned-off in the policy because somebody had identified it as a security exposure--probably some PHB ;-). The customer was not interested in wasting more time on pinpointing why this happened in the first place.

Welcome to IWETHEY!