This package is a fix for some common PWB problems. Specifically applicable
to PWB 2.1.49 (included with C7, MASM 6.1, and MASM 6.11).

Files included are:

        PWBFIX.TXT      - this file
        MI33.COM/ASM    - not so much a fix, but a convenience
        CLNPWB.EXE/BAS  - fixes PWB problem with Library template

The big problem with PWB when using the Library template is that one part
of the template is needed during the initial dependencies test, but then
that same part causes PWB to fail to recognize the makefile as a PWB
makefile. The Library template uses this line (one line, split here):

    build: release command lrf_lib "$(LRF) @<<$(PROJ).lrf\n-+$
           (?: = &^\n-+)\n$(LIBFLAGS_G)\n$(LIBFLAGS_R);\n<<\n#$(OBJS)"

The <<\n#$(OBJS) is what causes the problem in the resultant makefile. It
cannot be removed from this template because doing so causes PWB to not be
able to identify any of the modules to be included into the project (from
the Edit Project dialog). However, what can be done is the actual makefile
can be altered so that the #$(OBJS) is not included (or actually, simply
removed by overwriting with spaces). The above template generates the
following in the projects makefile (*.MAK):


    OPL\O\$(PROJ).lib : $(OBJS)
    !IF $(DEBUG)
            $(LRF) @<<OPL\O\$(PROJ).lrf
    -+$(?: = &^
    -+)
    $(LIBFLAGS_G)
    $(LIBFLAGS_D);
    <<
    #$(OBJS)

When PWB next loads this portion of the makefile, it stops when it reads the
#$(OBJS) and says that this is not a PWB-makefile and prompts if you want to
load it in as a non-PWB makefile. One great asset of PWB is that it manages
projects for you, so switching to a non-PWB makefile means you will have to do
all the work in managing this project if you choose to load it that way. The
best thing to do is to answer no and run the CLNPWB.EXE file on it. This
program overwrites #$(OBJS) with spaces, allowing PWB to recognize the file
as a PWB one.

