Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
DavidBG wrote:
So you haven't dropped the project?
No. I finally found what was wrong in my code. I have rewritten the mouse driver and fixed some bugs
with paging. Now, HyOS works very well on my laptop and I no longer have any reason to drop the project.
DavidBG wrote:
Can it load programs yet?
Yes, it can load applications from a RAM disk. It was also able from a floppy but I removed the floppy
driver because I think this media is old, slow and no longer supported by newer computers since a while.
I need to work on a IDE driver, so I could load applications from a hard disk or a CD-ROM drive.
Tommy
Last edited by f2 on Sat Sep 11, 2010 4:01 pm, edited 1 time in total.
"Open source seems to embrace the dark side of human nature." - Ville Turjanmaa
I've just implemented a new, HID-based, keymap system for Pedigree and today I've converted the German keymap. I have an EnUS keyboard, but I still wanted to try the new keymap.
The result:
He was also able from a floppy but I removed the floppy
driver because I think this media is old, slow and no longer supported by newer computers since a while.
Will you support it again at some point in the future or perhaps with a module? I still have many computers with floppy drives and I don't like testing OS's on new PC's or in VM's.
Ferrarius wrote:
Will you support it again at some point in the future or perhaps with a module? I still have many computers with floppy drives and I don't like testing OS's on new PC's or in VM's.
HyOS is still able to boot from a floppy, but he's no longer able to load programs on it. And I don't have a computer with a floppy drive. So, no! I won't reimplement a floppy driver in HyOS.
"Open source seems to embrace the dark side of human nature." - Ville Turjanmaa
Just a few changes in the screenshot compared to last time. But our compiler is finally able to compile structs, simple classes, generics and a stripped down corlib. So now we're finally able to use System.String instead of char-wise output
Just implemented a test driver for the VMware emulated graphics card.
This screenshot shows an accelerated copy from one area of the screen to another. It's not much to look at, but it's kind of cool to know the copy is performed by the "hardware" rather than by a memcpy or something.
pcmattman wrote:Just implemented a test driver for the VMware emulated graphics card.
This screenshot shows an accelerated copy from one area of the screen to another. It's not much to look at, but it's kind of cool to know the copy is performed by the "hardware" rather than by a memcpy or something.
Have you got some docs for that one? I was just analysing the Virtualbox one last night
A Black Hat paper discussing how to poison the host OS memory. Had a heap of information that I couldn't find anywhere else such as FIFO link psuedocode. Also discussed which 2D (and 3D) acceleration features were available across a number of tested VMware hosts - for example, it tells that SVGA_CMD_RECT_FILL is not available everywhere.
MIT licensing on Haiku and the xfree86 stuff is a massive bonus.
You can also refer to my source code which is currently a hacked-up test driver and will be changing a fair bit to integrate properly with the system.
Ok, so here is my OS booting in debug mode. At the time the screenshot was taken, it has full VESA support, a custom font, has switched to long mode, initialized multiprocessing support, located and traversed both the SMBIOS and ACPI tables, initialized a kernel debugger and initialized the High-Precision Timer (not necessarily in that order).
Attachments
The 2nd Doctor: "I have no doubt that you could augment an earwig to the point where it could understand nuclear physics, but it would still be a very stupid thing to do!"
Quick screenie to show what I've just accomplished for the first time.
Started rewrite about 2 months ago (full rewrite, little reuse). Right now it can:
- Start from a harddisk with Grub booting it.
- Switch to long mode
- Read from the harddisk, detect partitions, detect an Ext2FS with creatoros=42 and use that as rootfs for its vfs
- Detect that there's a BochsVbe device, switch it to 640x480 mode
- Load a background image from the ext2fs drive in plain regular BMP format and display it as background image
- Load an init program in ELF format & swap it into user space
- Transfer control to init
- Make init perform a syscall
- Halt, because there are no syscalls actually implemented (but it does get to printing "Not implemented: syscall_exit" - so it does get there).
Happiness, since I can now start on practically any bit. Stuff I want to fix:
- IDE driver doesn't use DMA. It should.
- Nothing has interrupts because I haven't bothered to set up APICs yet.
- Multithreading and multiprocessing
- Proper pagefault handling (there's a bluescreen but 85% of the info is wrong - CR2 is right though).
- A proper GUI server that has syscalls for defining windows
- Keyboard and mouse support (for obvious reasons)
- Rendering text in the GUI (there's a font, but there's no renderer for it yet).
- Loads of testing & porting to other systems. Have only tested under bochs so far; expecting trouble in the near future. Vbox doesn't like being run inside vbox so that's hard to test. Qemu doesn't like it so far (but it might just be compiled without long mode support - dunno yet). Vmware haven't tried. Need to make a vmware graphics driver though.
Regards,
Candy
PS: the image is just one of many google image hits for "desktop background abstract industrial" - I figured a random pattern didn't look quite as impressive as this. It's still just a flat image that I loaded from disk.
. I always liked the concept of GUI Windows 3.1 had: very simplist. Well, I added a bar on the desktop and
