How do I use my Assembly for operating system development?

[SamTouraz]

Hi.

I know Assembly but I don't know how to use it for operating system development. I know I can't use Linux system calls for making a bootloader. So what is a good resource? I know I can't use printf() C function for a bootloader. I got to make everything myself. So where is the best place?

I'm new to operating system development but I want to face it. It will be my hobby. I know it will be frustrating. I understand that it is not like any other task.

Here's an analogy.

I want to turn (well, I need to)

Code: Select all

Put butter on bread
Then eat it

into

Code: Select all

Get flour
Get yeast
Get a bread maker.
Put it in the machine.
Wait for the bread to cook.
Then put butter on the bread.
Then eat the bread with the butter

[iansjack]

You've already reached a good resource. Start with the "bare bones" tutorial in the Wiki.

And forget about making a bootloader; just use one of the existing ones, such as GRUB.

[SamTouraz]

I don't want to use GRUB or C. I want to use pure Assembly please. I would like a straight answer please.

[iansjack]

There's a ton of info on the Internet about this.

Just do a little research on your own.

Google is a good starting point.

[IanSeyler]

My suggestion would be to start simple (the following assumes you are targeting x86 systems).

- You will probably need to call the BIOS: http://www.ctyme.com/rbrown.htm
- Check what others have done before:
http://mikeos.sourceforge.net/
https://github.com/ReturnInfinity/Pure6 ... ootsectors

-Ian

[Schol-R-LEA]

There's a ton of info on the Internet about this.

Just do a little research on your own.

Google is a good starting point.

While I agree that this is in many ways the right answer, I suspect that it is on target but not a bullseye. In this instance, a bit of advice on the best ways to conduct the research might be in order.

@SamTouraz: As it happens, the Wiki does cover Rolling Your Own Bootloader, and while it is something we generally recommend against - vehemently, for reasons given on that page and elsewhere - the information is available if you do choose to do so. Also, the warnings about not writing a loader yourself aren't going to apply as strongly if you main interest is in learning about how the start-up goes, or if your are doing it mainly as a hobby (it's your time and effort to waste, after all).

Note, however, that you can use GRUB - or some other existing loader such as XOSL or Boot Magic - with an assembly-language kernel. It would probably help a lot to do so, as the boot procedure really is its own thing and tends to be more of a diversion than a really useful lesson.

Also, I would be curious as to why you want to work in assembly, and why want to write your own boot loader - not because I think is it a bad idea, but because it would give us a better sense of what you are looking for and what advice we could give. It would also help if you told us which assembler, toolchain, development platform (OS and hardware), and target platform, you mean to use (I am guessing that the last is a stock PC platform, but we do have people writing code for ARM and MIPS among other things).

