rezgui/fpos

Free Pascal Operating System (FPOS) is a operating system consists of a minimal kernel built on FreePascal. It contains a Scheme implementation of a hard drive (ATA) driver, keyboard (PS2), serial (8250 UART), FAT32 filesystem and a small real time clock manager. The project was built to experiment with developement of operating system using a high level functional language to study the developement process and the use of Scheme to build a fairly complex system.

FPOS - Free Pascal Operating System

Project started in 01-01-2010 and coded with ❤️

‼️ Attention :

This project is far from dead, but it requires revision... A new bootloader will be utilized for execution on 64-bit architecture. Additionally, new functionalities will be implemented:

• An integrated file system implementation supporting FAT32, NTFS, ext-versions, and much more.
• Multitasking extension for running many subprograms simultaneously.
• Extendable hardware driver slots for multitasking capability.
• An API for accessing all public kernel functionalities.
• A graphical user interface (possibly as a separate threading application). Many modern features will follow, but please be patient...

Introduction :

FPOS is a operating system consists of a minimal kernel built on FreePascal. It contains a Scheme implementation of a hard drive (ATA) driver, keyboard (PS2), serial (8250 UART), FAT32 filesystem and a small real time clock manager. The project was built to experiment with developement of operating system using a high level functional language to study the developement process and the use of Scheme to build a fairly complex system.

Boot	Shell (CLI)	Command (Help)

🤝 Bugs and help / improvements will be appreciated, please send them to (Yacine REZGUI) [email protected] and (Mario Ray Mahardhika) [email protected].

✔️ Implemented :

• GDT, IDT ( no problem... I hope )
• ISR ( currently, only page fault has additional handler )
• IRQ ( no problem... I hope )
• Console ( including simple command processing )
• Keyboard ( try to be US-std, but I don't know the keymap. Just guessing for now )
• Memory Manager ( needs testing )
• Speaker ( just for fun :-) )
• RTC ( seems wrong at PM, also for DayOfWeek )
• System calls
• Multitasking
• Filesystem ( perhaps FAT12 is the most obvious, or should we create one ourselves? )

🔧 Fixed :

• Successive Write(Ln) fails due to 103 IOResult
• Some inline assembler and assembler routines are missing register list, causing it to crash randomly (please test)

📋 Changed :

• Updated to FPC RTL revision 14499

➕ Added :

• Not 📅 planned for now

📝 Note :

• Some files are not used due to unusability ( multitasking & filesystem )

⚙️ How to compile :

• Make sure you have working FPC installation ( try using latest 2.5.x snapshot if your version fails )
• Copy executables** under tools to a directory listed in your PATH ( or Path )
• Open Command Prompt ( start->run->cmd ), cd to fpos top directory, then type 'make'

⚗️ How to test :

• Adapt (Qemu or Bochs).bat to your Qemu / Bochs installation
• On Linux, you must change 'i386-linux-ld' in make.rules to 'ld'

❤️ Contributing

Contributions, issues and feature requests are welcome!

🙏 Thanks to

• @achief-ws
• @Sio
• @James T. Sprinkle
• @Steve Jenson
• and Other here

📓 License

The GPL-2.0 License. Please see License File for more information.

🌳 Treeware

This Operating System is a Treeware. If you use it in production, then we ask that you buy the world a tree to thank us for our work. By contributing to the Treeware forest you’ll be creating employment for local families and restoring wildlife habitats. Read more about Treeware at treeware.earth

fpos's Issues

threads/tasking/heap

heap is a misnomer. its heap is userland.
kernal land uses paging.

both are incomplete in FPOS. I have working code from CoffeeOS(after several 
code rewrites) available for BOTH. Code syncing is appreciated.

The paging unit here repeatedly page faults.[TSS pages not allocated, IIRC]

This code is some of the most obscure C I have translated yet. Not one C 
programmer does it the same as another.

seems the maintainer here is taking some long holidays.

I have some linking issue i am working out. CoffeOS is at rjasmin,net.It 
builds, but I need to look at my linker.
Release: 4Nov2010
Will update the codebase on the site in a few hours, I have to update some 
other stuff.

