Re: RE: rename missing in Text_IO

Re: RE: rename missing in Text_IO

[Ted Dennison]

In article <mailman.989009524.30396.comp.lang.ada@ada.eu.org>, Beard, Frank
says...
>But why not be part of the standard, maybe in an Annex.  I
>almost sympathize with what Ted's saying.  But by his reasoning,
>Ada.Command_Line shouldn't be provided either, because the OS
>has an interface to do it.  For that matter, none of the IO should
>be there because we could pragma interface to all those routines.
..
>From: Ted Dennison [mailto:dennison@telepath.com]
>That's all stuff that's considered part of the OS, and thus you are expected
>to make the appropriate OS calls for your platform. Most of the time, your Ada
>vendor will have supplied a package that has bindings to those OS calls, but
>what it is depends on your vendor and platform.

Hey, I never said it was a Good Thing. I just said that this is the way it is.
For a beginner, that's the main issue.

I actually think it may well be a good thing to have some kind of Ada.C_Library
package hierarchy in an annex in some future version of the language for stuff
like that, since the C library realisticly is going to be available on most Ada
platforms. Perhaps an Ada.Directory_Operations would be a good idea too. Heck,
I'd even like to see a GUI in the standard, if its possible to agree on a good
one.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

RE: RE: rename missing in Text_IO

[Beard, Frank]

I'm apologize if I misunderstood you, but I've heard similar things from
others, including some vendors, and assumed that's what you meant.  One of
the vendors told me (highly paraphrased) they basically wait to see where
the market goes and then make bindings to the interfaces.  So, they're
always in a state of catch-up.

As far as Ada.C_Library, I wasn't thinking along those lines.  As a
matter of fact, I wouldn't really even want to make the connection
between the things I want provided in the language and their C counter
parts.  I was thinking more along the lines of your other suggestion,
such as Ada.Directory_Operations, Ada.File_Operations, etc.

Even if the C version is there first, hide that from me.  Take a good
idea and make it better with Ada.  

Frank

-----Original Message-----
From: Ted Dennison [mailto:dennison@telepath.com]
Sent: Friday, May 04, 2001 5:22 PM
To: comp.lang.ada@ada.eu.org
Subject: Re: RE: rename missing in Text_IO


In article <mailman.989009524.30396.comp.lang.ada@ada.eu.org>, Beard, Frank
says...
>But why not be part of the standard, maybe in an Annex.  I
>almost sympathize with what Ted's saying.  But by his reasoning,
>Ada.Command_Line shouldn't be provided either, because the OS
>has an interface to do it.  For that matter, none of the IO should
>be there because we could pragma interface to all those routines.
..
>From: Ted Dennison [mailto:dennison@telepath.com]
>That's all stuff that's considered part of the OS, and thus you are
expected
>to make the appropriate OS calls for your platform. Most of the time, your
Ada
>vendor will have supplied a package that has bindings to those OS calls,
but
>what it is depends on your vendor and platform.

Hey, I never said it was a Good Thing. I just said that this is the way it
is.
For a beginner, that's the main issue.

I actually think it may well be a good thing to have some kind of
Ada.C_Library
package hierarchy in an annex in some future version of the language for
stuff
like that, since the C library realisticly is going to be available on most
Ada
platforms. Perhaps an Ada.Directory_Operations would be a good idea too.
Heck,
I'd even like to see a GUI in the standard, if its possible to agree on a
good
one.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com
_______________________________________________
comp.lang.ada mailing list
comp.lang.ada@ada.eu.org
http://ada.eu.org/mailman/listinfo/comp.lang.ada

Re: RE: rename missing in Text_IO

[Keith Thompson]

Ted Dennison<dennison@telepath.com> writes:
[...]
> I actually think it may well be a good thing to have some kind of
> Ada.C_Library package hierarchy in an annex in some future version
> of the language for stuff like that, since the C library realisticly
> is going to be available on most Ada platforms. Perhaps an
> Ada.Directory_Operations would be a good idea too.

I think the Ada/POSIX binding covers most of that.

>                                                    Heck, I'd even
> like to see a GUI in the standard, if its possible to agree on a
> good one.

