OS

[~]

Can you please tell me an initial topic to solve (and its key points) as if I didn't know absolutely anything about OS development?

I want to solve the implementation of an OS based on the successive solving of the topics/key points that it covers.

Once a topic that can be fully added next is picked, it will have to be solved until the end.

So what topic/key points should I start with if I didn't know the tiniest about OS development as the very first coding step?

[iansjack]

Start by writing down what an OS is and what services you want yours to provide.

[~]

Start by writing down what an OS is and what services you want yours to provide.

The main goal is to search the complexity size of the standard PC (as the analog of the basic calculator of computers), PS/2, etc., to completely explain it functionally, like programmed things. Learn each detail by memory, clear, like normal study. If the operating system development kit isn't finished (one that could even be sellable), this is a good way of reviewing all functions to do it fast without doubting. Keyboard functions (controller), nonstandar drivers, full list of x86 CPU functions in existence, present or not. Making references of yearly projects to feed the different subsystems of the OS is a good way to make it advance.

Developing each topic until the end by discussing the effect of certain code from references and correcting (the Wiki, manuals, papers, books, other programs) is also an immediate way to turn knowledge into code. All topics need to include code to work on until turning it into a component. Minimal or middle-sized adaptations to add components may take up to a few weeks, but major components will normally need a year to reach usefulness.

An OS is the basic standard software tool that builds up the functionality of the whole system, like pliers, like defining their whole structure, like doing that for a toolbox, from functionality to visual design.

Given it's a daily use tool, it should be fully open source, and the code itself should answer easily all answers an user has about how it and the programs perform its tasks step by step leaving no doubt about any details.

It needs to emulate standard hardware access and basic devices across platforms, and provide old and new programming interfaces, to take advantage of proven computing elements.

The end result needs to be like a calculator, between hardware and software: Standard, predictable, with standard functions from the x86 PC and other old emulated machines that will never be lost, and on the other hand, that will always be the most important aspect that the system provides (no matter how much the hardware changes or if somebody only knows how to use the basic functions of a computer, the way of programming it with default tools will always be exactly the same).

It needs an amount of emulation that affects the real underlying hardware, as well as implementing the device subsystems from existing OSes for keeping full functionality intact over time.

An OS always has the goal of being regularly useful for daily usage so, no matter the development speed for being fully able to emulate the services of existing OSes with original programming approaches, an OS cannot regard anything as "obsolete" as it is a standard tool with the intention to make evident to the user how it and its applications do their tricks to learn, for example by making logs of the resources of an application as they are invoked, then the user can examine the tasks performed so far by a given application or the kernel itself, along with the system documentation/sources to explain how each resource was employed in a reproducible manner.

In the end it must provide a calculator for standard hardware/software programming, so its basic operations/services/APIs/ports will always be the same and thus it has to be able to emulate any other OS, hobby or big, as its job is simply to be a complex programming calculator with the whole range of computing to explain it at run time.

Ported, own and emulated bootable stand-alone programs without OS designed for bare metal hardware need to be supported natively for standard and driver-based hardware.

There needs to exist a single reference that can be turned immediately into implementation by showing simple and complex dependencies that make possible something as to know exactly what to do to achieve an implementation of each thing in a program.

The OS needs to come with installer/source/documentation discs.

It also needs to be portable, meaning that it should be a simple subfolder in a disk partition with a separate bootloader (from a floppy, CD, USB or removable media/network. It will make it possible for it to coexist with the other OSes like an additional application, without having to uninstall them or having to alter the bootloader (no file system changes must occur for basic execution).

The OS would be cleaner if it is compiled from sources. Besides the base CD images, downloading and compiling specific function versions of the software that will never be deleted from a global GNU/public domain/licenceless owner-less repository would be ideal.

That's exactly what I'm trying to do with my OS. I know it will be cleaner, I will have to keep final versions of all functions for even being able to download and compile my software/OS, never really downloaded as dull ZIPs.

[FusT]

I did not understand a single thing in that entire wall of text.

What are you trying to accomplish exactly? I think you might be shooting for the moon (or better, Jupiter) while you're still figuring out how to walk.

[iansjack]

Absolutely meaningless.

I think the OP needs to read a few books on OS design before proceeding further.

[~]

There is the vast MSDN collection in CD and at msdn.microsoft.com, the MSDN newsletter, and Windows versions (instead of just buying regular Windows versions, MSDN ones can be used to keep a clear study of operating systems).

There are the books from Ben Lunt.

Abraham Silberschatz.

Andrew S. Tanenbaum and MINIX.

We could stare at kernel.org, read the code updates, subscribe to the mailing list and wait for enlightenment ideas.

We could read all of the code and tutorials from mirrros or live websites, from QNX Neutrino (information to change to graphics mode 640x480x16 manually), from OSDever.net, MegaTokyo, the Chris Giese website, Singlix.net/Singlix.com, ReactOS.org, VisOpSys.org.

We can choose several snippets to start from. Entering protected mode, setting the GDT, the IDT, the PICs, detectinc ATA disks, driving ATAPI readers (open/close the tray, start/stop spinning), programming the keyboard, the PS/2 mouse, compiling kernel skeletons, installing our own bootloader (maybe with a way of restoring the previous one at least with iBored for hard disks), writing to the text-mode screen, hardware or software multitasking, paging, The Starman Realm (partition information, partition types list), scottie.20m.com (FAT records), BiosCentral.

Obviously we will choose the one style that allows the full expansion to any functions an OS is capable of.

Can someone without full UNIX experience start writing an UNIX-like platform? Can someone with little to nearly no knowledge of the actual UNIX internals (Commodore/Atari/DOS people) be pointed where to begin? Shouldn't it be better to start with a raw platform, only with access to the actual hardware and system primitives that allow supporting UNIX, DOS, NT architecture, OS/2, MacOS from those machines that have absolutely everything built into the color monitor (all gray in color, no transparent blue stripes) and that one could think that already use ATA disks?

I could say that deciding the language and tools would be the next step, which could need experimentation or clear prior experience. Such language and tools should be accessible to the very oldest desktop or handheld machines, with the intention to get fully free technology, instead of depending on something that will only ever run/properly compile on the newest environments as it is. Limit the core only to basic C, C++ and Assembly, and leave the rest for an already-working system as secondary programming environment until it compiles elsewhere.

[Schol-R-LEA]

Absolutely meaningless.

I think the OP needs to read a few books on OS design before proceeding further.

Well, we all already knew that ~ is both ignorant and insane. However, since he didn't take that advice in the (multiple) threads regarding his botch of a C compiler, I doubt he will listen now.

[iansjack]

The problem is that beginners come here for advice and believe what he says.

Caveat emptor.

[Ethin]

Yeah, the comparisons in his multiple posts here are entire nonsense. An OS is nothing even remotely close to a calculator -- it is about a thousand times more complex.

Typically, how I explain to my non-tech friends what an operating systems is like this: an operating system (OS) is the program that initially starts when you power on your computer (i.e. Windows, Mac OS). It is what makes it possible for you to do what you use your computer for today.
Of course its far more complex than that, but the last thing you want to do is to over-complexify the problem to people who do not understand technology as well as you do. Its quite sad that people take advice from ~ at all; its obvious, to me, that he has absolutely no idea what he's talking about. That then leads me to question his credibility in general.