My SVN setup got borked, so HTTP/FTP got setup instead.You need patch/diff on 
windows to sync your code.

Original issue reported on code.google.com by [email protected] on 5 Nov 2010 at 8:24

interrupts [or the lack thereof]

you half-assed it ,Mario is what it was.  you just didn't add-in a
'handler' for the keyboard, so anything that trips an interrupt on IRQ1,
just never gets handled. same with the mouse. there should be 256
interrupts available,according to what I'm reading.

everything just gets thrown into the general handler and causes the kernel
to panic.

9 is mapped to keyboard
33 mapped to mouse
21 needs to either be avoided, or  point somewhere else in the interrupt
table. this is because 'DOS'[the MS-DOS we know] isn't hooked in, and
probably never will be.

working on a fix, at least for the keyboard and mouse.

--Jazz

Original issue reported on code.google.com by [email protected] on 27 Feb 2009 at 1:53

endless reboots

before GRUB:
you need to put this in an IDE drive.in wont work in a SATA one yet.
this is a GRUB issue.


after grub:

if the kernel shows 'boot' after entrypoint xxxxxxx and spontaneously
reboots this is why.THERE IS NO HEAP allocated.

when adding the new heap to the kernel I get this:

heap.pas(37,19) Error: Wrong number of parameters specified for call to
"AllocPage"
heap.pas(38,8) Error: Identifier not found "Map"
heap.pas(52,15) Error: Identifier not found "GetMapping"
heap.pas(53,18) Error: Incompatible type for arg no. 1: Got "LongWord",
expected "PPageTableEntry"
heap.pas(54,10) Error: Identifier not found "UnMap"
heap.pas(150) Fatal: There were 5 errors compiling module, stopping
Fatal: Compilation aborted

so I have to use the older one for now. heap, vmm, and pmm files are linked
together.replace as a threesome.

--Jazz 

Original issue reported on code.google.com by [email protected] on 16 Feb 2009 at 3:04

code review

need to upload latest to rjasmin.net...anyway will get there in a week or so.

CODE REVIEW:

we have multitasking and initrd support.
locating root device is soon to come.
ACPI Poweroff and APM(real mode with drop code to RM) is available and
builds ok [needs some testing]

may need FPC/TP 16-bit compiler support for RM functions.Will look into
this as FPC v1.0 used TP to compile itself.Meanwhile, code in 32-bit and
avoid calls to RM.This is not as difficult as it sounds.Its just a matter
of locating the 32-bit interrupt you need.

This solves two root security holes in default linux's:

1) sysvinit CAN be bypassed, leaving the system wide open
2) the system can be taken down as filesystem navigation routines and login
routines are NOT inside the kernel.


give me a few days to get my latest code merged together.

I have com and printer port support, ring3 mode will be implemented as soon
as we have root filesystem access on a live hard drive.Then the new RTL
units should be more compatible with default FPC Linux distros, as of now,
they require root access to use.[aka video and timer units]

more updates on rjasmin.net  and inside the readme file as they become
available.

On writeln support, this will change to what FPC uses as soon as ring3 mode
support is available, but I'm keeping the kernel's pointer to those
functions as easy as possible, I don't want to recreate the wheel here,
like I've done a few times already.Both the syscall (int83 for VESA) and
the ring0 function should point to the same function, though obviously with
more overhead for the ring3 process. FPC does not properly implement the
video unit functions under Linux, although mine do require root access for
the time being. This is hopefully to be solved soon.

running X11 and acessing the video screen, however, will still be an issue.

NOTE:
readln and readkey support is not there yet.I'm working on it.

--Jazz

Original issue reported on code.google.com by [email protected] on 2 Oct 2009 at 1:27

Page Fault

What steps will reproduce the problem?
1. Run VMWare Workstation and install FPOS in it (from FPOS ISO). I used
"Other 32bit OS" as OS type selection.
2. Boot the installed OS.
3. Select the OS from the GRUB OS selection menu.

