PBDLL6 - Multiple Units 
Author Message
 PBDLL6 - Multiple Units

Is a .DLL the only available way to make use of multiple code units when
compiling a .EXE with PBDLL?  $LINK is nowhere to be found.

Thanks in advance.



Tue, 30 Apr 2002 03:00:00 GMT  
 PBDLL6 - Multiple Units


Quote:
>Is a .DLL the only available way to make use of multiple code units when
>compiling a .EXE with PBDLL?  $LINK is nowhere to be found.

Aaaah... That's one of the most missing features in PB/DLL. Not only
the capability to generate object modules, but also to be able to link
from standard ones generated by a different language compiler. In
PB/DOS, you can compile units, which is so good, but unfortunately
these may not be linked to "main"s made in another language, because
they are not standard format. You can, however, import from standard
formats. I still hope powerbasic shall one day correct this situation.
It has to do with the basics of what may be expected from a compiler.
Otherwise, speed and tight code may mean nothing for those who work
with several compilers.


Tue, 30 Apr 2002 03:00:00 GMT  
 PBDLL6 - Multiple Units

Quote:
> Is a .DLL the only available way to make use of multiple code units when
> compiling a .EXE with PBDLL?  $LINK is nowhere to be found.

Depends what you mean by a "code unit", I guess. You can't $LINK, but
you can certainly $INCLUDE. DLLs are a pretty proper and effective way
to go about it under Windows, I think. PowerBASIC may bring back a
notion like $LINK in the future, but right now, that's not an option.


Wed, 01 May 2002 03:00:00 GMT  
 PBDLL6 - Multiple Units

Quote:
> Depends what you mean by a "code unit", I guess. You can't $LINK, but
> you can certainly $INCLUDE. DLLs are a pretty proper and effective way
> to go about it under Windows, I think. PowerBASIC may bring back a
> notion like $LINK in the future, but right now, that's not an option.

Basically, I have a program that logically divides into several different
"execution blocks" for lack of a better term.  I'd like to write each piece
separately, get it working properly, then connect the pieces together.

A .DLL might work but there is no real need for one since only this program will
make use of the code.  As you say, $INCLUDE is available but that seems like a
rather brute force approach.  All the code will be re-compiled all the time.
But if that's all that is available, I have little choice.



Wed, 01 May 2002 03:00:00 GMT  
 PBDLL6 - Multiple Units
Tom, are you the Tom Hanlin that used to live
in Baton Rouge and were friends with Sean, Jae,
Paul, and that group?

- Troy



Wed, 01 May 2002 03:00:00 GMT  
 PBDLL6 - Multiple Units
You know, this topic - the lack of  statically-linkable precompiled code
modules in the PowerBASIC for Windows environment - also recently came up on
the PowerBASIC Web BBS. There, too, it seemed most expressing an opinion
felt the lack of such a capability in PB/DLL and PB/CC was a shortcoming of
the PowerBASIC/Windows product line.

Well, I disagree.

On the side of "using precompiled OBJ files as a component of my PB/DLL and
PB/CC programs:"

Here I could be missing something: third parties who supply developer
libraries in OBJ files rather than in DLLs. But as I browse through the
Provantage catalog and developer web sites, all I see is "libraries supplied
in DLL format."  So why does a PB/CC or PB/DLL developer need the ability to
link OBJ files? Both PB/CC and PB/DLL can use functions in any
industry-standard DLL. Is it to reuse the DOS libraries in which they have
already invested? Well, I have bad news - those libraries won't work under
Windows anyway (mostly). So who supplies developer libraries as Win/16-
or Win/32-bit OBJ files?

