Reading Raymond Chen's blog (The Old New Thing) is an eye opener. Now, to be fair, I do not consider myself a programmer. I can program, true enough. But I'm a WTF programmer. Good enough to know that the code I read is pretty bad code, good enough to see how it can be made better, but crappy enough to know that a fair amount of my code will look like WTFs all by themselves. Nevertheless, I can criticise with the best of them, and providing I lurk long enough, can masquerade as a 'native'.
One of the things that come up in his blog (All The Time) is compatibility. Has anyone ever wondered if you can run 16-bit Windows 3.x code in Windows Vista? You can. You can run 16 bit DOS code in Windows Vista as well, should you really, really want to. And when you consider the sheer differences between the design of DOS (which is not really an OS by modern standards - well, a crappy, minimalistic one at any rate) and the design of Windows 16-bit and Windows 32-bit, this can boggle the mind. Some of the stuff Microsoft programmers manage to pull off will both awe and appall you. It's truly miraculous how Windows manages to run, and run reasonably well (as of writing, my uptime in Vista with two browsers (and ~10 tabs in total), 2 P2P programs, various TSRs - well, the Win32 equivalents thereof - an antivirus, a dual-pane file manager and various sundry programs executed and exited is 318 hours or 13 days 6 hours).
In 64bit Vista/XP, however, you can't. That's because the V86 mode (Virtual 8086) which Windows relies on to do 16-bit code cannot be switched to when you run in 64-bit mode. This is slightly beside the point - even moving between Win9x and WinNT code bases, and heading into WinXP, Raymond Chen and the rest of the Windows core teams had lots of fun (read: blood, toil, tears and sweat, not to mention swear words) ensuring that every buggy piece of Windows software managed to run in the next version of Windows - even when these buggy Windows software did stuff they shouldn't.
That's what compatibility means in the computer world. When we say that Jack and Jill are compatible, we usually mean that they were made for each other. But when some IT geek says Jill is Gina-compatible, he's not talking about lesbian soulmates; oh no, what's he's saying is something to the effect that JILL (e.g. Java Identity Login Layer) can masquerade or take the place of GINA (Graphical Identification aNd Authentication). BTW, I don't think JILL actually exists, okay? I just made it up on the spot. So when Jack goes out with Jill, he's actually thinking he's having a date with Gina. And when he's makin' sweet, sweet love to Jill, he's actually crying out "Gina! Gina! Gina!"
Let's face facts: this situation sucks. Because Jack expects Gina-like behaviour, Jill can't act like herself - even if Jill's way, way smarter, and far prettier, and much better in the sack. It would utterly crash Jack to find out that he's not gettin' jiggy with Gina.
A proposed solution from some people is virtualisation. This is where instead of ensuring Jill behaved and acted like Gina, it was like having a copy of Gina's personality (call her schizo-Jill) instead. That way, Jill remains Jill, and Gina's still Gina.
Now, normally people think of virtualisation as actually installing a virtualisation software like Virtual PC or VMWare or something, but wouldn't it be better if instead of virtualising the whole machine, you only virtualised the high-level stuff? After all, Jill's a Woman, and so is Gina. You don't have to fake the hardware bits much, really, just the parts that matter. Strangely enough, Windows could accommodate that sort of behaviour. And why not? The original Windows NT was designed to be as modular as possible. You had the low-level micro-kernel, the HAL (Hardware Abstraction Layer, which provides a single view of hardware regardless of what it was underneath), and then you had the subsystems which rode on top of the low-level OS. Windows NT and its successors (Win2K, WinXP, WinVista, and soon enough, Win7) supported almost every subsystem there ever was. OS/2 (which was the original default subsystem, believe it or not), DOS, Windows 16-bit (otherwise known as Win16), Windows 32-bit (Win32), Windows 64-bit (presumably Win64), and Unix (via the Interix subsystem). In fact, the only major desktop OS subsystem Windows has never implemented (or have implemented by someone else) on the NT platform is the MacOS - and the Mac's running BSD (a Unix) on Intel processors now. So the idea's not as stupid as it sounds.
One problem. When you speak of a subsystem in NT, what you're actually talking about is the API, or Application Programming Interface. This is a contract - if you're programming on Win32 APIs, it pretty much says that "As long as you promise to do ONLY what is documented functionality in these APIs, we guarantee that as long as we implement Win32 APIs, your program will work flawlessly". In theory, of course. In practice, there are a largish number of programs that don't do this. Instead, they peek and poke into internal structures and directly do stuff assuming these structures will never change. In effect, instead of calling Undress(Girlfriend), they look at what the Undress() procedure did, as well as which structures it was manipulating, and proceeded to call Unfasten(Blouse.Buttons); Unzip(Skirt.Zip); Unhook(Bra.MetalClasp); and so on. And then the next version of Undress() did something different like Unzip(Dress.Zip); Eat(EdibleBra) and the program blew up because it didn't expect that. And yet, both procedures are Undress(). And it is the same Win32 API you're talking about.
Is there a proper solution? I don't know. But it's surely interesting trying to find out :)
One of the things that come up in his blog (All The Time) is compatibility. Has anyone ever wondered if you can run 16-bit Windows 3.x code in Windows Vista? You can. You can run 16 bit DOS code in Windows Vista as well, should you really, really want to. And when you consider the sheer differences between the design of DOS (which is not really an OS by modern standards - well, a crappy, minimalistic one at any rate) and the design of Windows 16-bit and Windows 32-bit, this can boggle the mind. Some of the stuff Microsoft programmers manage to pull off will both awe and appall you. It's truly miraculous how Windows manages to run, and run reasonably well (as of writing, my uptime in Vista with two browsers (and ~10 tabs in total), 2 P2P programs, various TSRs - well, the Win32 equivalents thereof - an antivirus, a dual-pane file manager and various sundry programs executed and exited is 318 hours or 13 days 6 hours).
In 64bit Vista/XP, however, you can't. That's because the V86 mode (Virtual 8086) which Windows relies on to do 16-bit code cannot be switched to when you run in 64-bit mode. This is slightly beside the point - even moving between Win9x and WinNT code bases, and heading into WinXP, Raymond Chen and the rest of the Windows core teams had lots of fun (read: blood, toil, tears and sweat, not to mention swear words) ensuring that every buggy piece of Windows software managed to run in the next version of Windows - even when these buggy Windows software did stuff they shouldn't.
That's what compatibility means in the computer world. When we say that Jack and Jill are compatible, we usually mean that they were made for each other. But when some IT geek says Jill is Gina-compatible, he's not talking about lesbian soulmates; oh no, what's he's saying is something to the effect that JILL (e.g. Java Identity Login Layer) can masquerade or take the place of GINA (Graphical Identification aNd Authentication). BTW, I don't think JILL actually exists, okay? I just made it up on the spot. So when Jack goes out with Jill, he's actually thinking he's having a date with Gina. And when he's makin' sweet, sweet love to Jill, he's actually crying out "Gina! Gina! Gina!"
Let's face facts: this situation sucks. Because Jack expects Gina-like behaviour, Jill can't act like herself - even if Jill's way, way smarter, and far prettier, and much better in the sack. It would utterly crash Jack to find out that he's not gettin' jiggy with Gina.
A proposed solution from some people is virtualisation. This is where instead of ensuring Jill behaved and acted like Gina, it was like having a copy of Gina's personality (call her schizo-Jill) instead. That way, Jill remains Jill, and Gina's still Gina.
Now, normally people think of virtualisation as actually installing a virtualisation software like Virtual PC or VMWare or something, but wouldn't it be better if instead of virtualising the whole machine, you only virtualised the high-level stuff? After all, Jill's a Woman, and so is Gina. You don't have to fake the hardware bits much, really, just the parts that matter. Strangely enough, Windows could accommodate that sort of behaviour. And why not? The original Windows NT was designed to be as modular as possible. You had the low-level micro-kernel, the HAL (Hardware Abstraction Layer, which provides a single view of hardware regardless of what it was underneath), and then you had the subsystems which rode on top of the low-level OS. Windows NT and its successors (Win2K, WinXP, WinVista, and soon enough, Win7) supported almost every subsystem there ever was. OS/2 (which was the original default subsystem, believe it or not), DOS, Windows 16-bit (otherwise known as Win16), Windows 32-bit (Win32), Windows 64-bit (presumably Win64), and Unix (via the Interix subsystem). In fact, the only major desktop OS subsystem Windows has never implemented (or have implemented by someone else) on the NT platform is the MacOS - and the Mac's running BSD (a Unix) on Intel processors now. So the idea's not as stupid as it sounds.
One problem. When you speak of a subsystem in NT, what you're actually talking about is the API, or Application Programming Interface. This is a contract - if you're programming on Win32 APIs, it pretty much says that "As long as you promise to do ONLY what is documented functionality in these APIs, we guarantee that as long as we implement Win32 APIs, your program will work flawlessly". In theory, of course. In practice, there are a largish number of programs that don't do this. Instead, they peek and poke into internal structures and directly do stuff assuming these structures will never change. In effect, instead of calling Undress(Girlfriend), they look at what the Undress() procedure did, as well as which structures it was manipulating, and proceeded to call Unfasten(Blouse.Buttons); Unzip(Skirt.Zip); Unhook(Bra.MetalClasp); and so on. And then the next version of Undress() did something different like Unzip(Dress.Zip); Eat(EdibleBra) and the program blew up because it didn't expect that. And yet, both procedures are Undress(). And it is the same Win32 API you're talking about.
Is there a proper solution? I don't know. But it's surely interesting trying to find out :)
Posts
No comments:
Post a Comment