DLLs and PB

[Walt Decker]

As I've stated before, I do not pretend to be a programmer. I'm a geologist looking into PB as an alternative to some other languages I use to develope the analysis and display of geologic data. This first question may be a bit unsophisticated.

1. It is my understanding that a DLL, at least the specifications for various functions within it, are linked into a windows application at compile time, but the DLL is not actually loaded until execution time. Is it loaded at execution time or when a function within it is actually called? Once the DLL has finished it's function, is it unloaded or does it stay attached to the application until the end? What I'm really trying to get at here is the difference between a DLL (or functions contained within it) and an overlay.

2. When PB/DLL first came out there was a lot of hype about it being able to transport DOS apps to windows. Now I'm reading that PB/DLL should be used to inhance VB applications. The question is: can PB/DLL actually make a PB-DOS application into a "stand alone" windows application or must the application be made into a DLL which is callable from a VB application?

3. I've been finding a number of little quirks in PB 3.5 that I didn't expect from reading and working with the users and reference manuals. Does PB have a knowledge base similar to the microstuff knowledge base where one can go to look up some of these quirks and possibly find the answers to others?

[Eric Pearson]

Walt --

1) When a 32-bit Windows application starts up, Windows automatically loads all of the DLLs that are necessary for the program to run. (It also automatically executes a function in each DLL called LibMain, in case the DLL needs to execute some initialization code at startup, before it begins executing the EXE.) If another application that uses the same DLL is started, Windows links the second application to a new "instance" of the DLL, but only one copy of the DLL is actually in memory at any given time. (Each instance of an EXE or DLL gets its own set of variables, however, so they can't "see" each other.) Windows keeps DLLs in memory until they are no longer needed by any application, i.e. when Windows detects that the last application that is using a DLL has closed, it automatically unloads the DLL from memory.

(It is possible to "manually" load and unload DLLs, but this is relatively uncommon, to say the least.)

2) PB/DLL can create both DLLs and stand-alone EXE files. Honestly, to say that it can "make a PB-DOS application into a stand alone windows application" is over-simplifying things. A significant amount of re-coding would be necessary, especially the user interface. PB/DLL does not support COLOR/LOCATE/PRINT/CLS/etc. so all of that code would have to be 100% re-worked into a Windows-style "GUI" interface. (The PB/CC compiler supports COLOR/etc. but it does not directly support GUI interfaces, and it cannot be used to create DLLs.)

Personally, I use PowerBASIC for virtually 100% of my programming. I own Visual Basic, but I literally never use it. And the EXE files (created with PB/DLL and PB/CC) that I distribute to my customers are 100% stand-alone applications, unless you count the DLLs (also written with PB/DLL) that I choose to use to "modularize" my apps.

3) Yes, you're reading an entry into the "knowledge base" right now. These forums (and their archives) almost certainly contain the largest single accumulation of knowledge about PowerBASIC that has ever existed. Use the Search feature at the top of the page, and you'll be amazed at what you'll find. Or just post a question on the appropriate forum!

-- Eric


------------------
Perfect Sync: Perfect Sync Development Tools
Email: mailto:[email protected][email protected]</A>



[This message has been edited by Eric Pearson (edited March 05, 2000).]

[Donald Darden]

I've been using PowerBASIC products since PB for DOS version
2.0, and was initially drawn because it could compile single
programs of great size that you could only emmulate in Quick-
BASIC as separate modules. I really loved using versions 3.2
and 3.5, and was slow to make the move to the Console Compiler,
and even slower to move to PB/DLL, which later became the PB/WIN
product. Not that these were limited products, but they required
some unlearning and retraining to use, and the full power that
they offered meant delving into other topic areas like Windows
API calls and COM.

The new data types offered certainly have convenced me over time
to make the transition, but I still use PB/DOS 3.5 when I want to
translate another program over to PowerBASIC, especially if it is
from another BASIC. It offers more compatability, and it still
runs just fine under various versions of Windows, including the
Windows 2000 Pro I currently have on several machines.