On the other side - creating reuseable code libraries (i.e., "making tools
to make applications"), I am totally at a loss as to why anyone would want
to create/deploy "OBJ" files in lieu of DLLs. DLLs are industry-standard,
may be used with many language products, including "non-user-compiled"
programs such as Excel, Access and Mercator (a data-mapping product), and
with "strong GUI - wimpy computational" languages such as Microsoft Visual
Basic (r).

Can someone (try to) set me straight? What am I missing?

Michael Mattias
Tal Systems
Racine WI USA

Quote:


> [and many others wrote on this topic]
>A .DLL might work but there is no real need for one since only this program
will
>make use of the code.  As you say, $INCLUDE is available but that seems
like a
>rather brute force approach.  All the code will be re-compiled all the
time.
>But if that's all that is available, I have little choice.



Thu, 02 May 2002 03:00:00 GMT  
 PBDLL6 - Multiple Units

Quote:
> Tom, are you the Tom Hanlin that used to live
> in Baton Rouge and were friends with Sean, Jae,
> Paul, and that group?

> - Troy

Eh... no. I'm the Tom Hanlin that used to live in Springfield,
{*filter*}ia; Mesa, Arizona; Laurel, Maryland; Alexandria,
{*filter*}ia; Smyrna, Georgia; Kennesaw, Georgia; and
Monterey, California-- mostly inclusive, and in roughly that
order. I get around, but I haven't spent much time in Baton
Rouge. Come to think of it, I don't think I've been there,
yet. Maybe next year. :-)

As far as I can guess, I was never friends with Sean, Jae,
Paul, and that group. Again, maybe next year. :-)

People who remember me are more likely to know me as
"Thomas G. Hanlin III" from Hammerly Computer Services,
TeraTech, Crescent Software, EllTech Development, or
indeed, PowerBASIC. Or from my old shareware
programming tools, now coming back online at
http://www.*-*-*.com/ (shameless plug). The Internet is a
new kid in the neighborhood-- when I was first online, we
were happy to have a RIME or ILINK or FidoNet echo
on our local BBSes, if they got that fancy.



Thu, 02 May 2002 03:00:00 GMT  
 PBDLL6 - Multiple Units
Michael,
   The advantage I see of obj or some other pb specific format module is the
ability to use the same variable names. It has nothing to do with libraries.
Also even though pb is blazingly fast it should improve compile times on very
large projects.

James

Quote:

>You know, this topic - the lack of  statically-linkable precompiled code
>modules in the PowerBASIC for Windows environment - also recently came up on
>the PowerBASIC Web BBS. There, too, it seemed most expressing an opinion
>felt the lack of such a capability in PB/DLL and PB/CC was a shortcoming of
>the PowerBASIC/Windows product line.

>Well, I disagree.

>On the side of "using precompiled OBJ files as a component of my PB/DLL and
>PB/CC programs:"

>Here I could be missing something: third parties who supply developer
>libraries in OBJ files rather than in DLLs. But as I browse through the
>Provantage catalog and developer web sites, all I see is "libraries supplied
>in DLL format."  So why does a PB/CC or PB/DLL developer need the ability to
>link OBJ files? Both PB/CC and PB/DLL can use functions in any
>industry-standard DLL. Is it to reuse the DOS libraries in which they have
>already invested? Well, I have bad news - those libraries won't work under
>Windows anyway (mostly). So who supplies developer libraries as Win/16-
>or Win/32-bit OBJ files?

