From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,b95a522100671708 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!news.glorb.com!meganewsservers.com!feeder2.on.meganewsservers.com!feed.cgocable.net!read2.cgocable.net.POSTED!53ab2750!not-for-mail From: "Warren W. Gay VE3WWG" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: For the AdaOS folks References: <1PTAd.1218$0y4.421@read1.cgocable.net> <1vemlj8wqr9ea$.qyecszhsmtqa$.dlg@40tude.net> <1b48kdfqsk3mw.7gajq12fsa82.dlg@40tude.net> <52fBd.42256$nV.1324414@news20.bellglobal.com> <_gHBd.14666$0y4.10314@read1.cgocable.net> <8rz51zshvp8k$.gvir0kpiedzk.dlg@40tude.net> In-Reply-To: <8rz51zshvp8k$.gvir0kpiedzk.dlg@40tude.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: Date: Sun, 02 Jan 2005 17:04:29 -0500 NNTP-Posting-Host: 24.150.168.167 X-Complaints-To: abuse@cogeco.ca X-Trace: read2.cgocable.net 1104703403 24.150.168.167 (Sun, 02 Jan 2005 17:03:23 EST) NNTP-Posting-Date: Sun, 02 Jan 2005 17:03:23 EST Organization: Cogeco Cable Xref: g2news1.google.com comp.lang.ada:7395 Date: 2005-01-02T17:04:29-05:00 List-Id: Dmitry A. Kazakov wrote: > On Sat, 01 Jan 2005 19:31:56 -0500, Warren W. Gay VE3WWG wrote: >>Dmitry A. Kazakov wrote: >>>On Fri, 31 Dec 2004 11:24:40 -0500, Warren W. Gay VE3WWG wrote: >>>>Dmitry A. Kazakov wrote: >>>>>On Fri, 31 Dec 2004 06:30:51 -0500, Warren W. Gay VE3WWG wrote: > Yes, because Ada's protected objects are local and cooperative. It'd like > to see system services exposed as protected objects, with entry queues and > data fully memory protected. Same with tasks. I like OO interface to OS, no > compromises. If you use Mach ports, you already get all of that (just think of the port as the handle to the object). > Where is any problem? If the kernel provides persistence and your > application needs, say an integer parameter. Derive from the base > Application_Data_Type add a field, here you are. The problem is where is the improvement over the registry API that says create/delete an integer? Put your own OO framework around it if that's what you want. >>Of course. But when you want to know where GNAT is installed, it >>is very easy in Windows to lookup a registry key and get the >>pathname for it. If I want to know where APQ should be installed >>as an Ada binding, I can do another registry query and get the >>top level GNAT directory for bindings. >> >>Is that so complicated? > > Yes it is. You have to know the names you are looking for! The first step > is of course to define some naming convention. This is a bad way, because > it is not enforced. See what happens with /etc and HKEY_LOCAL_MACHINE. So > the second step is to provide API to query that names from an application. > But that is still not good. A better way, as I said, is OO. You ask an > application: give me your settings and the result is an object of those. > The last step is to ask yourself what for? There is GNAT, an object why > cannot I talk to it directly? And how do your identify your GNAT object? At the end of the day, you still have to grapple with "names" and "identities". Only the details change. > Why there should be any pathnames? A name is used only to get an object > from a text map, provided that there should be one. So just how do you expect to identify what piece of software you want to know about, without using a name (or identity if you prefer)? OO doesn't do away with this requirement. > Once you have the > object forget about its name. It has a type and so the methods to call. Sure, like an open file you use its handle or file descriptor. Under Mach you use a port. So where's the problem? But when you open a file system object, you still have to specify which object to open by name. And a pathname is actually just a fancy composite name, because you are naming several objects all at once (from root directory down to the actual object). > Yes, this is the real source of our disagreement. As long as OS API are > non-OO you will fall back to bits and bytes or String and Unbounded_String, > if you want. Every strongly typed Ada entity is based upon bits, bytes, words and arrays of such as base types. Ie. every type has a base type. OS RTL libraries can strengthen the typing of the Ada interface. For a C interface, not much really changes. The O/S itself can present things in basic terms (registers and software interrupts for example), but the OS RTL can present it in any form you want. A binding. It is just that for an Ada based O/S, you want the RTL to support it in a first class citizen manner. > Did UNIX care much about Ada? We'll make them see! (:-)) The only problem with that is that you can make things hard for yourself. For example, I have no grand plans that I or anyone else I know, is going to convert the X-Window system to MyOS anytime soon. The best compromise is to allow an optional POSIX module on top of the mk, working with MyOS, to make it easy to port the X-Window system, if that's what I want. GNAT/GCC is another motive in that direction. > Call it service, that's no matter. I use the word OO only because it is a > known buzz word. Actually I meant ADT. The service should be a typed > object. Its entry points should have typed parameters. Type checks have to > be enforced both by the language and by the kernel. Further most of the > calls to the entry points have to be dispatching. Dispatching tables should > be memory-protected. Well, maybe I lack vision on this point, but I don't see it. The RTL can provide anything you lack at the O/S interface. >>And that is largely what the operating system >>provides. But if you say you must have OO interfaces, then >>the Ada RTL is there to let you model any way you see it. >>You could even write packages for this, or if you don't like >>the one you have write alternatives. > > No, I cannot. The problem is that tasks and protected objects are not > tagged. So? Have the RTL put a tagged face on it. Call it a binding. Essentially even traditional UNIX uses a thin libc binding for O/S services for C programs. > As you probably saw, I do not want to build a fat sandwich > OO-interface->procedural API->OO-kernel. It clumsy, ugly, buggy and > inefficient. I want to directly talk to OS. A couple of things. First of all, most microkernels that I am aware of (or at least the ones I plan to use), all use a procedural API (albeit with handles, if you want to call them that). Using a Mach type of approach, you write a bunch of executables that behave as "servers". Application programs become "clients" of these. This leaves the interface between the client user mode program and the server(s), as a RPC API interface set. Now MyOS (I'll just use that for example), would then of course sport a nice native Ada interface for application programs. However, underneath this "binding" (which is what it really is), it will be calling an RPC message API that is supported by the procedural API microkernel. User-mode-client-OO->Ada Binding->RPC->Server(s)->microkernel Can native objects be exported from operating systems? A quick survey produces this list: - integer file descriptor (POSIX) - handles (Windows) - ports (Mach) - identities (L4) - ipc ID (UNIX SysV) for message queues, shared mem etc. These are all fancy "handles" of one sort or another. You won't get much more than that from any O/S. Why? How do you share an object in protected-mode with a user-mode process? You can't. Even if you could, there would be parts of objects that the O/S wouldn't want you to mess with, or perhaps even look at. Maybe you can't because the object is just a Mach port. The best API answer seems to be to just provide a handle that can be used to refer to the object (like an Ada access type), or in the case of a Mach port, be the object metaphore. Then you call varied API set (effectively methods) on that object, using the given handle(s). Then if you want it to look different than that, you provide a binding. The general idea however, is that an Ada based O/S will have native bindings. The packages won't be adaptations of C header files etc. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg