This forums is for OS project announcements including project openings, new releases, update notices, test requests, and job openings (both paying and volunteer).
Here's the second public release I ever make in my life (the first being ZeroOS 0.1 in late 2014 or early 2015, I think.)
This release boots to graphics mode, and launches two programs at the same time to demonstrate multitasking and userspace (make a register dump at any moment ) Each program creates a window, on which the user can use the mouse to draw on the window, to demonstrate window manager events as well. YouTube video to demonstrate.
New stuff in this release:
Window event support.
Demo programs to demonstrate multitasking with ring 3 protection.
Major bugfix in memory manager.
Minor performance tweaks in mouse driver.
First release that boots on real hardware without page faulting.
Missing stuff in this release:
Unstable release; source code will be distributed with stable releases only.
MTRR configuration crashes some HW; so this release does not configure MTRR.
The graphics library is heavily optimized for 32-bit video modes, and 24-bit modes will suffer just from moving the mouse.
Nice work, congrats on the release, will try it out.
Would take a closer look, but why do you not provide the sources? Saying that it's GPLv3 but not providing the source violates GPL
Greets
He said he will release the source code soon.
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.
You are saying that you won't release the source of this (unstable) release. Which is exactly what Max said. And, as he said in an earlier post, that means that you can't claim the GPL for it as people can't "modify the code".
That you are going to release the source of a future release is irrelevant.
Technically you only have to provide the source if the source was provided to you under the GPL. That is not the case here, as omarrx024 wrote the source code rather than receive it from someone else.
Rusky wrote:Technically you only have to provide the source if the source was provided to you under the GPL. That is not the case here, as omarrx024 wrote the source code rather than receive it from someone else.
I believe that to be incorrect:
If you make object code available on a network server, you have to provide the Corresponding Source on a network server as well.
If you make object code available on a network server, you have to provide the Corresponding Source on a network server as well.
That only applies to those who received the project under the GPL. The original author is not bound by the license in that way- that is what makes it possible to dual-license, or to sell license exemptions, for example.
But not to derail this! Nice work getting everything working together at this scale- a few hardware devices and simple userspace working. What are your goals moving forward? Do you have a target audience? Do you plan to support long mode? What pieces do you want to move into userspace, with what sort of syscall API? What design decisions can we already see that we might not have noticed?
Rusky wrote:But not to derail this! Nice work getting everything working together at this scale- a few hardware devices and simple userspace working. What are your goals moving forward? Do you have a target audience? Do you plan to support long mode? What pieces do you want to move into userspace, with what sort of syscall API? What design decisions can we already see that we might not have noticed?
Thanks! First, I plan to make this OS self-hosting with an installer (i.e. it can boot from a generic "installer CD" and install itself to a hard disk). I also want to add more hardware support: AHCI, HPET and USB are in my list, although USB is rather far. I really do this just for learning and for passing time; I don't expect an audience to ever use it. I do plan to support long mode, but not any time soon. 3rd party drivers will run in userspace; native graphics drivers, sound drivers and network drivers will all run in ring 3 and not be built-in to the kernel.
You know your OS is advanced when you stop using the Intel programming guide as a reference.
Rusky wrote:But not to derail this! Nice work getting everything working together at this scale- a few hardware devices and simple userspace working. What are your goals moving forward? Do you have a target audience? Do you plan to support long mode? What pieces do you want to move into userspace, with what sort of syscall API? What design decisions can we already see that we might not have noticed?
Thanks! First, I plan to make this OS self-hosting with an installer (i.e. it can boot from a generic "installer CD" and install itself to a hard disk). I also want to add more hardware support: AHCI, HPET and USB are in my list, although USB is rather far. I really do this just for learning and for passing time; I don't expect an audience to ever use it. I do plan to support long mode, but not any time soon. 3rd party drivers will run in userspace; native graphics drivers, sound drivers and network drivers will all run in ring 3 and not be built-in to the kernel.
A smaller OS would be much more usable if it could be simply installed into a subfolder of the root directory (like "OS_Name_Folder") inside an already-existing partition (FAT, NTFS, Ext...) and if all installs of that OS could be searched and selected from a bootloader in all existing partitions from external media (avoiding installing or altering the most used booting configuration of the machine).
It all would be much easier if the bootloader was on a removable media like USB, floppy or CD/DVD, and if it just passed control to the OS on an existing formatted internal hard disk.
In this way the OS could be installed like any other regular application and then booted with, say, a configured USB stick to boot into it. Then nothing would need to be altered from the existing user OS and it would avoid keeping an exclusive hold on the machine against the rest of OSes and bootable system executive code applications/tests/demos.
It could well be a matter of creating a simple bootloader program based on FreeDOS installed into an external device or into the hard drive if we really need to make it our native OS.
Last edited by ~ on Mon Aug 01, 2016 2:20 pm, edited 2 times in total.
~ wrote:A smaller OS would be much more usable if it could be simply installed into a subfolder of the root directory (like "OS_Name_Folder") inside an already-existing partition (FAT, NTFS, Ext...) and if all installs of that OS could be searched and selected from a bootloader in all existing partitions from external media (avoiding installing or altering the most used booting configuration of the machine).
It all would be much easier if the bootloader was on a removable media like USB, floppy or CD/DVD, and if it just passed control to the OS on an existing formatted internal hard disk.
In this way the OS could be installed like any other regular application and then booted with, say, a configured USB stick to boot into it. Then nothing would need to be altered from the existing user OS and it would avoid keeping an exclusive hold on the machine against the rest of OSes and bootable system executive code applications/tests/demos.
This is planned! I do plan to support ISO9660 and FAT32. NTFS and Ext2/3/4 are too complex and a waste of time for the early stages I'm in. I also will add support for running the entire OS from a ramdisk (e.g. you could boot the OS with MEMDISK, etc...) and wouldn't require any changes in the host system except changes in the GRUB configuration file. I've done this before.
You know your OS is advanced when you stop using the Intel programming guide as a reference.
Hello.
I'm happy to announce the third public release of xOS, version 0.06. New things in this release include:
AHCI SATA read-only access; now boots from a SATA hard disk.
ATA improvements.
PCI improvements.
Major memory manager bugfix.
New default window theme.
SSE memcpy and some other performance improvements.
Known issues:
On VirtualBox, the AHCI controller doesn't respond to commands.
Things to expect in the next release:
File system driver.
Loading programs from disk.
Using a picture file as the background.
(Hopefully) fix the AHCI driver on VirtualBox.
For testing purposes, this release has a script called qemu.sh, which runs QEMU using SATA instead of ATA, just for demonstration. Download Link GitHub Release
I look forward to hearing all feedback, both good and bad.
Cheers.
You know your OS is advanced when you stop using the Intel programming guide as a reference.
) Each program creates a window, on which the user can use the mouse to draw on the window, to demonstrate window manager events as well. 
