DLLs in QB 7.1 PDS 
Author Message
 DLLs in QB 7.1 PDS

Looking for a DLL equivalent for QB, not so much the separate file as
the 'Dynamic Link' aspect of it.
So I can have one library with common procedures and use it in all of
my programs.

Thanx



Sun, 25 Sep 2005 05:57:49 GMT  
 DLLs in QB 7.1 PDS

Quote:
>Looking for a DLL equivalent for QB, not so much the separate file as
>the 'Dynamic Link' aspect of it.
>So I can have one library with common procedures and use it in all of
>my programs.

Sorry, ain't no such critter.

You can use DLL's with PDS programs if you use PharLap's RUN286,
however the linking is then done by the RUN286 loader. And, it costs
at least $500, if you can even find a copy.  And, you are running in
protected mode.

--
Arargh (at arargh dot com)    http://www.arargh.com
To reply by email, change the domain name, and remove the garbage.
(Enteract can keep the spam, they are gone anyway)



Sun, 25 Sep 2005 06:11:19 GMT  
 DLLs in QB 7.1 PDS

Quote:

> >Looking for a DLL equivalent for QB, not so much the separate file as
> >the 'Dynamic Link' aspect of it.
> >So I can have one library with common procedures and use it in all of
> >my programs.

> Sorry, ain't no such critter.

> You can use DLL's with PDS programs if you use PharLap's RUN286,
> however the linking is then done by the RUN286 loader. And, it costs
> at least $500, if you can even find a copy.  And, you are running in
> protected mode.

"Dynamic linking" is not necessary to have "one library with common
procedures."  You can always compile a collection of procedures to an OBJ
file and just include that in your link list when you compile each program.

Hmmm.. come to think of it... I never used PDS, but didn't PDS support
creation of alternate run-times? Sounds like this would be the ticket here..

MCM



Sun, 25 Sep 2005 19:58:37 GMT  
 DLLs in QB 7.1 PDS
On Wed, 09 Apr 2003 11:58:37 GMT, "Michael Mattias"

Quote:




>> >Looking for a DLL equivalent for QB, not so much the separate file as
>> >the 'Dynamic Link' aspect of it.
>> >So I can have one library with common procedures and use it in all of
>> >my programs.

>> Sorry, ain't no such critter.

>> You can use DLL's with PDS programs if you use PharLap's RUN286,
>> however the linking is then done by the RUN286 loader. And, it costs
>> at least $500, if you can even find a copy.  And, you are running in
>> protected mode.

That sounds very interesting
Quote:

>"Dynamic linking" is not necessary to have "one library with common
>procedures."  You can always compile a collection of procedures to an OBJ
>file and just include that in your link list when you compile each program.

Or even let your linker search a .LIB file
Quote:

>Hmmm.. come to think of it... I never used PDS, but didn't PDS support
>creation of alternate run-times? Sounds like this would be the ticket here..

Yes, it did, but they are of limited use as you have to compile every
App against the (already compiled) run time library
- basically you have to re-link every EXE when you change _anything_
in the run-time library
- a bit like VB DLLs without binary compatibility.

My hunch is that the OP has a whole load of EXEs that use some core
routines - and probably the core routines need frequent updating

One solution is to use Shell() - not particularly fast, but on today's
computers it runs like lightning.  

Another is to ship .OBJ and .LIB files and get the user to re-link the
system when they get an update
- that sounds impractical but it was fairly standard practise in the
days of CBASIC (from DR) on CP/M or even early MSDOS

Personally I would look at the App design, it is quite possible that
one can save the state of one EXE then Run/Chain another and return.

It takes a bit of effort modularizing things, but it does work
surprizingly well.

- Show quoted text -

Quote:

>MCM



Sun, 25 Sep 2005 20:35:28 GMT  
 DLLs in QB 7.1 PDS

Quote:



