Quote: "What amount of progress did you make on it?"
Well - I made a direct hardware IO "Floppy" driver one might say - (in the days when you could call Intel and they would snail mail you a 2 inch thick reference book on anything you wanted) directly to the floppy "controller" for disk based booting - reading the boot sector is done by bios - but you need to have code in the boot sector to load your loader LOL (sounds silly but that's how its usually done). Formatting the floppy - though you have tons of control programming the chip - was a pain - so I stuck with the standard 80 track, double density format.
I also wrote an EIDE lib and my own filesystem - that after I explained it to someone they said I made something a kin to the old IBM VSAM file system. In short - it allows reading files forward and backwards, and you never delete a file - they just get flagged "offline" with a unique ID number - like a autonumber - and when there is no more space - the "Oldest" (based on autonumber id) "deleted" file becomes the one that gets written on next. So you literally fill the drive first then it hunts for "emptys" one might say.
I basically alluded I wrote bootstrap code that loaded a loader - (bootstrap is tiny - and the loader was kinda big compared to a single sector - the loader would read from either floppy or harddrive). The loader would then start loading what people call the kernal - upon loading it - it would set the meory model, set up the task segment registers for a couple threads, and then call the loaded "kernal" code. I never called this part a kernal - I referred to it as the "os core" but that's because I'm self taught and didn't always know the "mainstream" names for thing back then.
I had my own EXE format - complete with memory usage headers, and relocable or non relocatable code "blocks" it could load and fire. You could switch tasks, and what I thought was neat about the whole thing was that you had to give an EXE rights to use resources, like users - but a user's didn't trump the exe rights. Sound Silly? It was done with the idea that only an administrator could set how much access to resources an executable could have... and looking back - this would eliminate most virus. I wrote it in such a way that if you ran an application - without any - rights you would see all the resources it "tried" to access. This was done so if it wasn't working the way it was supposed - you could discern what it needed access to and grant it.
This was entirely written in MASM (Microsoft old Macro Assembler) and I used NASM for some things, and old dos DEBUG and a utility I wrote - to create the bootsector stuff.
It was completely console based - and I programmed the video card directly - writing to the memory locations that show the ascii "console" and colors... like fullscreen console "looks" now.
It was called COPS - (Complete [control] OPerating System) but some other guy had one called the same thing and I didn't know - I was a little urked when I found out... His stood for something different - but - I liked the old Boot Up screen - you didn't see ANYTHING microsoft - the screen would turn Blue... and in yellow text you'd see: "C.O.P.S. Loading..." Then you'd get a command prompt not unlike linux or dos.
It only ran little assembly programs I wrote - and I had to write them one way to test in MSDOS (in PMODE) - then make sure the code was relocatable, and then literally "hand write" the exe header in MASM - (so it was all byte aligned, and had all the correct data in the spots the "kernal" expected to be able to load and launch it) then hand place it into the filesystem with a utility I made in Turbopascal to access the harddrive from dos the way COPS did natively... (I didn't have networking either BTW) .. then change that harddrive to the boot one - and fire it up - A LOT OF WORK!
so - I got 32bit mode working, booting, security, homebrew filesystem for large EIDE drives, and ability to lauch "programs" (which were only assembly language - but if I wrote a c compiler for it - (or its own macro assembler for that matter) then you could write apps in c (or assembly) natively without needing to "leave" and boot DOS to make things for it... this would involve writing text editor, compiler, linker - etc.. all from scratch as it didn't follow any (possibly copyrighted) specifications from anyone.
My reference manual was a bunch of intel books on different processors, and the "other" chips reference manual (that had the floppy stuff in it) and this book I bought on 32bit systems archietecture.. which taught me about designing the various memory models - (you typically choose one - Novell and I think early WinNT were flat memory model for example) - and it showed me was task segments were, how the TSS structures worked - (it turned it closer to english - intel reference had the info too but until you knew it a bit - it seemed kinda of hard for me to understand... but once you start banging on it and some thing works... (after 100 tried and reboots) you start to get it.
--Jason
