No announcement yet.

DLLs and PB

  • Filter
  • Time
  • Show
Clear All
new posts

  • DLLs and PB

    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?
    Walt Decker

  • #2
    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).]
    "Not my circus, not my monkeys."


    • #3
      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

      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


      • #4
        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]


        • #5
          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,

          Tom Hanlin
          PowerBASIC Staff