In any case, I would advise you to read several of the wiki pages at least twice each, and then writing out a few plans as to how to approach the problems at hand, before writing any actual code. That's your call, though. Since I don't know how much you already know - and you could probably do with a refresher any way (it can't hurt, after all) - I'm just going to give blanket recs on these.

• Getting Started
• How To Ask Questions
• FAQ
• Required Knowledge
• Beginner Mistakes

After this, go through the material on the practical aspects of
running an OS-dev project:

• What order should I make things in
• Code Management
• How kernel, compiler, and C library work together (and yes, this is useful reading even if you aren't using C)
• Using Programming Languages other than C
• Creating Disk Images, installing your loader and kernel into them, and running them

Then you should read up on the core technologies for the platform. Assuming that you are targeting the PC architecture, this would be:

• Real Mode, especially the section on memory addressing, and Segmentation
  Memory Map, Detecting Memory and A20 Line
• BIOS, and Boot Sequence
• Interrupts
• Bootloader and Rolling Your Own Bootloader
• FAT and SFS

Finally, you probably should give the Bare Bones pages - in multiple languages - and Baby Steps pages at least a brief once-over, even if you aren't looking to follow that process, as the do have some information in them that is relevant regardless of how you are writing your OS.

While this is a lot of reading, it simply reflects the due diligence that any OS-devver needs to go through in order to get anywhere. OS development, even as a simple project, is not amenable to the Stack Overflow cut-and-paste model of software development; you really need to understand a fair amount of the concepts and principles before writing any code, and the examples given in tutorials and forum posts generally are exactly that. Copying an existing code snippet without at least a basic idea of what it is doing simply won't do. While learning itself is an iterative process - you learn one thing, try it out, see what worked and what didn't, read some more, etc. - in this case a basic foundation is needed at the start. Without a solid understanding of at least some of the core ideas before starting, you simply can't get very far in OS dev.

Hopefully, this won't scare you off; it isn't nearly as bad as it sounds. It just takes a lot of patience and a bit of effort, a little at a time.

[zaval]

It would also help if you told us which assembler, toolchain, development platform (OS and hardware), and target platform, you mean to use

it seems the topic starter doesn't bother himself with a rubbish like this, he wants ASSEMBLY!!1 and that's it.

[SamTouraz]

Sorry for the late reply. I mean x86.

How can I actually use my programming for operating system development? It's not like writing printf("This is my OSn"); in C. I believe you have to do it differently. By the way, why doesn't the backslash symbol work on the forum? Security reasons? Never mind, I did another one.

[Schol-R-LEA]

Sorry for the late reply. I mean x86.

OK, that's a start. which assembler do you mean to use? What CPU mode are you targeting (Real Mode, 16-bit Protected Mode, 32-bit protected mode, 64-bit Long Mode)? What is your dev host OS (that is, which OS are you writing the code on - Windows, Linux, MacOS, etc.)? Which emulator or virtualizer, if any, are you using for testing (Bochs, QEMU, VirtualBox, HyperV, etc.)? How are you creating the disk images, and how are you writing the executable image(s) to them? All of these have an impact on how we answer your questions, because answers relevant to (say) NASM (Netwide Assembler, a multi-OS x86 assembler that uses the Intel syntax and is similar to but not the same as MASM) wouldn't always apply to MASM32 (Microsoft macro assembler, also using Intel syntax but with extensive macro facilities), or GAS (the multi-target assembler that comes with Binutils and is the default on Linux and MacOS, and uses a very different syntax based on the older AT&T assemblers - see Opcode syntax to get an idea of the differences).

The most important question is probably the CPU mode. A stock PC will boot into real mode by default (for backwards compatibility with MS-DOS and so forth, that's the default for most x86 CPUs, even though it is rarely used today), but the majority of operating systems today use either 32-bit p-mode, or the long mode introduced by AMD for 64-bit processors. Each of these has significant differences, and will drastically affect how you write the OS, especially for an assembly language OS.

While (AFAICT) some UEFI BIOSes can be configured to switch into p-mode (or even long mode) before loading an OS, and pretty much all stock bootloaders such as GRUB or Boot Magic will do so as part of the boot process, if you are writing your own loader for a p-mode or l-mode OS, and don't want to rely on UEFI, then either the loader or the first stage of the OS would need to switch to p-mode; note that you can only go into long mode by going into 32-bit p-mode first.

How can I actually use my programming for operating system development? It's not like writing printf("This is my OSn"); in C. I believe you have to do it differently.

That would be the case even in C; part of any OS development is writing the drivers for interfacing with the hardware, and the system calls for connecting the OS and applications to those drivers. While there are parts of the standard C library which can be written portably, at least some of the library routines need to be system-dependent; for example, while the printf() function can be written using a puts(), and puts() in turn can be written using something implementing putchar() or something similar, the putchar() routine would have to send the output to the driver, which usually would mean using a system call that either calls/implements the driver inside the kernel (typical of Monolithic Kernel and Hybrid Kernel designs, though hybrids usually load the drivers at runtime), or sends a message to the driver as a separate userland process (which is the typical Micro Kernel model, and could also be used by most hybrid kernels).

While I expect that you already know this, at least in a general sense, a lot of novices overlook this early on. They often also forget that buffering and streams are something that specifically need to be implemented. as an assembly coder, you may actually be at an advantage in this - you aren't going to be expecting there to be an extensive standard library ready for use, the way most programmers in a HLL would.

The point is, regardless of the implementation language, the OS needs to either implement its own interface to the hardware (including the console display and the keyboard), or provide a means to communicate to drivers which interface with the hardware. Most kernels - even microkernels - have their own internal mini-drivers, though these are usually only used during initialization. For example, most kernels will have a separate kputchar(), kputs() and/or kprintf() which talk to the console directly for things like startup and kernel panics.

Now, then, for the specific approach to interfacing with, say, the console output, you can find most of that in the wiki; while it is often written with C in mind, and uses C code examples, the code would not actually be different - just implemented in assembly.

For example, the information on writing to the console in text mode is on the page Text UI, though additional information can be found on the Text Mode Cursor page. The basic process - writing character/attribute pairs to the text video memory region that starts at physical address B800:0000 (hex), and keeping track of where in that buffer you are currently writing to - is the same either way, you just need to write the routines in assembly (the MOV instruction should be sufficient for writing the two bytes in most cases) and use the CALL/RET operations explicitly.

By the way, why doesn't the backslash symbol work on the forum? Security reasons? Never mind, I did another one.

Let's see: '\'. Hmmn, seems OK, to me.

[SamTouraz]

Sorry for the late reply. I mean x86.

OK, that's a start. which assembler do you mean to use? What CPU mode are you targeting (Real Mode, 16-bit Protected Mode, 32-bit protected mode, 64-bit Long Mode)? What is your dev host OS (that is, which OS are you writing the code on - Windows, Linux, MacOS, etc.)? Which emulator or virtualizer, if any, are you using for testing (Bochs, QEMU, VirtualBox, HyperV, etc.)? How are you creating the disk images, and how are you writing the executable image(s) to them? All of these have an impact on how we answer your questions, because answers relevant to (say) NASM (Netwide Assembler, a multi-OS x86 assembler that uses the Intel syntax and is similar to but not the same as MASM) wouldn't always apply to MASM32 (Microsoft macro assembler, also using Intel syntax but with extensive macro facilities), or GAS (the multi-target assembler that comes with Binutils and is the default on Linux and MacOS, and uses a very different syntax based on the older AT&T assemblers - see Opcode syntax to get an idea of the differences).

The most important question is probably the CPU mode. A stock PC will boot into real mode by default (for backwards compatibility with MS-DOS and so forth, that's the default for most x86 CPUs, even though it is rarely used today), but the majority of operating systems today use either 32-bit p-mode, or the long mode introduced by AMD for 64-bit processors. Each of these has significant differences, and will drastically affect how you write the OS, especially for an assembly language OS.

While (AFAICT) some UEFI BIOSes can be configured to switch into p-mode (or even long mode) before loading an OS, and pretty much all stock bootloaders such as GRUB or Boot Magic will do so as part of the boot process, if you are writing your own loader for a p-mode or l-mode OS, and don't want to rely on UEFI, then either the loader or the first stage of the OS would need to switch to p-mode; note that you can only go into long mode by going into 32-bit p-mode first.

How can I actually use my programming for operating system development? It's not like writing printf("This is my OSn"); in C. I believe you have to do it differently.

That would be the case even in C; part of any OS development is writing the drivers for interfacing with the hardware, and the system calls for connecting the OS and applications to those drivers. While there are parts of the standard C library which can be written portably, at least some of the library routines need to be system-dependent; for example, while the printf() function can be written using a puts(), and puts() in turn can be written using something implementing putchar() or something similar, the putchar() routine would have to send the output to the driver, which usually would mean using a system call that either calls/implements the driver inside the kernel (typical of Monolithic Kernel and Hybrid Kernel designs, though hybrids usually load the drivers at runtime), or sends a message to the driver as a separate userland process (which is the typical Micro Kernel model, and could also be used by most hybrid kernels).

While I expect that you already know this, at least in a general sense, a lot of novices overlook this early on. They often also forget that buffering and streams are something that specifically need to be implemented. as an assembly coder, you may actually be at an advantage in this - you aren't going to be expecting there to be an extensive standard library ready for use, the way most programmers in a HLL would.

The point is, regardless of the implementation language, the OS needs to either implement its own interface to the hardware (including the console display and the keyboard), or provide a means to communicate to drivers which interface with the hardware. Most kernels - even microkernels - have their own internal mini-drivers, though these are usually only used during initialization. For example, most kernels will have a separate kputchar(), kputs() and/or kprintf() which talk to the console directly for things like startup and kernel panics.

Now, then, for the specific approach to interfacing with, say, the console output, you can find most of that in the wiki; while it is often written with C in mind, and uses C code examples, the code would not actually be different - just implemented in assembly.

For example, the information on writing to the console in text mode is on the page Text UI, though additional information can be found on the Text Mode Cursor page. The basic process - writing character/attribute pairs to the text video memory region that starts at physical address B800:0000 (hex), and keeping track of where in that buffer you are currently writing to - is the same either way, you just need to write the routines in assembly (the MOV instruction should be sufficient for writing the two bytes in most cases) and use the CALL/RET operations explicitly.

By the way, why doesn't the backslash symbol work on the forum? Security reasons? Never mind, I did another one.

Let's see: ''. Hmmn, seems OK, to me.

x86
FASM
Ubuntu as a virtual machine (Linux)
DD (disk dump)

I will start at 16 bit but move on to 32 bit later on. I want to know how to use my Assembly for operating system development. You can't just do print hello world, you need to write to addresses like 0xb800 and setup things like GDT, BIOS Parameter Block (if you need it), IDT.

[Schol-R-LEA]

I will start at 16 bit but move on to 32 bit later on.

I would strongly advise against that. Real mode and p-mode are radically different, especially at the assembly language level. You would in effect be committing to writing two different operating systems, as the code for the 16-bit system would need to be almost entirely re-written when moving to 32-bit p-mode.

I want to know how to use my Assembly for operating system development. You can't just do print hello world, you need to write to addresses like 0xb800 and setup things like GDT, BIOS Parameter Block (if you need it), IDT.

OK, I am puzzled here, as I thought that the web pages linked to in my previous post provided ample information for these purposes. What are you confused by, and what parts of the wiki aren't clear (meaning we might have to work on improving them)?

Note that, regardless of the language in use, we can only give relatively general advice and examples; the code samples given are not meant to be actually used, they only illustrate the processes in a broad manner. We cannot give you code to use as there are so many different approaches to designing an OS that there would be no practical way to fit the pieces together - it would be less effort to write new code to begin with.

Even if that weren't the case, such a substitute would take away from the development process - since you presumably want to actually write the OS yourself, using such example code be contrary to your own goals.

I do not think this is your intent, anyway; you strike me as someone who wants to do as much as you can on your own. It is always worth making this disclaimer, however, since we have had so many people come here expecting to Frankenstein together an OS from existing parts that we even have the Duct von Tape archetype page to warn against it. Please don't take it as targeting you personally if that isn't your plan.

On a side note, I should mention that a BIOS Parameter Block is, strictly speaking, a FAT file system data structure, and is only required for partitions which use that format. However, most OS devvers who use a floppy (real or virtual) at least consider using FAT12 for their bootable floppy images, and if this is something you are thinking of doing, you'd want to take that into account. The main effect it has is that it further constrains the size of the boot block - rather than having 510 bytes to work with (512 - the 2 byte boot signature at the end of the boot block), you would only have 474 bytes (510 - 36) for a 'standard' BPB or 448 bytes (510 - 62) for an Extended BPB. The linked wiki page on FAT FS gives all the details on the BPB/EBPB data structure, if you think you will need it.

Since my own experience is that the some of the forum color schemes and layouts can make it hard to see the hyperlinks in the forum posts, here again are the links for the other things you mentioned: GDT, IDT, IVT (the Interrupt Vector Table used in Real Mode; it is a completely different data structure from the p-mode IDT, and is only used in Real Mode), Text UI, Text Cursor. If you have any questions about what those pages say, or have anything you aren't clear on, tells us in detail so we can address it here (and possibly in the wiki as well).

[Geri]

SamTouraz, you are maybe trying to feed the dog at the wrong side, and it will maybe accept your cube sugar balmly.

Schol-R-LEA is basically right. but the first question is what is your goal? ,,i writing an operating system in assembly'' isnt a goal. there are a lot of cpu platforms, and all have different assembly, and even different operational modes. first of all, what kind of goals you want to achieve with your operating system, what kind of purpose your operating system will fullfill?

https://www.youtube.com/watch?v=X7HmltUWXgs

you can do 16 bit, if your goal is to create a 10-20 kbyte sized graphicsal operating system for commodore64, zilog cpu western computers, or classic soviet computers. you will possibly even earn money, if you can make these computers more useful than they original is. but then you will still need to write a c and or basic compiter and/or interpreter for your system.

but i dubt this is your goal. i assume you just dont have one, you just probably decided to write a simple operating system as you maybe accumulated the technologic knowledge to do so.

but computers have 3 layers: its a science, a business, and an art at the same time. you have to well understand at least two of those at the same time of a topic before you just start jumping into something.

i would not suggest you to even write down a letter of your operating system yet, first and go and meditate what you really want to do.

[SamTouraz]

SamTouraz, you are maybe trying to feed the dog at the wrong side, and it will maybe accept your cube sugar balmly.

Schol-R-LEA is basically right. but the first question is what is your goal? ,,i writing an operating system in assembly'' isnt a goal. there are a lot of cpu platforms, and all have different assembly, and even different operational modes. first of all, what kind of goals you want to achieve with your operating system, what kind of purpose your operating system will fullfill?

https://www.youtube.com/watch?v=X7HmltUWXgs

you can do 16 bit, if your goal is to create a 10-20 kbyte sized graphicsal operating system for commodore64, zilog cpu western computers, or classic soviet computers. you will possibly even earn money, if you can make these computers more useful than they original is. but then you will still need to write a c and or basic compiter and/or interpreter for your system.

but i dubt this is your goal. i assume you just dont have one, you just probably decided to write a simple operating system as you maybe accumulated the technologic knowledge to do so.

but computers have 3 layers: its a science, a business, and an art at the same time. you have to well understand at least two of those at the same time of a topic before you just start jumping into something.

i would not suggest you to even write down a letter of your operating system yet, first and go and meditate what you really want to do.

I want to make an operating system for the x86 processor. I mean a bootloader can't do this

Code: Select all

section .data
folder db 'wow', 0

section .text
mov eax, 0x27 ; this is for creating a folder
mov ebx, folder
mov ecx, 077q
int 0x80

mov eax, 1
mov ebx, 0
int 0x80

By the way, I used this example because you're gonna think I don't know anything about Assembly.
Also, I do meditate.

It is always worth making this disclaimer, however, since we have had so many people come here expecting to Frankenstein together an OS from existing parts that we even have the Duct von Tape archetype page to warn against it.

Duct von Tape? That's the stupidest name I've ever heard in my life. You mean duct tape?

OK, I want a straight answer. I know how hard operating system development is. I don't want to copy code. I don't want to build on anything. I want to know how to use your Assembly (that you have learnt for a long time) for OSDev.

I understand there are different processors around (like ARM is for the Raspberry Pi and Android).

I want to make an operating system that runs on the Intel x86 architecture. I've checked out Ralf Brown's Interrupt List. That is better than what you suggest. The Intel manuals are just great. They're the best. However, they don't talk about how to print a string. 0xb800 is not mentioned in there.

For a forum and wiki since August 2000, it doesn't really help. Why do you have so many developer archetypes hidden away? Alta Lang... Bossy Boots... Duct von Tape.

I don't want code by the way. Stop misleading people. Why are you doing this? The Wiki tutorials are bad. Don't make excuses claiming your little community is esoteric.

Don't believe you get on people's nerves?

https://www.reddit.com/r/osdev/comments ... h=32a36470
https://www.reddit.com/r/osdev/comments ... h=230d7a31

I don't want trouble, OK? I want an answer to the question I posted. I don't want to be badmouthed. Don't go off the topic just because you don't know the answer.

= Most of the links on the Wiki don't work.
= You can't use MASM assembler (that is what Windows uses).

OSDev is lonely. There are no other forums or wikis that aren't annoying.

[Schol-R-LEA]

It is always worth making this disclaimer, however, since we have had so many people come here expecting to Frankenstein together an OS from existing parts that we even have the Duct von Tape archetype page to warn against it.

Duct von Tape? That's the stupidest name I've ever heard in my life. You mean duct tape?

Uhm... the archetypes pages are intended to be amusing, and to point out common faults. The titles are silly names for putative 'developers', intended to satirize the approaches they epitomize. The 'von' in this case is supposed to evoke a mad scientist - Herr Doktor Duct von Tape, in his castle LaBORatory sewing (or duct-taping) together a monster of an operating system from pieces of other OS projects.

All of the archetypes are examples of things people shouldn't do, describing bad habits and questionable focus, though that particular one is meant entirely as a warning. In this case, from things you have said, it doesn't apply, however the approach it describes comes up so frequently that I felt that making a disclaimer in that regard was necessary.

I want to make an operating system that runs on the Intel x86 architecture. I've checked out Ralf Brown's Interrupt List. That is better than what you suggest.

I am sort of at a loss as to what you mean by this. RBIL is a list of BIOS and MS-DOS interrupt routines; unless you are intending to write a real mode OS that uses the BIOS extensively for system services (something that is inadvisable, even for real mode, ~'s nonsense to the contrary), the only part of those which are applicable to you are the low-level disk and memory routines, and then only during the boot sequence.

The Intel manuals are just great. They're the best. However, they don't talk about how to print a string. 0xb800 is not mentioned in there.

Well, no, of course not. The Intel manuals only cover the CPUs themselves; they have nothing to say about the PC features which aren't part of the CPU, such as the bus, the video subsystem, the keyboard and mouse interface - all of these are facets of the motherboard, not the CPU, and while they are standardized (being rooted in the specific motherboard designs tracing back to the original IBM PC in 1981), they are outside the Intel manuals' scope.

Just to drive this point home: the way these features would work in a non-PC system that uses an x86 chip (a smartphone using an Atom processor, for example, or a single-board computer such as the MinnowBoard) would usually be entirely different, assuming they existed at all (which they often wouldn't in the case of an embedded SBC).

For a forum and wiki since August 2000, it doesn't really help. Why do you have so many developer archetypes hidden away? Alta Lang... Bossy Boots... Duct von Tape.

As I said, these are mainly meant as a diversion, not a guide. While they reflect the common behaviors of devs, they are for the most part negative - if you find yourself following one of those patterns, it is usually a sign that you are over-focusing on one aspect of OS development to the detriment of other facets of the system. Still, they are primarily meant to be humorous - a sardonic nod of self-awareness of our own mistakes and foibles - which is why they are out of the way. Of course, you could be asking why we have them at all, which is, to be fair, a good question; however, most technical sites do have some humorous sections, so... meh.

I don't want code by the way.

Good. That puts you in a minority of the new members, however, which is why we keep saying not to ask for any. It isn't really aimed at you, but a general warning to anyone looking to pursue the topic.

Stop misleading people. Why are you doing this?

I am unclear what you mean here. Please explain what you mean - if we are being unclear, we want to correct that.

The Wiki tutorials are bad.

The Bare Bones and Baby Steps tutorials are indeed flawed, and I am afraid we haven't put nearly enough effort into fixing them. However, that's in part because we aren't getting helpful feedback on them. We need people to tell us what problems they are having with them, so we can fix them.

The other pages aren't tutorials, and aren't meant to be tutorials. They are presenting information, which you then need to consider how to apply to your design. This is a common misunderstand, one which we keep trying to explain here and in the wiki: tutorials are not possible for these topics, for the same reason example code isn't possible. The answers are simply too interwoven with the specifics of the OS being developed to provide any. We are focused on explaining the facts, and while some code examples and detailed directions are given, they are deliberately vague and incomplete because a complete answer would require us to know your OS.

Don't make excuses claiming your little community is esoteric.

I am sorry, what? The topic is esoteric. Some of us - the more sensible ones, IMAO - are here because it is esoteric. That's what most hobbies are.

If your goal is anything practical, you shouldn't be trying this; you won't accomplish anything useful from it, and will waste a lot of time on it if you try to, because frankly, it isn't a useful topic - there simply isn't any niche for new operating systems, or much demand for new OS devs, anywhere in the world.

It also won't teach you much; it is about as relevant to programming in general as Byzantine architecture is to industrial food production. This topic is an intellectual cul de sac, and while that isn't a reason not to enjoy doing it or having an interest in it, if you think it will get you anything other than ego satisfaction from it you are simply wrong.

If you think writing an OS is a way to prove your skill at programming, well... it won't, even (or especially) if you are successful at it. While it is incredibly difficult and demanding, most of the skills it demands have no practical use except in OS dev - don't let anyone tell you otherwise.

OK, so yes, I personally am in it for something else, but that something else is basically intellectual wanking of an academic stripe. I have enough sense to realize that that's just an excuse for the hobby, not a motivation for it. If your primary goal in OS dev isn't ars gratia artis, you're Doing It Wrong.

Don't believe you get on people's nerves?

https://www.reddit.com/r/osdev/comments ... h=32a36470
https://www.reddit.com/r/osdev/comments ... h=230d7a31

I know of no online communities which don't have complaints like those. We have a lot of them, I know; honestly, we're abrasive, petty, and disputatious, and we know it. We do get on people's nerves, but most of the people in question are ones who are doing what you keep saying you don't intend to do - asking for code.

I don't want trouble, OK? I want an answer to the question I posted.

You really didn't ask any questions, at least not ones which could be answered in a meaningful way. You asked for general information, so we pointed you to the wiki. If you have more specific questions, ask away. We will be happy to answer them.

I don't want to be badmouthed. Don't go off the topic just because you don't know the answer.

OK. I don't know if this was directed at me, but if it was, I apologize for any slight you might have felt.

Most of the links on the Wiki don't work.

This is true, unfortunately, mainly because not enough time is spent on keeping links updated. We really can't excuse this, as it is simply a matter of lack of time to work on the wiki and the vagaries of volunteer projects, but we do ask that people fix broken links - or ask others to do so - when they are found.

You can't use MASM assembler (that is what Windows uses).

First off, this isn't true; a number of OS devs have used it, though we advise against it because it means the OS will never be self-hosting. Second, most of the references in question are to NASM (Netwide assembler), not MASM, though some refer to 'MASM' regarding syntax, as most other Intel-syntax assemblers (including NASM and FASM) base their specific syntax on the MASM dialect.

[iansjack]

This thread is beginning to drift into troll territory. I don't think it is possible to answer the OP's question in a way that will satisfy him, mainly because he doesn't really know what question he is asking.

@OP - If you don't like this site that's just fine. Use of it is not compulsory. But gratuitous rudeness is unnecessary and unproductive.