Talk:Bare Bones

Renaming

Shouldn't this page get renamed? Because every other language's BareBone is called [Language Name] BareBone. Only the C/C++ BareBone site is called BareBone. I think it is reasonable, to rename it to C/C++ BareBone. Then we could use the BareBone page for other things, like explaining why there are BareBones and so on. Columbus 08:50, 14 September 2014 (CDT)

I would've also thought that 'x86 Bare Bones' might also be more appropriate, since that is what you're actually building here. --Ajxs 23:59, 23 April 2017 (CDT)

main -> kmain

I was the one who originally decided to use main() as function name. I changed my mind, because of the possibility of brain-dead compiler option choices resulting in a main()-related linker error, which might be less confusing if the function in the code is called kmain() instead. Solar 07:01, 27 February 2008 (CST)

64 bits

Hello from a new user.

I tried to assemble stuff from this article, but it was no go:

loader.s:21: Error: suffix or operands invalid for `push'
loader.s:22: Error: suffix or operands invalid for `push'

While browsing, I encountered indications it might be my architecture (64bit AMD). I know that cross-compiler would do the job (for 32 bit), but couldn't the code instead be written in such way, so that it is cross-architecture instead? That way, I'd have the solution for both architectures (no need for replacement code to this), and possibly wouldn't need to build a cross compiler at this point (very, very early).

Also, it would be very good if someone could explain, line by line, what's happening here.
In any case, looks like a small, but a very important rewrite is in order.

So, in short:

• Is it architecture specific?
• Any ideas about a workaround?
• Can someone explain the (new!) code?

--Paxcoder 21:57, 5 January 2009 (UTC)

First of all, questions belong on the forum, not in some talkpage few people ever bother to read.

What you have is an assembler that defaults to 64-bit code, and assembly that is written for 32-bit code. To GAS those two are completely different architectures (i386 vs x86-64). There is however a command-line switch that would tell GAS to assemble for the correct architecture and as such needs no change in this code. - Combuster 22:45, 5 January 2009 (UTC)

I hope you understand what you offered is not a solution. I want it to be able to run on 64 bit processors. Basically, you said very little. Nevermind. I'll use forum. --Paxcoder 20:42, 6 January 2009 (UTC)

Added question at the bottom of the page with the options I use to build on my 64-bit Ubuntu 10.04 laptop. -- Mbrush 03:04, 21 May 2010 (UTC)

Revert of -fno-leading-underscore

fixed minor mistake-meshounah

Depending on the compiler, leading underscores are either required or wrong. Also, the summary field was designed for these messages - Combuster 17:42, 11 August 2007 (CDT)

We should add either -fleading-underscore or -fno-leading-underscore to the gcc command. I'd personally prefer -fno-leading-underscore and removing all underscores from the NASM and GAS code. Any opinions on the matter? -Jhawthorn 19:04, 15 August 2007 (CDT)

