No announcement yet.


  • Filter
  • Time
  • Show
Clear All
new posts

  • memory


    I hope that you can help me. I have inherited an undocumented program written using PB 3.2.
    I would like to place a watch on some of the variables and step through the program to better understand it.

    When I attempt to step into the program, I receive the following message:

    Not enough memory available to run
    in the IDE: try PBD.EXE. Press ESC
    IDE memory available: 190224
    IDE required to exec: 390288

    I am using windows xp with 512m RAM and have attempted to configure a pif to maximize the memory available to PB.
    Here is the memory that I have available in a dos window:

    655360 bytes total conventional memory
    655360 bytes available to MS-DOS
    628032 largest executable program size

    33554432 bytes total contiguous extended memory
    0 bytes available contiguous extended memory
    16711680 bytes available XMS memory
    MS-DOS resident in High Memory Area

    Last week I purchased PB 3.5 in order to get some documentation for PB.
    I also purchased PBCC thinking that perhaps I could port the program over to sidestep the memory problems, but that is turning into a bigger job than I expected.

    Can you please suggest some way that I can step through this program?

    Thank you for your help.


  • #2
    In PB.exe under Options/Compiler Set "Attach PBDebugInfo" to on.
    Run PBD.exe and use your standard debug commands to work through the program.


    ian[dot][email protected]
    :) IRC :)


    • #3
      Thanks for the tip. I guess I am somewhat closer to debugging, but I'm still not there.\

      After opening the file in pbd I received the following message:

      Success..Press any key.
      DDE memory available 273088
      DDE required to exec 390288

      When I attempt to step into the program I receive this message:
      Error 258: Program too big to fit in memory.

      Does anyone have any ideas?



      • #4
        You might try to make your module code smaller.

        Other than eliminating parts of code , you could move some procedures to compiled units (*.PBU) (procedures that you don't need to debug now), which is a good idea anyway.

        I'm sure there are more things you can do, just now i can't think of any, i'll post if they come to my mind.

        Davide Vecchi
        [email protected]


        • #5
          >you could move some procedures to compiled units (*.PBU

          Or *.PBC CHAIN files.

          Michael Mattias
          Tal Systems (retired)
          Port Washington WI USA
          [email protected]


          • #6
            try this link:
            ems memory and windows xp

            ian[dot][email protected]
            :) IRC :)


            • #7
              Friend Williams,

              If all this and WIN XP and so on wind up in a deep black memory
              hole and there is no other way out, but you MUST get this done,
              you might send me your Email address to mine which is published
              here.. I may be able to offer pointers to other operating system
              sources for DOS which will bail you out and then some.

              At the risk of starting a riot here, sigh ..

              There are ways in OS/2 to gain even more available memory and
              work, as far as I've seen, with larger programs in relation to
              the de-bugging issue, than I've seen in any other *DOS* platform
              variation. And, again, you can run larger programs for client
              use that you can de-bug in the conventional single-step way
              as well, if absolutely needed. I've heard it described as
              'cheese debugging' by other PB afficiandos in the past, and,
              yes, even I have to use it at times, grin.

              There are arguable some issues which have surfaced in the past
              with things that seem 'broken' that then can't be 'demonstrated'
              to those not working in the IBM version of *DOS* and the arguably
              'standard' EMS/XMS interface and so on.

              But so far, there are work-arounds that haven't stopped me yet.

              Amd as I sit here right now, I'm going forward with PB 3.5 for
              'DOS' in yet another program far bigger than I could even run in
              the PB 3.5 IDE in any other form of DOS I've ever had, today, using
              extra long quad integers for arrays with elements that big, for the
              first time in my life with PowerBasic. Plus while i'm writing this
              and taking a break to answer you in MOZ 1.8a6 in OS/2 MCP2 latest
              there are 156 threads and 15 complete active tasks running on this
              box with only 19% of a 500Mhz Intel CPU even used. Which includes
              two complete DOS comm port applications running full time in the
              background for dedicated logging purposes as well!

              And it *IS* possible, to run OS/2 as a GUEST in Windows, at least
              it was until M/S bought out Connectix, which although they killed
              the reverse to run WIN as a GUEST in OS/2, I'm told is cheerfully
              available for the reverse!

              And .. at least for USA folks .. all it costs for the Passport
              Advantage membership at IBM for a full year of support and the
              whole deal of MCP2 latest for OS/2, is a flying $62 USD. Which
              runs everything I've thrown at the IBM DOS provided back to 1974.
              Assembler code I still use, plus everything all the way into
              the whole USB, and so on for a heck of a lot into the future.

              You will, perhaps, as I am seeing, have a hard time getting the
              resulting DOS code from PB 3.5, running for certain communications
              and printing issues in WIN XP SP2 latest. I do have a test box of
              that level here which is giving me no end of trouble on some WIN
              items that are really WIN and have NOTHING to do with other than
              Windows code. So as I have found out there are even more compatiblity
              issues with where WIN is going as opposed to other operating systems
              in respect to heritage code..

              But if there is no other out, and the issue is one of absolute
              support for DOS operations, such as embedded systems work, hardware
              communications issues for water or oil field reservoir production
              work, numerical machine tool systems, .. and so on .. have hope!
              OS/2 is fully supported in writing from IBM through December 31,
              2006. And per disclosure at WarpStock for more than one year now..
              it's TCO'd under contract for very big customers in Europe .. through
              the year 2019. Plus IBM still officially posts that they are supporting
              over SIX MILLION pure DOS 'users' at this point. So it almost has to
              mean something about DOS and what is needed, I guess.

              Heritage applications are SERIOUS business for some people. And
              the ability to work with them is a very major commitement for some
              people as well.. Including PowerBasic, which has done a wonderful
              job for me for a long, long time.

              Mike Luther
              [email protected]
              Mike Luther
              [email protected]


              • #8
                For anyone who's interested:

                "Welcome to dosemu!"
                SHARE installed.

                Memory Type Total Used Free
                ---------------- -------- -------- --------
                Conventional 640K 10K 630K
                Upper 116K 21K 95K
                Reserved 268K 268K 0K
                Extended (XMS) 16,384K 8,292K 8,092K
                ---------------- -------- -------- --------
                Total memory 17,408K 8,591K 8,817K

                Total under 1 MB 756K 31K 725K

                Total Expanded (EMS) 2,048K (2,097,152 bytes)
                Free Expanded (EMS) 2,048K (2,097,152 bytes)

                Largest executable program size 630K (645,168 bytes)
                Largest free upper memory block 92K ( 94,560 bytes)
                FreeDOS is resident in the high memory area.