David Baron's weblog: January 2003

Friends & Colleagues

Wednesday 2003-01-29

In the fun with old hardware category...

I've never had a good way of testing things on MSIE for Windows. It's a pain to reboot my Linux box into Windows (wait, twice, and then restart the programs I was in), I have no interest in setting up WINE, and fitting one of my old machines that still dual-boots Windows into the same room would be tight.

However, I finally decided to make my dad's old laptop (running Windows 95) useful. The problem is, it doesn't have a network card, so it can't be added to the two computers (mine and my dad's) that are already running over the DSL. So to use it without using the modem I'd have to connect it to the network via a serial connection to another computer.

So after a few hours of fiddling with cables to see which cable was a null-modem and which wasn't (I was right from the start that only the Laplink cable was an unlabeled null-modem, but the serial ports were trying to run at different speeds), reading the PPP HOWTO, a short document on something close to what I did, the IP Masquerade HOWTO, and some less useful documentation, I had a solution.

On the Linux end, I run the script to set up masquerading (but from ppp1 to ppp0), and then run /usr/sbin/pppd -detach crtscts lock connect '/usr/sbin/chat -t 240 AT OK AT OK AT OK ATDT CONNECT' proxyarp /dev/ttyS0 115200. The messy chat command is only because Windows doesn't seem to have a null-modem driver, so I have to have the Linux box pretend to be a modem. The Windows box is just set up to use a "Standard 28800 modem" (on COM1, which took some time to figure out too), but with the maximum serial port speed (somewhere in the modem configuration) set to 115200.

Oh, and in other news, I've finished Harvard. I haven't actually gotten my degree yet, though. My last exam was last Tuesday (8 days ago) morning, and I packed all my stuff in boxes on Tuesday evening and Wednesday morning, shipped it via UPS on Wednesday morning and took the train home the same day. Then I did a lot of unpacking when they arrived Friday. So I'm at home until I get myself a job, something I should probably be pursuing a bit more aggressively than I am.

Sunday 2003-01-12

Just for the record, I was exaggerating when I said “twice the amount of memory.”

I've also become less sure whether we should even try cleaning up mozilla/layout incrementally, or whether we should throw pretty much the whole thing (nsIFrame and its implementations) out and start over. There really isn't much there that I like, and I think converting it to support concepts such as display-model and display-role or vertical text (ignoring the insanity of splitting direction into two separate properties) would be almost as hard as (if not harder than) starting over. Note that when I say start over, I mean starting with a new design, but pulling in bits of existing code that we want to keep. I don't mean throwing out every last line.

Thursday 2003-01-09

Since everyone else (hyatt, shaver, jwz) is commenting on Safari, I may as well add a few words.

Why is Mozilla's layout engine so big and complex? Perhaps the simple answer is that there were too many people available to write it, and they wrote as much code as they could. After all, they didn't have any incentives to keep the code small.

But what, in detail, is wrong? (Now I'm just speaking of the code in mozilla/layout, which is one of the pieces code I work on, and by far the most discouraging one for a company coming along and thinking of building a web browser based on Mozilla's layout engine.)

In the end, khtml's code is a lot simpler. Perhaps more importantly, the code looks a lot more like a description of the way the layout process works. After hearing a short explanation of what's what, I can understand some of khtml's code almost as well as the equivalent code in Mozilla.

How can Mozilla get from here to there? We need to concentrate on architectural cleanup rather than adding new features. Can it be done step-by-step? Perhaps. Can it be done without sacrificing at least some of the endless compatibility work that's made the layout engine compatible with obscure bugs in WinIE? Probably not. A lot of the compatibility work was done by grafting on little bits and pieces of code. (Oh, this value is wrong here in a certain case? Well, let's fix it.)

However, if we do find a way to do things step by step, we will be able to maintain a lot of the compatibility work that was done simply by regression testing. In theory, if we're switching to a better architecture, it should be possible to find better places for various hacks to go. Will those places always exist when we need them? Probably not. Would it be an easier development process if we didn't have to put in a lot of intermediate hacks? Certainly. Does that mean it would be better for any major architecture work to go off on a branch for six months and then land all at once? I'm not sure.