I'd go for suggesting that a cross-compiler is the only guarantee for success - it also fixes several other things one's system compiler might try to annoy the user (things commandline arguments won't fix). Since the crosscompiler described does not add leading underscores, and the use of having them is purely legacy, I'd go for no underscores anyway. - Combuster 04:34, 17 August 2007 (CDT)

I reverted an edit from Hangin10 regarding -fno-leading-underscore. One of the advantages of the GCC Cross-Compiler is that it makes any tweaks regarding this option unnecessary. IMHO, if we start "leaking" such tweaks into this tutorial, we end up with a "Bare bones for Windows" and a "Bare bones for Linux" again. Or has there been a reason for this edit that I am unaware of? -- Solar 08:26, 19 January 2009 (UTC)

Agreed If you use a windows oriented compiler you get stuck with all its windows oriented dependencies. Better not to silently allow a timebomb to be constructed on a windows platform by disabling leading underscores, and just have everybody use the crosscompiler from day one. - Combuster 23:59, 19 January 2009 (UTC)

FPU Support

I reverted an edit from Hangin10 where the 'finit' instruction was added. IMO, FPU initialization doesn't belong in Bare Bones, and a single 'finit' doesn't even begin to touch on anything else that is needed for proper FPU support. - quok 19:13, 29 September 2009 (UTC)

Disk image

Why does this tutorial still use the kernel 200+18 method of loading? Wouldn't it be better to teach how to create a FAT/ext2 GrUB boot disk?, hence simplifying debugging (and allowing the same code to be expanded to load multiboot modules, and be accessed by the kernel)

People may not want to implement either of these file systems. They may not even want file systems at all. I find the current approach to be more general. --Love4boobies 01:06, 27 November 2010 (UTC)

Linkage

Is everyone comfortable with switching to external linkage rather than pushing things on the stack and then picking them up as arguments? The current way seems less natural, less readable, and is dependent on the calling convention. --Love4boobies 04:17, 15 May 2012 (CDT)

Back then, I thought it a good idea to show how stuff pushed by ASM can be popped by C. It was also closer to the example code provided by GRUB. But that was back when there was no x64 calling convention. In that light, I think external linkage would be better today. But then, try to make sure that you make the chance in all "Bare Bones" articles. We should strive to have them so things as similar as possible, the only differences being those demanded by the language. -- Solar 07:21, 15 May 2012 (CDT)

I have updated the C and C++ tutorials but I'd rather someone else take care of the Pascal and FreeBasic tutorials. It's been about 10 years since I've last used Pascal and FreeBasic I do not know at all. --Love4boobies 05:06, 28 May 2012 (CDT)

Stack top & bottom

As far as I know, bottom of the stack is were the first element is added. In case of x86, it is the highest address. Compare with current content:

1. Currently the stack pointer register (esp) points at anything and using it may
2. cause massive harm. Instead, we'll provide our own stack. We will allocate
3. room for a small temporary stack by creating a symbol at the bottom of it,
4. then allocating 16384 bytes for it, and finally creating a symbol at the top.

.section .bootstrap_stack, "aw", @nobits stack_bottom: .skip 16384 # 16 KiB stack_top:

I think all these occurrences of words bottom and top should be swapped. Do I miss something?

Comment style

I've changed the commenting style from the old # ones to the new C-style ones using /* and */, hopefully this is OK, I thought it was a good idea since the # style is deprecated and is used to override line number / file name when errors are reported by the assembler. That said, if people can give a good reason as to why it should be changed back, by all means, go ahead, I'm just trying to help avoid headaches in the future. Also, I used my own commenting style (a single /* and */ before the first line and after the last line of a comment block), but I know people like other styles, so if you really feel strongly about one and think it helps readability, go ahead and use that. -- Mikumiku747 05:10, 19 July 2017 (CDT)

Loading at 2M

A change was recently made to this article to switch the load address from 1M to 2M. This was based on the change author's real-world experiences with UEFI systems that did not mark the 1M region as available.

The change author's experience was not unique. Grub developers encountered the same problem, and added a feature to Multiboot2 specifically to address it: https://git.savannah.gnu.org/cgit/grub.git/commit/grub-core/loader/multiboot_mbi2.c?id=a620876e3b32e4ea0c9a7b3541fcb9a4dd4fb9eb

As the code in the barebones is not affected by this load offset, we should keep the updated 2M address. --klange 22:08, 11 November 2023 (CST)

Deprecation of the tutorial

I would like to start a discussion on the deprecation of this article (I have added a Historical template, but it has been reverted). The motivation for doing that is that while this tutorial is "correct for what it is", it is using stuff that has been outdated for 30 or more years (multiboot 1, VGA text, no virtual memory...), and at this point, in my opinion, it is not even a good base for anything (unless you only target i386 retro hardware or something), and it is damaging and steers the people away from osdev by being the bare bones tutorial once they hit the inevitable roadblocks of it. I'm sorry for putting my frustration (not only with this tutorial, but the general stagnation of the wiki) out here, but the world has moved on, nobody has an Intel 386 with ancient VGA hardware in their PC (which would maybe warrant Multiboot 1 over Multiboot 2), and this tutorial, as it, is not even usable on most modern PCs (I am typing this on a not even that new of a machine, which has no VGA text mode).

I am of the opinion that at least having the Historical template is warranted for this page (this page was probably fine when it was written in 2009, but it is no longer so in 2026).

I also have personally been wanting and preparing to write a multiboot 2 barebones tutorials (for people who for some reason insist on using multiboot over a plethora of arguably better protocols), which would at least be a usable base for modern/64-bit PCs and can actually run outside of QEMU on hardware that people have, but have not had time to do so yet. --mishakov 2:42, 11 June 2026 (CST)

I have been planning to upgrade this tutorial to Multiboot 2. There is no particular reason that it should be using Multiboot 1, actually. If it gains e.g. multiboot 2 + framebuffer support, then it would work quite well on modern EFI systems if loaded via GRUB 2. Font rendering and graphics are more complicated topics though.

I might just go ahead and upgrade Bare Bones and Meaty Skeleton to Multiboot 2. I wanted to do it half a year ago, but I had some trouble with getting Multiboot 2 working for Sortix, but I should have some golden code now that can be a good reference.

Note how VGA hardware is still commonly available via Qemu emulation, which is much recommended for initial testing. If we start bundling 64-bit / paging into the initial bare bones tutorial, then in my opinion, it becomes even harder to understand as a newcomer. I generally recommend that people complete this 32-bit tutorial before going 64-bit or tackling paging. I think the major problem is that we should have a good follow up tutorial to Bare Bones with these more advanced topics, and connect those tutorials together in a nice intended experience.

You cannot deprecate this tutorial and consider it historical before you have a *replacement* available. Please feel free to write a new tutorial, or improve existing ones, but *please* *please* **please** get your changes peer reviewed by the wider community. There is a lot of misinformation and bad advice in almost all tutorials out there, and the osdev wiki base tutorials are different, because we have iterate on them for decades to get them perfect (for what they are). Please pop into the #osdev channel on irc.libera.chat and feel free to ping me if you want me to review your change, and I'll be very happy to lend a hand. :) --Sortie (talk) 20:35, 18 June 2026 (UTC)

Imo the Limine Bare Bones could be the indirect replacement; while limine protocol is somewhat opinionated (which for me for example doesn't make it very ergonomic), it does hide some amount of complexity from the beginners (hence why I added historical, there are alternatives already). I am personally not sure about the utility of starting with 32 bits either, I have seen people with different opinions on this. (but I agree that this whole thing, especially the follow-ups is not straightforward and does require a lot of discussion)

I have semi-recently added multiboot 2 to my kernel in preparation for the new tutorial (I had Limine and Ultra protocols), for both the AMD64 and IA32 ports of it, so I do think I have the working code that can be the base for the mb2 tutorial, that maps/gets the kernel to the higher half and enters C++.

However, the framebuffer situation is a bit sticky, since the other protocols map it for you and make it easier with libraries like franterm, but since multiboot doesn't (and considering that the framebuffer is sometimes not at <4GB), I feel like people have to do it themselves (my framebuffer/terminal driver is in userspace, so that my kernel doesn't even really touch it during the init so it's not a problem for me), but for QEMU in particular, COM0 could perhaps be used (which you would probably want for a kernel anyway), until the kernel can initialize the framebuffer...

I'm a bit busy right now so I'll probably come back to it in a week or so. --Mishakov (talk) 23:05, 18 June 2026 (UTC)

I think a better formatted Limine Bare Bones that includes Flanterm could be a perfectly reasonable base for Bare Bones and meaty skeleton, it will start you on x86_64, make UEFI a possibility (unlike with multiboot1 where it can boot but its kinda, terrible), and also works in general on modern hardware far better, and makes SMP far easier. --Anotheridiot