I don't think it is.  8-)}

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Cxiuj via bazo apartenas ni.

Re: RE: rename missing in Text_IO

[Marin David Condic]

Yes sir! Very much so sir!

Every time I have to dip into the Win32ada interfaces to get at Windoze, I
wish I had an ever-so-slightly thicker binding that simply had its own
parameter passing and data typing and all that so I don't have to deal with
all the long chains of types & subtypes and ridiculous parameters that the C
calls impose. Just clean it up and make it Ada-ish.

Above that, one can always build a thicker binding such as what one might
find in Claw. But at least let me connect to the bare OS using The Ada Way
rather than C. Typically, I roll my own, but I only do so for the packages I
need at the moment. It would be nice to have one for the whole interface -
especially when it gets hard to understand what the C functions are doing
with the parameters. (Ada is ***SOOOOO*** much nicer in the way it passes
parameters!)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Beard, Frank" <beardf@spawar.navy.mil> wrote in message
news:mailman.989012885.31301.comp.lang.ada@ada.eu.org...
> Even if the C version is there first, hide that from me.  Take a good
> idea and make it better with Ada.
>

Re: RE: rename missing in Text_IO

[Ted Dennison]

In article <9d6ahn$157$1@nh.pace.co.uk>, Marin David Condic says...
>Every time I have to dip into the Win32ada interfaces to get at Windoze, I
>wish I had an ever-so-slightly thicker binding that simply had its own
>parameter passing and data typing and all that so I don't have to deal with
>all the long chains of types & subtypes and ridiculous parameters that the C

I just flat out don't do it. The only thing (IMHO) the Win32Ada bindings (or any
other "thin bindings") are good for is a reference to the correct type sizes and
calling convention for a pragma Interface, which I will hide down in the body of
my own package. Even there, you're often better going to the C API's docs, as
they give much more detail about how an object is used and what is expected of
it. If you try to use the C types and error return values that a thin binding
provides you directly, they often end up spreading themselves (and the C style
their use requires) throughout your code like a cancer.

I'd like to take this opportunity to volunteer my services as a Win32 "thick
binding coordinator", since I can't seem to con anyone else into taking the job.
:-)  Anyone who has developed their own thick Win32 binding for some particular
Win32 facility, and has the legal right to allow their redistribution under the
GMGPL, feel free to email what you have to me. As mentioned before, I already
have bindings developed for WinNT/2K "services", process creation/control,
registry operations, and I am working on NT/2K's registry based "performance
data". They are currently only available under the GPL as part of the SETI@Home
Service (see the link on my website), but that will change soon.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: RE: rename missing in Text_IO

[Marin David Condic]

"Ted Dennison" <dennison@telepath.com> wrote in message
news:WazJ6.4532$vg1.353081@www.newsranger.com...
> I just flat out don't do it. The only thing (IMHO) the Win32Ada bindings
(or any
> other "thin bindings") are good for is a reference to the correct type
sizes and
> calling convention for a pragma Interface, which I will hide down in the
body of
> my own package. Even there, you're often better going to the C API's docs,
as
> they give much more detail about how an object is used and what is
expected of
> it. If you try to use the C types and error return values that a thin
binding
> provides you directly, they often end up spreading themselves (and the C
style
> their use requires) throughout your code like a cancer.
>
Its that cancer - as well as the simple, flat-out pain - that makes me hate
to use the Win32Ada bindings. There's just this huge and nasty collection of
subtypes, etc, that are needed to line up with the Win32api and they are a
ROYAL pain! I typically hide them in the bowels of a coresponding package
that has Ada strings, characters, integers, enumerations, etc., as
parameters. And yes, I too hate the error-code returns and usually resort to
either a set of enumerals for the statuses or exceptions or some combination
thereof.


> I'd like to take this opportunity to volunteer my services as a Win32
"thick
> binding coordinator", since I can't seem to con anyone else into taking
the job.
> :-)  Anyone who has developed their own thick Win32 binding for some
particular
> Win32 facility, and has the legal right to allow their redistribution
under the
> GMGPL, feel free to email what you have to me. As mentioned before, I
already
> have bindings developed for WinNT/2K "services", process creation/control,
> registry operations, and I am working on NT/2K's registry based
"performance
> data". They are currently only available under the GPL as part of the
SETI@Home
> Service (see the link on my website), but that will change soon.
>