What is the expected output? What do you see instead?
The running OS? I'm sorry and couldn't run this on other systems so not
really sure what came next.

What version of the product are you using? On what operating system?
FreePascal OS 0.01 (on VMWare workstation 6.5.1).

Please provide any additional information below.
This is what I saw on the screen:
---------------------------------------------------------------------------
Installing heap...              [ OK ]

Page Fault Exception
Error Code = 2
EAX        = $FF000004
EBX        = $00047000
ECX        = $FFFFC000
EDX        = $0009F800
ESI        = $000348EC
EDI        = $000348EC
ESP        = $0012A024
EBP        = $0012A03C
CS         = $00000008
DS         = $00000010
ES         = $00000010
FS         = $00000010
GS         = $00000010
SS         = $0012A058
EIP        = $001024DE
EFLAGS     = $00210016
User ESP   = $00047000
Page Fault at $001024DE, Faulting Address = $FF000004
Page is user-mode reserved
_
                                                         FreePascal OS 0.01
---------------------------------------------------------------------------

There was also a continuous system sound/beep, which only stopped when I
killed the OS (from VMware, eg, like you pull off the plug from your PC ;) ).

Original issue reported on code.google.com by [email protected] on 25 Oct 2009 at 7:59

100% CPU usage?

What steps will reproduce the problem?
1. Run qumu with the iso that came with the download

Well using the FPOS iso makes qemu use 100% of the CPU; and having a
default linux running through qumu uses 0%... so there's probably something
wrong


What version of the product are you using? On what operating system?
Using the latest qemu on Windows XP sp3, default fpos iso.

It's a pretty interesting start so far!

Original issue reported on code.google.com by [email protected] on 23 Dec 2008 at 9:29

CURRENT BUG REPORT APRIL 2009

We need to go over the commandlist variable and check it to work correctly,
my arrow keys are looping endlessly on a fuction that should not.

backspace key has been fixed and implemented.

KNOWN ISSUE:

No ansi codes available, at least, like dos or unix has, anyway.
writeln() only takes one variable and I haven't updated it from the video
and crt units in the RTL yet.

to do a 'writeln;' do a 'writechar(#10);' Really the same issue.

Floppy and hard drive is untested, so use caution. WILL NOT be HELD LIABLE
for data loss.

'dos', the fileopts unit, has mixed unix and dos routines.I dont plan to
fix this just yet.All int 80 syscalls and int21 syscalls have been removed.
DPMI and buffer access is only based on logic, not actual code, I may need
some help here.Technically, @anything should give you the address of
'anything'.

most interrupts not implemented.

Mouse, more particularly USB activity will hang the kernel at this time,
like it will do in real DOS.Freedos doesn't have this limitation.Then
again, it doesn't have USB mouse support, either.

we have a prtial 1.1 in pascal and libusb in C to work from on this.

Need USB support to support new mice before the 'mouse' unit can be made
available.I otherwise have a 'mouse' unit.I'm working on emulation right now.

we still need to wrap our calls for user level 3, not root level 0.nobody
has bothered with this yet.The kernel needs this, not the RTL.The RTL is
for building code, not necessarily the kernel ONLY.Anything for FPOS uses
the RTL. HAIKU OS has similar setup and it seems to work FINE.

need test bench bare bones pentium systems with minor hardware, like days a
few years back when all you had was slots on the mobo, not this integrated
shit.On this note, we can port drivers form the unix kernel if we are
careful enough.  The unix kernel seems to use objective C a lot and wrap a
lot of calls pointing to some obscure code reference not seen anywhere.Make
sure you have a full unit in C before translating to pascal.
This is one of the reasons why our RTL is so basic.

The RTL ATM WILL NOT COMPILE there have been severe changes to both the
layout and the included units.It will require some effort to recompile the
RTL, but once done will make our lives a bit easier.Our codebase has grown
dramatically in this process.

Daphine was a good help as well, I can believe the frenchman just abandoned
the project.Those units are not included at the moment.I also have a group
of C units as well that we can use, I haven't had time to port them
over,either.

