If you're going for minimum file and image sizes, writing assembly has the advantage that you see in advance how large the binaries become. Forcing yourself to think on that layer inevitably put you to pick the choices that reduce the size of the software.
This is visible in MenuetOS system calls.
There's more in here than just the choice of language, for example there reads on the front page:
> The design goal, since the first release in year 2000, has been to remove the extra layers between different parts of an OS, which normally complicate programming and create bugs.
It's probably good idea to verify what's been said. I don't see many benchmarks or anything else comparing it to other systems. I keep wondering what I'm actually looking at here too.
Here's a sample UI program. Here's how to create a button:
mov rax , 8
mov rbx , 020 shl 32 + 65
mov rcx , 110 shl 32 + 20
mov rdx , 20
mov r8 , 0
mov r9 , button_text
int 0x60
No thanks! I've done assembly programming and will take C over it every day and twice on Mondays.
If I'm reading this correctly, the 64-bit version does not use a Free license.
> Menuet64 Copyright (c) 2005-2014 Ville Turjanmaa
> 1) Free for personal and educational use. 2) Contact menuetos.net for commercial use. 3) Redistribution, reverse engineering, disassembly or decompilation prohibited without permission from the copyright holders.
> THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS, AUTHORS, AND CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL VILLE TURJANMAA OR ANY AUTHORS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
MenuetOS has a GUI and the entire OS is 1.44MB, less than your desktop background and just enough to fit on a single floppy disk.
To achieve this incredibly small size, the entire OS is written by hand in assembly, including the kernel which is not Linux.
I have flashed a fork of this OS called kolibriOS which is also 1.44MB onto the BIOS chip of my computer as a coreboot payload, allowing the computer to be booted directly from the BIOS chip without any other storage.
BI and or custom software code/programming is shite in my opinion. How many softwares i've seen that ONLY work if you run.....
XP or 98 while wearing a red hat backwards when the wind blows south east on 70F day, while standing on 1 leg and recite the alphabet backwards.
I've seen entire operating systems that fit on a floppy disc written entirely in 32/64 bit assembly language that sports, drivers, apps and 3D capabilities right of the box.
The database is shite my ass!
Assembly uses an assembler which is similar to a compiler[0]. Windows running on your Intel Core i7 CPU will be x86/x64 architecture which means you can do 32 or 64-bit x86 assembly[1].
Assembly is crazy simple but also crazy hard :) What I mean by that is you will only really use about 20-25 instructions but you will use them a hell of a lot and really need to understand what the hell they are actually doing with your computer. This isn't simple stuff like you have in high level languages such as Python or even C++. Getting a line of text printed to the screen takes a lot of work whereas in Python you would just write print("Hello")
Anyway the best place to get started is probably The Art of Assembly Language.
As for operating system programming. Well doing that in Assembly is going to be hell. There is a reason C became the number 1 language for operating system development! Ain't nobody (well except this guy) wants to make an OS in Assembly on x86!.
Edit: If I were you I would learn C first and then see if you want to go onto assembly. C is portable to different architectures much easier than assembly is and it will be much more useful to you.
[0] Not strictly true. They kind of do similar things but they are actually very different. The process is similar though in that you use an assembler to create an executable file.
[1] You can do 16-bit as well although running a 16-bit executable in modern versions of Windows will either not work right or not work at all depending on your version of Windows.
If anyone want to check a OS entirely written in Assembly, check out http://www.menuetos.net. It's just an 1.5 MB for download, you can even put it in a 3.5 floppy if you want.
Supports USB 2.0, sound, has an web browser, and can play Doom and Quake. It's really really impressive, and madness at the same time.
Win95/98/ME then RedHat, SuSe, Fedora Core, Ubuntu for a year, Fedora, then along Arch, OpenSuse, but Fedora is my main until today. I want to try BSD's, didn't use it outside VM's.
But speaking of cool OS's, one I remember now is Menuet OS, always amazed me, it's written entirely in Assembly and it's so small: http://www.menuetos.net/
It could very easily be in ASM. There have been many examples of very complete operating systems written completely in it. http://www.menuetos.net/ Is one of them. For a system of this size, hand optimized assembly may be the best way to belt out speed.
Memory-usage is not determined solely by architecture. (and no,. I'm not implying that you inferred that it was). There can be 100's of different factors that influence how much memory usage a particular system has. For example... a poorly designed or shitty coded 32bit OS,.. could use more memory (or have more crashes) than a tightly and skillfully coded 64bit OS.
Take for example this: http://www.menuetos.net .. it's a 64bit OS written entirely in Assembly. The entire OS is less than 50mb.
Try not to see whether particular approach have actual benefit or not, but rather, try to do it every once in a while just because you can.
If you take a look at those legendary programmers, one of the trait they share is they hack some code just for the sake of hacking. For example, what's the practical value of writing an entire OS in assembly? Probably none, the OS would be nowhere as good as linux anyway. But people still do it, just because they can (and it's fun).
Menuet OS is written in assembly, has a full GUI, fits on a floppy disk (I'll say that again -- it fits on a floppy disk) and might run. Menuet should run on a 486 without a problem.
someone vote this to the top please ;-)
Note: I make every effort to programatically figure out if links originally posted to Reddit are still good, but it's difficult.
If the original URL doesn't work, or has been replaced with something else, please help out by searching the Wayback Machine for the URL and posting a contemporary link if you find one. There's also a Chrome Extension which makes this process easy.
Changing my statement to Redditors substantially changes my statement. I have no knowledge of the general programming competence level of Reddit as a whole -- probably not what you meant. I would also not make the mistake of saying that most Redditors in the programming sub-reddits are below average (especially since many developers with far above average ability are on reddit).
Finally, I've made frameworks over the course of my career as a developer. I use React because it is easy, effective, has a decent ecosystem of libraries, and reduces my framework maintenance and design time to almost zero. Even a basic version of a React-style framework takes more time than most devs have available to spend on non-paying work.
Claiming that any dev could potentially write a framework using basic JS is like claiming that any dev could potentially write an OS in assembly. Just because a group of devs has done so doesn't mean that doing so is practical.
Technically possible and pragmatically do-able are very different. Calling out redditors for speaking about a practical framework in a pragmatic way does little to contribute to the discussion.