I might be willing to help out here, but I'm wondering about proper
guidelines. It wouldn't help much to have a dozen guys each developing
package specs that look substantially different to cover the various parts
of the Win32api. The intelligent thing to do would probably be to parallel
the Win32ada packages. Maybe there's a "Ada_Win32ada" for every "Win32ada"
where the sole job is to Ada-ize the types, parameters, return statuses,
etc. There would need to be some guidelines & examples of how to translate
to something that at least looks fairly regular across all the packages.
Otherwise, we'd just end up with our own proliferation of Ada types,
subtypes, etc.

Ideas?

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/

Re: RE: rename missing in Text_IO

[Ted Dennison]

In article <9d6h07$3b3$1@nh.pace.co.uk>, Marin David Condic says...
>parameters. And yes, I too hate the error-code returns and usually resort to
>either a set of enumerals for the statuses or exceptions or some combination
>thereof.

My current favorite trick is to just raise a single "Foo.Error" exception for
any C error condition in each package. There are obviously some situations where
this would be undesirable, but you'd be suprised how often its sufficient.
Sometimes when extra info might be in order for diagnosis, it can just be put
into the execption message.

>I might be willing to help out here, but I'm wondering about proper
>guidelines. It wouldn't help much to have a dozen guys each developing
>package specs that look substantially different to cover the various parts

Yeah, it would all need to interoperate. That's part of why I wanted to fob the
job off on someone else. My bindings aren't really that good for a base right
now, since a lot of basic Win32 stuff that everyone is liable to use isn't there
(with the notable exception of process id's).

>of the Win32api. The intelligent thing to do would probably be to parallel
>the Win32ada packages. Maybe there's a "Ada_Win32ada" for every "Win32ada"
>where the sole job is to Ada-ize the types, parameters, return statuses,

Nearly all of that crap in Gnat's Win32 package is special String and Void
pointer types that I never pass back to the user anyway. :-)

The problem with doing things this way is that when you abstract away some of
the C cruft, a lot of that organization doesn't make any sense. For instance,
the Windows NT/2K "performance data" that you need to parse to get stuff like a
what executable a process is using, is entirely accomplished using registry
calls. But if abstracted down to something like 
Get_Executable_Name (Process.ID)

Then it doesn't make much sense to put this call in a "Registry" package.

Another issue is that a lot of times the original C libraries aren't very well
organized in the first place. For instance, the Win32 process and thread stuff
is stuck into a huge 8 thousand line header file along with basic File I/O,
serial I/O, process syncronization stuff like pipes and mailslots and
semaphores, object priveleges and ACLs, computer and user names, etc. My current
bindings just have a single "Process" package for Win32 processes. I don't think
I'd want to make a Win32.Base_Services package and put all that crap into it.

>etc. There would need to be some guidelines & examples of how to translate
>to something that at least looks fairly regular across all the packages.
>Otherwise, we'd just end up with our own proliferation of Ada types,
>subtypes, etc.

Generally I try to stick to Strings, Integers, private types, and the odd
enumeration here or there. But some specific guidlines would indeed be required,
or I'm afraid I'd spend all my time redesigning submissions. Ick.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: RE: rename missing in Text_IO

[Marin David Condic]

"Ted Dennison" <dennison@telepath.com> wrote in message
news:BrBJ6.4787$vg1.374667@www.newsranger.com...
> My current favorite trick is to just raise a single "Foo.Error" exception
for
> any C error condition in each package. There are obviously some situations
where
> this would be undesirable, but you'd be suprised how often its sufficient.
> Sometimes when extra info might be in order for diagnosis, it can just be
put
> into the execption message.
>
It might work nicely enough to get the job done. If a function was provided
to return a more detailed error code (the actual return status of the C
function?) that might be enough to get the job done cleanly.


