I want to make a low memory OS

[OS-BONES]

I want to make an OS for my over crowded IBM that I can't format.
It needs to take up under 1 megabyte of space and have some basic files such as a simple text editor and be able to print.
Can this be done?

[HOS]

I'd say yes, I'm trying to do something very similar, and its only 20kb so far...

just try it!! start working on stuff.

[Solar]

Can this be done?

AmigaOS 3.1 was capable of many more things than just text-edit and print, and took up less than 3 megs, full install. It could be booted from a 880 kByte floppy disk, and with some tinkering, you could squeeze quite some tools into that.

MS-DOS was fully useable (as far as you can call that sorry excuse for an OS "useable") from a 1.44 meg floppy disk, too.

The QNX demo disk boots from a single 1.44 meg floppy disk into a graphical desktop including fully unicode-enabled web browser.

So, yes, it can definitely be done.

[Curufir]

You could take a look at MenuetOS http://www.menuetos.org/ to get an idea of how much you can squeeze onto a floppy.

Remember that the OS itself doesn't actually have to be that big. The thing that takes up the vast majority of space on any system is the applications and their data.

[OS-Bones]

Do you know of any tuturials on the net?

[Solar]

Well, you don't have to do anything fundamentally different, so there are no "low memory OS tutorials" on the net. Just focus on low memory usage when you make design decisions.

[mr. xsism]

are you planning on using C or assembly? For some reason that i still can't quite figure out completely, C produces a little fluffier code than straight assembly. That's one decision to make.

Then, do you consider stuff like DMA buffer, Page Structs, TSSes, GDT, ISRs, and other data areas part of the kernel? If so you will end up taking morethan 1MB RAM. But you can easilly limit the binary size.

Also, plugins can help you out with size of the kernel binary because they can be loaded while the kernel is "ON" so they don't have to be statically compiled in.

A GUI usually takes about 6MBs for a simple 640x480 16bpp dual buffer plus BMPs for widgets and themes.

Just some things to think about

-mr. xsism

[Solar]

Hmm... I agree that C does produce a bit more "fluffier" code than straight ASM. (Nice word, "fluffy". )

However, I'd strongly advise against "doing everything in ASM". It's a hell to maintain, and I know very few "pure ASM" projects that made it anywhere near even beta stage.

Unless you know your Intel opcodes inside out, you're bound to produce less efficient code than your trusty C compiler. C code should be sufficient for any but the tightest memory requirements (think real tiny embedded systems). Hell, even mobile phones run Java these days, and Java bytecode sure as hell ain't memory efficient.

[Schol-R-LEA]

I agree with Solar. The best solution is write the code in C (or whatever HLL you prefer) get it working and acceptably debugged, then test and profile it to find the 'hot spots' (points of high activity and/or memory usage), and finally rewrite just those key points in assembly (which will probably come to no more than 1% of the code). Doing it that way, you'll get better efficency than you are likely to with an all-assembly design (no one can write perfectly optimized code all the time, after all), with less work and fewer bugs.

[OS-Bones]

Um I don't really know what you're saying, I'm new to this whole thing.
I know that C is a type of BASIC programming, but thats it.
I need someone to explain.
Also a website tuturial would be helpful

[RuneOfFire]

I know that C is a type of BASIC programming, but thats it.

C is definitely not a type of BASIC. They're completely different.

Here's a pretty good C tutorial.
There a tons of them on the internet, it's just a matter of using google.
(Here are some other results for "C Tutorial")

[Solar]

Quick rundown on Machine Code - Assembly - C - C++ - Basic.

A CPU executes machine code; that's just '0' and '1', with certain sequences making sense to the CPU.

Assembly is a way of making machine code comprehensible for humans. Instead of giving 100101 for "move a long word", 110 for "from register EAX", 010 for "to memory", and a 32-bit binary sequence for the memory address, you say

Code: Select all

movl %eax, $04001280

