home *** CD-ROM | disk | FTP | other *** search
/ Media Share 9 / MEDIASHARE_09.ISO / progmisc / pwbfix.zip / PWBFIX.TXT < prev    next >
Text File  |  1994-02-11  |  9KB  |  174 lines
  1. This package is a fix for some common PWB problems. Specifically applicable
  2. to PWB 2.1.49 (included with C7, MASM 6.1, and MASM 6.11).
  3.  
  4. Files included are:
  5.  
  6.         PWBFIX.TXT      - this file
  7.         MI33.COM/ASM    - not so much a fix, but a convenience
  8.         CLNPWB.EXE/BAS  - fixes PWB problem with Library template
  9.  
  10. The big problem with PWB when using the Library template is that one part
  11. of the template is needed during the initial dependencies test, but then
  12. that same part causes PWB to fail to recognize the makefile as a PWB
  13. makefile. The Library template uses this line (one line, split here):
  14.  
  15.     build: release command lrf_lib "$(LRF) @<<$(PROJ).lrf\n-+$
  16.            (?: = &^\n-+)\n$(LIBFLAGS_G)\n$(LIBFLAGS_R);\n<<\n#$(OBJS)"
  17.  
  18. The <<\n#$(OBJS) is what causes the problem in the resultant makefile. It
  19. cannot be removed from this template because doing so causes PWB to not be
  20. able to identify any of the modules to be included into the project (from
  21. the Edit Project dialog). However, what can be done is the actual makefile
  22. can be altered so that the #$(OBJS) is not included (or actually, simply
  23. removed by overwriting with spaces). The above template generates the
  24. following in the projects makefile (*.MAK):
  25.  
  26.  
  27.     OPL\O\$(PROJ).lib : $(OBJS)
  28.     !IF $(DEBUG)
  29.             $(LRF) @<<OPL\O\$(PROJ).lrf
  30.     -+$(?: = &^
  31.     -+)
  32.     $(LIBFLAGS_G)
  33.     $(LIBFLAGS_D);
  34.     <<
  35.     #$(OBJS)
  36.  
  37. When PWB next loads this portion of the makefile, it stops when it reads the
  38. #$(OBJS) and says that this is not a PWB-makefile and prompts if you want to
  39. load it in as a non-PWB makefile. One great asset of PWB is that it manages
  40. projects for you, so switching to a non-PWB makefile means you will have to do
  41. all the work in managing this project if you choose to load it that way. The
  42. best thing to do is to answer no and run the CLNPWB.EXE file on it. This
  43. program overwrites #$(OBJS) with spaces, allowing PWB to recognize the file
  44. as a PWB one.
  45.  
  46. Problems? Wouldn't you know there'd be one. It seems that PWB only goes to
  47. disk to get a project makefile (*.MAK, where the #$(OBJS) is/was) when it
  48. hasn't already loaded it during the session. In other words, it caches the
  49. makefile. This means that you cannot clean a makefile once it has already
  50. been loaded (you can, but it won't have any effect during the session).
  51. The best thing to do, and you will get into a routine, is to simply run
  52. CLNPWB as you start up PWB. If the fix fails to bring PWB around (if it has
  53. already loaded it), simply exit and restart, being sure not to load the
  54. project makefile until you first run CLNPWB.EXE. I don't know why this bug
  55. is still around. It's pretty bad (without this work-around).
  56.  
  57. To facilitate CLNPWB, I recommend the following directory structure:
  58.  
  59.         \Prg
  60.             \OtherProjects\
  61.             \CurrProject\
  62.                         \LibPrj1\
  63.                                 \O     <-build objects to O directory
  64.                                  LP1src1.asm
  65.                                  LP1src2.asm
  66.                                  LP1etc.
  67.                         \LibPrj2\
  68.                                 \O
  69.                                  LP2src1.asm
  70.                           :
  71.                         \LibPrjN\
  72.                                 \O
  73.                                  LPNsrc1.asm
  74.  
  75.                         LibPrj1.MAK
  76.                         LibPrj1.STS
  77.                         LibPrj2.MAK
  78.                         LibPrj2.STS
  79.                         LibPrjN.MAK
  80.                         LibPrjN.STS
  81.  
  82. The idea here is to have all your project make and state files in
  83. a single directory. This makes it easier to keep track of things (for
  84. me it does) and also lets you run a single instance of CLNPWB.EXE
  85. (on the current directory or one you specify). This is easy to setup
  86. in PWB.
  87.  
  88. To have CLNPWB.EXE added to your RUN menu, you can directly add this line
  89. to your TOOLS.INI file, in the main section. You can also simply add it
  90. yourself from PWB by doing so from the RUN menu setup in PWB. You should
  91. edit the directories to suit your setup, if you choose to simply add this.
  92.    
  93. user: "C~lean *.MAK",e:\bin\bin\clnpwb.exe,"f:\prg\asm\r2",,,"Remove #$(OBJS)  \
  94.  from Library MAKs. May need to reload PWB.",n,y,n,3
  95.  
  96.  
  97. Other Interesting Things:
  98.  
  99. I've had people ask me how I can run PWB 200+ hours at a time between crashes.
  100. Well, there's a problem with PWB in that once it crashes, it will want to
  101. keep crashing (as in almost immediately, or very soon after the initial).
  102. While this doesn't happen for each crash, some crashes do cause PWB to
  103. "remember" a bogus state and, hence, it keeps playing dirty. The solution,
  104. I've found, is to delete the offending *.STS and *.MAK files. For example,
  105. if PROJONE keeps crashing PWB, take a good inventory of the project so you
  106. can recreate it with minimum hassle (things like memory model, files in the
  107. project, and so on -- if you use the structure I diagrammed above, this
  108. isn't very difficult), then delete PROJONE.MAK and PROJONE.STS (both). Then
  109. simply recreate the project using the various PWB menu options. This almost
  110. always straightens PWB out (these are both text files, so it beats me what
  111. the real problem is). As a very last resort, you can also delete CURRENT.STS.
  112. HOWEVER, CURRENT.STS contains the state of all your tools (CV, for instance),
  113. so you will want to make a backup of the file, if only for reference. This
  114. is, of course, if you make use of a central CURRENT.STS (I do).
  115.  
  116. As for things that cause PWB to crash. I've found that its VMM tends to get
  117. real flakey when its menu drop boxes are quickly moved around. While its
  118. unlikely the menu boxes themselves are the culprit, the accessing of the
  119. menu boxes always results in disk access (almost always). That's also one
  120. thing I ritually start a session with: I move the mouse across all the menu
  121. items. Anyway, just about all crashes I can recall (I don't have many any
  122. more, and have never lost _any_ data -- PWB always saves before it comes
  123. back with a VMM error) occured after making adjusts to the project, many
  124. adjustments at a time. There's a relationship in there somewhere. Find it
  125. and collect the prize!
  126.  
  127. Also, I've found that you want to leave PWB 2048K to work with. This is
  128. the default (I suppose if you have the memory). If you need to change it,
  129. just keep that in mind. I did have a problem early on when I set it to
  130. a lower value. It may have been a coincidence.
  131.  
  132.         keepmem: 2048   ;this is part of TOOLS.INI
  133.  
  134. That's about it. PWB really is a pretty good IDE -- just need to stroke it
  135. every now and then to keep it happy.
  136.  
  137. One last thing: CV. CV 4.01 (C7, MASM 6.1x) has a problem in that it
  138. corrupts the high word of 32-bit registers (no is this a problem or what!).
  139. It also doesn't take advantage of the 386+ debugging features (4.10 does
  140. make use of the debug registers, but nothing more). As a great add-on tool
  141. to CV I recommend CV/ICEing, from Periscope (written by Vernon Brooks). It
  142. integrates directly into CV, extending the CV command set (e.g., ZL, ZR, ZM,
  143. and so on). It provides 28 different breakpoints covering everything from the
  144. debug registers, to I/O port trapping, to page-fault memory breakpoints (o),
  145. interrupt breakpoints, and it fixes the 32-bit register corruption bug in
  146. CV 4.0x. While you can find most of these features in TD (TDH386), TD cannot
  147. run with a memory manager installed (least my TD 2.0 can't) and it sure won't
  148. handle CV debugging info (not 4.x anyway). CV/ICEing _requires_ 386MAX. This
  149. has worked out perfectly for me. Price is $129 list ($99 now, I believe), and
  150. available at Programmer's Connection for $75. Highly recommended if you use
  151. CV 4.0x or 4.10.
  152.  
  153. Comments can be directed to:
  154.  
  155. Cornel Huth
  156. 6402 Ingram Rd
  157. SAN ANTONIO TX 78238-2915
  158. U.S.A.
  159.  
  160. Internet: cornel.huth@LChance.sa.tx.us
  161.  Fidonet: 1:387/800.8
  162.   My BBS: 40th Floor
  163.           1(210)684-8065. V.32bis (300-14.4k BPS)
  164.           Hours: Monday through Friday, 5pm to 9am next morning
  165.                  Weekend hours are 1pm to 9am next morning.
  166.                  All times USA Central Time [-0600 winter, -0500 summer]
  167.  
  168.           BBS carries several high-performance shareware toolkits for
  169.           things such as network/multi-user btree/DBF database manager;
  170.           soundcard tools for SB, SB-Pro, SB-16, GUS, PAS-16, Aria, and
  171.           others; and other one-of-a-kind type stuff.
  172.  
  173. <EOF>
  174.