Re: RE: rename missing in Text_IO

["Marin David Condic" <marin.condic.auntie.spam@pacemicro.com>]

"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/