> > >Looking for a DLL equivalent for QB, not so much the separate file as
> > >the 'Dynamic Link' aspect of it.
> > >So I can have one library with common procedures and use it in all of
> > >my programs.

> Hmmm.. come to think of it... I never used PDS, but didn't PDS support
> creation of alternate run-times? Sounds like this would be the ticket

here..

Yes, it does, and I've been using it forever.  I have an alternate runtime
which contains routines common to all my chained programs, and also use
link-time libraries for other common type routines, but which are not
required by as many programs.

You have to keep your runtime library to a minimum, though, as a larger
runtime obviously requires more RAM, and for all programs.  I've spent years
t{*filter*} down the runtime size to attempt to free up more RAM for my
applications.

--
Frisbee? MCNGP #13

http://www.*-*-*.com/
The MCNGP Team - We're here to help



Sun, 25 Sep 2005 20:55:44 GMT  
 DLLs in QB 7.1 PDS
On Wed, 09 Apr 2003 11:58:37 GMT, "Michael Mattias"

Quote:




>> >Looking for a DLL equivalent for QB, not so much the separate file as
>> >the 'Dynamic Link' aspect of it.
>> >So I can have one library with common procedures and use it in all of
>> >my programs.

>> Sorry, ain't no such critter.

>> You can use DLL's with PDS programs if you use PharLap's RUN286,
>> however the linking is then done by the RUN286 loader. And, it costs
>> at least $500, if you can even find a copy.  And, you are running in
>> protected mode.

>"Dynamic linking" is not necessary to have "one library with common
>procedures."  You can always compile a collection of procedures to an OBJ
>file and just include that in your link list when you compile each program.

Yes, that just what I do.  But thats not "Dynamic linking".  Its
"static linking" :-)
Quote:

>Hmmm.. come to think of it... I never used PDS, but didn't PDS support
>creation of alternate run-times? Sounds like this would be the ticket here..

It does.  I have never used it.  I always compile to a standalone exe.

--
Arargh (at arargh dot com)    http://www.arargh.com
To reply by email, change the domain name, and remove the garbage.
(Enteract can keep the spam, they are gone anyway)



Mon, 26 Sep 2005 06:39:18 GMT  
 DLLs in QB 7.1 PDS

Quote:

>On Wed, 09 Apr 2003 11:58:37 GMT, "Michael Mattias"




>>> >Looking for a DLL equivalent for QB, not so much the separate file as
>>> >the 'Dynamic Link' aspect of it.
>>> >So I can have one library with common procedures and use it in all of
>>> >my programs.

>>> Sorry, ain't no such critter.

>>> You can use DLL's with PDS programs if you use PharLap's RUN286,
>>> however the linking is then done by the RUN286 loader. And, it costs
>>> at least $500, if you can even find a copy.  And, you are running in
>>> protected mode.
>That sounds very interesting

Maybe.  It is somewhat of a pain to use.  You are effectivly
programming for OS/2 Ver 1.2 which is what RUN286 supports (16-bit
protected mode).  However, it will run on plain old DOS, Ver 3 or
later.  (or maybe Ver 5).

When I get futher along with the compiler I am working on, it will
support DLLs, just like any other windows language.  It's getting up
to late alpha state.  URL: http://www.arargh.com/basic/basic.html  for
a very simple example.  I will put up another a little later today.

The initial design goal is to read a PDS source file and generate an
.ASM file, which requires MASM 6.x or later. The end result is a
windows console app.  Some things are not yet working, and some things
will never be supported.  ISAM for one.

- Show quoted text -

Quote:

>>"Dynamic linking" is not necessary to have "one library with common
>>procedures."  You can always compile a collection of procedures to an OBJ
>>file and just include that in your link list when you compile each program.
>Or even let your linker search a .LIB file

