home *** CD-ROM | disk | FTP | other *** search
/ ftp.wwiv.com / ftp.wwiv.com.zip / ftp.wwiv.com / pub / HATCH / WWIVNEWS.ZIP / 9209_2.NWS < prev    next >
Text File  |  1992-09-29  |  21KB  |  420 lines
  1.  
  2. ───────────────┬─────────────────────────────────────────────┬───────────────
  3.                │            Tackling DGROUP with             │
  4.                │         External String Management          │
  5.                │              by Elrond (8@4)                │
  6.                └─────────────────────────────────────────────┘
  7.  
  8. DGROUP: 
  9.  
  10. The word alone is enough to send shivers down the spines of even the most
  11. experienced WWIV modders. To them, DGROUP conjures up living nightmares of 
  12. installing complex modifications, only to wind up having to pull out their 
  13. favorite (and largest) mods because they took up too much DGROUP space. For 
  14. others, the less initiated, it brings up a several questions: For instance,
  15. what the heck is it, and how come everyone is always so caught up in it? 
  16. And above all, how can I get rid of the problems it causes?
  17.  
  18. Let's start from the beginning. Assuming that the vast majority of people
  19. out there really do not have even the slightest knowledge of Pascal, C, or
  20. Assembly, I will try and keep things simple. A program has several different
  21. segments of memory that are assigned to it. One of these segments is called
  22. the DGROUP, which is a group encompassing several memory segments that can be
  23. referred to as a single group. DGROUP is short for the (D)ATA GROUP, and it
  24. is where certain parts of the current (EXEC'ing) program are stored. I will
  25. not get into the sub-segments within the DGROUP, because it is enough to say
  26. that it holds parts of the program, which of course for us is WWIV.
  27.  
  28. One of the major parts of any program's data is text. When a program is
  29. compiled, it is translated into the binary language (machine language) that
  30. your CPU can understand. Most of what goes into a program is actually ignored 
  31. or simplified when a program is compiled, for the CPU has no use for this extra
  32. information. We only include it in our programs in order to increase the
  33. readability of the code. Addition, subtraction, variables, and the other common
  34. parts of your program are translated into their simple equivalent instructions
  35. that your CPU can understand. However, the text, or strings in your program
  36. cannot be translated to some simpler equivalent. If they were, then you 
  37. obviously would not be able to read them. So, when a program is compiled, any
  38. text that gets sent to any device (be it the CRT, COM port, LPT port, whatever)
  39. is kept in its original state.
  40.  
  41. If you have lots of text in your program (and BBS systems have a lot just by
  42. their very nature) then the DGROUP segment starts to get filled up rather
  43. quickly. Each character in a string takes up at least one byte of memory, so
  44. one thousand characters will take up about a kilobyte. Wayne was smart(?)
  45. enough to compile his program in a memory model that only allocates 64
  46. kilobytes for the DGROUP segment. So, when you fill that up, your finished. 
  47. No more modding. You get a compiler error, and so you are up against a brick
  48. wall. Right?
  49.  
  50. To many sysops, this is exactly what they thought. If they did understand
  51. DGROUP, at least slightly, they would go rip out a big mod, like a time bank
  52. or a fancy file listing system. Then they could compile again, but they would 
  53. be stuck without being able to install any more of the neat mods that come out 
  54. every day. I can remember myself running around all the different support 
  55. boards at the beginning of last summer looking for *SOMETHING* that would 
  56. save me from that infernal compile message. I installed lots of little, very 
  57. inefficient fixes - the DGROUP error went away for a mod or two, but then it 
  58. was back to plague me again. 
  59.  
  60. Then one day Tolkien released ESM, and thus changed the way that people thought
  61. about DGROUP altogether.
  62.  
  63. ESM, or External Strings Manager, is a program to help you cut down on the
  64. amount of DGROUP that WWIV takes up. The logic behind this is that if you can 
  65. get the strings out of the program, and into an external file, then they will 
  66. not have to be loaded every time the program is run. Whoever first came up with
  67. this idea (it was not an original) is someone we owe a lot to. With the strings
  68. out of the main program and in an external file, we virtually eliminate as much
  69. DGROUP space as we choose to - it all depends on how many strings we remove.
  70.  
  71. ESM is very efficient (and FAST!!) at retrieving strings from the external 
  72. file. Even on an 8 mhz. 286, there is hardly a noticeable delay while the call
  73. to get a string from the external file is executed. Plus, the ESM editor (for
  74. editing strings in your external strings file) makes it easy to change what a
  75. string says, and you don't even have to re-compile your BBS when you do it.
  76.  
  77. There is only one major drawback with ESM, and that is it takes a long time to
  78. manually remove the strings from your source code and paste them into a strings
  79. file. This can take literally hours, if not DAYS, and it is a very slow and 
  80. painstaking process. You cannot afford to screw up a string, or you'll wind up
  81. printing out the wrong one. That can look very funny, but is still a bit
  82. embarrassing. With the recent upgrades to ESM, however, this task can be done 
  83. automatically with a special utility program (available only to registered ESM
  84. users). Using this utility, you can generate a strings file by letting the 
  85. program go through and pull out the strings for you. Therefore, it is a very
  86. fast and effortless process. 
  87.  
  88. If you do not plan on registering ESM, there is an alternative. I have written
  89. a program which I call ASR, or Automatic Strings Remover, which does virtually
  90. the same thing. Best of all, it is free, like all the software that I write
  91. (and it looks neater, too, but that's just an opinion). 
  92.  
  93. A note on the side: There was a mod released some months ago onto the modnet
  94. which will allow WWIV to compile in a much larger memory model, and thus allow
  95. 1024 k of DGROUP. This will obviously be much more than you will probably ever
  96. use. But if you want my advice, I wouldn't install it. Here's why: It is way 
  97. too unstandard. Installing this mod not only stops you from using the wonderful
  98. MAKE interface, but it also forces you to rewrite most of the routines in some
  99. of the major C files. Sure, the replacements are included, but they are very 
  100. confusing, probably (no guarantees) not very well coded, and that much more 
  101. difficult to deal with than the ESM/ASR combination. There also is the chance
  102. that other mods will conflict or not work at all with this one installed. All 
  103. told, I suggest that you steer clear of it. If Wayne himself ever takes it upon
  104. himself to rewrite WWIV to support this memory model, then you we can all stop 
  105. worrying about DGROUP, but that's just it - he hasn't.
  106.  
  107. With ESM and its support programs, or with ESM and ASR, you can very easily 
  108. eliminate those horrible DGROUP errors and get back to the business at hand,
  109. which is adding more mods, of course. Regardless of how good a modder you may
  110. be, sooner or later you will reach the limit of the DGROUP segment. Go grab ESM
  111. and ASR, install them, and then basically forget them. Then, go treat yourself
  112. by installing the biggest, most DGROUP consuming mod that you can find on the
  113. Modnet which you couldn't dare install before. Good luck with your modding!
  114.  
  115. ──────────────────────────────────────────────────────────────────────────────
  116.  
  117. Where to obtain ESM and ASR:
  118.  
  119. ESM, External Strings Manager
  120. Current version     : 1.04 (shareware), 2.00 (registered)
  121. Author              : Tolkien
  122. BBS name            : The Fellowship
  123. WWIVnet             : @3456
  124. Phone number        : (314) 664-5777
  125. Auto Validation     : YES
  126. WWIV support board  : YES
  127. High speed modem    : v32, v32bis, HST (14,400 and lower)
  128.  
  129. ASR, Automatic Strings Remover
  130. Current version     : 1.50 (freeware)
  131. Author              : Ellrond
  132. BBS name            : Silicon Valley
  133. WWIVnet             : @9987
  134. Phone number        : (919) 765-8640
  135. WWIV support board  : NO
  136. Auto Validation     : YES
  137. High speed modem    : v32, v32bis, HST (14,400 and lower)
  138.  
  139. ───────────────┬─────────────────────────────────────────────┬───────────────
  140.                │          Filo's Mod of the Month            │
  141.                │              by Filo (1@5252)               │
  142.                └─────────────────────────────────────────────┘
  143.  
  144. The Mod-of-The-Month Selection represents my choice of what appears to be a 
  145. useful, practical mod to WWIV. It does not mean it is the best mod posted or
  146. even that it works as I may not have tested it. Given the limitations of this
  147. media, uuencoded mods are NOT eligible for selection as mod-of-the-month.
  148.  
  149. This month's offerings contained three mods that really appealed to me. All
  150. three involved features that are already in NET32 but which are definitely
  151. needed in NET31 and v4.21 usage: a NETNAME in the name of the Sub, a NETNAME
  152. in E-mail response to user, and a force specific network callouts. The latter
  153. is the one that I have chosen to put here.
  154.  
  155. This is another of Darrel Mobley's fine mods:
  156.  
  157. ┌──────────────────────────────────────────────────────────────────────┐
  158. │ Mod Name:    :  DDM-0002.MOD          Author :  The Primerican #1    │
  159. │ Difficulty   :  Moderate              Network:  WWIVnet @9402        │
  160. │ WWIV Version :  4.21a                 Files  :  NETSUP.C             │
  161. │                                                                      │
  162. │ Description  :  This mod allows you to force a callout to other      │
  163. │                 network node numbers than your main network.  4.21a  │
  164. │  (9/12/92)      does not check to see if you use the same node #     │
  165. │ CALLOUT4.21B    in more than one network during Forced Callout "/".  │
  166. └──────────────────────────────────────────────────────────────────────┘
  167.                                                                       
  168. What this does:
  169.  
  170. I noticed from my WFC screen in the net pending list that if I had two nodes
  171. sharing the same number but were in different networks, the "/" Force Callout
  172. command would always force the callout to the node in the primary network.
  173.  
  174. This is the second version of the mod. This will ONLY prompt you IF there are
  175. two nodes sharing the same node number within multiple networks on your system.
  176. The first mod asked the network to force from on each callout attempt, this one
  177. only asks for the network if it finds more than one network sharing the same
  178. node number.
  179.  
  180. On with the mod.
  181.  
  182. Disclaimer: Why bother? You KNOW to back up your source! Grin.
  183.  
  184. Replace the entire void "force_callout(void)" with this void:
  185.  
  186. void force_callout(void)
  187. {
  188.   int i,i1,i2,i3,index,ok,sn,nn;
  189.   int nv,onxi,odci,abort;                                                   
  190.   float fl,fl1,fl2,ffl;
  191.   long l,l1;
  192.   char ch,s[81],s1[81];
  193.   char *ss,onx[20],*mmk;                                                    
  194.   struct time ti;
  195.   net_system_list_rec *csne;                                                
  196.  
  197.   time(&l);
  198.   nl();
  199.   prt(2,"Which system? ");
  200.   input(s,5);
  201.   sn=atoi(s);
  202.   abort=0;                                                                  
  203.   if (sn && (net_num_max>1)) {                                              
  204.     odc[0]=0;                                                               
  205.     odci=0;                                                                 
  206.     onx[0]='Q';                                                             
  207.     onx[1]=0;                                                               
  208.     onxi=1;                                                                 
  209.     nv=0;                                                                   
  210.     ss=malloc(net_num_max);                                                 
  211.     for (nn=0; nn<net_num_max; nn++) {
  212.       set_net_num(nn);
  213.       if (next_system(sn))                                                  
  214.         ss[nv++]=nn;                                                        
  215.     }
  216.     if (nv==1) {
  217.       set_net_num(ss[0]);
  218.     } else {
  219.       nl();
  220.       for (i=0; i<nv; i++) {
  221.         set_net_num(ss[i]);
  222.         csne=next_system(sn);
  223.         if (csne) {
  224.           if (i<9) {
  225.             onx[onxi++]=i+'1';
  226.             onx[onxi]=0;
  227.           } else {
  228.             odci=(i+1)/10;
  229.             odc[odci-1]=odci+'0';
  230.             odc[odci]=0;
  231.           }
  232.           npr("%d. %s (%s)\r\n",i+1,net_name,csne->name);
  233.         }
  234.       }
  235.       pl("Q. Quit");
  236.       nl();
  237.       prt(2,"Which network (number)? ");
  238.       if (nv<9) {
  239.         ch=onek(onx);
  240.         if (ch=='Q')
  241.           i=-1;
  242.         else
  243.           i=ch-'1';
  244.       } else {
  245.         mmk=mmkey(2);
  246.         if (*mmk=='Q')
  247.           i=-1;
  248.         else
  249.           i=atoi(mmk)-1;
  250.       }
  251.       if ((i>=0) && (i<nv)) {
  252.         set_net_num(ss[i]);
  253.       } else {
  254.         nl();
  255.         pl("Aborted.");
  256.         nl();
  257.         abort=1;
  258.       }
  259.     }
  260.   }
  261.  
  262.   if (!abort) {
  263.     if (!net_networks[net_num].con)
  264.       read_call_out_list();
  265.   
  266.   
  267.     i=-1;
  268.     for (i1=0; i1<net_networks[net_num].num_con; i1++) {
  269.       if (net_networks[net_num].con[i1].sysnum == sn) {
  270.         i=i1;
  271.         break;
  272.       }
  273.     }
  274.   
  275.     if (i!=-1) {
  276.       if (!net_networks[net_num].ncn)
  277.         read_contacts();
  278.        ok=ok_to_call(i);
  279.       i2=-1;
  280.       for (i1=0; i1<net_networks[net_num].num_ncn; i1++) {
  281.         if (net_networks[net_num].ncn[i1].systemnumber==sn) {
  282.           i2=i1;
  283.           break;
  284.         }
  285.       }
  286.       if (i2==-1)
  287.         ok=0;
  288.       else
  289.         if (!ok) {
  290.           nl();
  291.           prt(5,"Are you sure? ");
  292.           if (yn())
  293.             ok=1;
  294.         }
  295.       if (ok) {
  296.         if (net_networks[net_num].ncn[i2].bytes_waiting==0L)
  297.           if (!(net_networks[net_num].con[i].options & options_sendback))
  298.             ok=0;
  299.         if (ok) {
  300.           nl();
  301.           do_callout(sn);
  302.         }
  303.       }
  304.     }
  305.   } 
  306. }
  307.  
  308. Recompile and enjoy!
  309.  
  310. ───────────────┬─────────────────────────────────────────────┬───────────────
  311.                │             Dateline: @#$*()#!              │
  312.                │     Editor's Notes by Omega Man (1@5282)    │
  313.                └─────────────────────────────────────────────┘
  314.  
  315. Editor's nOTE: The past four months worth of weekends have been spent by yours
  316. truly on the monumental task of first upgrading @5282 to WWIV 4.21, and then
  317. scrapping everything when Wayne released 4.21a and starting over. This task
  318. included the monumental effort of evaluating over 750 WWIV mods with widely
  319. varying levels of "assured compatibilty." 
  320.  
  321. As one could expect, it damned near caused this issue of WWIVnews to be 
  322. replaced with a "Best Of" special issue I've got stashed away for such
  323. emergencies...
  324.  
  325. As of this writing I'm almost finished with the upgrading. Despite several 
  326. setbacks and several trips to my favorite place to kick back and think (which 
  327. also happens to be my favorite topless bar, incedentally), the following 
  328. commentary keeps burning in my thoughts every time I fire up MAKE.EXE.
  329.  
  330. Sympathize, identify, or villify. In any case, keep the above facts in your 
  331. mind as you read some of what's been running through mine...
  332.  
  333. ─────────────────────────────────────────────────────────────────────────────
  334.  
  335. Evolution and Change.
  336.  
  337. These are integral parts of the whole that we refer to as the "Computer 
  338. Revolution." In the history of Mankind no previous form of socio-technological 
  339. advancement has possessed such a propensity for consistent alteration and 
  340. improvement and seen it utilized to an equal degree. Unlike any other type of
  341. industrial or technological base, that which is produced and deemed "state of 
  342. the art" when first designed is usually well on its way to becoming outdated by
  343. the time it hits the open market. The degree of Evolution and Change in this
  344. area is indeed that great.
  345.  
  346. As a result, survivability within the computer industry now requires that each 
  347. new advancement be able to adapt readily to consistently evolving standards, 
  348. and those who design said advancements must in turn be able to not only meet 
  349. and even exceed these demands, but in essence predict future demands in well in
  350. advance of their actual implementation. 
  351.  
  352. To accomplish this, designers must not only be users of the products themselves
  353. but they must also be trailblazers as well. No longer is it simply enough to 
  354. blaze the trail and hope the users will follow; designers must be willing to 
  355. travel those trails already taken and determine the next best path to take
  356. without choosing one that will force users to halt in their tracks.
  357.  
  358. WWIV and all its various facets are no exception to these forces of Evolution 
  359. and Change. Witness the fact that the Turbo C version of WWIV has been upgraded
  360. 14 times in the near 5 years since Wayne's decision to abandon Turbo Pascal, 
  361. and that the WWIVnet executables themselves have been upgraded more than twice
  362. that number as well. This number of upgrades, while arguably far above current
  363. industry averages, reflect not only improved software flexibility and 
  364. functionality (not to mention bug fixes), but to accommodate the evolution of 
  365. Turbo C as well. 
  366.  
  367. With WWIV and WWIVnet evolving and changing at these rates, those who design 
  368. and test the literally thousands of modifications to the basic WWIV source code
  369. are pressed harder than ever to not only accommodate users by debugging their 
  370. mods thoroughly and providing instructions for seamless, efficient 
  371. installation, but to provide improvements and additions to stock WWIV features
  372. that may provide a permanent increase in versatility and user-friendliness.
  373.  
  374. This, in essence, is what truly motivates the WWIV modder in today's continuing
  375. Computer Revolution. The desire to produce something that not only improves 
  376. existing features of WWIV, but offers a new approach to a particular WWIV facet
  377. that isn't so radical that it scares people away from implementing it. This
  378. also, in essence, is the "catch" that any modder has to face. How modders
  379. should handle this catch is the focus of this editorial.
  380.  
  381. Innovation and creativity is fine and dandy, but make damn sure that you've 
  382. made it clear exactly what you're trying to accomplish. Without a proper 
  383. approach to design and implementation, a mod that might be the best thing to 
  384. hit WWIV since Wayne added color to the TP3 version could very well be ignored 
  385. due to improper design, presentation, and implementation
  386.  
  387. In other words, modders, document your mods *properly*. Explain not only what 
  388. they do, but *why* they are in fact an improvement over stock code. If your mod
  389. is a radically different approach, go into details as to *what* is so different
  390. about your mod, and *why* your way of doing things is that much better. If 
  391. there are any "catches" to installing your mod, then make doubly certain that 
  392. you explain them in detail, and what should be done to prevent getting stung by
  393. them.
  394.  
  395. Carry on, modders! Blaze those trails to the future and blaze them well! We're
  396. right behind you, so make sure you don't set ablaze the collective rear ends of
  397. those who follow your path.
  398.  
  399. Including, of course, your own.
  400.  
  401. ┌───────────────────────────────────────────────────────────────────────────┐
  402. │                             Closing Credits                               │
  403. ├───────────────────────────────────────────────────────────────────────────┤
  404. │ WWIVnews is an independent newsletter published monthly as a service to   │
  405. │ the WWIV community of sysops and users. The opinions and reviews expressed│
  406. │ herein are the expressed views of the respective writers, and do not      │
  407. │ necessarily reflect those of the WWIVnews staff. Reproduction in whole or │
  408. │ in part is allowed provided proper credit is given. All rights reserved.  │
  409. ├───────────────────────────────────────────────────────────────────────────┤
  410. │ The distribution sites for WWIVnews are the Klingon Empire BBS (512-459-  │
  411. │ 1088), WWIVnet node @5282, and the WWIVnews Editorial Desk networked      │
  412. │ subboard, subtype 15282 host 5282. Information regarding article and      │
  413. │ editorial submissions, back issue requests, and the WWIVnews Writer's     │
  414. │ Guide, can be requested in e-mail from the WWIVnews editor, 1@5282.       │
  415. ├───────────────────────────────────────────────────────────────────────────┤
  416. │            WWIV and WWIVnet, copyright 1986,1990 by Wayne Bell            │
  417. │  Any product or company mentioned or reviewed herein are copyrighted of   │
  418. │  their respective owners, creators, and other corporate pseudoentities.   │
  419. └───────────────────────────────────────────────────────────────────────────┘
  420.