All off topic discussions go here. Everything from the funny thing your cat did to your favorite tv shows. Non-programming computer questions are ok too.
My last exam is on the 23rd of January, and then I'll be on holiday until some time in early/middle of February. I plan to dedicate most of this time to my OS.
Things that are rather high in my priority list (in this order):
Implement file system write access, and port FASM.
Write a very simple text editor (which basically means implement a textbox component.)
Write a driver for UHCI and OHCI because getting my old PS/2 mouse to work is such a pain when the button is broken...
This is probably all I can do in about a month, and most likely I won't be able to achieve this whole list in just a month, because it's a big set of goals, but after implementing the first two I'll be self hosting.
So, what are you guys planning to do this coming time?
You know your OS is advanced when you stop using the Intel programming guide as a reference.
I have three projects on my todo list (sorted by priority):
– my microkernel (Serelix);
– an app that lets you turn your iPad into an AirPlay receiver, that would allow using an iPad as an external display for a Mac;
– maybe an iOS client for MPD.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
- Alan Kay
Converting 10 or so drivers (including an entire USB-stack with OHCI, UHCI, EHCI, MSD + HID) to user-space drivers, and they need to conform to my new driver/device interface I've built the past month. It's gonna take forever It was a lot more work than i thought converting my kernel to a more micro-kernel approach. And if I have time I'm going to do some improvements to my filesystem!
MollenOS wrote:Converting 10 or so drivers (including an entire USB-stack with OHCI, UHCI, EHCI, MSD + HID) to user-space drivers, and they need to conform to my new driver/device interface I've built the past month.
Cool, someone else with userspace drivers! I doubt they're anything like mine though - mine doesn't support USB to begin with.
When you start writing an OS you do the minimum possible to get the x86 processor in a usable state, then you try to get as far away from it as possible.
Do you think it's so unusual to have userspace drivers? A while ago I had the impressions that, apart from OSes in their Hello World stage, models with at least some userspace drivers were actually more popular than pure monolithic kernels.
Kevin wrote:Do you think it's so unusual to have userspace drivers? A while ago I had the impressions that, apart from OSes in their Hello World stage, models with at least some userspace drivers were actually more popular than pure monolithic kernels.
Anyway, I'm another one with userspace drivers.
I thought userspace drivers were typically regarded as less secure and more clumsy to implement. Currently I don't have much in the way of protection in my OS (i.e. any code can access the hardware directly) but once that's sorted out I plan on having drivers contain a particular metadata bit to indicate "this code needs direct access to the hardware" probably accompanied by some form of user authorisation (i.e. an alert asking "Do you want to allow <name of driver> to have direct hardware access?" when the driver is loaded for the first time).
When you start writing an OS you do the minimum possible to get the x86 processor in a usable state, then you try to get as far away from it as possible.
How could they possibly be less secure than drivers in a monolithic kernel? It's true that, at least without an IOMMU, a malicious hardware driver probably has ways to escape into ring 0 and get access to kernel memory or other processes. Exploiting a buggy driver to do the same thing might not be that easy, though. And without an attempt to exploit, a buggy driver will likely just crash itself instead of overwriting memory of the kernel or other drivers.
So in comparison with a monolithic kernel, where the driver would be in ring 0 to begin with, we definitely didn't lose anything, but probably have reduced the impact of driver bugs.
About "clumsy to implement", I'm not sure if I would call it "clumsy", but certainly a bit harder - even more so, if you care about performance.
stevej150 wrote:I like your plans. I would love to see more programs and a start menu. Looking good!
I've already started very early work on a graphical shell. This is the program which will provide a start menu and a "run program" dialog.
The LICENSE file in the root of your project states that it's licensed under the MIT license, while at the top of your files you add "Copyright [...] all rights reserved". Which is it?
com.sun.java.swing.plaf.nimbus.InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState Compiler Development Forum
matt11235 wrote:The LICENSE file in the root of your project states that it's licensed under the MIT license, while at the top of your files you add "Copyright [...] all rights reserved". Which is it?
It's MIT. I'll update the copyright notices tonight.
You know your OS is advanced when you stop using the Intel programming guide as a reference.
matt11235 wrote:
The LICENSE file in the root of your project states that it's licensed under the MIT license, while at the top of your files you add "Copyright [...] all rights reserved". Which is it?
Kevin wrote:It doesn't, but depending on how you read it, it contradicts the "All rights reserved".
Agree.
Details: "Originating in the Buenos Aires Convention of 1910, it no longer has any legal effect in any jurisdiction." the phrase itself does not bear any effect, but as "a handy convention widely used by artists, writers, and content creators to prevent ambiguity and clearly spell out the warning that their content cannot be copied freely." it completely contradicts the MIT license terms.
It was a lot more work than i thought converting my kernel to a more micro-kernel approach. And if I have time I'm going to do some improvements to my filesystem! 