> Yeah, it would all need to interoperate. That's part of why I wanted to
fob the
> job off on someone else. My bindings aren't really that good for a base
right
> now, since a lot of basic Win32 stuff that everyone is liable to use isn't
there
> (with the notable exception of process id's).
>
Its always nicer if you can get someone else to do all the work! :-) I don't
have an easy answer for this other than possibly someone has/had a corporate
need to build the bindings anyway & are willing to give it away.


> Nearly all of that crap in Gnat's Win32 package is special String and Void
> pointer types that I never pass back to the user anyway. :-)
>
> The problem with doing things this way is that when you abstract away some
of
> the C cruft, a lot of that organization doesn't make any sense. For
instance,
> the Windows NT/2K "performance data" that you need to parse to get stuff
like a
> what executable a process is using, is entirely accomplished using
registry
> calls. But if abstracted down to something like
> Get_Executable_Name (Process.ID)
>
Two issues: One is that the Win32ada bindings are not specific to Gnat. They
exist in Aonix as well (& Maybe RR?) & I think they were originally a
product of Averstar - so they're pretty much a common thing. I'm sure you
know this, but given the way you phrased the statement above, it might not
have been clear to someone just now approaching it. (It wouldn't be fair to
blame Gnat for the fact that the Win32api is a turd that no matter how long
you polish it will always remain a turd!)

The other thing is to remember that the whole Win32api was organically grown
at Micro$oft (probably in a damp basement with no light) so it is enormously
internally inconsistent. No getting around that - its someone else's dirty
work. I like abstracting things and have done so with the Winsock calls in
particular. The only problem is that then you're heading off into a much
thicker binding and where do you stop? I'd rather just go with something
like Claw if I wanted to get further away from the absurdities of Win32api.
For some uses, it may be fine just to get a step away from the C-isms of the
Win32api.


> Then it doesn't make much sense to put this call in a "Registry" package.
>
> Another issue is that a lot of times the original C libraries aren't very
well
> organized in the first place. For instance, the Win32 process and thread
stuff
> is stuck into a huge 8 thousand line header file along with basic File
I/O,
> serial I/O, process syncronization stuff like pipes and mailslots and
> semaphores, object priveleges and ACLs, computer and user names, etc. My
current
> bindings just have a single "Process" package for Win32 processes. I don't
think
> I'd want to make a Win32.Base_Services package and put all that crap into
it.
>
As I said - Win32api is a turd. However, your your proposal of consolidating
some of this stuff (wise as it may be) leaves open the question of how thick
a binding do you want to construct? I'd reiterate that it might make sense
to simply have something that was one-step away from the really crappy
C-isms in the Win32ada collection. (At least it would be familiar & would
parallel existing Win32api documentation.) Beyond that another layer of
abstraction may be in order to simplify things in some manner. But that's
just rebuilding Claw. Where do you want to draw the line and say "This far
and no farther?"

> Generally I try to stick to Strings, Integers, private types, and the odd
> enumeration here or there. But some specific guidlines would indeed be
required,
> or I'm afraid I'd spend all my time redesigning submissions. Ick.
>
I agree. Where possible, use the standard types insofar as they align with
the sizes required by the actual calls. Usage of Integer, Float,
(Long_Integer, Long_Float, etc.) Character & String should handle 99% of
everything - probably with some enumerations & exceptions to cover return
statuses. Maybe some hiding of structs within private types makes sense. One
might want to construct some primitive types (Integer_32, Float_64?) just to
guarantee sizes and the overridability of operations.

Maybe an example or two would suffice as a guideline? "Make it look like
this!"

MDC


--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/

Re: RE: rename missing in Text_IO

[tmoran]

> I like abstracting things and have done so with the Winsock calls in
> particular.
  This may be key.  Too thick a binding, no matter how good it might
be, may just not be attractive.  Most people have their own styles
and preferences, and just aren't as comfortable using something
right out of the box.  It's standard marketing that nobody wants
to feel their input consists of putting tab A in slot B.  People
want instead pieces that can be helpful in creating the final product.
Your comment
> managing programmers is like hearding cats... :-)
is relevant here.

Re: RE: rename missing in Text_IO

[tmoran]