Problems? Wouldn't you know there'd be one. It seems that PWB only goes to
disk to get a project makefile (*.MAK, where the #$(OBJS) is/was) when it
hasn't already loaded it during the session. In other words, it caches the
makefile. This means that you cannot clean a makefile once it has already
been loaded (you can, but it won't have any effect during the session).
The best thing to do, and you will get into a routine, is to simply run
CLNPWB as you start up PWB. If the fix fails to bring PWB around (if it has
already loaded it), simply exit and restart, being sure not to load the
project makefile until you first run CLNPWB.EXE. I don't know why this bug
is still around. It's pretty bad (without this work-around).

To facilitate CLNPWB, I recommend the following directory structure:

        \Prg
            \OtherProjects\
            \CurrProject\
                        \LibPrj1\
                                \O     <-build objects to O directory
                                 LP1src1.asm
                                 LP1src2.asm
                                 LP1etc.
                        \LibPrj2\
                                \O
                                 LP2src1.asm
                          :
                        \LibPrjN\
                                \O
                                 LPNsrc1.asm

                        LibPrj1.MAK
                        LibPrj1.STS
                        LibPrj2.MAK
                        LibPrj2.STS
                        LibPrjN.MAK
                        LibPrjN.STS

The idea here is to have all your project make and state files in
a single directory. This makes it easier to keep track of things (for
me it does) and also lets you run a single instance of CLNPWB.EXE
(on the current directory or one you specify). This is easy to setup
in PWB.

To have CLNPWB.EXE added to your RUN menu, you can directly add this line
to your TOOLS.INI file, in the main section. You can also simply add it
yourself from PWB by doing so from the RUN menu setup in PWB. You should
edit the directories to suit your setup, if you choose to simply add this.
   
user: "C~lean *.MAK",e:\bin\bin\clnpwb.exe,"f:\prg\asm\r2",,,"Remove #$(OBJS)  \
 from Library MAKs. May need to reload PWB.",n,y,n,3


Other Interesting Things:

I've had people ask me how I can run PWB 200+ hours at a time between crashes.
Well, there's a problem with PWB in that once it crashes, it will want to
keep crashing (as in almost immediately, or very soon after the initial).
While this doesn't happen for each crash, some crashes do cause PWB to
"remember" a bogus state and, hence, it keeps playing dirty. The solution,
I've found, is to delete the offending *.STS and *.MAK files. For example,
if PROJONE keeps crashing PWB, take a good inventory of the project so you
can recreate it with minimum hassle (things like memory model, files in the
project, and so on -- if you use the structure I diagrammed above, this
isn't very difficult), then delete PROJONE.MAK and PROJONE.STS (both). Then
simply recreate the project using the various PWB menu options. This almost
always straightens PWB out (these are both text files, so it beats me what
the real problem is). As a very last resort, you can also delete CURRENT.STS.
HOWEVER, CURRENT.STS contains the state of all your tools (CV, for instance),
so you will want to make a backup of the file, if only for reference. This
is, of course, if you make use of a central CURRENT.STS (I do).

As for things that cause PWB to crash. I've found that its VMM tends to get
real flakey when its menu drop boxes are quickly moved around. While its
unlikely the menu boxes themselves are the culprit, the accessing of the
menu boxes always results in disk access (almost always). That's also one
thing I ritually start a session with: I move the mouse across all the menu
items. Anyway, just about all crashes I can recall (I don't have many any
more, and have never lost _any_ data -- PWB always saves before it comes
back with a VMM error) occured after making adjusts to the project, many
adjustments at a time. There's a relationship in there somewhere. Find it
and collect the prize!

Also, I've found that you want to leave PWB 2048K to work with. This is
the default (I suppose if you have the memory). If you need to change it,
just keep that in mind. I did have a problem early on when I set it to
a lower value. It may have been a coincidence.

        keepmem: 2048   ;this is part of TOOLS.INI

That's about it. PWB really is a pretty good IDE -- just need to stroke it
every now and then to keep it happy.

One last thing: CV. CV 4.01 (C7, MASM 6.1x) has a problem in that it
corrupts the high word of 32-bit registers (no is this a problem or what!).
It also doesn't take advantage of the 386+ debugging features (4.10 does
make use of the debug registers, but nothing more). As a great add-on tool
to CV I recommend CV/ICEing, from Periscope (written by Vernon Brooks). It
integrates directly into CV, extending the CV command set (e.g., ZL, ZR, ZM,
and so on). It provides 28 different breakpoints covering everything from the
debug registers, to I/O port trapping, to page-fault memory breakpoints (o),
interrupt breakpoints, and it fixes the 32-bit register corruption bug in
CV 4.0x. While you can find most of these features in TD (TDH386), TD cannot
run with a memory manager installed (least my TD 2.0 can't) and it sure won't
handle CV debugging info (not 4.x anyway). CV/ICEing _requires_ 386MAX. This
has worked out perfectly for me. Price is $129 list ($99 now, I believe), and
available at Programmer's Connection for $75. Highly recommended if you use
CV 4.0x or 4.10.

Comments can be directed to:

Cornel Huth
6402 Ingram Rd
SAN ANTONIO TX 78238-2915
U.S.A.

Internet: cornel.huth@LChance.sa.tx.us
 Fidonet: 1:387/800.8
  My BBS: 40th Floor
          1(210)684-8065. V.32bis (300-14.4k BPS)
          Hours: Monday through Friday, 5pm to 9am next morning
                 Weekend hours are 1pm to 9am next morning.
                 All times USA Central Time [-0600 winter, -0500 summer]

          BBS carries several high-performance shareware toolkits for
          things such as network/multi-user btree/DBF database manager;
          soundcard tools for SB, SB-Pro, SB-16, GUS, PAS-16, Aria, and
          others; and other one-of-a-kind type stuff.

<EOF>