>On the other side - creating reuseable code libraries (i.e., "making tools
>to make applications"), I am totally at a loss as to why anyone would want
>to create/deploy "OBJ" files in lieu of DLLs. DLLs are industry-standard,
>may be used with many language products, including "non-user-compiled"
>programs such as Excel, Access and Mercator (a data-mapping product), and
>with "strong GUI - wimpy computational" languages such as Microsoft Visual
>Basic (r).

>Can someone (try to) set me straight? What am I missing?

>Michael Mattias
>Tal Systems
>Racine WI USA



>> [and many others wrote on this topic]
>>A .DLL might work but there is no real need for one since only this program
>will
>>make use of the code.  As you say, $INCLUDE is available but that seems
>like a
>>rather brute force approach.  All the code will be re-compiled all the
>time.
>>But if that's all that is available, I have little choice.



Thu, 02 May 2002 03:00:00 GMT  
 PBDLL6 - Multiple Units
hehehe... Well said!

--Lance.

Quote:

>You know, this topic - the lack of  statically-linkable precompiled code
>modules in the PowerBASIC for Windows environment - also recently came up on
>the PowerBASIC Web BBS. There, too, it seemed most expressing an opinion
>felt the lack of such a capability in PB/DLL and PB/CC was a shortcoming of
>the PowerBASIC/Windows product line.

>Well, I disagree.

>On the side of "using precompiled OBJ files as a component of my PB/DLL and
>PB/CC programs:"

>Here I could be missing something: third parties who supply developer
>libraries in OBJ files rather than in DLLs. But as I browse through the
>Provantage catalog and developer web sites, all I see is "libraries supplied
>in DLL format."  So why does a PB/CC or PB/DLL developer need the ability to
>link OBJ files? Both PB/CC and PB/DLL can use functions in any
>industry-standard DLL. Is it to reuse the DOS libraries in which they have
>already invested? Well, I have bad news - those libraries won't work under
>Windows anyway (mostly). So who supplies developer libraries as Win/16-
>or Win/32-bit OBJ files?

>On the other side - creating reuseable code libraries (i.e., "making tools
>to make applications"), I am totally at a loss as to why anyone would want
>to create/deploy "OBJ" files in lieu of DLLs. DLLs are industry-standard,
>may be used with many language products, including "non-user-compiled"
>programs such as Excel, Access and Mercator (a data-mapping product), and
>with "strong GUI - wimpy computational" languages such as Microsoft Visual
>Basic (r).

>Can someone (try to) set me straight? What am I missing?

>Michael Mattias
>Tal Systems
>Racine WI USA



>> [and many others wrote on this topic]
>>A .DLL might work but there is no real need for one since only this program
>will
>>make use of the code.  As you say, $INCLUDE is available but that seems
>like a
>>rather brute force approach.  All the code will be re-compiled all the
>time.
>>But if that's all that is available, I have little choice.



Thu, 02 May 2002 03:00:00 GMT  
 PBDLL6 - Multiple Units


Quote:
>On the other side - creating reuseable code libraries (i.e., "making tools
>to make applications"), I am totally at a loss as to why anyone would want
>to create/deploy "OBJ" files in lieu of DLLs. DLLs are industry-standard,
>may be used with many language products, including "non-user-compiled"
>programs such as Excel, Access and Mercator (a data-mapping product), and
>with "strong GUI - wimpy computational" languages such as Microsoft Visual
>Basic (r).

>Can someone (try to) set me straight? What am I missing?

Hi Mike,

  What you're missing is that the library files we're talking about and
missing are NOT distributed to the end user. They are used for development
only and hold all the routines we may use in a single .EXE. At compile time
the compiler goes into these files and pull out ONLY the code that is required
and integrates it into the .EXE. All the other routines that are not required
to do the compile are NOT integrated. When you're finished you've got an .EXE
containing only the required code and nothing more.

  In PB/dos we had/have the .PBL files that allowed us to store and call code.
It was an easy matter to $LINK all our libraries to the source code without
running through hundreds of $DECLARE statements deleting what we didn't use
for this particular compile.

  Believe me, it _IS_ a missed feature in PB/cc and/or PB/dll that has cost me
much time already and more in the future, I'm sure.

I WANT MY LIBRARIES BACK!!!!!!! (a cry in the wilderness)

C'ya,

   ____    _    ____      ____  _____
  |  _ \  / \  / ___) __ | ___)(_   _) Don Schullian

  |____//_/ \_\(____/\__/|_|     |_|    www.DASoftVSS.com
  ___________________________________   www.basicguru.com
      Vertical Software Solutions



Thu, 02 May 2002 03:00:00 GMT  
 
 [ 42 post ]  Go to page: [1] [2] [3]

 Relevant Pages 

1. unit with multiple input

2. File naming in GNAT and multiple units/file

3. Tasking and multiple execution units

4. Multiple same construct name in program unit

5. New enhancements for next PBDLL6+

6. A request for the PBDLL6 team...

7. using test::unit for C++ unit tests

8. Test::Unit::Mock: Mock objects for testing with Test::Unit

9. Generic units and child units

10. g77 + unit #s + open unit limits

11. closing unit=5 and unit=6 and print *

12. POSC Units Converter - Units Data Updated 4/26

 

 
Powered by phpBB® Forum Software