I'd certainly have liked to read what happens all the way up to the GPU. I need a better understanding of how the operating system talks to the GPU and how all these graphics are represented and manipulated by the hardware.
You'd definitively be interested by the ryg[1] series on the graphic pipeline. It goes in details about how bits get to the GPU and how the GPU handle them. The author writes that using a 3D graphics API is a prerequisite. To the contrary, the series itself is great to get a grasp on things and not feel completely alienated by 3D graphics APIs if you ever decide to use one in the future. It's fairly old (2011) but I still see it recommended as a relevant resource today.
I love this. Taking something we all take for granted and putting it under the microscope is so fascinating.
If the author (or translator) is reading this: one thing you should consider is changing the use of "AST tree". That expands to "abstract syntax tree tree" which is like saying "PIN number" or "ATM machine".
I love these kind of writeups, they're so illuminating. I'd have preferred to see it with Linux, but the author really did some work to dive into Windows, which is interesting:
> "In order to better understand how fontdrvhost.exe works internally, we would need to focus our analysis on that executable. Unfortunately, unlike consoles, the source code of this component has not been made publicly available, so we need to roll up our sleeves and run the disassembler. There is a small consolation in the form of debug symbols (.pdb files) made available by Microsoft for system libraries [12], thanks to which we can at least know the names of individual functions."
the writeup has two parts, the first half is python3 hello world, from reading the source all the way to byte code interpretation, and the second half is how the console output is transformed into pixels, by the low level part of python and then the windows UI, all the way to the renderering of glyphs with anti aliasing in a GUI text console.
I feel hinting at it not being about Linux bears the risk of diverting potential readers from an outstanding text.
The only deep difference to Linux imnsho would be the different graphics architecture, with it's flavours X11 and Wayland, and I'd dare to claim that 90% of the article are not platform dependent.
I hope it doesn't turn anyone off from the article, it's a great writeup. I was actually more impressed about the willingness to fire up the disassembler for the Windows section, although it shouldn't be necessary. (Running it to bare metal would also be cool).
This is great. It brings me back to the early days in my undergraduate trying to get a grasp on programming.
The "Intro to Programming" i.e. Java 101 was my first experience with programming in general, and nearly made me drop out of the CS program altogether. Something about the high-level learning and lack of understanding what was going on behind the scenes made it very difficult to grasp. It wasn't until I took a course in C the following semester that I finally began to grasp the actions behind the code I was writing. Although the code was much more difficult to write, I found the laborious process of writing C made it much easier to grasp the underlying functionality.
There's benefit in not having to understand the underlying intricacies of the code that you're writing, but there is something about that knowledge that makes it just so much more engaging.
> There's benefit in not having to understand the underlying intricacies of the code that you're writing
I don't know. All these abstractions eventually leak. We often run into problems that can only be solved by fully understanding the software layers we're building on top of. I think that this cancels out any initial benefits.
> there is something about that knowledge that makes it just so much more engaging
Agreed. It's such a joy to discover the underlying technology. Lots of people don't care about these "already solved problems" but I find them deeply interesting.
14 comments
[ 3.7 ms ] story [ 44.7 ms ] thread[1] https://fgiesen.wordpress.com/2011/07/09/a-trip-through-the-...
If the author (or translator) is reading this: one thing you should consider is changing the use of "AST tree". That expands to "abstract syntax tree tree" which is like saying "PIN number" or "ATM machine".
> "In order to better understand how fontdrvhost.exe works internally, we would need to focus our analysis on that executable. Unfortunately, unlike consoles, the source code of this component has not been made publicly available, so we need to roll up our sleeves and run the disassembler. There is a small consolation in the form of debug symbols (.pdb files) made available by Microsoft for system libraries [12], thanks to which we can at least know the names of individual functions."
I feel hinting at it not being about Linux bears the risk of diverting potential readers from an outstanding text.
The only deep difference to Linux imnsho would be the different graphics architecture, with it's flavours X11 and Wayland, and I'd dare to claim that 90% of the article are not platform dependent.
The "Intro to Programming" i.e. Java 101 was my first experience with programming in general, and nearly made me drop out of the CS program altogether. Something about the high-level learning and lack of understanding what was going on behind the scenes made it very difficult to grasp. It wasn't until I took a course in C the following semester that I finally began to grasp the actions behind the code I was writing. Although the code was much more difficult to write, I found the laborious process of writing C made it much easier to grasp the underlying functionality.
There's benefit in not having to understand the underlying intricacies of the code that you're writing, but there is something about that knowledge that makes it just so much more engaging.
I don't know. All these abstractions eventually leak. We often run into problems that can only be solved by fully understanding the software layers we're building on top of. I think that this cancels out any initial benefits.
> there is something about that knowledge that makes it just so much more engaging
Agreed. It's such a joy to discover the underlying technology. Lots of people don't care about these "already solved problems" but I find them deeply interesting.