Author Topic: OSFree Project News  (Read 6662 times)

BigWarpGuy

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 649
    • View Profile
OSFree Project News
« on: 2010.03.13, 04:53:29 »
http://www.os2world.com/content/view/19755/2/
Quote
Posted by Martin Iturbide - Friday, 12 March 2010


At OSFree p. .. .

It is good to hear some progress for OSFree.
http://www.osfree.org

djcaetano

  • Full Member
  • ***
  • Posts: 205
    • View Profile
Re: OSFree Project News
« Reply #1 on: 2011.05.04, 21:09:43 »

   It seems OSFree was updated. Today I downloaded the 0.0.4.5 ISO image (which is the only known "OS/2" able to boot on my new hardware ... :) ) and it works nicely. It seems to run some servers already and this version has a simple command line which allows process listing, killing and alike.
   Since uK development is such a pain in the arse, I am really impressed with the advancements!

http://www.osfree.org/wiki/doku.php/en:download

(Notice: only the ISO and code were updated. I spotted no changes on the web page itself.)

Sigurd

  • Full Member
  • ***
  • Posts: 245
    • View Profile
Re: OSFree Project News
« Reply #2 on: 2011.05.05, 08:11:28 »
Hm, while not knowing what exactly to do with it it meanwhile boots well in Virtualbox 4.04.


valerius

  • Newbie
  • *
  • Posts: 12
    • View Profile
Re: OSFree Project News
« Reply #3 on: 2011.05.06, 12:16:05 »
hi all,

I am one of osFree developers.

Actually, we uploaded an unofficial demo, and showed it to several people, but did not announced it. Martin Iturbide wrote us a readme, but it need some more documentetion and bugfixing before we announce it. But if the info is leaked, we must do something sooner ;-)

Actually, what is on Sigurd's screenshot is a l4 'run' program. It is intended to show some system information, start/kill tasks, reboot, etc. You can see some help if you press 'h' key. It is not what we wrote, but it is a helper program from l4 environment.

The main screen is that of a 'l4con' server which provides several virtual screens. It waits untill a client connects to it, and shows its screen in a separate tab. On the lower screen line, you can see 9 digits from the right, three of which are marked with green. -- That are those tabs for virtual screens. You can switch virtual consoles by pressing Shift-left/Shift-right or Shift-F1/Shift-F2/... Each virtual desktop can be browsed back/forth by Shift-PgUp/Shift-PgDn or Shift-UpArrow/Shift-DownArrow (to scroll by line). The 'l4con' server shows on the screen the window of that application which is first connected to it. When a new app is connected to it, it shows it's screen

Actually, there are three virtual screens here. The 3rd one is 'run' program, it is started last, so it's window is showed on a screen. though, the main for us is 'minicmd' and OS/2 personality window. -- It is on the second tab. And the 1st tab is the 'logcon' server window. It shows the system log. The logcon server is a version of log server which shows system log on a screen -- the debug of all l4 servers. The 'run' program shows some system info, can start/kill tasks and reboot the system (you can see the help screen if you press 'h' key).

