jwalsh@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:
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
-
Thomas Weidenmueller