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 192.168.0.6:192.168.0.50 /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.
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.
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.)
I think some of the people who wrote the code didn't understand
the specifications that they were implementing. Part of the problem
may lie in the specifications themselves. For example, there's almost
no information in CSS2
describing shrink wrapping. Might being an afterthought explain why
Mozilla's layout engine has shrink wrapping code scattered throughout
it in a disorganized fashion? Even lately I've watched some
developers want to make incorrect changes in behavior or fail to
understand the reason that another browser lays a page out
differently.
I think part of the problem may have been a desire to make
everything modular so that it could be split up between different
programmers. In the end, there were just too many pieces. (Could
this be a problem of too many design documents?)
There's overoptimization in certain areas. For example, our
rendering object structures are extremely optimized for size at the
cost of code complexity, and, to some degree, performance. However,
our content tree structures are larger and the code is simpler. From
what I understand about khtml, it has much smaller content tree
structures (with the DOM using tearoffs), while its rendering objects
(what Mozilla calls frames for some confusing reason) are
much larger, allowing for simpler code.
There's been an inability to focus on more than one or two things
at the same time. In 1998-1999, there was a focus on standards
compliance. In 2000-2002, there was a focus on making real web sites
work. In 2001 there was a focus on performance. Now (late 2002/early
2003) there's a focus on memory use. In many of these cases, working
on one objective can hurt another one, and I think we've often failed
to balance them appropriately.
(The real solution to cleaning up
layout probably involves making layout objects use twice the amount of
memory that they currently do. Is that a problem? I don't think so,
since they take up so little of the total. We're better off
increasing the amount of memory that frames use and attacking memory
use in other areas. If I do this, will I be told that I have to fix
the memory use regression in 72 hours or back out the changes? I hope
not.)
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.
