it has a "chess client" and an "mp3 server", i'm fucking sold.
Name:
Anonymous2007-11-02 10:36
writing the drivers is the worst part
have fun using BIOS and ancient standards because you can't find any documentations for your devices
Name:
Anonymous2007-11-02 11:16
>>9
"The design goal has been to remove the extra layers between different parts of an OS, which normally complicate programming and create bugs."
This idiot obviously doesn't understand the benefits of abstraction.
Name:
Anonymous2007-11-02 11:51
Stupid question, but it'll be fun to hear the cursing: Does anyone think it possible to write an operation system in a toy language (like LISP, Java, or Haskell) without writing most of it in assembly or C?
Minix 3 still lacks virtual memory, so programs like Firefox won't work. Various critics think the author writes Minix just to publicize his books. That said, there are dozens of Minix-based packages fitting on 1 or a few floppies. tomsrtbt was the best known at one time. Dillo and links/lynx were associated web browsers which now support graphics.
No one mentioned Freedos yet. Or the various open source DOS emulators like DosBox and dosemu.
BusyBox is a subset of UNIX commands meant to be small enough to fit in an embedded system.
BeOS predates Win3.1 as I recall. I don't know how small it was.
The learning curve might go faser if you join a project that solicits help like ReactOS and Wine.
Name:
Anonymous2007-11-02 21:17
How to write an OS
1 - Figure out every single low-level details (down to the registers and how they operate) of the following components:
A - CPU (duh)
B - FDD interface
C - IDE interface
D - VGA interface
2 - Write bootloader
3 - Develop a filesystem
4 - Develop a system call interface and what functions your OS will boil everything down to
5 - Develop a driver framework and a way to address devices
6 - Actually program all that
7 - Develop basic drivers
8 - Start writing basic tools to manage filesystem
TADA, A NEW OS
Name:
Anonymous2007-11-02 23:45
>>20
Speaks the truth. The documentation is out there and people have done it. But it ain't easy.
It's fucktons easier to do on a simple embedded environment. (e.g. Motorola/Freescale based system with code on ROM and any persistent date on BBU RAM) I'm writing a simple multitasking OS for a course in school. Not very hard. Really really fun stuff.
>>21
The Nintendo DS (and, to degree with which I'm much less familiar, the PSP) also provide easily-obtainable platforms to do embedded systems work on. The DS requires you to get some extra hardware, and the PSP has the firmware version hassles, but other than those headaches the hardware is very usable.
In case anyone is looking for an embedded system to experiment with.
Name:
Anonymous2007-11-03 3:57
>>15
No, the whole point of those extra layers is that there can be interchangeable hardware or services behind those layers, and the same programs will still work.
Name:
Anonymous2007-11-03 6:40
>>20
wait, how does one "address devices" in a Win32.
On the simple as possible mentality:
1. use a prewritten filesystem like EXT or possibly NFS(which is well documented and standardised.) They aren't much more complex than the ones you could write. Not reinventing the wheel means it probably won't end up triangular in shape.
2. There is a fuckload of BIOS functions as interrupts that are meant for everything from plotting pixels, to setting the clock to writing a floppy. Most of them are slow on modern architecture, not used and hence, not reliably present. That doesn't however mean you cannot use them for a testing platform instead of the IO-ports and DMA.
3. The zen art of loading and running programs will probably mean you cannot run programs built on other systems. The loader Minix uses might still be compatible with Linux programs, which probably is your best shot at running something intresting. That is if you don't want to write a C or assembly compiler to go with that OS.
4. BSD-sockets, implement them. Again standard, well documented, portable.
IO-ports and DMA take me back, God damnit I've grown old!
Name:
Anonymous2007-11-03 15:32
IDEA:
Buy a cheap cell phone with no plan
Write an OS for it
ZING
>>26,28
I think he meant programs that don't use anything except the CPU.
Name:
Anonymous2007-11-03 16:22
>>29
Kind of hard to write programs that don't use RAM at all. I suppose it's possible, technically, but it wouldn't be able to do much.
Name:
Anonymous2007-11-03 16:22
I'm >>27 and I was actually just trolling. I think >>1 is just a moron.
Name:
Anonymous2007-11-03 17:53
>>19
You forgot FreeDOS-32, which only comes as a floppy image right now.
Name:
Anonymous2007-11-03 20:43
>>24
Good question. I'm not familar with Win32 at all.
To understand what I meant, think of how DOS used to do it. The console was addressed through "CON", the printer through "LPT", block devices through "A", "B", etc. I know there were DOS function calls that wrote directly to screen memory and stuff like that, outside of this ancient CPM device model.
I know under Linux, everything is in the /dev directory and you work with it using the same function calls as for files. It's not perfect as some devices need special ioctl's to do things, but it's way more consistent.
Name:
Anonymous2007-11-03 22:02
Is there actually a good guide for building an own OS yet?
I tried it years ago and stopped after the bootloader because Google failed me on the important stuff like IO ports.
>>33
The DOS addressing didn't come to mind... mainly because when I was writing stuff in the 90s the DOS system of referring to devices was totally inadequate. I have particularily fond memories of the debugging for sound cards and modems - with no drivers, no interface, no standards and very little sketchy documentation.
Also the listing for block devices in DOS is actually just 0,1,2... the characters are "added" by the user-called program and the directory string resembles an URL in that it has to be handled in pieces: first convert and set the possible device, then parse the directory and open the file.
I've been a Linux user for some time, but what I've gathered from some bits and pieces of programming on WinNT kernel, you basicly "address" the devices via standard API:s under the names like user32.dll, kernel32.dll and the functions listed therein. There is also a "syscall" instruction that works in about the same way as an interrupt that allows you to pass directions to the kernel from user-mode. Of course once your program is in the "well-protected" system-mode you can just pass instructions to the system like you did back in the day. But, to my knowledge beyound the .dll API:s there is no standardized way of addressing devices. In Gates-think: "users shouldn't worry of devices or they might develop to dangerous hackers and threaten the monopoly. On the other hand, proper (non-malware) programming is done by professionals under big projects with access to propietary resources such as the source and documentation for the firmware and drivers. Coding needs be neither simple or fast, don't worry about it."
Name:
Anonymous2007-11-04 8:51
>>36 blah blah windows conspiracy nerd talk
In Windows, just as in Linux, it comes down to what the developer of the driver wants you to have access to, not to a limitation in the architecture of the OS.
Name:
Alabama!0okrDnkUYI2007-11-04 14:09
Color Forth comes with a 63KB operating system. "The current colorForth environment is limited to running on Pentium based PCs with limited support for lowest-common-denominator motherboards, AGP video, disk, and network hardware."
Charles Moore >>HATES<< large software and has a history of completely rewriting entire sytems down to the metal to make them as small as he can.
Here is the IDE hard disk driver. The ENTIRE driver:
----------------------------------------
bsy 1f7 p@ 80 and if bsy ; then ;
rdy 1f7 p@ 8 and if 1f0 a! 256 ; then rdy ;
sector 1f3 a! swap p!+ /8 p!+ /8 p!+ /8 e0 or p!+ drop p!+ drop 4 * ;
read 20 sector 256 for rdy insw next drop ;
write bsy 30 sector 256 for rdy outsw next drop ;
----------------------------------------------------------------
I remember reading years ago Moore's articles stating he has GUI, windows manager, networking, and all the niceties you expect in a modern OS. Since he intended to compete in that market. All in a few hundred kilobytes.
My own experience is limited to the old Sun workstation Monitor program, a Forth in a ROM chip that you could program to control the hardware.
Name:
Anonymous2007-11-04 14:42
>>36
NO DRIVERS
NO INTERFACE
NO STANDARDS
NO DOCUMENTATION
MEMORY ONLY
FINAL DESTINATION
Name:
Anonymous2007-11-04 15:53
>>38 with limited support for lowest-common-denominator motherboards, AGP video, disk, and network hardware
And that's they way it will always be, because...
Charles Moore >>HATES<< large software and has a history of completely rewriting entire sytems down to the metal to make them as small as he can.
...the author is a retard.