TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Jerry van Dijk <[log in to unmask]>
Reply To:
Jerry van Dijk <[log in to unmask]>
Date:
Wed, 2 Dec 1998 00:02:10 +0100
Content-Type:
text/plain
Parts/Attachments:
text/plain (44 lines)
> The problem is with Java calls to native code.
> On most platforms these calls use the C convention.
> However on Windows, the Stdcall convention is used.

Yep, that is one of the reasons why I did a NT specific
GLUT binding.

> Thus users of my binding need a different pragma
> on windows to other platforms.
> How can this be done without changing the code,
> or having two versions of it?

You cannot. Courtesy of MS...

> Is there a good reason for windows libraries to not use
> C convention?

Basically there are two types of library calls on NT. The
standard C library (which uses the C convention) and the
Win32 API library (which uses the StdCall convention).
The StdCall convention really is the Pascal convention.
On Intel processors this is slightly more efficient,
especially for 'call-back' functions. In old Windows v2.x
times, this mattered.

It is safe to assume that (except for a couple of oddball
functions) all callback functions need StdCall.

> Although the Stdcall convention is not in the RM,
> is it available with the same name with most Ada
> compilers on windows?

I think it can be called a de-facto standard. Probably
has something to do with its usage by the Intermetrics
Win32Api binding... :-)

> First I have to solve this Stdcall issue and do some
> more testing.

I'm afraid that windows users will have to learn to live
with it...

Jerry.

ATOM RSS1 RSS2