20-June-94  PWBFIX Part II.

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:

        PWBFIX2.TXT     - this file
        MI33.COM/ASM    - not so much a fix, but a convenience
        CLNPWB.EXE/BAS  - fixes PWB problem with Library template (#1)
        DBGPWB.EXE/BAS  - fixes PWB dup-project files problem (#2)

-----------
Problem #1:

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



-----------
Problem #2:

Another PIA with PWB is that when you change anything in a project, such
as BUILD mode, compiler/linker/whatever switches to use, and so on, PWB
has a bad habit of duplicating the *.MAK info for the first file of the
project.  In other words, it'll compile (or assemble) the first file entry
of the project twice (and then again for each to you edit the project).
while the actual .OBJ isn't processed twice, the source module is always
re-processed.  Fixing the problem can take even longer than just letting
the thing compile twice!  But sometimes the thing can get real out of hand
and just become the PIA that it really is.  Since I often change BUILD mode,
I wrote DBGPWB to take care of this without using PWB.

The included DBGPWB.EXE, like CLNPWB.EXE, scans the *.MAK files in the
specified directory, and also the *.STS, and converts them to either DEBUG
mode or RELEASE mode versions.  Sure, you can do this in PWB with a simple
click, but on the update by PWB, it dups the first entry (and dups each time
you change the project).  As with CLNPWB.EXE, close all projects before
running it (PWB caches open project info in memory).  DBGPWB.EXE requires
either a /0 to set all projects to RELEASE mode, or /1 for DEBUG mode. An
optional directory can be added after the /x switch.  For example, from
the command line:

        C>dbgpwb /1 k:\asm\r2

This scans all *.MAK and *.STS files in K:\ASM\R2\ and alters the appropriate
line in each so that it reflects the mode you want. See the source for details.

On the dup problem, if it happens, there's really only one way to fix it
once it happens (other than going in by hand and removing all the dups).
This is the procedure:

 1) OPEN Project
 2) EDIT Project
 3) CLEAR List
 4) SAVE List

At this point, you just saved an empty list.  This removes not just the
dups in the project file, but all files.  After the SAVE, you're back at
PWB, so

 5) EDIT Project (again)
 6) ADD All

Add All means to add all *.ext in the project's directory.  If you have a
separate directory for each project, similar to that described in Problem #1,
this is easy. If not, manually add each project file.

 7) SAVE List

At this point, the project MAK file is in pristine shape.  If you need to
switch DEBUG/RELEASE mode, first close the project, then run DBGPWB.EXE
with either /0 or /1.


-------------------------
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

CV 4.10 is better than 4.01 but if you use it with older compilers/assemblers,
you need to use the new CVPACK on it (CV 4.10 comes with VC++10/15).  You
cannot use the LINK.EXE that comes with VC since it won't sync the source
file with your debug code (properly).  Anyway, if you plan on using 4.10
you can get rid of 4.01, but replace CVPACK.EXE with the new one (LINK.EXE
5.31.009 will call CVPACK so all it peachy).

MASM 6.11 includes PWB 2.1.49 (as did 6.1) and CV 4.01.  MSC7 also
included both those.  Neither VC1.0 nor VC1.5 include PWB, but they
both include CV 4.10.  PWB is a very fine IDE for DOS, and if it
doesn't do what you need it to do, you can extended it so that it
does (so it's claimed).  You can do this by writing extensions in
.C or .ASM, or by simply modifying the templates available for a
project.

If anyone knows if MS is still providing ready-made extensions (*.MXT)
for PWB for its newer compilers, I'd especially like to here from you.


--------------------------------------------------------------
Additional notes on crashing PWB and how to avoid the obvious:

In case I didn't mention it above (the first writing was in November 1993)
a sure-fire way to crash PWB is to use the mouse to drop down a menu
from the menu bar while PWB is busy doing something on disk.  For example,
if you tell PWB to save a file (for instance) and then move to drop down
the, say, RUN menu while that save task is going on (so that as soon as
the save is completed the menu drops), then chances are pretty good that
you will have a PWB crash in the next couple seconds, or at least when
you next try to shell (or run a compile, etc.).

The error from this is a VMM error, memory corrupt, cannot load COMMAND.COM
(on separate lines and paraphrased).  Since PWB seems to always access the
disk on a menu drop (VMM'ing something), it could be that doing a menu drop
as the first thing when PWB is already doing disk work, then it crashes --
let it have a second or two BEFORE dropping the menu (don't have to do
anything else, just do nothing for a second or two), then it runs fine.

Anyway, just an observation (and I can't remember the last time I crashed
PWB; I can only guess that it's crashed two or three times the last
several months -- and I use it every day).


----------------------------
Comments can be directed to:

Cornel Huth
6402 Ingram Rd
SAN ANTONIO TX 78238-2915
USA

Internet: cornel.huth@LChance.sa.tx.us  -or-  cornel@ephsa.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, WSS, and others; and other one-of-a-kind type
stuff, like this.  Latest-and-greatest versions always at the BBS.

Files to look for:

BULLET
Filename: BLTC*.ZIP and BLTQ*.ZIP
B-tree/DBF file/database toolkit for DOS compilers (most including C, C++,
QuickBASIC/BASIC7/VBDOS).

BULLET for Windows
Filename: BLTW*.ZIP
B-tree/DBF file/database toolkit for Windows (coming real soon).

RUCKUS
Filename: RUKC*.ZIP and RUKQ*.ZIP
Soundcard toolkit for DOS compilers (most including C, C++,
QuickBASIC/BASIC7/VBDOS) supporting many cards such as Sound Blasters, PAS-16,
WSS-types, Roland Sound Canvas, MT-32; MIDI and Vox/Wav/Trak, and much more.

LP
Filename: LP261.ZIP
Linear programming optimizer including integer and mixed-integer solutions.
Handles 1000s of constraints/variables, or use virtual memory for even more.
;<EOF>
