IE6 is hanging around

When I gave this site a face-lift recently, I used some CSS2 features which were not present in IE until IE7 (E1 + E2 selectors and the min-height property). So I analyzed the access logs to see how many visitors are using IE6. I was surprised to find that most IE users are still on IE6.

At the start of this year, Microsoft used Windows Update to distribute IE7, so many Windows users were upgraded automatically. And indeed, my access logs showed that (IE 7 users)/(IE users) went from nothing to almost one third in a month. But since then, it has stayed at about a third, with only a very slight upwards trend. Most of my visitors arrive here on Google searches rather than being regular readers, so I don't think my sample is hugely biased. My results are also roughly consistent with those available with the many browser surveys out there (example), suggesting that it will be a long time before IE7 overtakes IE6.

In order to accommodate IE6 users, I have used IE's conditional comments feature to deliver an additional stylesheet to IE6 which makes the appearance of the site mostly consistent with that in more standards-compliant browsers.

I still wonder why IE6 is still so dominant. Some IE6 users must be those at large corporations with IT departments that have opted to stick with IE6 until all their internal apps have been verified with IE7. There will also be some small number of non-corporate users who go to the effort of unselecting the IE7 update in Windows Update. But I suspect that the biggest factor is users of unlicensed copies of Windows who are locked out of Windows Update.

Update (2007-09-23): I didn't include precise figures in this post, because the modest number of hits this site gets means that the numbers are probably not very robust. But an anonymous commenter suggested that maybe Windows 2000 was a factor, since IE7 is not available for Windows versions prior to XP. So here is a table showing the breakdown of the IE version together with the Windows version, from my access logs for July, August and September so far:

58.93%MSIE 6.0Windows NT 5.1 (XP)
28.41%MSIE 7.0Windows NT 5.1 (XP)
6.40%MSIE 7.0Windows NT 6.0 (Vista)
3.08%MSIE 6.0Windows NT 5.0 (2000)
2.16%MSIE 6.0Windows NT 5.2 (Server 2003)
0.49%MSIE 6.0Windows 98
0.29%MSIE 7.0Windows NT 5.2 (Server 2003)
0.11%MSIE 5.5Windows NT 5.0 (2000)

4 comments

Building 32-bit/i386 binaries on x86-64 Fedora

x86-64 Linux distributions have adopted different approaches to handling compatibility with 32-bit i386 binaries, depending on whether seamless compatibility or support for a pure 64-bit installation was the priority. Fedora falls on the seamless compatibility side. This means that you can install binaries built for Fedora i386 onto a Fedora x86-64 system, and they generally just work. What seems to be less well known is that you can easily build for i386 on a Fedora x86-64 system. I had to search around a bit to find the necessary option. But once you know the secret, it is very straightforward.

Why would you want to build for i386 on an x86-64 system? My motivation was developing software that I wanted to build and test for both platforms, without having to run two development machines. Another potential reason is the slight performance advantage that some applications enjoy on i386 (pointers are 32-bits, so some data structures are smaller, so processor caches are more effective).

The trick is the -m32 flag to gcc:

$ cat >hello.c
#include <stdio.h>

int main(void)
{
        printf("Hello, world!\n");
        return 0;
}
$ gcc -m32 hello.c -o hello
$ file ./hello
./hello: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically l
inked (uses shared libs), for GNU/Linux 2.6.9, not stripped
$ ./hello 
Hello, world!

It can also be used when building a package with a autoconf configure script or similar. This worked for FreeCiv:

$ CFLAGS="-m32" ./configure

Fedora usually installs both the 32-bit and 64-bit versions of each library package, including the -devel packages. There are some exceptions: My system had cairo-devel.x86-64, but not cairo-devel.i386. But such things are easy to fix.

0 comments