No announcement yet.

Units vs single BAS in IDE

  • Filter
  • Time
  • Show
Clear All
new posts

  • Units vs single BAS in IDE

    I have a quite large PB3.5 project that was made by a single BAS file (no Units). Finally, i took the time to split it into several appropriate Units (12 small Units) and related $INCLUDE files.

    Before splitting it, i was able to run it inside the IDE (it has 8042 lines, 4069 statements and after compilation 3760K free memory are shown by the compilation window).

    Now that it' s splitted, although i really didn' t add significant amount of code, the IDE returns this message hitting F9 after successfully loading the main BAS module (not Unit):

    +-[_]----------Load File--------------+
    ¦ Not enough memory available to run ¦
    ¦ in the IDE: try PBD.EXE. Press ESC ¦
    ¦ IDE memory available: 167568 ¦
    ¦ IDE required to exec: 168480 ¦

    I' ll go for PBD immediately, just i can' t figure out why so much additional memory is required just because i splitted the code into Units. I admit that i was expecting that splitting into Units wasn' t significantly affecting the memory requirements, or, if it did, then it was tending to reduce them.

    Can someone clarify what may bring to this?
    In general, having this implications made clear would be important every time one has to decide whether structuring a project by Units or not.
    In particular, i' m afraid for the possibility that this error message is not the true problem and that it hides something that went wrong in my splitting process, but i can' t imagine what. The EXE runs normally as it did before splitting.

    Davide Vecchi
    [email protected]


  • #2
    Even though the code for the program isn't any larger, the symbol table is. It needs to store information about all of the units and unit source files. That takes up a bit more memory.


    PowerBASIC Support
    mailto:[email protected][email protected]</A>

    Home of the BASIC Gurus


    • #3
      Hi Davide,

      I´ve the problem too. Try to delete some diver You don`t need so
      urgent perhaps for mouse etc. in the autoexec.bat or the config.sys.
      Try to use memmaker too to spare free memory under Dos. Type in
      the 'mem' command to check your free memory.

      The other way is to split Your program in serveral EXE´s if

      Hope this helps.

      Regards Matthias Kuhn


      • #4
        Interesting item which may or may not be related ..

        Even in a WIN-95 setup with 16-megs of free EMS memory, the
        PB-DOS-3.5 compiler "Get Info" stats list an EMS max of 4-megs--
        and this is with PB.EXE adjusted via PBINST to allow for ALL
        EMS/XMS memory to be used.

        Was 4-megs a limit set by Power-Basic? Were later releases of
        PB-DOS-3.5 adjusted to allow for EMS/XMS memory usage above 4 meg?

        [This message has been edited by Frank Ferrell (edited January 27, 2000).]


        • #5
          The IDE's EMS/XMS settings are purely for the editor and for use during the compilation process, not your code.

          By design, PB.EXE is limited to using 4Mb of EMS (of less if you configure it using PBINST). Your own code can use EMS for Virtual Arrays up to the limit provided by the EMS memory manager (typically 16 or 32Mb).

          Therefore the EMS limit for the IDE is esentially unrelated to the EMS usage for your actual program. It is possible to disable EMS usage for the IDE to ensure your code has as much as possible during debugging (at the expense of compilation time in the IDE). You'd be hard pressed to use all the XMS/EMS up during a debugging session in the IDE

          PowerBASIC Support
          mailto:[email protected][email protected]</A>
          mailto:[email protected]


          • #6
            Thanks to all. So it' s clear that i was already running very close to the limit of IDE available memory with my all-in-one code, and splitting it into units just anticipated what was about to happen anyway when i should have added a bit of new code to it.

            Davide Vecchi
            [email protected]