>I'd like to take this opportunity to volunteer my services as a Win32
>"thick binding coordinator", ...
>... As mentioned before, I already have bindings developed for ...
  www.adapower.com also lists:
Claw       2.7 MB (free for non-commerical use)
           5.8 MB + examples, docs, and GUI Builder, $>0
Windex     2.4 MB
GWindows   1.3 MB
Jewl        .9 MB
  Perhaps "thick binding coordination" would fit nicely in the
Ada Bindings Working Group?

I suspect it is currently difficult to mix different parts of these
bindings.  Maybe part of "coordination" should be development of
ways to switch between, or mix and match, instead of being locked in
to one particular binding.

BTW, one of the major, but rarely mentioned, advantages of a thick
binding is that someone else has tracked down the obscurities,
ambiguities, MS doc errors, etc to find out what the various API
calls actually do, and how they need to hang together.  The thinner
the binding, the more of that you get to do yourself.  ;)

Re: RE: rename missing in Text_IO

[tmoran]

>"Ted Dennison" <dennison@telepath.com> wrote in message
>news:BrBJ6.4787$vg1.374667@www.newsranger.com...
>> My current favorite trick is to just raise a single "Foo.Error" exception
>for
>> any C error condition in each package. There are obviously some situations
>where
>> this would be undesirable, but you'd be suprised how often its sufficient.
>> Sometimes when extra info might be in order for diagnosis, it can just be
>put
>> into the execption message.
>>
>It might work nicely enough to get the job done. If a function was provided
>to return a more detailed error code (the actual return status of the C
>function?) that might be enough to get the job done cleanly.
  In Claw we have a very few exceptions, Already_Valid_Error for
instance, plus
    Windows_Error : Exception;  -- An (unusual) error occurred in Windows.
                                -- The exception message for this exception
                                -- always includes the Windows error code.
But in Claw.Sockets, for instance, the windows error code is often
uninteresting, so there is a specific
  procedure Get_Error_Code(Socket     : in out Root_Socket_Type;
                           Error_Code :    out Error_Codes);
  -- Call this after a Windows_Error exception on an operation on Socket.
to get the winsock error code.


>Maybe an example or two would suffice as a guideline? "Make it look like
>this!"
  I'll modestly suggest perusing the Claw docs, an early, incomplete,
but still showing a flavor, work version of which is still posted at
http://members.home.net/twmoran/H1.htm

>Where do you want to draw the line and say "This far and no farther?"
  Perhaps Claw defines what's beyond the line?

Re: RE: rename missing in Text_IO

[Marin David Condic]

Since the discussion started concerning Win32ada simply having way too many
types and way too much C-ish feeling to the parameter lists, etc., my
original idea was to put a relatively simple layer on top of Win32ada. Just
enough so that when a string was called for, you used an Ada string - not
some 2nd or 3rd layer subtype of a pointer to a char - or other equally
unfriendly examples. I wouldn't want to consolidate multiple calls into
single calls or significantly change anything about the interface - so far
as it could be avoided. Just Ada-ize what one sees when one uses the
Win32api. (Some compromises are in order - you'd want to change all the
numeric return statuses into something more Ada-ish like enumerations.
Again, its a question of where does one stop?)

To that end, I'd think that Claw exceeds the spec. Claw is a perfectly fine
tool and one might be quite happy to develop on top of it. I'd think that
there would remain times when one would simply want to get at a single
Win32api call without any other layers of abstraction beyond making the
thing not quite so agonizing to use from an Ada perspective.

Claw may be a better answer for overall development, but I was kind of
thinking along the lines of something that would be freely available as a
blanket over the Win32ada binding. Sort of a "binding to a binding". (Now we
could start the GPL vs LGPL vs GMGPL debate along a whole new thread! :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


<tmoran@acm.org> wrote in message
news:mLKJ6.43239$Jh5.41288199@news1.rdc1.sfba.home.com...
> >Where do you want to draw the line and say "This far and no farther?"
>   Perhaps Claw defines what's beyond the line?

Re: RE: rename missing in Text_IO

[Ted Dennison]

In article <mLKJ6.43240$Jh5.41288728@news1.rdc1.sfba.home.com>, tmoran@acm.org
says...
>  Perhaps "thick binding coordination" would fit nicely in the
>Ada Bindings Working Group?

I'd go for that. As I said, my main interest is in fobbing this job off on
someone else. :-)

