OSDev.org

Me again here. Old stuff link as usual: http://forum.osdev.org/viewtopic.php?f=2&t=22634

For whoever might be interested in that Aprom OS of mine, here is the new project page and a new build 101023:

http://orbides.1gb.ru/aprom.php?lng=eng

There you can find the thing both in builds and deconstructed to bare pieces to play with.
Also, lots of documentation.

Since 101014 it's became much more stable.
I would have posted a change log, but it's doubtful it would be of any meaning without knowing the internals.

Have fun.
If fun does not happen, comments are welcome both here and there.

So, is it so breathtakingly cool no one dares to comment, or so casually uneventful that no one finds anything worth a comment in over month?

berkus wrote:

best of luck, but don't mind, i think u r more concentrating on application than OSdevelopment.

Mohanty wrote:best of luck, but don't mind, i think u r more concentrating on application than OSdevelopment.

Hm.
An OS without applications is an oxymoron, no?

Continuing our discussion from Orbiter Forum, my feedback:

-Certain apps seem to lack any means to exit, short of /bin/kill. Process names aren't always reported by ps (which sometimes only gives "unnamed" for the process name), so figuring out which process to kill with /bin/kill can be difficult. Having the shell recognize some sort of keystroke like Ctrl-C to end a process from the shell running it would be nice.

-It would be convenient if terminals would close when the shell was given the exit command. As is the terminal simply becomes unresponsive and wastes space in the page list on the taskbar/panel/whatever-it's-called until /bin/kill is used to clean it up.

-/demo/hw crashes Qemu.

-The memory viewer is awesome. I (quite pleasantly) wasted quite a bit of time opening and closing copies of maxg to see how badly I could fragment the heap.

-/bin/reboot gives no response except that the machine stops responding and QEMU stops using so much CPU time. I assume this is intentional: It simply puts the machine into a safe state and halts without clearing the screen or displaying any sort of message and waits for the user to kill the power or close the emulator. Am I right? If so, it could use a bit of feedback (along the lines of displaying "/bin/reboot called. Halting" right before it actually halts, and/or clearing the screen), so that the user knows that it has executed successfully, rather than having frozen or something. If it is supposed to display feedback, then I'm not seeing it.

linguofreak wrote:-Certain apps seem to lack any means to exit, short of /bin/kill. Process names aren't always reported by ps (which sometimes only gives "unnamed" for the process name), so figuring out which process to kill with /bin/kill can be difficult. Having the shell recognize some sort of keystroke like Ctrl-C to end a process from the shell running it would be nice.

Older apps were developed in an environment where stable operation was on orders of a few commands, so exit capability was kind of superfluous. It's being cleaned up one demo at a time.
The kernel have no idea about filesystem, so setting the process names are responsibilityes of the processes. Some are irresponsible.

linguofreak wrote:-It would be convenient if terminals would close when the shell was given the exit command.

Worth fixing, to be fixed.

linguofreak wrote:-/demo/hw crashes Qemu.

Strange. I have Qemu 0.12.2, win32, and it prints out a hello world string.
Just tried with the old images you have, putting the image onto a bootable ISO.

linguofreak wrote:-/bin/reboot gives no response except that the machine stops responding and QEMU stops using so much CPU time. I assume this is intentional

No, it's not. Same as above, the command causes an ACPI reboot. It does so on most real PCs i tried, and in every emulator around.
Are you sure you set things up properly and have a stable Qemu version?

Artlav wrote:

linguofreak wrote:-Certain apps seem to lack any means to exit, short of /bin/kill. Process names aren't always reported by ps (which sometimes only gives "unnamed" for the process name), so figuring out which process to kill with /bin/kill can be difficult. Having the shell recognize some sort of keystroke like Ctrl-C to end a process from the shell running it would be nice.

Older apps were developed in an environment where stable operation was on orders of a few commands, so exit capability was kind of superfluous. It's being cleaned up one demo at a time.
The kernel have no idea about filesystem, so setting the process names are responsibilityes of the processes. Some are irresponsible.

linguofreak wrote:-It would be convenient if terminals would close when the shell was given the exit command.