>>Hmmm.. come to think of it... I never used PDS, but didn't PDS support
>>creation of alternate run-times? Sounds like this would be the ticket here..
>Yes, it did, but they are of limited use as you have to compile every
>App against the (already compiled) run time library
>- basically you have to re-link every EXE when you change _anything_
>in the run-time library
>- a bit like VB DLLs without binary compatibility.

>My hunch is that the OP has a whole load of EXEs that use some core
>routines - and probably the core routines need frequent updating

>One solution is to use Shell() - not particularly fast, but on today's
>computers it runs like lightning.  

>Another is to ship .OBJ and .LIB files and get the user to re-link the
>system when they get an update
>- that sounds impractical but it was fairly standard practise in the
>days of CBASIC (from DR) on CP/M or even early MSDOS

>Personally I would look at the App design, it is quite possible that
>one can save the state of one EXE then Run/Chain another and return.

>It takes a bit of effort modularizing things, but it does work
>surprizingly well.

>>MCM

--
Arargh (at arargh dot com)    http://www.arargh.com
To reply by email, change the domain name, and remove the garbage.
(Enteract can keep the spam, they are gone anyway)


Mon, 26 Sep 2005 06:50:41 GMT  
 DLLs in QB 7.1 PDS
On Wed, 9 Apr 2003 08:55:44 -0400, Frisbee? MCNGP

Quote:






>> > >Looking for a DLL equivalent for QB, not so much the separate file as
>> > >the 'Dynamic Link' aspect of it.
>> > >So I can have one library with common procedures and use it in all of
>> > >my programs.

>> Hmmm.. come to think of it... I never used PDS, but didn't PDS support
>> creation of alternate run-times? Sounds like this would be the ticket
>here..

>Yes, it does, and I've been using it forever.  I have an alternate runtime
>which contains routines common to all my chained programs, and also use
>link-time libraries for other common type routines, but which are not
>required by as many programs.

>You have to keep your runtime library to a minimum, though, as a larger
>runtime obviously requires more RAM, and for all programs.  I've spent years
>t{*filter*} down the runtime size to attempt to free up more RAM for my
>applications.

Using the RUN286 stunt gets around some of the memory limits, but read
my slightly earlier post for more comments.

--
Arargh (at arargh dot com)     http://www.*-*-*.com/
To reply by email, change the domain name, and remove the garbage.
(Enteract can keep the spam, they are gone anyway)



Mon, 26 Sep 2005 06:52:12 GMT  
 DLLs in QB 7.1 PDS

Quote:
> On Wed, 09 Apr 2003 11:58:37 GMT, "Michael Mattias"




> >> >Looking for a DLL equivalent for QB, not so much the separate file as
> >> >the 'Dynamic Link' aspect of it.
> >> >So I can have one library with common procedures and use it in all of
> >> >my programs.
> >Hmmm.. come to think of it... I never used PDS, but didn't PDS support
> >creation of alternate run-times? Sounds like this would be the ticket

here..

Quote:
> Yes, it did, but they are of limited use as you have to compile every
> App against the (already compiled) run time library
> - basically you have to re-link every EXE when you change _anything_
> in the run-time library - a bit like VB DLLs without binary compatibility.

A. Why would one need to re-link if the run time changes as long as the
parameters (number or data type) to a routine do not change?  That makes so
sense.   If you add a procedure to the runtime, programs not using that
procedure should not need to change.   But I suspect the real problem here
is....

B. Every time you change the run-time library? If the run-time "library" is
changing, it's not much of a library now, is it?

Just thought of something on 'A' : Does LINK.EXE link the PDS exececutable
program with something like a hard-coded offset into the run-time module?
Then I can see why you'd have to relink everything. Well, that brings me
back to point 'B' - the "library" which is subject to frequent changes.

MCM



Mon, 26 Sep 2005 19:42:19 GMT  
 DLLs in QB 7.1 PDS


<snip>