As always, latest SVN is over at assembla [if I bother to upload it.]
There are clients available for windows, but I dont know how Mario gets it
to compile under windows.I use Ubuntu with the full Lazarus IDE
installed.Seems to work ok for me. NEED 2.3.1 or ABOVE to compile, this
seems to be a compiler or RTL issue.Oddly enough, I think I'm pulling units
from 2.2.2.

--Jazz

Original issue reported on code.google.com by [email protected] on 9 Apr 2009 at 4:49

Paging mode ENABLE glitch from C devs

What steps will reproduce the problem?

'or' the paging BIT, AHEM BIT...by 8.

--affects all versions posted.

CORRECT FIX:

'or' the bit by 1. You cannot set a 0/1(binary) value to 8. This confuses the 
processor and causes a triple fault.It also sets an incorrect value.These are 
INTERNAL FLAGS, not LONGWORDS here people...

This did not dawn on me until I looked at WikiDocumentation.

NOTE: Under emulation this will cause QEMU to issue "executing beyond end of 
ram" error. This is expected as we are now working/loading HIGH at pageDir 768 
address space ~ @ C000 0000, which you probably do not have 3GB or more 
allocated to QEMU. This is why this error trips. Its a nonsence error for 
machines with less then 3GB to begin with.

Would recommend loading at another address, such as PageDir0 [otherwise 1:1 
map] instead.To resolve this "new" error. 

So, higher-half loading is out for the moment...

Note: you can 'map' in the kernel with the 'map' routine inside a repeat..until 
loop by setting va to the page directory and pa to where we want the kernel 
mapped to inside of the paging structure. I have done this and it otherwise 
works.

Original issue reported on code.google.com by [email protected] on 2 Sep 2011 at 3:26

no svn access yet.

if not here, please use fpos project at assembla.com. that svn is already
setup.TESTING release is MY CURRENT copy, not mario's.

if you need it in another folder, let me know.

http://my-svn.assembla.com/svn/fpos/trunk/

releases [from here] and testing folders.

-Jazz

Original issue reported on code.google.com by [email protected] on 16 Feb 2009 at 3:09

procedure trunc << Error

1. version 01.01.2010 --  compilation FPOS 
2. run FPOS on Bochs 
3. on call trunc -- always  crash 

Original issue reported on code.google.com by [email protected] on 9 Jan 2010 at 11:14

SVN and FTP issues

Due to FTP issues, Im moving over to DreamHost to have better support via 
Drupal /Trac /SVN 
access.Will still mirror to fpos.firmos.at as the dev there is looking for 
network related OS 
development.

This should clear up a lot of things that we dont have here.

Also, code is in flux, meaning the nightly has a higher chance of NOT building.

This is due to the amount of changes in the RTL and (BAseUnix) units. This 
could not be avoided. 
We should have stable RTL units for the FPC RTL soon.Currently we only have 
kernel level code 
implemented and it isn't very useful on Linux, but it SHOLD work ok.

If there is a procedure missing there, its because I haven't found level 0 code 
for it yet. (Like 
Readkey) and had to come up with it on my own.Most (some stuff just isnt 
implemented) of the 
original ring3 code should port ok from the FPC RTL into ours.

I intend on breaking the *NIX tradition, so full FPC RTL integration wont be 
there.What this 
means is that Linux code HAS to be ported over.This cant be avoided as *NIX has 
some serious 
links to bad C, buggy C, and downright C that we dont need.(such as older 
drivers, ETC....) as 
well as BAD FPC support for (FREE)Pascal.

Im wading thru C as we need it, but most of the C can be avoided. 

UNFORTUNATELY, this increases our DL size by a few HUNDRED MB as we have to 
port all of the 
(now old) FPC LCL and ETC parts into FPOS.This is intended.I haven''t gotten to 
anything but the 
RTL yet.

There is enough here to make FPOS useful, given time the old ways of doing 
things will change.

Most unix like functions are implemented, so dont go freaking out.This is still 
Linux-based.We 
just remove a lot of old-school thinking and ways of doing things that are not 
needed.

