Dll files

Dll files

[Andy Perkins]

I have been programming for several years, but have never ran across a
situation where I absolutely needed to make a DLL file.  Now I have...
I have Borland C++ 5.02 and need to write a SVGA graphics package to
link into an Ada program.

I don't have a clue about where to start...  I will probably end up
writing most of it in inline assembly.  I don't know if I am supposed to
have anything special in my source code to make a DLL file.  So, if
anyone can get me started on this, it would be much appreciated as I
need to have this DLL finished by the end of the week.

It would be much easier for my to just link in an object file from Turbo
Assembler, like you can do in Pascal.  So, if any Ada programmers know
of a way to do that, or even a way to output data to a port (such as
assembly "out") please let me know.  I am using GNAT Ada 3.10p.

Thanks
storm@vci.net

Re: Dll files

[Andy Perkins]

Nick Roberts wrote:

> Use of DLLs implies Windows, which implies availability of the Windows GDI
> (Graphical Device Interface), which is a part of the Windows API, and will
> drive SVGA as well as umpteen other graphics protocols.  So it sounds to me
> like you just want to use the Windows API direct.

    That would be the best course, if I were planning to use the finished
product in a C program.  The DLL will eventually be converted to an Ada library
file and imported into an Ada program.  Since the DLL can be converted to an
Ada library file, Ada can use (in a manner of speaking) DLL files, but as far
as I know, there is no way to use the Windows API from within Ada.

Andy

Re: Dll files

[Nick Roberts]

Use of DLLs implies Windows, which implies availability of the Windows GDI
(Graphical Device Interface), which is a part of the Windows API, and will
drive SVGA as well as umpteen other graphics protocols.  So it sounds to me
like you just want to use the Windows API direct.

== Nick Roberts ================================================
== Croydon, UK                       ===========================
==                                              ================
== Proprietor, ThoughtWing Software                   ==========
== Independent Software Development Consultant            ======
== Nick.Roberts@dial.pipex.com                              ====
== Voicemail & Fax +44 181-405 1124                          ===
==                                                            ==
==           I live not in myself, but I become               ==
===          Portion of that around me; and to me             ==
====         High mountains are a feeling, but the hum        ==
=======      Of human cities torture.
===========                             -- Byron [Childe Harold]


Andy Perkins <storm@vci.net> wrote in article
<34E9EEB7.4723FD1E@vci.net>...
> I have been programming for several years, but have never ran across a
> situation where I absolutely needed to make a DLL file.  Now I have...
> I have Borland C++ 5.02 and need to write a SVGA graphics package to
> link into an Ada program.
> 
> I don't have a clue about where to start...  I will probably end up
> writing most of it in inline assembly.  I don't know if I am supposed to
> have anything special in my source code to make a DLL file.  So, if
> anyone can get me started on this, it would be much appreciated as I
> need to have this DLL finished by the end of the week.
> 
> It would be much easier for my to just link in an object file from Turbo
> Assembler, like you can do in Pascal.  So, if any Ada programmers know
> of a way to do that, or even a way to output data to a port (such as
> assembly "out") please let me know.  I am using GNAT Ada 3.10p.

Re: DLL files

[Nick Roberts]

OK, but if you write a DLL which goes direct to the SVGA hardware
(bypassing Windows), Windows is probably not going to like it!

Assuming (as I am) that your Ada compiler targets DOS (or bare PC), perhaps
what you need to do is to write an Ada library unit (presumably a package)
-- forget the DLL -- which controls the SVGA board directly.  If the
compiler hosts under Windows, so much the better (richer environment), but
then to run (you _might_ be able to run in DOS box, otherwise) you will
have to 'shut down to DOS', and run there.

I'm afraid I don't have SVGA data to hand -- I'll a little rummage -- but
if you can get your hands on that, I reckon the package should be pretty
easy to knock up.

I hope this is some help to you.  If I'm getting the wrong end of the stick
(as I often do ;-), enlighten me!


== Nick Roberts ================================================
== Croydon, UK                       ===========================
==                                              ================
== Proprietor, ThoughtWing Software                   ==========
== Independent Software Development Consultant            ======
== Nick.Roberts@dial.pipex.com                              ====
== Voicemail & Fax +44 181-405 1124                          ===
==                                                            ==
==           I live not in myself, but I become               ==
===          Portion of that around me; and to me             ==
====         High mountains are a feeling, but the hum        ==
=======      Of human cities torture.
===========                             -- Byron [Childe Harold]