Quote:
>>That sounds very interesting
>Maybe.  It is somewhat of a pain to use.  You are effectivly
>programming for OS/2 Ver 1.2 which is what RUN286 supports (16-bit
>protected mode).  However, it will run on plain old DOS, Ver 3 or
>later.  (or maybe Ver 5).

>When I get futher along with the compiler I am working on, it will
>support DLLs, just like any other windows language.  It's getting up
>to late alpha state.  URL: http://www.arargh.com/basic/basic.html  for
>a very simple example.  I will put up another a little later today.

>The initial design goal is to read a PDS source file and generate an
>.ASM file, which requires MASM 6.x or later. The end result is a
>windows console app.  Some things are not yet working, and some things
>will never be supported.  ISAM for one.

Now ISAMs are things that really do belong in a DLL !

One should be able to implement some form of DLL with the Overlay
mechanism

Two things that really narks me about the PDS7.1 compiler
- Declare Function ... eats code space at compile time
- String literals eat data segment - even with overlays



Mon, 26 Sep 2005 19:15:18 GMT  
 DLLs in QB 7.1 PDS
On Thu, 10 Apr 2003 11:42:19 GMT, "Michael Mattias"

<snip>

Quote:
>A. Why would one need to re-link if the run time changes as long as the
>parameters (number or data type) to a routine do not change?  That makes so
>sense.   If you add a procedure to the runtime, programs not using that
>procedure should not need to change.   But I suspect the real problem here
>is....

Well they use a 'Cookie' - this is delving into the depths of my
memory, but I think 1990 was the first time I heard the phrase 'Magic
Cookie' - and I know it was in this context.

Quote:

>B. Every time you change the run-time library? If the run-time "library" is
>changing, it's not much of a library now, is it?

It is (probably/certainly) something to do with the Load Overlay stuff
- it certainly is a Library but not a 'DL' Library
Quote:

>Just thought of something on 'A' : Does LINK.EXE link the PDS exececutable
>program with something like a hard-coded offset into the run-time module?
>Then I can see why you'd have to relink everything. Well, that brings me
>back to point 'B' - the "library" which is subject to frequent changes.

It is not worth bothering with, unless one is very smart and intends
doing something very sneaky, but yes it is (I believe) hard coded
offsets.

Those things were developed in the days when you had a maximum of 60mb
(local) disk to play with - so the footprint of EXEs was signficant.

Heck I've just checked it, the copyright is 1982-90

IIRC pre DOS 5 ( and DOS 4 was bug ridden )
- ergo a max of 30mb on one drive

Quote:

>MCM



Tue, 27 Sep 2005 00:06:30 GMT  
 DLLs in QB 7.1 PDS

Quote:



><snip>
>>>That sounds very interesting
>>Maybe.  It is somewhat of a pain to use.  You are effectivly
>>programming for OS/2 Ver 1.2 which is what RUN286 supports (16-bit
>>protected mode).  However, it will run on plain old DOS, Ver 3 or
>>later.  (or maybe Ver 5).

>>When I get futher along with the compiler I am working on, it will
>>support DLLs, just like any other windows language.  It's getting up
>>to late alpha state.  URL: http://www.arargh.com/basic/basic.html  for
>>a very simple example.  I will put up another a little later today.

>>The initial design goal is to read a PDS source file and generate an
>>.ASM file, which requires MASM 6.x or later. The end result is a
>>windows console app.  Some things are not yet working, and some things
>>will never be supported.  ISAM for one.

>Now ISAMs are things that really do belong in a DLL !

>One should be able to implement some form of DLL with the Overlay
>mechanism

Yes, but that still happens at link time, not load time.
Quote:

>Two things that really narks me about the PDS7.1 compiler
>- Declare Function ... eats code space at compile time

I would assume Declare SUB does also. :-)
Quote:
>- String literals eat data segment - even with overlays

If you have a large number of fixed strings, it is trivial to write a
routine to move the whole mess to far memory.  Or, use VBDOS 1.0 where
string constants wind up in far memory.