(for example, 286 based code and the way C normally  loads the OS in 16 bit 
mode, its JUST NOT 
NEEDED.)

UNFORTUNATELY, this has been my headache for the past several months. I finally 
got it 
solved.There were some issues with the HEAP a while back.Most have been fixed 
and the new 
unit compiles ok.(Its pulling everything in ATM during my compile check of the 
kernel.)

I will be needing help with documentation(running files thru the engine, its 
EASY) on a semi-
ongoing bases here soon.

Hope to have a XMAS release or sooner, no promises yet. Please use the latest 
version before 
posting bugs.

We almost have a Filesystem and I will aim to mounting ANYTHING as R/W as soon 
as I have 
enough code.(IM NOT breaking the VFS structure, it will be mounted as 
/media/xxx, unless its a 
EXT2+ partition...)

I have some working FAT code from a working bootloader example from Mike.Mario, 
I think you 
might have been looking for this.Sorry about the FREEDOS code.

I dont have ELF loading support for a custom bootloader ATM, am working on 
finding the 
code.For now, use the GRUB method when building.(it is default)

--Jazz

Original issue reported on code.google.com by [email protected] on 21 Dec 2009 at 6:53

FS missing

I have included the sources from freedos and the linux kernel[Linux debian
2.6.26-1-686] to assist in the creation of a known FS.

porting from C may be an issue, im working on addressing it myself.

updated sources are attached.[as of 01-17-2009 with FS C sources included]

Original issue reported on code.google.com by [email protected] on 17 Jan 2009 at 4:40

Attachments:

