Monthly Archives: March 2008

64-bit, geek-out, hardware, microsoft

Vista… 64-bit… Where’s My Headroom?

1 Comment

Other than a couple of virtual machine beta builds, I had managed to stay out of Vista entirely until the last month or so. Since then I’ve tried to install on three machines–a client’s Dell Optiplex, which never was able to boot after install, and two home-built systems. This weekend I built a brand new system out of all Vista-logo components. It booted; Vista reported the hardware compatible; it even got a 5.8 experience index score. But I had continuous crashing of both IE and Windows Explorer. Also, on what should have been basically the fastest hardware available, the Vista with SP1 install took over 90 minutes.

I’m walking away. My current approach for my development machine is going to be Windows Server 2008 Standard 64-bit. Again I have certified components, but 64-bit in itself represents a struggle in terms of driver and application compatibility. We’ve had 64-bit CPUs in our machines for going on 5 years, and 64-bit Windows options for almost as long, and yet you still cannot run common programs and drivers in the environment–Flash, TWAIN, most VPN software, the list of things you can’t do (or do well) is astoundingly comprehensive.

We’re heading toward a very real wall here: 32-bit versions of Vista (as with other flavors of Windows) are limited to 4GB of RAM. Yet that is simply not enough for Vista plus any serious suite of applications. At the same time, 64-bit Windows still isn’t a truly viable desktop for most users. Out of necessity, I’ll compromise on many fronts–multimedia capability, peripheral compatibility, native software availability–but some of this stuff isn’t easily virtualizable, so I’m looking at the possibility of having to keep 32-bit systems around (for example for scanning, connecting to client VPNs, etc.). I’m really starting to feel hemmed in.

I guess I could take a step back here and look at it from the Mac perspective. It works because it’s broken; it’s broken because it works. That is, by forcing a switch to 64-bit Server I’m pruning the 16- and 32-bit dead wood that’s keeping me in the 4-gigabyte sandbox. Apple users long ago embraced obsolescence as a feature. Vista and 64-bit computing may (finally) force the Windows side of the PC world to wake up to this. Or maybe not. There’s a downside to the Mac example: “performance” in an absolute sense is to some extent irrelevant, and scaling up doesn’t necessarily have to be as smooth or cheap as we’re used to, as long as the chrome is shiny and doesn’t peel off too obviously.

This issue bears similarities to the current Internet Explorer 8 web standards argument–do we break the web (force IE8 standards mode, cripple billions of web pages) to move toward the Platonic ideal of standards? Do we break the PC ecosystem (Vista, 64-bit) for the hope of increased functionality and capacity in the next generation of platforms (available today, but considered unusable by the consumer)? You know it’s a tough question when even Joel Spolsky can’t tell you the answer. But generally, culturally, we’re not long-term investors, certainly not when the benefits are nebulous and far off and the pain points are obvious and immediate. As Joel argues, for web standards under IE this is a late-bound issue–they can throw the switch any time to go back to a more relaxed mode. But the issue of Vista running out of memory and 64-bit versions not being ready for prime time is a lot harder to resolve.

code, psa, short

G-Archiver and the Risks of Random Downloading

Leave a comment

This is a pretty amazing story about a free utility with a malicious back-end twist.

This is so bad that I assumed it was a hoax. However, I downloaded the program, installed it (on a virtual machine), decompiled it, and verified that it is, in fact, “phoning home” with your gmail user name and password. Yikes.

The manufacturer’s page has been updated to indicate that this “was in no way intentional,” but does it really matter?

code, geek-out, microsoft, web-x.0

Dynamically Adding Option Elements to Select Objects… The Real Story

2 Comments

I don’t normally blog about pure code subjects, so this is going to be way too technical/boring for the general readership of this blog. However, I wasn’t able to find the definitive answer to this question after searching around with Google, so I figured I’d contribute a little. This is also a wiki-style reminder to myself the next time I need to do this.

Mostly you’ll be interested in this post if you’re trying to programmatically add options to a select list using JavaScript. Of all the ways to do this, there are a few that work and many that don’t. The catch seems to be that IE is picky about how and when the data “inside” the option tag (the visible text in the option list) is set. According to the documentation there should be any number of ways to set this–.text, .innerHTML, .innerText. Of those, the only one that seems to be broadly compatible is .text. .innerText is IE-only, so it’s right out. .innerHTML is valid across platforms, but it messes with the object model in IE6 and IE7 (and IE8 beta 1, now that I look) in such a way that if you use it, you have to add the option element to the select element before setting the .innerHTML property. See below for a breakdown of the methods, plus test code. Blogger might break this, so be sure to look at the plain test page (“view source” is going to be a lot friendlier on that page as well).

In any case, here’s the take-away when adding options to select elements:

  • Always use the .text property of the newly-created option object to set the visible text for the option.

  • As a precaution, add the new option object to the select object’s options collection before setting other properties of the option.

create option, set .value, set .text, add to options list (generally compatible)


function createSetTextAddOption(selectEl,val,displayText) {
 var o = document.createElement("OPTION");
 o.value = val;
 o.text = displayText;
 selectEl.options.add(o);
 return false;
}


create option, set .value, set .innerHTML, add to options list (fails IE6, IE7, IE8-‘invalid argument’)


function createSetInnerHTMLAddOption(selectEl,val,displayText) {
 var o = document.createElement("OPTION");
 o.value = val;
 o.innerHTML = displayText;
 selectEl.options.add(o);
 return false;
}


create option, add option to list, set .value, set .innerHTML (generally compatible)


function createAddOptionSetInnerHTML(selectEl,val,displayText) {
 var o = document.createElement("OPTION");
 o.value = val;
 selectEl.options.add(o);
 o.innerHTML = displayText;
 return false;
}


create option, add option to list, set .value, set .text (generally compatible)


function createAddOptionSetText(selectEl,val,displayText) {
 var o = document.createElement("OPTION");
 o.value = val;
 selectEl.options.add(o);
 o.text = displayText;
 return false;
}


Attempt to add new options/selects inline (option 2 and select 2 fail in IE, either silently or with the “invalid argument” error)

According to the Microsoft documentation, this shouldn’t work at all. Here’s what they say about the option.add() method:

This method can be used to add elements only after the page loads.

If the method is applied inline, a run-time error occurs.

And yet, it mostly does work, aside from the innerHTML limitation…


// generally compatible inline adds
createSetTextAddOption(document.getElementById('sel5'),'1','added value 1');
createAddOptionSetInnerHTML(document.getElementById('sel5'),'3','added value 3');
createAddOptionSetText(document.getElementById('sel5'),'4','added value 4');
   
addNewSelect(document.getElementById('sel5'),'1','added value 1',createSetTextAddOption);
addNewSelect(document.getElementById('sel5'),'1','added value 3',createAddOptionSetInnerHTML);
addNewSelect(document.getElementById('sel5'),'1','added value 4',createAddOptionSetText);

// these two fail in IE6, IE7, IE8
createSetInnerHTMLAddOption(document.getElementById('sel5'),'2','added value 2');
addNewSelect(document.getElementById('sel5'),'1','added value 2',createSetInnerHTMLAddOption);

Again, I encourage you to view the plain test page to avoid any Blogger-induced weirdness.