#361 From: "Bartosz Tomasik (Bart/2)" <bart2@...>
Date: Thu Mar 7, 2002 2:41 pm
Subject: Re: Microwindows gui? ihsiatko
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
On Tue, 05 Mar 2002 20:23:44 -0000, tomleem7659 wrote:
>I was referred to microwindows gui when I asked the
>[...]
>Can this be used with the 'osfree' project? I believe
>it is open source.
I am aware of this and examining that....
-------------------------------------------------
Bart/2 irc:Ihsahn Bart2@... UIN:50890586
Asu'a Programmers Group http://www.asua.org.pl
TeamOS/2 Polska http://www.teamos2.org.pl
Part 13 - Mar 07 2002
Re: Part 13
#362 From: "JMA" <mail@...>
Date: Wed Mar 6, 2002 12:06 am
Subject: Re: My point of view... mailjmase
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
On Mon, 04 Mar 2002 23:13:44 -0800 (PST), Lynn H. Maxson wrote:
>John Martin (JMA) writes:
>"...Lets build a good CPAPI layer and build it so it can be placed
>on more than one kernel. Then we can much more easily switch
>kernel. ..."
>
>As a retired IBM employee I find myself disqualified from
>participating in the coding of the kernel. That leaves me with
>participating in the documentation only. However, we may as well
>put this portable CPAPI issue to rest. If you haven't the
>resources to produce a single kernel, you have even less to
>produce multiple.
>
>Everything from the CPAPI on down is part of the kernel. Implicit
>in this remark is that the CPAPI is somehow an OS personality
>sitting on top of some unspecified layer. What isn't said is that
>from the CPAPI on down to the fundamental APIs is an architecture.
>
Sorry. The reason to have a CPAPI is to avoid kernel dependancies.
I must change your phrase to:
"Everything below the CPAPI and down is part of the kernel"
Dont confuse that API with its implementation.
Sincerely
JMA
Development and Consulting
John Martin , jma@...
==================================
Website: http://www.jma.se/
email: mail@...
Phone: 46-(0)70-6278410
==================================
Date: Wed Mar 6, 2002 12:06 am
Subject: Re: My point of view... mailjmase
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
On Mon, 04 Mar 2002 23:13:44 -0800 (PST), Lynn H. Maxson wrote:
>John Martin (JMA) writes:
>"...Lets build a good CPAPI layer and build it so it can be placed
>on more than one kernel. Then we can much more easily switch
>kernel. ..."
>
>As a retired IBM employee I find myself disqualified from
>participating in the coding of the kernel. That leaves me with
>participating in the documentation only. However, we may as well
>put this portable CPAPI issue to rest. If you haven't the
>resources to produce a single kernel, you have even less to
>produce multiple.
>
>Everything from the CPAPI on down is part of the kernel. Implicit
>in this remark is that the CPAPI is somehow an OS personality
>sitting on top of some unspecified layer. What isn't said is that
>from the CPAPI on down to the fundamental APIs is an architecture.
>
Sorry. The reason to have a CPAPI is to avoid kernel dependancies.
I must change your phrase to:
"Everything below the CPAPI and down is part of the kernel"
Dont confuse that API with its implementation.
Sincerely
JMA
Development and Consulting
John Martin , jma@...
==================================
Website: http://www.jma.se/
email: mail@...
Phone: 46-(0)70-6278410
==================================
Re: Part 13
#363 From: "tomleem7659" <jersey@...>
Date: Wed Mar 6, 2002 4:43 pm
Subject: MiniGui? tomleem7659
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
I was refferred to a program called minigui when I
asked about a gui for DOS (FreeDOS to be specific).
Its url is http://www.minigui.org . I believe it
is open source (IIRC). Could it be used as a source
for this project; OSFree?
TomLeeM
Date: Wed Mar 6, 2002 4:43 pm
Subject: MiniGui? tomleem7659
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
I was refferred to a program called minigui when I
asked about a gui for DOS (FreeDOS to be specific).
Its url is http://www.minigui.org . I believe it
is open source (IIRC). Could it be used as a source
for this project; OSFree?
TomLeeM
Re: Part 13
#364 From: "timur_tabi" <timur@...>
Date: Wed Mar 6, 2002 7:02 pm
Subject: Re: Linux + OS/2 layer timur_tabi
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
--- In osFree@y..., Bert Thomas <bert@b...> wrote:
>
> Linux originally took this path, but later on they changed it to
support
> loading drivers at runtime. Ok, nowadays the kernel still supports
it to
> compile drivers into the kernel, but that is mainly for special
> application and certain drivers for "special" hardware.
Yes, drivers can be loaded dynamically, but they still must be
compiled AGAINST a kernel. That is, you can't just install a kernel
binary and then compile just the driver. If you download a driver's
source code, you must combine that source code with the source code to
a compatible kernel, and then recompile both the kernel and the driver
together. You then install the kernel in /boot and reboot. Under
this new kernel, you can then use insmod to load your driver.
> Would you really need hundreds of APIs for a driver??? OS/2's
DevHelp
> doesn't support hundreds of function calls, does it?
Maybe hundreds is an exaggeration, but in Linux, many drivers
interface with the kernel by directly accessing data structures. To
make a binary-compatible kernel, you would need to create an API for
each of these modifications. So I think you would have many more API
functions in Linux than in OS/2.
I think Windows 2000 actually does have hundreds of kernel APIs, but
then, that kernel is very bloated.
> Linux drivers in principle use a very well defined set of APIs and
> structures. I am not a very skilled driver developer, but I have
written
> several loadable kernel modules for Linux. None of them needed
something
> other than just this basic API set. It was just recently that I
> discovered that my "old" drivers wouldn't work on a new kernel. Not
> because something had changed in the APIs or internal structure, but
> just because they added that version detection mechanism.
I wrote a driver that had to manipulate the free physical memory data
structures (the struct mem_map_t array) directly because Linux (unlike
Windows) doesn't provide any API functions to do what I needed to do.
I had to port this one driver from Windows to Linux, and where
Windows had a one-line API call, I had to write a dozen functions in
Linux to do the same thing.
> I aggree on the interesting part, but I doubt this was the goal of
the
> designers.
I think it is. I've been involved in enough lkml discussions to hear
this exact sentiment numerous times.
>In theory, they could write (and some even do!) loadable
> modules for every major version of the kernel and make only the
object
> binaries available).
I tried doing that, and that doesn't really work. In most cases,
you'll get lucky and the driver will load and function, but only
because it interfaces with a subset of the Linux kernel, and avoids
the part that is incompatible.
I once worked for a company that could not release its source code,
but the driver had to interface very closely with the kernel and some
critical data strutures. It was a nightmare. We had to divide the
driver into "open-source" and "closed-source" portions, where the
installation routine would actually compile the open source portions
and link them with the closed-source object modules.
> And what about 'make menuconfig' ? Not user friendly enough?
make menuconfig doesn't scan your hardware to determine what you have
installed! The Red Hat installer installs a generic kernel that has
every module compiled, and at runtime a tool called kudzu examines
your hardware (presumably by comparing PCI registers) and loads the
appropriate driver.
> Isn't that just something in the nature of Unix?
No, it's not. Just look at Mac OS X. A distribution vendor could
decide that they really want to target the home market, and create a
version of Linux that really is user-friendly. Most of the tools are
there, someone just needs to spend the time and money to make it
happen.
Date: Wed Mar 6, 2002 7:02 pm
Subject: Re: Linux + OS/2 layer timur_tabi
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
--- In osFree@y..., Bert Thomas <bert@b...> wrote:
>
> Linux originally took this path, but later on they changed it to
support
> loading drivers at runtime. Ok, nowadays the kernel still supports
it to
> compile drivers into the kernel, but that is mainly for special
> application and certain drivers for "special" hardware.
Yes, drivers can be loaded dynamically, but they still must be
compiled AGAINST a kernel. That is, you can't just install a kernel
binary and then compile just the driver. If you download a driver's
source code, you must combine that source code with the source code to
a compatible kernel, and then recompile both the kernel and the driver
together. You then install the kernel in /boot and reboot. Under
this new kernel, you can then use insmod to load your driver.
> Would you really need hundreds of APIs for a driver??? OS/2's
DevHelp
> doesn't support hundreds of function calls, does it?
Maybe hundreds is an exaggeration, but in Linux, many drivers
interface with the kernel by directly accessing data structures. To
make a binary-compatible kernel, you would need to create an API for
each of these modifications. So I think you would have many more API
functions in Linux than in OS/2.
I think Windows 2000 actually does have hundreds of kernel APIs, but
then, that kernel is very bloated.
> Linux drivers in principle use a very well defined set of APIs and
> structures. I am not a very skilled driver developer, but I have
written
> several loadable kernel modules for Linux. None of them needed
something
> other than just this basic API set. It was just recently that I
> discovered that my "old" drivers wouldn't work on a new kernel. Not
> because something had changed in the APIs or internal structure, but
> just because they added that version detection mechanism.
I wrote a driver that had to manipulate the free physical memory data
structures (the struct mem_map_t array) directly because Linux (unlike
Windows) doesn't provide any API functions to do what I needed to do.
I had to port this one driver from Windows to Linux, and where
Windows had a one-line API call, I had to write a dozen functions in
Linux to do the same thing.
> I aggree on the interesting part, but I doubt this was the goal of
the
> designers.
I think it is. I've been involved in enough lkml discussions to hear
this exact sentiment numerous times.
>In theory, they could write (and some even do!) loadable
> modules for every major version of the kernel and make only the
object
> binaries available).
I tried doing that, and that doesn't really work. In most cases,
you'll get lucky and the driver will load and function, but only
because it interfaces with a subset of the Linux kernel, and avoids
the part that is incompatible.
I once worked for a company that could not release its source code,
but the driver had to interface very closely with the kernel and some
critical data strutures. It was a nightmare. We had to divide the
driver into "open-source" and "closed-source" portions, where the
installation routine would actually compile the open source portions
and link them with the closed-source object modules.
> And what about 'make menuconfig' ? Not user friendly enough?
make menuconfig doesn't scan your hardware to determine what you have
installed! The Red Hat installer installs a generic kernel that has
every module compiled, and at runtime a tool called kudzu examines
your hardware (presumably by comparing PCI registers) and loads the
appropriate driver.
> Isn't that just something in the nature of Unix?
No, it's not. Just look at Mac OS X. A distribution vendor could
decide that they really want to target the home market, and create a
version of Linux that really is user-friendly. Most of the tools are
there, someone just needs to spend the time and money to make it
happen.
Re: Part 13
#365 From: "Lynn H. Maxson" <lmaxson@...>
Date: Wed Mar 6, 2002 7:54 pm
Subject: Re: My point of view... lynnmaxson
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
John Martin (JMA) writes:
"Sorry. The reason to have a CPAPI is to avoid kernel
dependancies.
I must change your phrase to: "Everything below the CPAPI and down
is part of the kernel"
Dont confuse that API with its implementation."
I'm trying to understand just where the confusion lies. API
stands for Application Programming Interface. CPAPI stands for
Control Program Application Programming Interface. Essentially we
have a "connection" through an interface, on the "calling" side of
which is the application and on the "responding" side, the control
program.
Like it or not the CPAPI is an implementation, a support
commitment allowing an application to communicate with (in this
instance) a control program. All portions of the control program
reside within the kernel as does the "responding" connection
portion of the interface.
In truth you cannot make the CPAPI independent of kernel as we
must have a path from the application layer interface, the CPAPI,
down to the lowest support layer in the kernel. That set of paths
represents an architecture, a kernel dependent architecture.
This does not change and only gets more complicated when
"layering" one OS's CPAPI (a guest) on top of another (the host).
All you have done is place an application layer with its lowest
level based on the host CPAPI with its highest level based on the
guest CPAPI. If this layering were such a done deal, then ODIN
would no longer remain essentially a "beta test" product, i.e. let
the user beware.
The microkernel takes a different approach. It regards a kernel
as something composed of two parts, the microkernel plus one or
more OS personalities. The microkernel, in effect, regards an OS
personality as an application, a buffered layer lying between it
and the applications written to its interface.
Thus the microkernel becomes the kernel-independent unit, as it
depends on no lower level of support. The OS personalities become
microkernel-dependent. However, this dependency now means that
they can co-reside as well as execute concurrently, in fact
multiple copies of each. This form of parallel "layering" of OS
personalities on top of a microkernel offers the best guarantee of
"shortest path" (thus maximum performance) over any vertical
layering approach.
Consider then that a specific kernel has a lowest API level, which
we will designate as a MKAPI, and a highest level, a CPAPI. Thus
you have three well-defined layers: (1) a microkernel layer, (2)
an OS personality layer, and (3) an application layer. We connect
them as follows:
<microkernel>[MKAPI]<os_personality>[CPAPI]<application>.
<*****************(((kernel)))*********><***(((application)))***>
Now the MKAPI has to support the sum of the CPAPIs of the various
personalities. This means that in general this sum is a
"superset" of any OS CPAPI, which in turn makes it a "proper"
subset. This superset capability of the MKAPI allows then for the
functional expansion and extension of any guest OS. In a sense it
is more important to define the MKAPI, as this defines the total
functionality (in terms of existing and future extensions) of any
guest OS personality.
In the FreeOS forum a division occurred on which was the easiest
and fastest means of implementation. Basically it came down to a
difference of opinion between Frank Griffin and myself, he
favoring a vertical layering approach on top of Linux and I, a
parallel layering on top of a microkernel. We each think that our
selection was the easiest and fastest to implement. Please
understand I say this with the greatest respect for Frank Griffin.
Just as we have multiple OS personalities to deal with we seem to
have an equal amount of microkernel choices, an equal number of
MKAPI sets to evaluate. As "No man is an island" no microkernel
decision is independent of a chosen OS personality, which in turn
is not independent its application possibilities. Thus we have an
architecture defined from the MKAPI level through the CPAPI level
to the desired set of APAPI levels. This says that what we want
to do in terms of applications drives what we must do in terms of
support.
While it is well and good to direct coding efforts at the CPAPI
level and above, replacing existing support with improved
replacements while maintaining functionality, in and off itself it
does nothing to preserve and extend OS/2 into a future beyond IBM
support. Making an exact OS/2 open source clone available some
five years after cessation of IBM support offers existing users no
more than what they have.
Why not then offer a better OS/2 than OS/2, a better Linux than
Linux, and a better Windows than Windows? Why not offer a
replacement product superior in terms of performance,
functionality, quality, reliability, security, and resource usage
to any of the others? At the same time protect users' application
investments?
Frankly doing all this is no harder, in fact easier, than going
around the barn trying to not do it.
Date: Wed Mar 6, 2002 7:54 pm
Subject: Re: My point of view... lynnmaxson
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
John Martin (JMA) writes:
"Sorry. The reason to have a CPAPI is to avoid kernel
dependancies.
I must change your phrase to: "Everything below the CPAPI and down
is part of the kernel"
Dont confuse that API with its implementation."
I'm trying to understand just where the confusion lies. API
stands for Application Programming Interface. CPAPI stands for
Control Program Application Programming Interface. Essentially we
have a "connection" through an interface, on the "calling" side of
which is the application and on the "responding" side, the control
program.
Like it or not the CPAPI is an implementation, a support
commitment allowing an application to communicate with (in this
instance) a control program. All portions of the control program
reside within the kernel as does the "responding" connection
portion of the interface.
In truth you cannot make the CPAPI independent of kernel as we
must have a path from the application layer interface, the CPAPI,
down to the lowest support layer in the kernel. That set of paths
represents an architecture, a kernel dependent architecture.
This does not change and only gets more complicated when
"layering" one OS's CPAPI (a guest) on top of another (the host).
All you have done is place an application layer with its lowest
level based on the host CPAPI with its highest level based on the
guest CPAPI. If this layering were such a done deal, then ODIN
would no longer remain essentially a "beta test" product, i.e. let
the user beware.
The microkernel takes a different approach. It regards a kernel
as something composed of two parts, the microkernel plus one or
more OS personalities. The microkernel, in effect, regards an OS
personality as an application, a buffered layer lying between it
and the applications written to its interface.
Thus the microkernel becomes the kernel-independent unit, as it
depends on no lower level of support. The OS personalities become
microkernel-dependent. However, this dependency now means that
they can co-reside as well as execute concurrently, in fact
multiple copies of each. This form of parallel "layering" of OS
personalities on top of a microkernel offers the best guarantee of
"shortest path" (thus maximum performance) over any vertical
layering approach.
Consider then that a specific kernel has a lowest API level, which
we will designate as a MKAPI, and a highest level, a CPAPI. Thus
you have three well-defined layers: (1) a microkernel layer, (2)
an OS personality layer, and (3) an application layer. We connect
them as follows:
<microkernel>[MKAPI]<os_personality>[CPAPI]<application>.
<*****************(((kernel)))*********><***(((application)))***>
Now the MKAPI has to support the sum of the CPAPIs of the various
personalities. This means that in general this sum is a
"superset" of any OS CPAPI, which in turn makes it a "proper"
subset. This superset capability of the MKAPI allows then for the
functional expansion and extension of any guest OS. In a sense it
is more important to define the MKAPI, as this defines the total
functionality (in terms of existing and future extensions) of any
guest OS personality.
In the FreeOS forum a division occurred on which was the easiest
and fastest means of implementation. Basically it came down to a
difference of opinion between Frank Griffin and myself, he
favoring a vertical layering approach on top of Linux and I, a
parallel layering on top of a microkernel. We each think that our
selection was the easiest and fastest to implement. Please
understand I say this with the greatest respect for Frank Griffin.
Just as we have multiple OS personalities to deal with we seem to
have an equal amount of microkernel choices, an equal number of
MKAPI sets to evaluate. As "No man is an island" no microkernel
decision is independent of a chosen OS personality, which in turn
is not independent its application possibilities. Thus we have an
architecture defined from the MKAPI level through the CPAPI level
to the desired set of APAPI levels. This says that what we want
to do in terms of applications drives what we must do in terms of
support.
While it is well and good to direct coding efforts at the CPAPI
level and above, replacing existing support with improved
replacements while maintaining functionality, in and off itself it
does nothing to preserve and extend OS/2 into a future beyond IBM
support. Making an exact OS/2 open source clone available some
five years after cessation of IBM support offers existing users no
more than what they have.
Why not then offer a better OS/2 than OS/2, a better Linux than
Linux, and a better Windows than Windows? Why not offer a
replacement product superior in terms of performance,
functionality, quality, reliability, security, and resource usage
to any of the others? At the same time protect users' application
investments?
Frankly doing all this is no harder, in fact easier, than going
around the barn trying to not do it.
Re: Part 13
#366 From: "Michal Necasek" <michaln@...>
Date: Wed Mar 6, 2002 9:43 pm
Subject: Re: My point of view... michalnec
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
On Wed, 06 Mar 2002 08:54:49 -0800 (PST), Lynn H. Maxson wrote:
>Like it or not the CPAPI is an implementation, a support
>commitment allowing an application to communicate with (in this
>instance) a control program. All portions of the control program
>reside within the kernel as does the "responding" connection
>portion of the interface.
>
That is nonsense. API is an INTERFACE. It does not rigidly
define the implementation.
>In truth you cannot make the CPAPI independent of kernel as we
>must have a path from the application layer interface, the CPAPI,
>down to the lowest support layer in the kernel. That set of paths
>represents an architecture, a kernel dependent architecture.
>
Really? Let's take a look at the OS/2 1.x Control Program API.
There are at least three OSes that provide it:
- OS/2 1.x
- OS/2 2.x
- Windows NT
Not to mention PharLap's 286|DOS extender.
You're saying that these all must be the same because they
provide the same API. I somehow don't think they are.
>This does not change and only gets more complicated when
>"layering" one OS's CPAPI (a guest) on top of another (the host).
>All you have done is place an application layer with its lowest
>level based on the host CPAPI with its highest level based on the
>guest CPAPI. If this layering were such a done deal, then ODIN
>would no longer remain essentially a "beta test" product, i.e. let
>the user beware.
>
Odin is what it is because the resources expended towards its
development are ridiculously small, not because the approach
is flawed.
Michal
Date: Wed Mar 6, 2002 9:43 pm
Subject: Re: My point of view... michalnec
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
On Wed, 06 Mar 2002 08:54:49 -0800 (PST), Lynn H. Maxson wrote:
>Like it or not the CPAPI is an implementation, a support
>commitment allowing an application to communicate with (in this
>instance) a control program. All portions of the control program
>reside within the kernel as does the "responding" connection
>portion of the interface.
>
That is nonsense. API is an INTERFACE. It does not rigidly
define the implementation.
>In truth you cannot make the CPAPI independent of kernel as we
>must have a path from the application layer interface, the CPAPI,
>down to the lowest support layer in the kernel. That set of paths
>represents an architecture, a kernel dependent architecture.
>
Really? Let's take a look at the OS/2 1.x Control Program API.
There are at least three OSes that provide it:
- OS/2 1.x
- OS/2 2.x
- Windows NT
Not to mention PharLap's 286|DOS extender.
You're saying that these all must be the same because they
provide the same API. I somehow don't think they are.
>This does not change and only gets more complicated when
>"layering" one OS's CPAPI (a guest) on top of another (the host).
>All you have done is place an application layer with its lowest
>level based on the host CPAPI with its highest level based on the
>guest CPAPI. If this layering were such a done deal, then ODIN
>would no longer remain essentially a "beta test" product, i.e. let
>the user beware.
>
Odin is what it is because the resources expended towards its
development are ridiculously small, not because the approach
is flawed.
Michal
Re: Part 13
#367 From: "Gregory L. Marx" <gregory.marx@...>
Date: Wed Mar 6, 2002 2:09 pm
Subject: Re: Re: Linux + OS/2 layer chekmarx
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
On Tue, 05 Mar 2002 16:53:52 -0000, timur_tabi wrote:
<snip>
>Linux #1 problem is that none of the distribution vendors really
>understand what "user friendly" really means.
We have a winner !!!
This single statement sums up for me the single biggest problem with Linux ...
Many of the distros are attempting to emulate Windows ... which IMO is not a
good thing ...
I'd like to see them develope a "user-friendly" personality all on their own ...
But as Timur states they don't seem to understand what that means ...
Greg
Date: Wed Mar 6, 2002 2:09 pm
Subject: Re: Re: Linux + OS/2 layer chekmarx
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
On Tue, 05 Mar 2002 16:53:52 -0000, timur_tabi wrote:
<snip>
>Linux #1 problem is that none of the distribution vendors really
>understand what "user friendly" really means.
We have a winner !!!
This single statement sums up for me the single biggest problem with Linux ...
Many of the distros are attempting to emulate Windows ... which IMO is not a
good thing ...
I'd like to see them develope a "user-friendly" personality all on their own ...
But as Timur states they don't seem to understand what that means ...
Greg
Re: Part 13
#368 From: "JMA" <mail@...>
Date: Wed Mar 6, 2002 1:12 pm
Subject: Re: Microwindows gui? mailjmase
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
On Tue, 05 Mar 2002 20:23:44 -0000, tomleem7659 wrote:
>I was referred to microwindows gui when I asked the
>FreeDOS group about a small graphical user interface
>that could be used with their FreeDOS software
>(http://www.freedos.org) and be used to start programs
>without having to go their directories. I found the
>microwindows gui web site (http://www.microwindows.org).
>Can this be used with the 'osfree' project? I believe
>it is open source.
>
Sure, but if we dont want to go for a PM compatability then
xFree/86 is a much better choice. Its mature, has lots of
drivers and porting Linux apps is relativly easy.
Sincerely
JMA
Development and Consulting
John Martin , jma@...
==================================
Website: http://www.jma.se/
email: mail@...
Phone: 46-(0)70-6278410
==================================
Date: Wed Mar 6, 2002 1:12 pm
Subject: Re: Microwindows gui? mailjmase
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
On Tue, 05 Mar 2002 20:23:44 -0000, tomleem7659 wrote:
>I was referred to microwindows gui when I asked the
>FreeDOS group about a small graphical user interface
>that could be used with their FreeDOS software
>(http://www.freedos.org) and be used to start programs
>without having to go their directories. I found the
>microwindows gui web site (http://www.microwindows.org).
>Can this be used with the 'osfree' project? I believe
>it is open source.
>
Sure, but if we dont want to go for a PM compatability then
xFree/86 is a much better choice. Its mature, has lots of
drivers and porting Linux apps is relativly easy.
Sincerely
JMA
Development and Consulting
John Martin , jma@...
==================================
Website: http://www.jma.se/
email: mail@...
Phone: 46-(0)70-6278410
==================================
Re: Part 13
#369 From: "Lynn H. Maxson" <lmaxson@...>
Date: Thu Mar 7, 2002 11:02 am
Subject: Re: My point of view... lynnmaxson
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
Michal Necasek writes:
"That is nonsense. API is an INTERFACE. It does not rigidly
define the implementation."
If by implementation you mean "how" the source is written, the
actual coding, you are correct. If, however, you mean "what" the
source does, you are incorrect. The APIs define the functions,
their inputs, their outputs, and "what" processing must occur.
"Really? Let's take a look at the OS/2 1.x Control Program API.
There are at least three OSes that provide it:
- OS/2 1.x
- OS/2 2.x
- Windows NT
Not to mention PharLap's 286|DOS extender.
You're saying that these all must be the same because they
provide the same API. I somehow don't think they are."
Refer to my previous response, the difference between "how"
something is achieved and "what" it is supposed to achieve. In
all the examples you provide they could differ on the "how", but
to be logically equivalent they cannot differ on the "what".
The "what" determines the architecture. The "how" exists to
support the "what". The same highest levele "whats" can have
different architectures internally, i.e. the aggregate set of
paths from the lowest level APIs to the highest. It's just a
different construction, a "how", to produce the same result. But
the highest level "whats" in turn determine the lower.
"Odin is what it is because the resources expended towards its
development are ridiculously small, not because the approach
is flawed."
ODIN was flawed from the get-go, not as a technical blunder, but
as a support one. The same effort applied to a microkernel
approach would have produced a Windows personality and be further
along than it is. However, the support issue is seemingly
overlooked in all the approaches offered here.
That issue lies in the problem determination/resolution when an
application breaks. Is it a problem with the application in its
"native" OS or not? That means you must have a native OS
environment (vendor supplied) in which the application fails
identically. If it does not fail in its native OS, then the fault
lies with the non-native environment.
The ODIN developers seek to provide a technical solution without a
support infrastructure for the larger marketplace. Thus ODIN does
nothing to expand the market for OS/2. Neither, in fact, does the
microkernel approach as it expands a market for itself independent
of OS/2.
I have no argument with those who have participated in ODIN as
either developers or users. I applaud them for what technical
success they enjoy. I know many of my fellow OS/2 users in SCOUG
(Southern California OS/2 User Group) use ODIN. At Warpstock '98
in Chicago Tabi Timur preceded me as a speaker presenting his
ODIN-like effort ongoing at the time. My feeling then as it is
now is that even if it succeeds 100% technically, it will fail in
terms of expanding the OS/2 marketplace without an adequate
support infrastructure.
Date: Thu Mar 7, 2002 11:02 am
Subject: Re: My point of view... lynnmaxson
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
Michal Necasek writes:
"That is nonsense. API is an INTERFACE. It does not rigidly
define the implementation."
If by implementation you mean "how" the source is written, the
actual coding, you are correct. If, however, you mean "what" the
source does, you are incorrect. The APIs define the functions,
their inputs, their outputs, and "what" processing must occur.
"Really? Let's take a look at the OS/2 1.x Control Program API.
There are at least three OSes that provide it:
- OS/2 1.x
- OS/2 2.x
- Windows NT
Not to mention PharLap's 286|DOS extender.
You're saying that these all must be the same because they
provide the same API. I somehow don't think they are."
Refer to my previous response, the difference between "how"
something is achieved and "what" it is supposed to achieve. In
all the examples you provide they could differ on the "how", but
to be logically equivalent they cannot differ on the "what".
The "what" determines the architecture. The "how" exists to
support the "what". The same highest levele "whats" can have
different architectures internally, i.e. the aggregate set of
paths from the lowest level APIs to the highest. It's just a
different construction, a "how", to produce the same result. But
the highest level "whats" in turn determine the lower.
"Odin is what it is because the resources expended towards its
development are ridiculously small, not because the approach
is flawed."
ODIN was flawed from the get-go, not as a technical blunder, but
as a support one. The same effort applied to a microkernel
approach would have produced a Windows personality and be further
along than it is. However, the support issue is seemingly
overlooked in all the approaches offered here.
That issue lies in the problem determination/resolution when an
application breaks. Is it a problem with the application in its
"native" OS or not? That means you must have a native OS
environment (vendor supplied) in which the application fails
identically. If it does not fail in its native OS, then the fault
lies with the non-native environment.
The ODIN developers seek to provide a technical solution without a
support infrastructure for the larger marketplace. Thus ODIN does
nothing to expand the market for OS/2. Neither, in fact, does the
microkernel approach as it expands a market for itself independent
of OS/2.
I have no argument with those who have participated in ODIN as
either developers or users. I applaud them for what technical
success they enjoy. I know many of my fellow OS/2 users in SCOUG
(Southern California OS/2 User Group) use ODIN. At Warpstock '98
in Chicago Tabi Timur preceded me as a speaker presenting his
ODIN-like effort ongoing at the time. My feeling then as it is
now is that even if it succeeds 100% technically, it will fail in
terms of expanding the OS/2 marketplace without an adequate
support infrastructure.
Re: Part 13
#370 From: "dwgras" <dwgras@...>
Date: Wed Mar 6, 2002 11:39 pm
Subject: Re: My point of view... dwgras
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
Does this disqualify you from reviewing any code and offering
suggestions since you wouldn't actually be writing any code.
Also is your expertise in kernal coding?
What about coding for other areas of the project?
Regards,
David Graser
--- In osFree@y..., "Lynn H. Maxson" <lmaxson@p...> wrote:
>
> As a retired IBM employee I find myself disqualified from
> participating in the coding of the kernel. That leaves me with
> participating in the documentation only. However, we may as well
> put this portable CPAPI issue to rest. If you haven't the
> resources to produce a single kernel, you have even less to
> produce multiple.
>
Date: Wed Mar 6, 2002 11:39 pm
Subject: Re: My point of view... dwgras
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
Does this disqualify you from reviewing any code and offering
suggestions since you wouldn't actually be writing any code.
Also is your expertise in kernal coding?
What about coding for other areas of the project?
Regards,
David Graser
--- In osFree@y..., "Lynn H. Maxson" <lmaxson@p...> wrote:
>
> As a retired IBM employee I find myself disqualified from
> participating in the coding of the kernel. That leaves me with
> participating in the documentation only. However, we may as well
> put this portable CPAPI issue to rest. If you haven't the
> resources to produce a single kernel, you have even less to
> produce multiple.
>