But the main for us is osFree OS/2 personality, it is showed on the 2nd tab. Actually, you can see here the minicmd screen and nothing more. c:\minicmd.exe is a small minishell program -- the 10 kilobyte LX executable started as protshell=. It is  a minimal shell-like application which uses a minimal subset of OS/2 API. (It uses about a dozen API's)

In this demo, minicmd can start a second (third, ..., N-th) copy of itself, if you enter 'c:\minicmd.exe' at its prompt. The 2nd copy is started, its Process  ID is showed. You can exit from Nth copy to n-1-th by entering 'exit' command.

For external commands, in this setup there is also 'mini33.exe' -- the most minimal LX executable. It does not contain the C startup code and uses only one DosPutMessage API from msg.dll. All -i't does, writes a 'I'm really small!' message to the screen.

You can see that only after starting an external program a command prompt is shown, so here a synchronous DosExecPgm API is implemented.

Also, so far, we implemented a minimal API for starting simple C written programs (a minimal set of API's needed by libc functions of Watcom). (it is in a newer versions, not yet uploaded to the web site). We have a small test program working, which uses 'printf' C function to output its command line args and environment variables. So, args and environment passing is implemented too, though some bugs still present. Also, there is a test for DosScanEnv API which shows a PATH variable.

Now we have a 'os2srv' server -- the OS/2 Server -- the main OS/2 personality server. It parses config.sys, spawns other servers and finally, calls run=/call= programs and starts a protshell=c:\minicmd.exe program. There is two more servers, execsrv and os2fs. The 1st one mainatins all executable modules in the system (EXE/DLL ones). For that, it loads lx.ixf and ne.ixf -- IXF drivers. IXF stands for Installable eXecutable Format driver -- an ELF shared library supporting LX/NE/ELF/etc format executables loading. So, each executable format support is separated to a separate module. They are analogous to IFS for file systems. So, execsrv loads all neeeded executables/libraries on demand. Libraries are loaded to a shared arena. Also, I want to move all shared-memory related API's support to execsrv, so it also will maintain all the shared memory and shared sepaphores etc.

The os2fs server is a filesystem server. It maintains all the FS-related API's. In the future, I plan to implement IFS support in os2fs server, so it will provide IFS'es with FSH_* helpers through FSHELPER virtual DLL and mount filesystems, end export these filesystems to other personalities. In l4env there already exists some FS support in l4vfs subsystem. Ihe idea is to have the central 'name_server' which implements a root of a hierarchical namespace,
in which other servers are mounted. In our setup, there are two more l4vfs servers, 'simple_file_server' which mounts to the '/file/system' mountpoint, and terminals server, 'term_con', which mounts to '/dev'. Each terminal, /dev/vc0, /dev/vc1,... corresponds to each client's stdin/stdout/stderr. So, it implements stdin/stdout/stderr for programs. the 'simple_file_server' exports GRUB or FreeLDR loaded modules as a flat filesytem, mounted to /file/system dir. Also, other file-alike entities, like pipes, registry keys can be added to the same namespace.

I plan to make os2fs server as one of a l4vfs servers, so, it will export OS/2 filesystem to other personalities. I plan to port ramfs.ifs to osFree, so it will be the 1st IFS. The IFS drivers are planned to be LX executables (DLL's), called by os2fs server, which will implement a FS router. For ramfs.ifs, no block device drivers or os2dasd/os2lvm analogues are needed (it is a 'remote' filesystem). And it uses only 5 FSH_*-helpers, so it will be the simpliest case to implement ;) I plan to make API's needed for unzip.exe, and instead of using 'simple_file_server', I will pack all needed files to a zip file, and unpack them to a ramdisk ;-)

Beside the servers, the important part for OS/2 executables support is 'os2app' l4env program. It is 'OS/2 application container'. It is started by l4 'loader' server as 'os2app --stdin /dev/vc0 --stdout /dev/vc0 --stderr /dev/vc0 c:\minicmd.exe'. So, the 'os2app' program is started, it is passed a terminal name which will be used as stdin/stdout/stderr, and an OS/2 app to load. It starts as a separate l4 task, in the separate address space, prepares the needed OS/2 app address space layout, loads an OS/2 application and all needed DLL's (they are loaded by execsrv server, and then are passed to 'os2app' task.). Then 'os2app' prepares OS/2 application info blocks (TIB and PIB), gets OS/2 app command line parameters and environment, etc, and then starts the OS/2 app by calling its entry point.

After all, 'os2app' contains a kal.dll virtual library, which contain the calls to L4 and OS/2 personality servers to implement OS/2 API's. OS/2 API's are in doscalls.dll. Unlike the 'classic' OS/2 but like in OS/2 Warp (PowerPC edition), it is a real disk file. DOSCALLS.DLL functions are implemented on top of KAL.DLL functions. So, the border between KAL and DOSCALLS is the border between 'L4 world' and 'OS/2 world'  ;)

So, we'll trying to make additional progress. The main problem now is that at the moment only me is making something for osFree, other team members are busy now ;( So, any help is welcomed, especially if someone will help me with programming ;)

PS: I am trying to post this for the 2nd time, the previous time I tried, the message is dissappeared and I was log out from forum, so I needed to type thsi message again ;(

WBR,
valery

cyber

  • Sr. Member
  • ****
  • Posts: 253
    • View Profile
Re: OSFree Project News
« Reply #4 on: 2011.05.11, 12:43:17 »
The next release will be 0.0.5, with an earliest projected release date being not known.

Well, with just one programer writing code, I will be to old when osFree reach 0.0.12 version.  (OOREXX) :(

valerius

  • Newbie
  • *
  • Posts: 12
    • View Profile
Re: OSFree Project News
« Reply #5 on: 2011.05.11, 18:17:33 »
The next release will be 0.0.5, with an earliest projected release date being not known.

Version 0.0.5 will be the nearest official release. It is official milestones only. But we upload many unofficial builds, so the progress can be seen. The date is not known because all we write the code at our spare time, so no strict plan available. It depends on our free time and enthusiasm :)

Quote from: cyber
Well, with just one programer writing code, I will be to old when osFree reach 0.0.12 version.  (OOREXX) :(

So, attract new people, promote the project, tell about it other people, sponsor it, participate in it... Many OS/2 users are too passive unfortunately :( But not so long time ago two people had impressed with our project news and said that they maybe, will join it. So, maybe someone will help us to progress more quicker. Maybe, you too, if you really wish it ;-)
« Last Edit: 2011.05.11, 18:22:00 by valerius »

demetrioussharpe

  • Full Member
  • ***
  • Posts: 206
    • View Profile
Re: OSFree Project News
« Reply #6 on: 2011.05.17, 19:25:07 »
The next release will be 0.0.5, with an earliest projected release date being not known.

Version 0.0.5 will be the nearest official release. It is official milestones only. But we upload many unofficial builds, so the progress can be seen. The date is not known because all we write the code at our spare time, so no strict plan available. It depends on our free time and enthusiasm :)

Quote from: cyber
Well, with just one programer writing code, I will be to old when osFree reach 0.0.12 version.  (OOREXX) :(

So, attract new people, promote the project, tell about it other people, sponsor it, participate in it... Many OS/2 users are too passive unfortunately :( But not so long time ago two people had impressed with our project news and said that they maybe, will join it. So, maybe someone will help us to progress more quicker. Maybe, you too, if you really wish it ;-)


You know, it's no secret that I'm not a fan of the OS/2 PPC style of architecture & I'm sure that I've been more than a little critical of the choice to use that approach. With that being said, I'm impressed with you're progress. I look forward to seeing what you guys accomplish. Regardless of which route I decide to take (if I start working on a kernel at all), I wish you guys the best of luck!
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

valerius

  • Newbie
  • *
  • Posts: 12
    • View Profile
Re: OSFree Project News
« Reply #7 on: 2011.05.19, 16:50:07 »
Hi, demetrioussharpe.

Really, we just benefit from using L4 together with l4env, not a bare microkernel. So, many thanks go to its authors. For example, we have a base for implementing files support -- a l4vfs subsystem, into which we must only write our own file servers, which integrate into it. Also, for textmode application support, we already have stdin/stdout/stderr support in form of terminals server which serves files which can be used as stdin/stdout/stderr for programs, so we have some kind of lego constructor. which speeds up the development. So, this is not a miracle :) And also, there is a generic graphical virtual consoles support too (a terminal server attaches a virtual console for each its terminal, so, if we extend the terminal server, we could also create VIO support). Also, some other primitives exist, like virtual memory construction via region map and dataspaces; event semaphores, mutexes, signals... They support some base functionality, so we can use them to implement OS/2-kind semaphores, thread and exceptions.

Thank you for your note
WBR,
valery

theuserbl

  • Newbie
  • *
  • Posts: 1
    • View Profile
Re: OSFree Project News
« Reply #8 on: 2011.05.19, 20:59:28 »
Very nice.
In my eyes OsFree is for OS/2 something similar like something between WINE and ReactOS for Windows.
Like WINE it is based on a complete different other operating system. And like ReactOS it uses for the own system real EXE-files.

But a little optical thing:
Your MiniCMD-prompt is "C:\>". But that is on OS/2 only the DOS-prompt. The own OS/2 prompt is "[C:\]:)

Greatings
theuserbl

valerius

  • Newbie
  • *
  • Posts: 12
    • View Profile
Re: OSFree Project News
« Reply #9 on: 2011.05.20, 05:46:24 »
No, osFree is not like Wine. It is complete OS/2 implementation on the base of L4 microkernel and some microkernel services. Those services are not a complete 'Operating system', but a some  'construction kit' for building OS'es. If it could be based on Linux or windows, then it could be like WINE (it is based on another API), but osFree is not based on other OS API. It is based on a microkernel and some generic services.

Regarding the command prompt, -- I don't think we must make it similar to OS/2 cmd.exe, and command prompt to be in square brackets ;) It is just a test program, minicmd.exe, which is intended to be a minimal OS/2 application, for which API is implemented. It is 1) minimal 2) can start extermal programs 3) may be, the 'dir' command will be implemented, for completeness. But it should not copy the behaviour of cmd.exe or 4os2.exe. When we will implement enough API's, we'll simply change it to a real 4.os2.exe -- why reinvent the wheel? :)

PS: is theuserbl == AlexT ? and why not using the realname? AlexT is one of OS/4 developers, from whom I heard similiar claims...

PPS: AlexT says that it is not he... But very similar...
« Last Edit: 2011.05.20, 07:44:47 by valerius »