Worth fixing, to be fixed.

linguofreak wrote:-/demo/hw crashes Qemu.

Strange. I have Qemu 0.12.2, win32, and it prints out a hello world string.
Just tried with the old images you have, putting the image onto a bootable ISO.

This is with Qemu 0.12.3, Linux x86_64 (Ubuntu Lucid, upgraded from Jaunty) with a custom compiled kernel, and the images put on a hard disk image that may or may not have been set up in a stable fashion (it does boot though).

linguofreak wrote:-/bin/reboot gives no response except that the machine stops responding and QEMU stops using so much CPU time. I assume this is intentional

No, it's not. Same as above, the command causes an ACPI reboot. It does so on most real PCs i tried, and in every emulator around.
Are you sure you set things up properly and have a stable Qemu version?

I've got the Qemu package from lucid-updates. I'm *not* sure whether I have things set up properly, especially the disk image, which took forever to prepare so it would even boot.

linguofreak wrote:I'm *not* sure whether I have things set up properly, especially the disk image, which took forever to prepare so it would even boot.

Sorry, i should have provided means to do it nicely sooner.
Here is a template: http://orbides.1gb.ru/ape/ape_iso_make.zip
Put init, kernel and arosroot_big.img into cd/ape, then run mkgrubiso.sh to make a bootable CD image.

That should also allow you to rebuild the root image in two easy steps if you want to experiment with it
(Pack: ./arostool e directory_with_files newarosroot.img)
(Unpack: ./arostool d arosroot.img)

Qemu can apparently differ from platform to platform, you're likely have a kqemu module installed, or x86_64 fact might throw a wrench somewhere.

Artlav wrote:\

linguofreak wrote:-/demo/hw crashes Qemu.

Strange. I have Qemu 0.12.2, win32, and it prints out a hello world string.
Just tried with the old images you have, putting the image onto a bootable ISO.

I haven't made an ISO yet, but under Bochs with the same HD image I was using with Qemu, /demo/hw hangs the terminal, but the mouse continues responding until one tries to launch a new terminal. At that point the mouse hangs as well, and upon pausing execution in the bochs debugger, the instruction pointer is found to be running through empty memory.

EDIT: /bin/reboot works as advertised on Bochs.

2nd EDIT: I made an ISO and tried it out under Qemu. Here /demo/hw works, but /bin/reboot freezes.

Some updates, testing would be appreciated.
Floppy image: http://orbides.1gb.ru/ape/aprom-110512.zip
Or extract and boot with GRUB.
Floppy, CD and USB drivers not included, aros image tools are on the orbides site linked in post 0.

It's mostly about stability and minor quirks - like hw and reboot working, terminals closing, filesystem daemon not crashing, GUI mode selectable, etc. Everything started should be stoppable.
So do your best to crash it (killing init is cheating).

Approximate changes:
-General threading and processes fixes, stability should shoot through the roof.
-Filesystem and threads now work fine (testfs command would give ramdisk a stir)
-Fixed GUI having window 0 under bochs
-Most apps now have exit options
-Zterm auto-close on shell termination
-XCMD now have an exit button
-GUI now gives more usable mode list if default is missing

Some tips:
-To go into GUI from console mode type gui & zterm
-To start Pascal IDE launch /bin/text
-If all windows are closed, click into upper-right corner (icons there are quicklaunch)
-If a program lacks clear exit button, Esc key should close it
-OpenGL demo is /demos/zgl_gears, should work if the driver is loaded
-Launching console apps from xcmd would not open a terminal for them, but if xcmd was started from a terminal, then their output would go there.
-/ramd is a ramdisk, the only writeable spot in this assembly
-The thing considered is too slow for double buffering, so flickering is a known issue
-Don't kill init. That contains all the drivers, filesystem daemon, executables parser, etc. With all this shut down everything else would just hang in panic or bail out.

Looks very interesting, Artlav - keep up the good work!

One thing I was wondering - which license is the OS released under?
I downloaded the "base" but couldn't seem to find a license. Is it "public domain"?
- mooseman