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.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。