>BTW, one of the major, but rarely mentioned, advantages of a thick
>binding is that someone else has tracked down the obscurities,
>ambiguities, MS doc errors, etc to find out what the various API
>calls actually do, and how they need to hang together.  The thinner

Likewise, one of the major, but rarely mentioned, advantages to *writing* a
thick binding is that you become quite well acquainted with the API in question.
:-)

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: rename missing in Text_IO

[Stephen Leake]

"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes:

> Since the discussion started concerning Win32ada simply having way too many
> types and way too much C-ish feeling to the parameter lists, etc., my
> original idea was to put a relatively simple layer on top of Win32ada. Just
> enough so that when a string was called for, you used an Ada string - not
> some 2nd or 3rd layer subtype of a pointer to a char - or other equally
> unfriendly examples. I wouldn't want to consolidate multiple calls into
> single calls or significantly change anything about the interface - so far
> as it could be avoided. Just Ada-ize what one sees when one uses the
> Win32api. (Some compromises are in order - you'd want to change all the
> numeric return statuses into something more Ada-ish like enumerations.
> Again, its a question of where does one stop?)

That was the original philosophy of Windex. I may have gone beyond
that some in developing whole new controls.

> To that end, I'd think that Claw exceeds the spec. Claw is a
> perfectly fine tool and one might be quite happy to develop on top
> of it. I'd think that there would remain times when one would simply
> want to get at a single Win32api call without any other layers of
> abstraction beyond making the thing not quite so agonizing to use
> from an Ada perspective.

It would be interesting to hear which parts of Claw you think are "too
thick". My nomination for that category is its use of a hidden task to
serialize access to the GUI. On the other hand, I have not yet
succeeded in building a multi-tasking Windex app, so I can't really
complain! 

> Claw may be a better answer for overall development, but I was kind
> of thinking along the lines of something that would be freely
> available as a blanket over the Win32ada binding. Sort of a "binding
> to a binding". (Now we could start the GPL vs LGPL vs GMGPL debate
> along a whole new thread! :-)

Windex is _not_ built on top of the Win32Ada binding, and neither is
Claw. Part of the reason is licensing; the Win32Ada binding is
actually copyright by Microsoft, since it was built by automatic
translation from their C source. It is _not_ "freely distributable";
the license terms state that you must own a Microsoft development
environment to use Win32Ada. Windex is GMGPL.

The other part of the reason is that there is lots of stuff in Win32
that should not be used; either because it is superceded by other
parts of Win32, or there is a better Ada way.

I haven't worked on Windex in quite a while. I'll probably make
another release when GNAT 3.14p comes out, but I don't anticipate much
beyond that. I just don't seem to have the urge to write Win32 apps
any more; I may do something for my latest toy, a Palm handheld.

-- 
-- Stephe

Re: rename missing in Text_IO

[Marin David Condic]

"Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
news:uheyuzn0y.fsf@gsfc.nasa.gov...
> It would be interesting to hear which parts of Claw you think are "too
> thick". My nomination for that category is its use of a hidden task to
> serialize access to the GUI. On the other hand, I have not yet
> succeeded in building a multi-tasking Windex app, so I can't really
> complain!
>
Never said Claw was "too thick". What I said was that it didn't meet the
specification of being simply an Ada equivalent to the Win32api. I think
we'd both agree that Claw provides a bit more than what you would see from
Win32ada. It does a bit more than just wrap Ada-isms around the Win32api. I
don't object to that at all - far from it. I just don't think it is the
answer to having a slightly more than "thin" binding to the Win32api. (Also,
it isn't likely to end up distributed with all of the Ada/PC targeted
compilers.)