• [free pascal OS sources.zip](https://storage.googleapis.com/google-code-attachments/fpos/issue-3/comment-0/free pascal OS sources.zip)

FPOS compiler issue[SOLVED]

use the following attachments to compile on debian x86, maybe other uni-ces
as well.it is a modified make.rules file that goes  in the top-level
directory.since I can't [YET] duplicate the build environment on windows,
i'll support the build from here.

--Jazz

Original issue reported on code.google.com by [email protected] on 20 Jan 2009 at 2:32

Attachments:

• make.rules

list of current bugs as of 19-feb-09

time:

hour for 08 reports 81
date reports for year +2000 as 217,otherwise TWO digit code.
--NOT y2k compliant. use four year codes.

output of date.year is fixed, but this is not Y2K compliant.its just a
quick hack.not sure about the 217.

heap hints(broken compile):
[first you have xxx.bitmap.pas in the kernel folder and im assuming this is
because you forgot to rename them??]

pmm.pas(31,48) Hint: Mixing signed expressions and longwords gives a 64bit
result
pmm.pas(128,19) Hint: Conversion between ordinals and pointers is not portable
pmm.pas(147,20) Hint: Conversion between ordinals and pointers is not portable
pmm.pas(162,12) Hint: Conversion between ordinals and pointers is not portable
pmm.pas(169,14) Hint: Conversion between ordinals and pointers is not portable
pmm.pas(170,9) Hint: Conversion between ordinals and pointers is not portable
vmm.pas(58,19) Hint: Conversion between ordinals and pointers is not portable
vmm.pas(67,37) Hint: Conversion between ordinals and pointers is not portable
vmm.pas(155,16) Hint: Conversion between ordinals and pointers is not portable

heap.pas(37,19) Error: Wrong number of parameters specified for call to
"AllocPage"

vmm.pas(52,10) Hint: Found declaration: AllocPage(PPageTableEntry):Boolean;

heap.pas(38,8) Error: Identifier not found "Map"

heap.pas(50,27) Hint: Conversion between ordinals and pointers is not portable

heap.pas(52,15) Error: Identifier not found "GetMapping"
heap.pas(53,18) Error: Incompatible type for arg no. 1: Got "LongWord",
expected "PPageTableEntry"

vmm.pas(65,11) Hint: Found declaration: FreePage(PPageTableEntry);

heap.pas(54,10) Error: Identifier not found "UnMap"

heap.pas(65,23) Hint: Conversion between ordinals and pointers is not portable
heap.pas(65,15) Hint: Conversion between ordinals and pointers is not portable
heap.pas(113,25) Hint: Conversion between ordinals and pointers is not portable
heap.pas(113,17) Hint: Conversion between ordinals and pointers is not portable
heap.pas(121,17) Hint: Conversion between ordinals and pointers is not portable
heap.pas(124,16) Hint: Conversion between ordinals and pointers is not portable
heap.pas(128,14) Hint: Conversion between ordinals and pointers is not portable
heap.pas(137,13) Hint: Conversion between ordinals and pointers is not portable
heap.pas(144,19) Hint: Conversion between ordinals and pointers is not portable
heap.pas(144,11) Hint: Conversion between ordinals and pointers is not portable
heap.pas(150) Fatal: There were 5 errors compiling module, stopping

im using the old one for now.


keyboard:

please look at

procedure KeyboardHandler(var r: TRegisters);

in
keybrd.pas.

functionkeys and keys not in letters,numbers,enterKey do not work as
intended. the kernel panics when you press these keys.
[on simulator or real hardware.] This includes up and down arrows and
backspace.

assuming that this is because there doesn't seem to be a second 'readkey'
call. You need TWO for extended codes.
I placed another one in place,but not sure if it's going to work.

the key codes should be listed in the  const section now.



display routines:

i wouldn't replace your calls just yet, let fullansi engage itself after
the rest of the kernel loads. I had some issues in the past with getting
this working.it works fine now.

writestrln, writestring, and settextcolor should be the only overlapping
routines.

dos:

NOT TESTED, some routines are missing from the RTL. It seems, and this is
weird, that routines that should be present are being pulled out of thin
air.I know these routines exist, but they are not in go32 or dos units, or
thier includes, which I have included within our DOS unit.

some necessary  fileIO routines are missing because of this.

ALSO, the FPC programmers didn't intend on this unit ever compiling, as it
is flawed and chock full of syntax [and some logic] errors. I have fixed
these in our unit. That is why parts are incomplete.

 also we do not need 'fpc_dosomething' procedures, those are for the
compiler, which is why the unit is usually in the RTL, not your project.
They just define what is configured [in this case from dos] as far as
IsMemory manager present and similar calls. we neither need these or have
to implement them.

I think I setup mem[] construct correctly, linux targets seem to need a two
dimensional array when dos [go32] target only seems to need one.There is a
workaround for mem[] easily available and easy to configure.

I hate peeking and poking as well[writeport,readport], but some things have
to have direct hardwareIO, at least for now.

would urge someone to help fix these issues as I work on getting a
filesystem and stable dos unit.

these are annoyances for me, but BIG issues for end users. everything else
works the way it should.

Original issue reported on code.google.com by [email protected] on 19 Feb 2009 at 8:42

Does not compile

when I try to compile it I get this error(I tried doesn't work on Mac or Linux) system.pp(68) Error: Can't create object file: ../units/i386-fpos/system.o
system.pp(68) Fatal: Can't create object ../units/i386-fpos/system.o
Fatal: Compilation aborted
Error: /usr/local/bin/ppc386 returned an error exitcode (normal if you did not specify a source file to be compiled)
make[2]: *** [system] Error 1
make[1]: *** [all] Error 2
make: *** [fpos] Error 2

Code review request

Purpose of code changes on this branch:

updates..

When reviewing my code changes, please focus on:
buildability. I can't seem to re-build the sources.

I'm on Debian x86.So far no luck with compiling the sources.

After the review, I'll merge this branch into:
/trunk(if you mind showing me how...)


I re-wrote some things for accuracy, added a bit to expand on what we had.I
found some multi-tasking and threading sources we should be able to use.All
we [mostly] need is a filesystem now.

NOTE:

Error 12: invalid device requested ONLY comes up when booting off a SATA
cdrom drive
[in my case Blu-ray]

switch drives to IDE, and the OS boots.

this is not an issue with grub.

NOW:
based off info from flash32 for windows, SATA can be found on 1 of 4
addresses.these are controlled individually, not like IDE, where it is
two to a bus.
[yes, i do my bit of hacking...]

PORT:[on intel 945 GCNL mobo]
0x01F0 <sata1>
0x0170 <sata2>
0x<sata3>
0x<sata4>
[i have four.the latter two i dont have memorized or written down.]

on my VIA expansion board:
[proper numbers are found in dos with dosflash]
0x1147
0x1157
0x1137 [should be the external port]

 we need to probe these for cdroms to get this to load correctly and
insert a check to determine if we are on IDE or SATA when booting.

otherwise, not bad for a working point release. makers of Haiku OS can't
even get this far natively.They emulate the entire OS and pretend at one
point that they will EVENTUALLY get thier OS to run natively.Thier
bootloader only works in an emulator.HA!

 if we add some [internal] commands for basic fileIO,[chdir,cd,etc...] then
we only need
a filesystem like ext3 or fat[16?]32, and we should be off and
running.please use 'clear' not cls.I know its probably the 'DOS man' in you.

filesystem wise: we can pull what we need [source-wise] from a linux
kernel if we need to.FPC allows calling C functions.Didn't realize how much
a pain C was to look at.

SEE.the way i see it, linux has a major FLAW.  TWO actually.....

DOS has internalized commands, and linux does not. [when it was created
from CP/M, we did not have enough ram to do this.this process was never
changed.HENCE:  cd,ls,rm,ln for commands. UGLY!!

NOTICE that these files exist [in /bin or /sbin, i forget which] and
removing them will issue GREAT warnings upon startup and shutdown.
WILL ALSO FILL YOUR /TMP folder and there is nothing you can do about it.

nearly every binary written on UNIX is Dependant on these files
existing.You cannot internalize these commands without REWRITING the
base kernel sources.


HENCE NEVER ALLOW ROOT ACCESS TO UNKNOWN USERS]

SECONDLY:

UNIX assumes too much on startup.Interrupt sysVinit in ANY manner, and
now you have root access without being root.
[discovered this building a python 'shell']

[I AM GOD, I have HACKED YOUR SYSTEM.THERE IS NOTHING YOU CAN DO ABOUT
IT.....]

The way unix is designed, this cannot be avoided.There is NO known
'system' user or lock-out process.The system just runs as root,
assuming it is GOD.This is WAY WAY before you even login.ASSUME ROOT or
'system' at this level and your system has ALREADY been annihilated.YOU
ARE TOAST.

DOS at least had this going for it. DISABLE CTRL-C and CTRL-BREAK and
the OS [or app even..] CANNOT be stopped.

files are zipped and attached.if i missed a licensing issue, let me know,
I'm a little new to that sort of thing.we still need crt and stringIO
routines, that I think are not in this, I'll have to grep for them.I have
included ANSI for now.The stringIO should fix the 'missing' writeln function.

we also need a 'procedure not implemented' debug message.

also compiler options, I had to cut the last three from the makefile, but I
wound up with a backtrace on build.I'm using the latest CVS snapshot with
lazarus.please be consistent with the tools you are using, some are win32,
some are dos based.i know this, as it requires wine to run some of them.

--Jazz

Original issue reported on code.google.com by [email protected] on 17 Jan 2009 at 5:56

Filesystem

I built this in Docker using run-release. Here is the output:

[  0.040000] kmain: loading kshell...

This is ArvernOS kernel shell. Type 'help' for more information.
Protip: switch to usermode with the 'usermode' command.

kshell> ls
     2 ./
     2 ../
     0 dev/
     0 proc/
     0 bin/
   172 booo
     0 etc/
   717 info
   446 lorem.txt
kshell> cat lorem.txt
no such file or directory
kshell>

Am I missing something? Why is lorem.txt not found?

What FPOS stand for?

Hey,

I'm sorry, i don't have to write it here, but i don't found any e-mail or 
forum, so i have to other way to constact. My question is: What is FPOS 
standing for? Is that project continue, or will be? Please answer...

Payl

Original issue reported on code.google.com by [email protected] on 6 Nov 2009 at 5:05

[deleted issue]

[deleted issue]