No announcement yet.

DLLs and PB

  • Filter
  • Time
  • Show
Clear All
new posts

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

    Tom Hanlin
    PowerBASIC Staff

    Leave a comment:

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

    Leave a comment:

  • 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

    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

    Leave a comment:

  • 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).]

    Leave a comment:

  • Walt Decker
    started a topic DLLs and PB

    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?