I wish I had a correct term for this kind of binding. "Thick" kind of
implies you've packaged something up to provide similar {rather than
identical} services, but in a more friendly way. "Thin" kind of implies that
it is just a set of hooks to the routines to provide absolutely identical
services from another language - right down to matching data types, etc.
There ought to be a word for a binding that provides identical services, but
smooths over the things that don't translate well from C to Ada. (A thin
binding with "software spackle"? :-) Arguably, that ought to be a "thick"
binding with something like Claw becoming a "subsystem" - it provides
similar and *extended* services.

> Windex is _not_ built on top of the Win32Ada binding, and neither is
> Claw. Part of the reason is licensing; the Win32Ada binding is
> actually copyright by Microsoft, since it was built by automatic
> translation from their C source. It is _not_ "freely distributable";
> the license terms state that you must own a Microsoft development
> environment to use Win32Ada. Windex is GMGPL.
>
Fair enough. My casual attitude towards precise writing may once again have
me in trouble! :-) Let me say this: The Ada compilers that I've seen
targeted to Windows/PCs have all come with the Win32ada bindings. I don't
know of any that don't - maybe you know of one? Hence (even if it isn't a
"standard") I could go off and develop a Spackle Binding (tm) that "withed"
the Win32ada stuff and pretty much be asured it would work any place I
needed it to.

One could develop a Spackle Binding (tm) that had in the package body all of
the same sorts of pragmas, etc. one finds in the Win32ada binding and sort
of reverse engineer the Win32api. That would probably not infringe on
anyone's copyright or license. But if Win32ada exists everywhere I'd want to
compile my stuff, is that really necessary?

> The other part of the reason is that there is lots of stuff in Win32
> that should not be used; either because it is superceded by other
> parts of Win32, or there is a better Ada way.
>
Yes - many aspects of Win32api are Morally Evil and should be avoided like
cigarettes, whisky & wild women. Still, if one wants to make a binding to
it, one ought to be thorough so that Joe Programmer who is familiar with
Win32api can find whatever he might be used to using. Tough call. At some
point you're no longer making a binding - but a subsystem. Its not a *bad*
thing to make a subsystem, but I'd probably do it in layers -the binding is
the binding and the simplification of services rides on top of that.

> I haven't worked on Windex in quite a while. I'll probably make
> another release when GNAT 3.14p comes out, but I don't anticipate much
> beyond that. I just don't seem to have the urge to write Win32 apps
> any more; I may do something for my latest toy, a Palm handheld.
>
Perhaps Windex fits the bill. I've not looked it over. The rest of it comes
down to how freely available it is for use. That starts moving from
technical questions to business & legal questions.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/

Re: rename missing in Text_IO

[tmoran]

>... that ought to be a "thick" binding with something like Claw
>becoming a "subsystem" - it provides similar and *extended* services.
  I'm not used to using the word "subsystem" that way.  e.g, in
Orbitals (www.adapower.com) there is a child of a window type where
the additional data is 3D graphic stuff which is displayed in user
selectable mono or stereo and can be rotated by mouse movements,
quite independently of the data generating program.  I would call
that a "subsystem" since it is a system in itself, and clearly a
distinct separate part of the entire app-system.  It is an extension
of a simple "window", but not an extension of Windows.  But that
does leave me with no simple word connoting a certain thickness
layer of a binding.

Re: RE: rename missing in Text_IO

[Randy Brukardt]

In article <9d6ahn$157$1@nh.pace.co.uk>, Marin David Condic says...
>Every time I have to dip into the Win32ada interfaces to get at
Windoze, I
>wish I had an ever-so-slightly thicker binding that simply had its own
>parameter passing and data typing and all that so I don't have to deal
with
>all the long chains of types & subtypes and ridiculous parameters that
the C

R.R.'s Win32 bindings (which predate Win32Ada) were designed exactly
that way, and for exactly that reason. There even was a project to
create a public version of them ("just thick enough" - named "MAWB" for
Medium Ada Windows Binding), but that ended up going nowhere when people
adopted Win32Ada instead.

We ended up stopping development on it in favor of a thicker binding
(which now is Claw). (Claw includes lots of stuff outside of pure GUI
functions, including sockets, registry operations [including
common-high-level operations such as registering a file extension], and
directory operations.

            Randy.

(P.S. I posted this message last week, but I don't think it ever got
posted. Apologies to anyone that sees it twice.)