(No, the binary encoding is not correct. I'm too lazy to look it up.)

The Assembler will take the above code, and assemble it to machine code.

One example of functional Assembler:

Code: Select all

               mov  $start, %ebx
               jmp  2f
1:             call *(%ebx)
               add  $4, %ebx
2:             cmp  $end, %ebx
               jb   1b

This takes an array of function pointers starting at $start and ending at $end, and executes each function pointed at.

Now this is still pretty arcane. C, on the other hand, is a "high-level language" (HLL) where you no longer try to understand the CPU, but make the CPU understand you. Above code would look like this in C:

Code: Select all

typedef func* (*void)();
for (func = START; func != END; ++func)
{
    func();
}

Granted, that's still not beautiful (not even for C code), but it's already much "clearer" than Assembly. You feed this code to a compiler, and it will compile this into machine code that will be only marginally less effective than hand-optimized Assembly (if you're an Assembler professional), probably even more effective (if you're an average Assembly programmer). While there are some parts of an OS that have to be done in Assembly for technical reasons, C has been the OS-implementing language of choice for decades.

C++, now, is a superset of C that does introduce much "syntactic suggar": Stuff that makes large-scale programming, object-oriented programming, and generic programming much easier. This cannot be easily displayed in a short code example. If you aren't a hard-core C++ coder to begin with, forget about using it for OS development, since it's a much more complex language than C. (Although the claim that it is per se inferor to C is false - I'd say it's on par, depending on what you're looking for.)

Basic, now, is a completely different ballgame. Assembly, C, or C++ are translated into machine code, and the translators (assembler / compiler) can be instructed to generate machine code that does not assume the existence of an operating system.

But many Basic dialects are interpreted languages. That means that the Basic code is translated into machine code at runtime, which requires the presence of an interpreter in the system. Even if you happen to have a Basic compiler at hand that directly translates Basic into machine code, that would still be machine code that assumes the presence of an OS for delegating such tasks as opening a file or printing a text to screen.

Basic was simply not designed for system programming. It is likely to have poorer performance and larger memory requirements. It is poorly standarized (is it at all?), so what works on one Basic interpreter breaks on another. No OS I know of has ever been written in Basic, so chances are slim that you'd find someone who can help you with OS-level Basic code.


Bottom line: You will need several dozen / hundred lines of Assembly. Whether you use Assembly, C, C++, or Something Completely Different (tm) for the rest is up to you, mainly depending on your experience with the languages. The most common choice is C, since Assembly is considered too low-level, and C++ too new / complex / little known.

Whenever you go for Something Completely Different (tm), be aware that you will be out in uncharted waters with little to help you tutorial / literature / forum wise. Stay away from languages who have not been designed for this kind of work, which includes Basic, Pascal, Cobol, AP/L and Intercal.

[Pype.Clicker]

now, at the risk of being a Servant of the Dark Side, if all you want to have is a very small OS that allows you from a single boot disk to move around the FAT filesystem and run a text/hex viewer (text editor is a bit more complex but it should be feasible too) and if you don't know about C but are pretty good at assembly and know the BIOS functions pretty well, i'd say than 16 bits unreal mode is probably your best choice.

You'll have BIOS to assist you in loading stuff from the hard disk, you'll have full access to physical memory for storing data (thus the ability of quickly manipulating large files or whatever...) but you'll have to cope with far jumps, will not be able to use code larger than 640Kb without the help of overlays and will probably have hard time when you'll like to add something like a "clock" program ...

It's more a "figure de style" than a really useful job as Solar and the other said, but it could also be the quickest path to your requirements.

[OS-Bones]

This is too much information.
Keep it simple and tell me where to start on making my OS.
I'm a complete newbie and I don't know what you're talking about half the time.

[Slasher]

hi, I suggest you then read up on os theories and dev. then learn the architecture you want to dev for,most of us dev for the x86 family of computers. if you are also doing x86 development then read the intel docs.a search on intel 386 manual will get you the 3 volumes. hope this helps