lpino, Posted: Jun 13, 2008 5:15:29 pm:
Is very good to see this forum up and runing. I'm waiting to hear some news from the
development team on how are things progressing, what problems they have and the
direction they are going, always hoping to see a prototype of some kind working.
Congrats on the new forum
Leonardo Pino
Good to see this up and running
Re: Good to see this up and running
Ben Dragon, Posted: Jun 13, 2008 6:51:37 pm:
Yes. Congratulations on the new forum.
It is pleasing to know that the OSFree project is not dead.
There does seem to be some problem with this forum though... several of the buttons
aren't working... "Quote", " "Add Reply" for example.
Actually, on further examination, they sometimes will work after reloading and re-clicking
a few times.
I'm certainly more than interested to hear what the present state of development is though. 8)
Yes. Congratulations on the new forum.
It is pleasing to know that the OSFree project is not dead.
There does seem to be some problem with this forum though... several of the buttons
aren't working... "Quote", " "Add Reply" for example.
Actually, on further examination, they sometimes will work after reloading and re-clicking
a few times.
I'm certainly more than interested to hear what the present state of development is though. 8)
Re: Good to see this up and running
BigWarpGuy, Posted: Jun 14, 2008 11:00:32 am:
I am glad this site is back and am looking forward to using OSFree in the future
as a replacement for eCS if it goes away.
BigWarpGuy --
http://www.os2world.com
http://www.os2ecs.org
I am glad this site is back and am looking forward to using OSFree in the future
as a replacement for eCS if it goes away.
BigWarpGuy --
http://www.os2world.com
http://www.os2ecs.org
Re: Good to see this up and running
prokushev, Posted: Jun 19, 2008 10:59:49 am:
Actually, we continue our work on following ways:
Actually, we continue our work on following ways:
- Kernel loader. Mostly works, now we at level of menu implementation. Usage
without menu is possible now. - Command line tools. Some tools sources added to build environment and now
more compatible with original OS/2 tools. - OS/2 Personality server. For now development is stalled. At the present time
we can parse configuration file and execute shell. Also we have LX loader which
works less or more well under Linux. We need to port it to L4. - FreePM. Now development goes under Linux using SDL as core.
- REXX. Integrated some ooREXX sources and added replacement of RexxUtils.
RexxMath library also added. - Multimedia. Added JPGIO procedure and MMAudio Pak 2.
As always, we are open for contributors.
wbr,
Yuri
Re: Good to see this up and running
lpino, Posted: Jun 19, 2008 10:08:09 pm:
Have you thought out a plan or a design?. Is the OS/2 personality server going to capture
all the API calls and send them to the L4?, what about i/o interrupts?, file system access?,
are you planning on having a server for file system issues?
Finally, device drivers?,,, how are you going to do it?, There is an effort to port the Mac OSX
I/O driver model from Mach to L4 to see if the theorical improved performance of L4 translates
to a faster driver model.
Good to hear you are working hard. Don't desperate, as soon as you came out of really low level
stuff you will begin to get more help.
When you are done with the menu, can you post a picture on the site?
PS. The dates of the posts here are wrong
Thanks
Have you thought out a plan or a design?. Is the OS/2 personality server going to capture
all the API calls and send them to the L4?, what about i/o interrupts?, file system access?,
are you planning on having a server for file system issues?
Finally, device drivers?,,, how are you going to do it?, There is an effort to port the Mac OSX
I/O driver model from Mach to L4 to see if the theorical improved performance of L4 translates
to a faster driver model.
Good to hear you are working hard. Don't desperate, as soon as you came out of really low level
stuff you will begin to get more help.
When you are done with the menu, can you post a picture on the site?
PS. The dates of the posts here are wrong
Thanks
Re: Good to see this up and running
valerius, Posted: Jun 20, 2008 1:10:09 am:
2lpino: We've now some partly planned scheme. There will be L4 microkernel with
Personality-Neutral servers at the bottom of the scheme. L4 executes at kernel level
and all other servers at user level. Personality Neutral (PN) services handle some basic
resources, like I/O, Interrupts, memory access, console access. PN servers are based
on L4 environment developed by Technische Universitaet Dresden along with L4/Fiasco
microkernel. L4env has partly implemented a DDE -- Device Driver Environment -- the
device driver wrappers for Linux drivers. There is, for example, ATA/IDE driver etc.
We plan to re-use DDE environment as device driver model. For I/O and IRQ access
these drivers use l4io server which is a part of l4env (L4 environment).
Concerning device drivers. DDE environment lets to use a big codebase of Linux drivers.
It is not yet fully implemented at this time but in future we could use almost any Linux
drivers. MacOS drivers as I know is being ported at NICTA (Australia) to L4Ka::Pistachio-embedded,
but we use Fiasco, not Pistachio. MacOS drivers are part of L4/Darwin (Darbat) project to port
Darwin (the underlying UNIX-like OS for MacOS X, implemented as a services on top of Mach
microkernel). So, Darbat ports Darwin to L4 from Mach microkernel and lets it to exploit the
improved performance of L4. But as I already said, this is for Pistachio microkernel, and we
use Fiasco. Darbat could be probably ported to Fiasco, but it has an older API version of base
microkernel.
Now we're trying to implement an OS/2 Server prototype. It starts along with L4 microkernel
and L4env services and it parses a config.sys file, from which it gets a client program name
(the client program, using OS/2 API's, is started as a PM prototype, from protshell= statement).
The scheme is the following: The OS/2 server implements OS/2 API and environment for client
programs. Also, there is a DOSCALLS.DLL library, which is imported by each OS/2 program.
DOSCALLS in Intel OS/2 is just a virtual library implemented by OS/2 kernel. But in microkernel
version of OS/2 it is a real existing DLL. It was so in OS/2 (PowerPC) and it will be so in our
version of OS/2. Thus, every OS/2 program imports a doscalls.dll library. Doscalls functions
implement OS/2 API's and for help with it they send microkernel messages to OS/2 server.
DOSCALLS library is (according to Yuri's idea) divided into two parts: DOSCALLS itself and
KAL library. KAL is "Kernel abstraction layer" (for lack of better name). It communicates
directly with OS/2 server and implements a base for DOSCALLS. DOSCALLS functions are
depended by it. For example, MSG API for messages in .msg files is in Intel OS/2 implemented
in DOSCALL1.DLL and is not kernel-dependent. msg.dll is just a forwarder to doscall1.dll. But
MSG API's are implemented completely in DOSCALL1 and they don't depend on kernel. So, for
example, MSG API could be implemented directly in DOSCALLS.DLL, without calling KAL. Thus,
DOSCALLS functions are based on KAL functions and KAL functions are the "CORE" for OS/2 API
which cannot be implemented without the help of OS/2 Server. And DOSCALLS functions are (in
fact there are many such functions) depended on them.
In our prototype, OS/2 server starts a client program. It knows its name from config.sys. The
client program takes place of protshell= program. So, we implement an API in server, and test
it in client program. The first API to test is VioWrtTTY(). So, the client program asks OS/2
server to print a message on console. Later, this prototype will be more complicated (as more
API's will be added). Now we have a server, a client and a client library as a simple l4env
application in ELF format. It is compiled by GCC in Linux. Now we're somewhat stalled trying
to make ELF executable by OpenWatcom. It appears that OW can't link an ELF executable with
imported shared library (ELF support in Watcom is at very early stage). ELF is needed because
l4env severs are all in ELF format and they can start only ELF executables. Yuri suggested to
implement only OS/2 server and KAL as ELF binaries and other parts (DOSCALLS and other libraries
and client programs will be ordinary LX executables). In the future, we plan to implement executable
formats support as a PN service (we plan to fork l4env loader server for that), the loader server
will have IXF (Installable eXecutable Formats) support, like IFS for file systems.
According the file system issues. The L4env now has a hierarchical namespace support. For that,
there are l4vfs services -- a root name server that can integrate many object servers, which create
a full hierarchical namespace. The namespace is a universal naming system for different objects,
like files, pipes, registry entries, terminals and such. They have names such as "/dir1/dir2/dir3/objXX",
divided into "directories and files", i.e. hierarchically. The objects can have any type. Each object
server mounts to a namespace branch. The filesystem server can be implemented as an object server
with "plug-in" IFS drivers. IFS is planned to be ordinary DLL's/shared libraries, exporting a standard
set of entry points, as described in IFS.inf. This is planned to be implemented as a PN service. So,
there will be a server, and a set of client libraries, which implement an object access to all
personalities. And a FS server, plugged into this system. The IFS-es are plugged into FS server. And,
in OS/2 personality, there will be OS/2-specific file system wrapper, which adds drive letters, paths
with backslashes etc.
PS: yesterday, I made simple menu for loader. (It is not final variant, of course )
do not use windows, try doors first
2lpino: We've now some partly planned scheme. There will be L4 microkernel with
Personality-Neutral servers at the bottom of the scheme. L4 executes at kernel level
and all other servers at user level. Personality Neutral (PN) services handle some basic
resources, like I/O, Interrupts, memory access, console access. PN servers are based
on L4 environment developed by Technische Universitaet Dresden along with L4/Fiasco
microkernel. L4env has partly implemented a DDE -- Device Driver Environment -- the
device driver wrappers for Linux drivers. There is, for example, ATA/IDE driver etc.
We plan to re-use DDE environment as device driver model. For I/O and IRQ access
these drivers use l4io server which is a part of l4env (L4 environment).
Concerning device drivers. DDE environment lets to use a big codebase of Linux drivers.
It is not yet fully implemented at this time but in future we could use almost any Linux
drivers. MacOS drivers as I know is being ported at NICTA (Australia) to L4Ka::Pistachio-embedded,
but we use Fiasco, not Pistachio. MacOS drivers are part of L4/Darwin (Darbat) project to port
Darwin (the underlying UNIX-like OS for MacOS X, implemented as a services on top of Mach
microkernel). So, Darbat ports Darwin to L4 from Mach microkernel and lets it to exploit the
improved performance of L4. But as I already said, this is for Pistachio microkernel, and we
use Fiasco. Darbat could be probably ported to Fiasco, but it has an older API version of base
microkernel.
Now we're trying to implement an OS/2 Server prototype. It starts along with L4 microkernel
and L4env services and it parses a config.sys file, from which it gets a client program name
(the client program, using OS/2 API's, is started as a PM prototype, from protshell= statement).
The scheme is the following: The OS/2 server implements OS/2 API and environment for client
programs. Also, there is a DOSCALLS.DLL library, which is imported by each OS/2 program.
DOSCALLS in Intel OS/2 is just a virtual library implemented by OS/2 kernel. But in microkernel
version of OS/2 it is a real existing DLL. It was so in OS/2 (PowerPC) and it will be so in our
version of OS/2. Thus, every OS/2 program imports a doscalls.dll library. Doscalls functions
implement OS/2 API's and for help with it they send microkernel messages to OS/2 server.
DOSCALLS library is (according to Yuri's idea) divided into two parts: DOSCALLS itself and
KAL library. KAL is "Kernel abstraction layer" (for lack of better name). It communicates
directly with OS/2 server and implements a base for DOSCALLS. DOSCALLS functions are
depended by it. For example, MSG API for messages in .msg files is in Intel OS/2 implemented
in DOSCALL1.DLL and is not kernel-dependent. msg.dll is just a forwarder to doscall1.dll. But
MSG API's are implemented completely in DOSCALL1 and they don't depend on kernel. So, for
example, MSG API could be implemented directly in DOSCALLS.DLL, without calling KAL. Thus,
DOSCALLS functions are based on KAL functions and KAL functions are the "CORE" for OS/2 API
which cannot be implemented without the help of OS/2 Server. And DOSCALLS functions are (in
fact there are many such functions) depended on them.
In our prototype, OS/2 server starts a client program. It knows its name from config.sys. The
client program takes place of protshell= program. So, we implement an API in server, and test
it in client program. The first API to test is VioWrtTTY(). So, the client program asks OS/2
server to print a message on console. Later, this prototype will be more complicated (as more
API's will be added). Now we have a server, a client and a client library as a simple l4env
application in ELF format. It is compiled by GCC in Linux. Now we're somewhat stalled trying
to make ELF executable by OpenWatcom. It appears that OW can't link an ELF executable with
imported shared library (ELF support in Watcom is at very early stage). ELF is needed because
l4env severs are all in ELF format and they can start only ELF executables. Yuri suggested to
implement only OS/2 server and KAL as ELF binaries and other parts (DOSCALLS and other libraries
and client programs will be ordinary LX executables). In the future, we plan to implement executable
formats support as a PN service (we plan to fork l4env loader server for that), the loader server
will have IXF (Installable eXecutable Formats) support, like IFS for file systems.
According the file system issues. The L4env now has a hierarchical namespace support. For that,
there are l4vfs services -- a root name server that can integrate many object servers, which create
a full hierarchical namespace. The namespace is a universal naming system for different objects,
like files, pipes, registry entries, terminals and such. They have names such as "/dir1/dir2/dir3/objXX",
divided into "directories and files", i.e. hierarchically. The objects can have any type. Each object
server mounts to a namespace branch. The filesystem server can be implemented as an object server
with "plug-in" IFS drivers. IFS is planned to be ordinary DLL's/shared libraries, exporting a standard
set of entry points, as described in IFS.inf. This is planned to be implemented as a PN service. So,
there will be a server, and a set of client libraries, which implement an object access to all
personalities. And a FS server, plugged into this system. The IFS-es are plugged into FS server. And,
in OS/2 personality, there will be OS/2-specific file system wrapper, which adds drive letters, paths
with backslashes etc.
PS: yesterday, I made simple menu for loader. (It is not final variant, of course )
do not use windows, try doors first