16 Oct
2005
16 Oct
'05
10:10 p.m.
Ok Thomas. I am beginning to understand.
I'm a bit slow. I saw it as merely providing a more stable Foundation for ROS, that is
all.
If you are so unknowing of OSI, and API and all that stuff now, and do not care, then I am
wasting your time.
Sorry.
Frankly, the Universal API is still only an Idea which never got off the ground about 25
years ago (because of in-fighting), but still does work in isolated practice.
From the Email I am getting there is so much
disagreement on this list you will need all you time and effort to keep it from
collapsing.
In your best interest, please consider this topic closed.
Regards and Success
Justin
---- Thomas Weidenmueller <thomas(a)reactsoft.com> wrote:
jwalsh(a)bigpond.net.au wrote:
I'll switch to private mode, so as not to
annoy the ros-general list.
It is a little off topic.
I don't think that's a good idea, especially when I keep getting
annoying spam approval emails which I won't approve.
I'll choose three references which I feel, by
and large, describe the API.
The first also includes a reference to wine:
1.
http://www.absoluteastronomy.com/encyclopedia/a/ap/application_programming_…
2. http://www.absoluteastronomy.com/encyclopedia/o/os/osi_model2.htm
3. http://en.wikipedia.org/wiki/Layer_2
I do know the OSI model and I do know what APIs are. I however don't
know what exactly the UAPI is supposed to be. We're working on a windows
compatible operating system. We do not plan to add ReactOS-specific
APIs, so whatever UAPI is, unless it's an API provided by Windows,
there's a low chance we'd ever implement it into the core code base.
What we expect to do, is study the "rats
nest" of protocols and reduces them to a single Universal OSI Standard. We believer
that hardware must dance to the tune of software, not the opposite.
We have some success at the Application Layer (level 7) already.
Here we can reduce many hundreds of applications to a single application, automatically.
Then we simply print of the "blueprint" i.e. Application Requirements
Definition (ARD).
We then simply pass the ARD to the programmers to be put into code.
This way we have turned a medievel like craft into an industrial process.
In fact we are preparing to generate the code directly from the text based ARD.
We can't change existing hardware, ReactOS is supposed to work on the
existing platforms. What you described is extremely theoretical, I still
don't really know what it is supposed to be. Most of us - i think - are
more practical people, give us the detailed description of how the API
is supposed to look like and what it should provide and we can do it.
Discussing theories about APIs that don't exist (in Windows) doesn't
make much sense I think.
We have reduced application development from
months-years to hours-days.
That's great, for ReactOS this is just not going to work.
Unfortunately, no matter how perfect our design
is, it can only be as good as the weakest link.
We've found that weakest link hidden in the API itself, outside of our control.
Of course the hardware providers will not be happy with this development.
Which leads to the question whether hardware depends on software or the
other way around...
Neither will the software providers who write the
drivers.
It must be, if it is to be backward (and forward) compatible, transparent to the any and
every application.
Wine, in a sense is trying to acheive the same thing, by not trying to create a single
standard, but merely an API adapter.
Wine is all about creating a compatible implementation of the Win32 API.
Sorry again for being so long winded.
Hope that explains it
Not really, sorry ;)
So my final question about this - and I don't plan to spend any more
time about this - is: Is this UAPI thing just a theory or actually an
API that exists?
- Thomas
_______________________________________________
ros-general mailing list
ros-general(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-general