home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / c / 20101 < prev    next >
Encoding:
Text File  |  1993-01-23  |  4.0 KB  |  100 lines
  1. Path: sparky!uunet!noc.near.net!bigboote.WPI.EDU!nntp!tomster
  2. From: tomster@bigwpi.WPI.EDU (Thomas Richard Dibble)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: Need info for Turbo-C on storing lots of data within source.
  5. Date: 22 Jan 93 21:59:15
  6. Organization: ZikZak Corporation
  7. Lines: 87
  8. Message-ID: <TOMSTER.93Jan22215915@bigwpi.WPI.EDU>
  9. References: <1jo1ihINNkom@darkstar.UCSC.EDU>
  10. NNTP-Posting-Host: bigwpi.wpi.edu
  11. In-reply-to: noah@ucscb.UCSC.EDU's message of 22 Jan 93 05:43:45 GMT
  12.  
  13. >>>>> On 22 Jan 93 05:43:45 GMT, noah@ucscb.UCSC.EDU (Noah Spurrier) said:
  14.  
  15.  
  16.   NS> Keywords: Turbo C data
  17.  
  18.   NS> I have a program that stores a compressed picture of its title
  19.   NS> screen. The title screen is a graphic image. Also the program
  20.   NS> stores some documentation.  The program is fairly short. I do
  21.   NS> not want to store this data in separate files. What I did is use
  22.   NS> HUGE arrays with initialization to the big chunk of data. This
  23.   NS> works fine, but I notice that some people have had the program
  24.   NS> crash with something like the following error:
  25.  
  26.   NS> STACK OVERFLOW
  27.  
  28.   NS> or
  29.  
  30.   NS> STACK FULL, SYSTEM HALTED
  31.  
  32. Say no more.  First, you need to understand how Intel machines
  33. (running MS-DOS) handle their memory -- in 64k chunks.  No matter how
  34. much memory a DOS machine has, it can only have 64k segments of
  35. memory.  For more info, see any good basic or advanced C book and look
  36. up Memory Models in the index.  I will assume you can find this
  37. yourself and just give you the solution for this particular problem next.
  38.  
  39.   NS> Another person told me that these huge arrays were being stored
  40.   NS> in the stack segment and that because they just sit on the stack
  41.   NS> and never move this does not give my program much room to work
  42.   NS> with.
  43.  
  44.   NS> Would simply making the array STATIC help things?
  45.  
  46. (no.)
  47.  
  48.   NS> I also farmalloc a 64K buffer, but I don't think that should
  49.   NS> hurt the stack at all.
  50.  
  51.   NS> How can I get Turbo-C to store these variables in the data
  52.   NS> segment instead of the stack?
  53.  
  54. Okay, here we go:
  55.  
  56.   NS> Here is an example of how I declare and initialize one of my
  57.   NS> arrays: unsigned char far TITLE_DATA [(X_TITLE*Y_TITLE/4)] = {
  58.   NS> ....  ....};
  59.  
  60. Stop right there.  First off, the maximum Stack Length is 0xffff, of
  61. 64k.  is X_TITLE*YTITLE/4 > 64k?  If so, your program probably won't
  62. even get past the startup code.  Otherwise, I suspect that
  63. X_TITLE*Y_TITLE/4 is a pretty large number, right?  I also suspect
  64. that you have a few other variables in your program which (since they
  65. are declared like this, but at the beginning of functions) also must
  66. fit in the stack.  That's your problem.
  67.  
  68. The first solution you would try, if you really didn't want to think
  69. about it at all is (since you are in Turbo C) put the line:
  70.     extern unsigned _stacklen = 0xffff;
  71. at the top of your main file to set the stack as large as it can get
  72. and to switch into a memory model which can support this size of a
  73. stack.
  74.     But that won't work.  Or it won't work once you start adding
  75. new functions (and therefore, variables) on top of your basic program.
  76.  
  77.     What you want to do is just put a pointer to that humungous
  78. array on the stack.  This is done by putting the line:
  79.     unsigned char far *TITLE_DATA;
  80. in the global var's section of your file.  Then, in your main or in a
  81. function you call before using TITLE_DATA, put the line:
  82.     TITLE_DATA = (unsigned char far *)calloc(X_.../4,sizeof(char));
  83. If X_TITLE*Y_TITLE/4 is greater than 64k, you will have to split this
  84. up into 64k chunks (say, two chunks of X_TITLE*Y_TITLE/8, etc).  THEN
  85. write data to the memory locations you just alloc'd.  Remember to free
  86. TITLE_DATA before you exit();
  87.  
  88.   NS> Thanks for even bothering to read this damn thing!
  89.  
  90.   NS> noah@ucscb.ucsc.edu
  91.  
  92.         ---- tomster@wpi.wpi.edu
  93.  
  94. --
  95. /****************************************************************************\
  96. | "I sometimes used to try to catch her, :    FROM:   tomster@wpi.wpi.edu  |
  97. | but never even caught her name."     :    TO:    who(m)ever reads it  |
  98. |    ---- the cure             :    CC:    programming language |
  99. \vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv/
  100.