object ada, visual c and tasking combined.

object ada, visual c and tasking combined.

[john donoghue]

Hi all,

I have a problem that perhaps someoneelse has encountered before and
found a way around.
Firstly, I have some legacy ada code that amongst other things displays
some stuff on a display via a custom graphics controller board.
Recently it has been decided to upgrade that by replacing the existing
graphics code with a visual c front end.

All well and good, I can build a gui in visual c in several cpp files
and link it in after defining a few pragmas to access the c
functionality  - first problem with objectAda ...
it complains about conflicts between libcd.lib having variables that are
alreadt defined.
And also it complains about linking in some of the visual c dll's etc
and unresolved symbols and more.

After getting sick of that, I decided to try compiling the gui part in
to a dll and link that to the ada code ... hey it works ... but to be
compatible with the old graphics stuff, the dll has to also call a few
ada functions that are within the main ada application ... no problem
... let's send a structure from the ada code to the visual c code on
initialization that contains pointers to the functions that the c code
will need to call later.
... It seems to work ... next problem .... The visual c windowing stuff
is in its own task, and there is also another C task that needs to wait
on an ada function to return with data - but everytime I call the
"pointered" functions from these tasks the app spits the dummy (
terminates with a exception that provides no name or message or
anything. )
I am guessing that you cant call the ada functions from the other C
tasks since they are in other tasks to the ada functions :) ... but is
there a way around it?

Cheers,
  John

Re: object ada, visual c and tasking combined.

[Stephen Leake]

john donoghue <donoghue@chariot.net.au> writes:

> <snip discussion of mixing C++ and Ada tasks>

I have not done this, but would bet you cannot communicate between C++
(actually native Win32) threads and Ada tasks by simply calling
functions. 

You'll probably have to use some sort of Win32 message passing.

-- 
-- Stephe

Re: object ada, visual c and tasking combined.

[tmoran]

>I have not done this, but would bet you cannot communicate between C++
>(actually native Win32) threads and Ada tasks by simply calling
>functions.
  Functions, as in sqrt, are not thread-specific.  Subprograms that
manipulate a thread's data clearly do require access to the correct
thread's data.

Re: object ada, visual c and tasking combined.

[john donoghue]

tmoran@acm.org wrote:

> >I have not done this, but would bet you cannot communicate between C++
> >(actually native Win32) threads and Ada tasks by simply calling
> >functions.
>   Functions, as in sqrt, are not thread-specific.  Subprograms that
> manipulate a thread's data clearly do require access to the correct
> thread's data.

At the moment all the function on the Ada side does is something like

type c_data_type is array(0..8) of Interfaces.C.Char;

function ADA_Func( data: c_data_type ) return Interfaces.C.Int is
begin
  text_io.put_line("Here we are :) ");
 return 0;
end ADA_Func;

The data being passed in is from a a function calll in the thread in the C
dll code, so really it shouldnt be much different from the thread calling
a normal operation ?

Re: object ada, visual c and tasking combined.

[Steve Doiel]

"john donoghue" <donoghue@chariot.net.au> wrote in message
news:3C6CC24D.D013A4AC@chariot.net.au...
> Hi all,
>
> I have a problem that perhaps someoneelse has encountered before and
> found a way around.
> Firstly, I have some legacy ada code that amongst other things displays
> some stuff on a display via a custom graphics controller board.
> Recently it has been decided to upgrade that by replacing the existing
> graphics code with a visual c front end.

Yuk.  I always hate to see C replacing Ada in any context, oh well.

> All well and good, I can build a gui in visual c in several cpp files
> and link it in after defining a few pragmas to access the c
> functionality  - first problem with objectAda ...
> it complains about conflicts between libcd.lib having variables that are
> alreadt defined.
> And also it complains about linking in some of the visual c dll's etc
> and unresolved symbols and more.

In the "pass to linker" options of ObjectAda try /nodefaultlib.  I've seen
something similar, but not quite the same that this corrected.

> After getting sick of that, I decided to try compiling the gui part in
> to a dll and link that to the ada code ... hey it works ... but to be
> compatible with the old graphics stuff, the dll has to also call a few
> ada functions that are within the main ada application ... no problem
> ... let's send a structure from the ada code to the visual c code on
> initialization that contains pointers to the functions that the c code
> will need to call later.
> ... It seems to work ... next problem .... The visual c windowing stuff
> is in its own task, and there is also another C task that needs to wait
> on an ada function to return with data - but everytime I call the
> "pointered" functions from these tasks the app spits the dummy (
> terminates with a exception that provides no name or message or
> anything. )

I had a similar problem.  In my case I registered a callback with the DLL
that needed to wait for something in on the Ada side.  When I tried having
the callback wait on a protected type, I don't remember the specific
behavior, but bad things happened.

The way I got around this is using the Win32 API objects, although I can't
remember specifically which object, and I don't have the code handy.  The
Ada code creates the win32 (I'll call it a semaphore) and sets its state to
empty.  The callback trys to take the semaphore and pends until the
semaphore is given.

I hope this helps,
SteveD

> I am guessing that you cant call the ada functions from the other C
> tasks since they are in other tasks to the ada functions :) ... but is
> there a way around it?
>
> Cheers,
>   John
>

Re: object ada, visual c and tasking combined.

[Nick Roberts]

On Fri, 15 Feb 2002 18:39:49 +1030, john donoghue <donoghue@chariot.net.au>
strongly typed:

>...
>... It seems to work ... next problem .... The visual c windowing stuff
>is in its own task, and there is also another C task that needs to wait
>on an ada function to return with data - but everytime I call the
>"pointered" functions from these tasks the app spits the dummy (
>terminates with a exception that provides no name or message or
>anything. )
>I am guessing that you cant call the ada functions from the other C
>tasks since they are in other tasks to the ada functions :) ... but is
>there a way around it?

