UAPI [Re: [ros-general] ReactOS UI...]

[jwalsh at bigpond.net.au]

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 at reactsoft.com> wrote: 
> jwalsh at 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_interface.htm
> > 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 at reactos.org
> http://www.reactos.org/mailman/listinfo/ros-general