--
Arargh (at arargh dot com)    http://www.arargh.com
To reply by email, change the domain name, and remove the garbage.
(Enteract can keep the spam, they are gone anyway)



Tue, 27 Sep 2005 05:16:33 GMT  
 DLLs in QB 7.1 PDS


<snip>

Quote:
>>One should be able to implement some form of DLL with the Overlay
>>mechanism
>Yes, but that still happens at link time, not load time.

Not necessarily - I think it is Int 21 4B

Quote:

>>Two things that really narks me about the PDS7.1 compiler
>>- Declare Function ... eats code space at compile time
>I would assume Declare SUB does also. :-)

True ...

Quote:
>>- String literals eat data segment - even with overlays
>If you have a large number of fixed strings, it is trivial to write a
>routine to move the whole mess to far memory.  

Or indeed to Code Segment - which IMO is where it belongs
Quote:
>Or, use VBDOS 1.0 where
>string constants wind up in far memory.

I've never tried that

BTW do you anticipate eventually making your compiler .OBJ compatible
with PDS7 ?



Tue, 27 Sep 2005 15:33:13 GMT  
 DLLs in QB 7.1 PDS

Quote:



><snip>
>>>One should be able to implement some form of DLL with the Overlay
>>>mechanism
>>Yes, but that still happens at link time, not load time.
>Not necessarily - I think it is Int 21 4B

That int would only be used for external overlay files.  I doubt that
it is even possible to use them with PDS.  Except maybe CALL Absolute.
Normal overlays are created at link time.
Quote:

>>>Two things that really narks me about the PDS7.1 compiler
>>>- Declare Function ... eats code space at compile time
>>I would assume Declare SUB does also. :-)
>True ...

>>>- String literals eat data segment - even with overlays
>>If you have a large number of fixed strings, it is trivial to write a
>>routine to move the whole mess to far memory.  
>Or indeed to Code Segment - which IMO is where it belongs

It is easier to handle them as Far Data, at least in the several
situations I have had to deal with that.

Quote:
>>Or, use VBDOS 1.0 where
>>string constants wind up in far memory.
>I've never tried that

>BTW do you anticipate eventually making your compiler .OBJ compatible
>with PDS7 ?

Probably not.  It was always intended to (initially) generate win32
console apps.  Once it gets to late beta stage, I intended to modify
the runtime code to work with other 32 bit flat model systems. FreeBSD
first, because I have that running here. Actually, I would have to
rework the code generator also.  It currently generates MASM specific
code.

If at some point in the future there is sufficient demand (and enough
money) I could write a DOS specific runtime.  But, that still would
require a 32 bit DOS extender.

Something else I need to write is an design goal overview so I have
something readable to stick up on the web site.  Trouble is, I am
pretty good at writing code, but lousy with documentation.

--
Arargh (at arargh dot com)    http://www.arargh.com
To reply by email, change the domain name, and remove the garbage.
(Enteract can keep the spam, they are gone anyway)



Wed, 28 Sep 2005 06:56:49 GMT  
 
 [ 14 post ] 

 Relevant Pages 

1. QB 7.1 (sorry - PDS 7.1)

2. Year2K Compliance of Microsoft Basic PDS 7.1 and Consulting Firms specializing in Y2K and PDS 7.1

3. command line arguments in QB 7.1 PDS

4. QB 4.5/Basic PDS 7.1/Visual Basic Consultants Available

5. QB 4.5/Basic PDS 7.1/Visual Basic Consultants Available

6. want QB 4.5 QB 7.1 FOR FREE!!!

7. PDS 7.1 to PowerBasic

8. PDS 7.1 date validation

9. MS PDS 7.1 and ProBas 5.6

10. FS: QBasic PDS 7.1

11. PDS 7.1 Extender

12. PDS 7.1 and HPFS

 

 
Powered by phpBB® Forum Software