HN2new | past | comments | ask | show | jobs | submitlogin

> Was it really a mistake in a practical sense?

This is what many people on the internet say. This does not mean there there might be good arguments for the opposite standpoint, too.

At least I can tell that Microsoft is working to move parts of GDI step by step from the kernel back to user mode again, which should provide evidence that they consider this decision as a historical mistake, too, because it opens too many potential gateways for security flaws.



> which should provide evidence that they consider this decision as a historical mistake, too, because it opens too many potential gateways for security flaws.

Or perhaps it was the correct decision at the time, but now (decades on, with computing power orders of magnitude cheaper and security vulnerabilities orders of magnitude more expensive) a different decision is appropriate?


I don't know about that... plenty of other operating systems didn't render fonts in the kernel at the time, and they seemed fast enough. Let's just say it was a mistake but that we can be happy Microsoft is now fixing it.


> plenty of other operating systems didn't render fonts in the kernel at the time, and they seemed fast enough.

Which ones? I'd be surprised if either of classic MacOS or BeOS didn't have the display layer in the kernel; Solaris had it in userspace but was pretty slow; BSD was still tangled in lawsuits and Linux barely existed.


> BSD was still tangled in lawsuits and Linux barely existed.

Yea, but they seemed fast enough with rendering fonts in the userspace (xfstt). Which is what I thought we were talking about.


> Yea, but they seemed fast enough with rendering fonts in the userspace (xfstt).

I don't remember there being enough GUI applications around on Linux/BSD to be able to talk about whether font rendering was fast or slow. Anything that used motif was slow, netscape was very slow. xterm was fast but fixed-font.


Classic MacOS can't really be said to have a kernel, as it had no privilege separation and no security whatsoever; user applications ran with full access to the hardware, and used cooperative multitasking instead of being preemptable. The QuickDraw routines were in ROM but the only difference that made is you had to modify a jump table instead of being able to overwrite them directly.

(All of the above supports your point; it's just that the Mac went further than you implied.)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: