This is more like "by communicating with the X server", which is not exactly the level of "from scratch" I was expecting, but then again, it's more involved than the equivalent in Win32 that's not much more than filling in some structures and invoking a few functions.
It's not even that much more involved, just tedious. The serialization/deserialization of X requests and responses is fairly straight-forward (it could be more straightforward - it's not a very nice protocol, but it's also not difficult), as the article also shows, and it can be made more compact than that with a couple of helpers.
The biggest pain in doing "raw" X is the async nature of the protocol - to write a robust X client you really want an event-loop driven approach that embraces that like XCB does, instead of trying to paper over it (like Xlib did).
I was expecting something closer to direct framebuffer writes, as is often done in the various write-an-OS articles that get posted here semi-regularly.
was a bit confused about the segfault stuff mentioned towards the beginning of the article. but got quite quickly disabused of that notion with gdb etc.
Most "from scratch" would be some sort of microcontroller - write directly to hardware, program registers directly. It's the best feeling when you know every single instructions on the CPU is under your control, there is no 20 million lines of kernel code that do something.
But the MCU needs special hardware (MCU itself, display, programmer) so it is not a good starting project. This brings us to good old MS-DOS. Sure, you need to call BIOS to set up graphics (mode 13h, "320x200x256 colors" is the best for beginners), but after that, you are talking directly to hardware.
no u just grab the framebuffer addr somewhere (lot of places u can dig that up) and ram in the right type of pixels. :'). this article demoes exactly 0 GUI functionality...
This reminds me of the time I was a young, naïve idiot, and decided I would learn GTK by writing some basic app in GTK. In x86 (not x86-64) assembly. Like all of my other project ideas from that era, never went anywhere, and I horribly underappreciated just how complicated things were.
Kudos for actually getting somewhere in their attempt to do this, a further state than I ever managed.
C++ is an advanced programming language with a couple decades of features.
Assembly is very simple in terms of syntax, requiring an hour to understand the basics.
Assembly is simple if you know the processor you are writing against. It can take some time to learn instructions and figure out how to implement familiar programming constructs like loop and logic conditions.
The simplicity of assembly comes with a cost: it takes many more lines of assembly to do simple things compared even to C. The lack of abstraction and language features make assembly very simple, but not easy for large programs.
I learned X86 ASM by sinking my teeth into the Intel 8085 manual, then lighting up LEDs on a hardware emulator and later on a 8085 simulator that me and my brother built.
What certainly helped was that I had did some digital design and instruction set architecture, etc.
Later on, I did some real-world assembly programming for the PIC microcontrollers and some inlined assembly in C, which I did not find daunting at all because of my previous experience.
I guess the best prerequisite for this material is having done some low-level C, the kind where you know about text/data sections and being comfortable with calling conventions, the run time and the linking process.
I was curious about the rep movsb, so I tried to compare this with how a compiler would copy a known small size chunk of memory. It seems pretty complicated. I didn't manage to make a compiler generate the `rep movsb` idiom but I managed to find out some interesting stuff:
- small, known size moves are stitched from a fixed number of mov instructions, sometimes overlapped. For example 21 bytes is qword (8 bytes) + xmmword (16 bytes), overlapped.
- char-copying loops like "a++ = b++ c times" with c not known at compile time are either realized as simple increase, compare, conditional jump, or, at higher optimization, a monster that has like 10 branches to use anything from xmmword to byte depending on the amount of data
- big, known size moves (> 256 bytes) just generate a call to memcpy
I have to say, writing a GUI is one of the last places I’d ever find it appropriate to use assembly language. Man, those click handlers are going to be fast.
Perhaps unintuitively, the recipe for writing a GUI from scratch is almost exactly the same as making an apple pie from scratch, save some minor details at the very end.
This is more like "by communicating with the X server", which is not exactly the level of "from scratch" I was expecting, but then again, it's more involved than the equivalent in Win32 that's not much more than filling in some structures and invoking a few functions.
It's not even that much more involved, just tedious. The serialization/deserialization of X requests and responses is fairly straight-forward (it could be more straightforward - it's not a very nice protocol, but it's also not difficult), as the article also shows, and it can be made more compact than that with a couple of helpers.
The biggest pain in doing "raw" X is the async nature of the protocol - to write a robust X client you really want an event-loop driven approach that embraces that like XCB does, instead of trying to paper over it (like Xlib did).
seesh ! what would `from scratch` mean for you ? invent the whole universe ?
I was expecting something closer to direct framebuffer writes, as is often done in the various write-an-OS articles that get posted here semi-regularly.
i on the other hand, just loved the article.
was a bit confused about the segfault stuff mentioned towards the beginning of the article. but got quite quickly disabused of that notion with gdb etc.
KMSDRM is soooo much more fun than X. Truly the way programs were meant to be.
and then once it works u can slap it to ur own OS and avoid the rest of linux too! yay! :')
that is correct, id rather attempt to understand the hdmi protocol before i understand 50 million lines of linux ^.^
Talk to hardware directly
Most "from scratch" would be some sort of microcontroller - write directly to hardware, program registers directly. It's the best feeling when you know every single instructions on the CPU is under your control, there is no 20 million lines of kernel code that do something.
But the MCU needs special hardware (MCU itself, display, programmer) so it is not a good starting project. This brings us to good old MS-DOS. Sure, you need to call BIOS to set up graphics (mode 13h, "320x200x256 colors" is the best for beginners), but after that, you are talking directly to hardware.
no u just grab the framebuffer addr somewhere (lot of places u can dig that up) and ram in the right type of pixels. :'). this article demoes exactly 0 GUI functionality...
This reminds me of the time I was a young, naïve idiot, and decided I would learn GTK by writing some basic app in GTK. In x86 (not x86-64) assembly. Like all of my other project ideas from that era, never went anywhere, and I horribly underappreciated just how complicated things were.
Kudos for actually getting somewhere in their attempt to do this, a further state than I ever managed.
I currently re-learn ASM by writing my own virtual machine with my own cpu architecture and instruction set. Its FUN :)
I never expected to write programs in pure machine code before, but here I am. Writing my own assembler now :)
Way easier than C++ LOL
I highly recommend it.
How so? I know some of both but not enough to know why C++ is that much more complex.
C++ is an advanced programming language with a couple decades of features. Assembly is very simple in terms of syntax, requiring an hour to understand the basics. Assembly is simple if you know the processor you are writing against. It can take some time to learn instructions and figure out how to implement familiar programming constructs like loop and logic conditions. The simplicity of assembly comes with a cost: it takes many more lines of assembly to do simple things compared even to C. The lack of abstraction and language features make assembly very simple, but not easy for large programs.
When you don't know what you don't know...
In my youth, kids learned assembly to crack games.
I learned X86 ASM by sinking my teeth into the Intel 8085 manual, then lighting up LEDs on a hardware emulator and later on a 8085 simulator that me and my brother built.
What certainly helped was that I had did some digital design and instruction set architecture, etc.
Later on, I did some real-world assembly programming for the PIC microcontrollers and some inlined assembly in C, which I did not find daunting at all because of my previous experience.
I guess the best prerequisite for this material is having done some low-level C, the kind where you know about text/data sections and being comfortable with calling conventions, the run time and the linking process.
Corresponding Windows article: https://bitcodersblog.wordpress.com/2017/05/10/win32-in-nasm...
(but yes, I also would have expected a bit more "from scratch". Is there an annotated disassembly of, say, AmigaOS around?)
Previously:
Learn x86-64 assembly by writing a GUI from scratch - https://news.ycombinator.com/item?id=36153237 - June 2023 (146 comments)
I was curious about the rep movsb, so I tried to compare this with how a compiler would copy a known small size chunk of memory. It seems pretty complicated. I didn't manage to make a compiler generate the `rep movsb` idiom but I managed to find out some interesting stuff:
- small, known size moves are stitched from a fixed number of mov instructions, sometimes overlapped. For example 21 bytes is qword (8 bytes) + xmmword (16 bytes), overlapped.
- char-copying loops like "a++ = b++ c times" with c not known at compile time are either realized as simple increase, compare, conditional jump, or, at higher optimization, a monster that has like 10 branches to use anything from xmmword to byte depending on the amount of data
- big, known size moves (> 256 bytes) just generate a call to memcpy
Does anyone know of a C version of this, communicating with the X server without libraries?
I have to say, writing a GUI is one of the last places I’d ever find it appropriate to use assembly language. Man, those click handlers are going to be fast.
Using X11 isn't exactly from scratch.
Perhaps unintuitively, the recipe for writing a GUI from scratch is almost exactly the same as making an apple pie from scratch, save some minor details at the very end.
First, invent the universe (left as an exercise)
(on Linux/X11, which should have been mentioned in the title)
[dead]
XQuartz does not support high resolution displays, that is not what macOS users looking for.