It's the end of an era

Here is Zoomin.exe, a pixel magnifier, running on Vista:


Microsoft finally broke this program. It runs, but no longer sees the screen and only magnifies itself. If you look closely, you'll see it's a 16-bit Windows 3.0 program. Microsoft shipped it as part of the Windows SDK circa 1990.

Do I care that it's broken? Nope, only cavemen (and possibly Voyager) are running applications this old. There are many, many, more and better programs like this around, but I kind of got a kick out of running this one. It's only 7K. No DLL's, resource or config files, yet it has an icon . It really is just a 7K EXE.

In my youth, I once built a Digitalk Smalltalk/V program that did the same thing. I used the tools of the day to throw out almost everything and managed to create something that was 37K. Of course, it needed the VM DLL's, but they were tiny too. I remember being mad when I figured out the Smalltalk VM was taking 256K at runtime (probably for the garbage collector old and new spaces).

For me, Zoomin.exe was kind of a test that Microsoft passed, year after year. The program is 17 years old and is only now broken. Imagine trying the same thing with a Linux distribution.

It was also a reminder. GUI programs could be tiny. Oh computing world, where did we bloat out and go wrong? I guess I'll have to get my kicks some other way.

Finally, this is the sort of backwards compatibility that we aim to achieve with SWT, despite the fact we run on Linux!

Steve

What happens when you don't fix a critical bug?

For a while now, there were a number of problems in our OLE support. The worst was 49098. Some controls, such as Microsoft Word, wouldn't show scroll bars. I'm happy to say that this bug and a bunch more long standing OLE problems have been fixed.

What happens when you don't fix a critical bug? Smart people find work arounds. For example, IBM wrote the IBM Container for ActiveX Documents. By using the OLE support in MFC, they were able to work around the problem. Why didn't we do this? SWT doesn't use MFC for performance, memory and maintenance reasons. We couldn't throw out our existing code or the SWT OLE API. The fact that we had no idea what MFC was doing to fix the problem and no one could tell us cinched the deal.

Other people began to investigate and use DSOFramer, a Microsoft control that embeds Office documents. This wasn't ideal, but it did solve the sizing issues.

I'm not proud of these work arounds, but at least open source makes them possible. The design pattern that SWT uses is "just write the code" so people can see what we are doing and where we are doing it.

OLE's not dead yet ... but we can only hope.

Steve

No M5a?

What on earth happened? Traditionally, Eclipse M5 represents a low point in the Eclipse development cycle. If you saw Erich Gamma and John Wiegand's great JavaOne talk last year, it is the lowest dip in the rope. Teams scramble to get features in and stability suffers, causing us to blow the milestone. I know 'cause I've blown a few.

This is normal for the Eclipse development cycle. Does this mean that the dreaded "a" is still to come?

Steve

Get the engineers together and get out of the way!

Those of you that know me know I avoid calls. I can always be reached through email, the bug system, the newsgroups and mailing lists.

Sometimes, there's a critical situation and a call is dictated. Normally this consists of twelve or more people, only two of which know what is going on. Because nobody can see anyone else, people repeat themselves and state the obvious. There's no eye contact to tell you, "Yes, I understand. I get it."

My reaction to all this is, "My smart people will talk to your smart people. Together they will either fix it, determine that it can never be fixed, or get an estimate of how long it will take to be fixed."

Get the engineers together and get out of the way! Is your manager listening?

Steve