Retro video games delivered to your door every month!
Click above to get retro games delivered to your door ever month!
X-Hacker.org- QWIKC20 & Multi-Level Virtual Windows - Norton Guide http://www.X-Hacker.org [<<Previous Entry] [^^Up^^] [Next Entry>>] [Menu] [About The Guide]

                M E M O R Y   A L L O C A T I O N

  This section covers the memory requirements for static data in the data
  segment and dynamic data in the heap.  This will give you the figures on
  how to calculate the memory needed for your program.


  GLOBAL MEMORY

  Global Memory - WNDWC is very frugal with global data.  Here is the
  breakdown on the fixed amount of data required:

    Variables                       Bytes
    ------------------------------- -----
    Border array                      210
    Basic windows                     142
    Additional for virtual windows     69
    Additional for multi-page video     4
                                    -----
    Fixed allocation                  425

  The additional data space for virtual windows and multi-page video, if not
  used, can be excluded by undefining the macros.  This is the allocation for
  MAXWINDOW=0.  For each additional window structure, add 52 bytes.  So, for
  MAXWINDOW=10, the allocation would be (52*10)+425=945 bytes.


  DYNAMIC MEMORY

  Dynamic Variables - To alleviate using global data, dynamic variables are
  used for permanent and temporary use.  The allocation for virtual screen
  records and video page records are permanent throughout the program.  Many
  other procedures such as movewindow temporarily use the heap to perform
  operations.

  Permanent Variables - If the macros have been defined, the following
  allocation can be calculated:

    Variables       Bytes
    --------------- -------------------------------
    virtualstat     52 per virtual window
    pagestat        (sizeof(pagestat_t)) per video page
    Virtual screen  virtualsize

  Virtual screens are kept in memory until removewindow is called.

  Temporary Variables - For functions that temporarily use the heap, the size
  of allocation is listed along with each function in section 2 above.
  Generally, you should allow about the same size as 3 CRT screens of
  available heap for those functions.  For a video mode with 25 rows and 80
  columns, this is (80*25*2)*3=12000 bytes, in addition to the random
  allocation.

  Random Allocation - Because of the nature of random access to windows and
  underlays, the program uses farmalloc and farfree.  This means that there
  are going to be gaps of free memory in the heap.  To account for this, you
  should more than double the amount of data expected for underlays and
  virtual screens.  It is up to you to judge just how much of the heap is
  going to be truly random.  In the case of simple serial-access to windows,
  the heap will be contiguous and doubling of the heap is unnecessary.


  CODE SIZE

  Code Size - WNDWC is also very frugal with code.  Here is the breakdown for
  code usage in the Small model (this may vary slightly):

    Code Description                Bytes
    ------------------------------- -----
    Basic windows                    9385
    Additional for virtual windows    742
    Additional for multi-page video  4049
                                    -----
    Total code                      14176

  Of course the linker will optimize the code leaving out unused functions.
  But this gives you a good idea of how small the code really is!


Online resources provided by: http://www.X-Hacker.org --- NG 2 HTML conversion by Dave Pearson