Andy Perkins <storm@vci.net> wrote in article
<34EC8B90.EEDC9238@vci.net>...
> Nick Roberts wrote:
> 
> > Use of DLLs implies Windows, which implies availability of the Windows
GDI
> > (Graphical Device Interface), which is a part of the Windows API, and
will
> > drive SVGA as well as umpteen other graphics protocols.  So it sounds
to me
> > like you just want to use the Windows API direct.
> 
>     That would be the best course, if I were planning to use the finished
> product in a C program.  The DLL will eventually be converted to an Ada
library
> file and imported into an Ada program.  Since the DLL can be converted to
an
> Ada library file, Ada can use (in a manner of speaking) DLL files, but as
far
> as I know, there is no way to use the Windows API from within Ada.

Re: Dll files

[Jerry van Dijk]

Andy,

> > Use of DLLs implies Windows, which implies availability of the Windows
GDI
> > (Graphical Device Interface), which is a part of the Windows API, and
will
> > drive SVGA as well as umpteen other graphics protocols.  So it sounds
to me
> > like you just want to use the Windows API direct.

Sorry, but your original message was rather confusing, and this is even
more
so:

>     That would be the best course, if I were planning to use the finished
> product in a C program.

C has nothing to do with this.

> The DLL will eventually be converted to an Ada library
> file and imported into an Ada program.

I'm not sure what you think a 'Ada library file' is, but I can assure you
that you cannot convert a DLL into it.

>  Since the DLL can be converted to an
> Ada library file, Ada can use (in a manner of speaking) DLL files, but as
far
> as I know, there is no way to use the Windows API from within Ada.

If you use an Ada compiler for Windows, it can use DLL files. It can also
call the Win32 API.

It seems you are confusing C and Pascal with Ada and Windows with Dos.

For more info on the use of Ada under Windows, take a peek at my homepage
at http://stad.dsl.nl/~jvandyk.

Jerry.

Re: DLL files

[Jerry van Dijk]

Nick,

> I hope this is some help to you.  If I'm getting the wrong end of the
stick
> (as I often do ;-), enlighten me!

Ok, you asked for it! :-))

> OK, but if you write a DLL which goes direct to the SVGA hardware
> (bypassing Windows), Windows is probably not going to like it!

There is a non-documented way to disable the GDI, but a much 
easier way is to use the DirectX API.

> Assuming (as I am) that your Ada compiler targets DOS (or bare PC),
perhaps
> what you need to do is to write an Ada library unit (presumably a
package)
> -- forget the DLL -- which controls the SVGA board directly.

This has already been done with SVGA01.ZIP. This version has some bugs,
the only current package that fixes this was pointed to by Gautier several
times on this group.

>  If the
> compiler hosts under Windows, so much the better (richer environment),
but
> then to run (you _might_ be able to run in DOS box, otherwise) you will
> have to 'shut down to DOS', and run there.

No, if you were using OA with DOS extender, you can 'rebind' for DOS.

Jerry.

Re: Dll files

[Dennis Weldy]

If you can call DLL functions written in C from your Ada program (through a
library file) then you can call the Win32 API. Linking with the API just
involves using the correct import library
(GDI, KERNEL, etc).

Dennis
Andy Perkins wrote in message <34EC8B90.EEDC9238@vci.net>...
>Nick Roberts wrote:
>
>> Use of DLLs implies Windows, which implies availability of the Windows
GDI
>> (Graphical Device Interface), which is a part of the Windows API, and
will
>> drive SVGA as well as umpteen other graphics protocols.  So it sounds to
me
>> like you just want to use the Windows API direct.
>
>    That would be the best course, if I were planning to use the finished
>product in a C program.  The DLL will eventually be converted to an Ada
library
>file and imported into an Ada program.  Since the DLL can be converted to
an
>Ada library file, Ada can use (in a manner of speaking) DLL files, but as
far
>as I know, there is no way to use the Windows API from within Ada.
>
>Andy
>

Re: Dll files

[tmoran]

>... but as far as I know, there is no way to use the Windows API
> from within Ada.
How about "pragma import" for a roll-your-own thin binding, Win32Ada
for a free-for-the-downloading, thin binding, CLAW for an Ada-style
thick binding, or TASH for a very thick (Tcl/Tk) binding.

Re: Dll files

[Simon Wright]

"Nick Roberts" <Nick.Roberts@dial.pipex.com> writes:

> Use of DLLs implies Windows, which implies availability of the Windows GDI
> (Graphical Device Interface), which is a part of the Windows API, and will
> drive SVGA as well as umpteen other graphics protocols.  So it sounds to me
> like you just want to use the Windows API direct.

I tend to describe Unix sharable image (.so) files as DLLs when trying
to explain where they fit in the scheme of things; the concept is the
same, after all!