What do you mean by "another C task"? Do you mean a Windows thread, or do
you mean a separate process (as in execXX etc.)? In either case (as best I
recall) Windows, since threads permit options regarding memory sharing (and
your Ada may take advantage of these options), I suspect the cross-'task'
calls fail because they cause code to try to access memory that it it is
not permitted to.

You may hate this suggestion, but my suggestion to you would be to
modularise your application at a different (higher) level, e.g. COM.

You could make your Ada 'engine' into a stand-alone program whch is a COM
server, and the VC front-end into a COM client. I am no expert on Windows
COM, but I think the stuff on AdaPower should give you most of what you
need to do it. I think in the end you'd find this to be a better solution.

Best of luck!
-- 
Nick Roberts

Re: object ada, visual c and tasking combined.

[john donoghue]

Nick Roberts wrote:

> On Fri, 15 Feb 2002 18:39:49 +1030, john donoghue <donoghue@chariot.net.au>
> strongly typed:
>
> >...
> >... It seems to work ... next problem .... The visual c windowing stuff
> >is in its own task, and there is also another C task that needs to wait
> >on an ada function to return with data - but everytime I call the
> >"pointered" functions from these tasks the app spits the dummy (
> >terminates with a exception that provides no name or message or
> >anything. )
> >I am guessing that you cant call the ada functions from the other C
> >tasks since they are in other tasks to the ada functions :) ... but is
> >there a way around it?
>
> What do you mean by "another C task"? Do you mean a Windows thread, or do
> you mean a separate process (as in execXX etc.)? In either case (as best I
> recall) Windows, since threads permit options regarding memory sharing (and
> your Ada may take advantage of these options), I suspect the cross-'task'
> calls fail because they cause code to try to access memory that it it is
> not permitted to.
>
> You may hate this suggestion, but my suggestion to you would be to
> modularise your application at a different (higher) level, e.g. COM.
>
> You could make your Ada 'engine' into a stand-alone program whch is a COM
> server, and the VC front-end into a COM client. I am no expert on Windows
> COM, but I think the stuff on AdaPower should give you most of what you
> need to do it. I think in the end you'd find this to be a better solution.
>
> Best of luck!
> --
> Nick Roberts

The C task was a windows thread.
The data beging passed around could have been anything - it didnt matter even
if I never used the value being passed in. Just calling the ada code from
another windows task caused problems.

I gave up on MFC and am using some c++ classes I have written previously that
use just the basic win32.
These dont have any tasks created for messages pumps or anything, and so
allows me to create a task in ADA that processes the message loop and allows
me to keep all tasks as ada ones.
... no more unknown application closing now :)

Thanks all.

Re: object ada, visual c and tasking combined.

[Frank J. Lhota]

"john donoghue" <donoghue@chariot.net.au> wrote in message
news:3C7A288B.9875C255@chariot.net.au...
> I gave up on MFC and am using some c++ classes I have written previously
that
> use just the basic win32.

A good choice. MFC used to be a rather thin binding, but it has thickened to
the point where it tweaks a lot Win32 stuff in order to work. This
complicates the interaction with any Win32 code not written in MFC -- it's
practically it's own API at this point. For this reason, my enthusiasm for
MFC has cooled considerably.

Getting back to Ada, I'm still a fan of CLAW.

Re: object ada, visual c and tasking combined.

[Randy Brukardt]

>The C task was a windows thread.
>The data beging passed around could have been anything - it didnt
matter even
>if I never used the value being passed in. Just calling the ada code
from
>another windows task caused problems.
>
>I gave up on MFC and am using some c++ classes I have written
previously that
>use just the basic win32.
>These dont have any tasks created for messages pumps or anything, and
so
>allows me to create a task in ADA that processes the message loop and
allows
>me to keep all tasks as ada ones.
>... no more unknown application closing now :)

If you really need a task safe GUI, you should look into Claw. Claw
provides a task-safe object-oriented Ada interface to Windows, if you
used it, you wouldn't need any C at all. And its a lot easier to use
than writing raw Win32 (in any language). You can look at the
Introductory version at www.rrsoftware.com/htmp/prodinf/claw.htm.

             Randy Brukardt.
             Disclaimer: I'm one of the authors of Claw.

Re: object ada, visual c and tasking combined.

[john donoghue]

Randy Brukardt wrote:

> >The C task was a windows thread.
> >The data beging passed around could have been anything - it didnt
> matter even
> >if I never used the value being passed in. Just calling the ada code
> from
> >another windows task caused problems.
> >
> >I gave up on MFC and am using some c++ classes I have written
> previously that
> >use just the basic win32.
> >These dont have any tasks created for messages pumps or anything, and
> so
> >allows me to create a task in ADA that processes the message loop and
> allows
> >me to keep all tasks as ada ones.
> >... no more unknown application closing now :)
>
> If you really need a task safe GUI, you should look into Claw. Claw
> provides a task-safe object-oriented Ada interface to Windows, if you
> used it, you wouldn't need any C at all. And its a lot easier to use
> than writing raw Win32 (in any language). You can look at the
> Introductory version at www.rrsoftware.com/htmp/prodinf/claw.htm.
>
>              Randy Brukardt.
>              Disclaimer: I'm one of the authors of Claw.

Well C++ is my language of choice ... when I have a choice :)
I have programmed win32 for quite a few years before having to stry
across onto the dark side for MFC.
I have written several C++ classes for win32 programming which, when I
get to put them on the web, will be at ezwin.sourceforge.net ( project
info: http://sourceforge.net/project/ezwin/?group_id=47473 )