PowerBASIC, to me, has the ability to scale up to any size task.
I wrote programs with it that routinely scoured digital switches
and IBM mainframes, accumulating some 200 million bytes of data
weekly, and these programs processed that data and found all
manner of inconsistencies. I took a volume of data that had
swamped our analysts, and gave them the means to render all that
data down into a trivial four hours process each week, and the
programs were so resiliant that they ran without any human
intervention. You just kicked them off and let them run until
done. But here is the really neat thing: Instead of writing these
programs in PB/DOS 3.5, a clear favorite at the onset, I chose
instead to learn to write code using PB/CC, where I already knew
about 80% of the BASIC syntax, and learned the rest as I needed it.
The result was truely impressive, because while the program was
single-threaded in nature, I could run multiple instances of it
all at once - not just on multiple PCs, but even on the same PC!

I ran over twelve instances of the same program on the same PC,
each in its own little window, and saw each addition resulted in
a net gain in the speed at which the processing was done. But
from roughly 13 to 16 processes running, there was no gain, and
beyond sixteen process, the speed began to drop off. I attributed
this to the increased threshing within the operating system
(Windows NT 4.0) and network slowdowns as I was working though a
single 10mps ethernet connection.

In other words, I had not only taken months of analytical work
and scaled it down to a matter of a few hours, but I had also
taken the work that one PC could do under DOS and advanced it to
where it could do the work of 12 PCs, just by taking advantage of
window's native ability to support multi-tasking and PB/CC's
ability to take advantage of virtually every feature of that
environment. The only limitations to PB/CC are (1) It does not
hatively support a GUI interface (you can get libraries, use API
calls, or move to PB/Win to deal with that_, and (2) it does not
fully support timed events (although you can make it do so by
creating your own infinate loop within the main body of the
program).

Could I have done even better under Linux? I suspect so, but
right now I wouldn't have the luxury of using PB/CC or PB/Win
to write my programs, either! At present, thess two products
depend upon the feature set that comes with Windows - but they
do so in such a transparent way, that you are usually not even
aware of which Windows operating system is involved!

What makes my accomplishments even more impressive was that I
got these results on a 400 MHz PC's with just 256 MBytes of RAM
and 30 GBytes of Hard Disk Space! Running that program today
under Windows 2000 Pro at over 2GHz, with more memory and hard
drive space, the bottleneck would surely have been the network
connection itself.

I was extremely happy to be one of the Beta-testers involved
with the most recent PowerBASIC offerings, and believe me,
PowerBASIC worked hard with us to get everything just right,
until our bunch of very demanding people (all badge-toting
nitpickers) were finally satisfied that we had contributed to
turn out a product that everyone should be proud of and happy
to work with. So this is just one very happy customer who is
pleased to lend his endorsement to some great products.

------------------
Old Navy Chief, Systems Engineer, Systems Analyst, now semi-retired

[Davide Vecchi]

I had also taken the work that one PC could do under DOS
and advanced it to where it could do the work of 12 PCs, just by
taking advantage of window's native ability to support multi-tasking

If improving speed is important enough to justify the adoption
of not trendy solutions, and Windows is not required for other reasons,
then it's likely that writing the app in PB/DOS and running it in some
DOS multitasking environment (DR-DOS, DesqView or other) would allow
even greater speed improvements.

------------------
Davide Vecchi
[email protected]

[Tom Hanlin]

I think this is usually not going to be the case when dealing with
large amounts of data. Windows has access to far more RAM and disk
space at higher bandwidth, plus 32-bit processing, multithreading,
and high-performance floating point. Apps like DESQview did amazing
things with the capacity available, but the tech passed them by 20
years ago. Doubling the engines in a Model-T Ford will not get you
a Ferrari. 'Course, when the radiator boils over, you won't be able
to fix the Ferrari with a wad of chewing gum, but that's Progress,
y'see?

------------------
Tom Hanlin
PowerBASIC Staff