Btw, this attachment seems to contain the real meat (STACK TEXT): https://bugs.freedesktop.org/attachment.cgi?id=77055
As for the font problem, the on-going saga of KB2753842 may be to blame: http://support.microsoft.com/kb/2753842
It looks like MS have had a few attempts at tightening up the potential for security exploits caused by executing what can effectively be untrusted code (the glyph program) in kernel space. This is why fonts are considered system components - they are code, not data, executing on a VM.
If you like MS conspiracy theories of course, you can pretend that it's a deliberate ploy to break LibreOffice, but personally I think that's tin-foil hat territory. Most likely there's a bug in the GDI code triggered by an unusual glyph in the font (perhaps in turn generated by a bug in whatever font design software was used). Complexity + poor choice of performance optimisation = fail. At least the kernel bug check is working as designed - if only all OSes were so robust in the face of memory corruption.
I don't think I've seen any kernel deal directly with fonts. I understand the reasoning they added the GDI to kernel space, but IMHO it seems to me that they should seriously reconsider their reasoning.
At the very least, they need to relook at their glyph parsing/building algorithm and perhaps look into better fuzz testing around these routines. Just my 2c :-)
Like Javascript in a web page?
MSIE is an integral part of Windows. Microsoft has always said so.
If they hadn't done the same sort of thing before, it would sound like a conspiracy theory. Since they have, well... DOS isn't done 'til Lotus won't run, right?
I guess part of the reason for the poor performance was that video card drivers of the era were tightly coupled with the OS, effectively replacing GDI functions with their own implementations. The NT 3.x design made it difficult to support these existing graphics accelerators.
Applications render by calling OpenGL library, which obviously executes in calling processes. OpenGL library asks the kernel to allocate required memory buffers, prepares code for the GPU and submits it to the kernel for execution. Kernel collects jobs submitted by processes, executes them on the GPU and notifies processes on completion.
When application wants to display something on the screen, it shares its buffer with the X server (or equivalent) and instructs it to redraw its window from this buffer. The display server uses some special syscall to obtain access to screen output buffer.
http://blog.ffwll.ch/2013/01/i915gem-crashcourse-overview.ht...
This (plus some low-level register poking) is the stuff you would need to implement in your GPU daemon. Actual generation of drawing commands, compilation of shaders etc is performed by applications.
The overhead should be in the order of few context switches to the GPU server for each frame rendered by any application (in Linux it's few syscalls instead of context switches). Probably not terrible.
I wonder why they didn't move the rest of GDI out of the kernel at the same time? A composing window manager was also introduced in Windows Vista, which really cuts down on the number of window repaints. Surely they can afford to take the performance hit now?
NT itself is flipping marvellous :)
Here's to that project's success.
I was a dev in the Windows organization for a few years and this is the conclusion I came to as well. When people complain about development on Windows, they're rarely talking about NT or even Win32. They're usually talking about some layer on top.
Even the example here about spawn() - that function is from the CRT, which honestly is a very crummy and poorly maintained library, but more importantly it isn't really "Windows" and couldn't really be called "the Windows API" - it's just some library that gets new versions alongside releases of Visual Studio. And that spawn() function, ironically enough, mostly exists so that people who know the fork + exec pattern will feel at home.