How I got winSig+
to cough up
Sig had confiscated
<LYNX ALERT: This piece uses guillemets,
« and »,
which your installation may not render.>
A kbd file full of recurrences of a sequence like
JM,(,2,.,#,g,O,l,d,) is a mess. &[0-9/A-Z]
ldpms can prevent that--custom.kbd &O instead--but
each requires a file loaded to permanent memory.
In xyWrite 3, &ldpms are effectively workarounds
for Help file type 5 frames, which use less memory,
can do the same things, when assigned a $[0-9/A-Z]
designation also keep kbd files neat--custom.kbd $O--but
when used without user interaction cause an annoying
flash. Windows U2 type 5 frames don't flash, but
Signature+ releases don't implement U2 $[0-9/A-Z] frames.
Thus, for custom.kbd tidiness recurrent sequences
require sacrificing chunks of permanent memory to
load otherwise unnecessary &ldpm files.
Or do they? Without apparent ill effect, my NB.INI
and XWSTART.INT load MY_NB.DLG and MY_XW.DLG, copies
of *.DLG I edited to turn on designated U2 $[0-9/A-Z]
frames, instead of NB.DLG and XW.DLG. Because of the
xyW3 frame 5 flash, !xyWise and !OutBack use several
&ldpms and >99 variables that in xyWin/nbWin
are $[X] frames. I use two >99 vars in
xyWin/nbWin--tiny databases for va$s Sig+ lack--and
no &ldpms. Nor do I allow nbWin to load
&ldpms--i.e., my installations load no *.AUX, but
still load the NB overlay (more on this presently).
Understand that I'm simply sharing what I've done.
I certainly do not suggest, emphatically do not
recommend, that you do this. I am after all a
xyWin/nbWin novice and one doesn't edit these files
or change loading procedures casually. Further:
Unless one invests
more effort than I'm willing to, the only way I know
to edit NB.DLG, a crucial file, without destroying
it destroys menu access to the character
"i circumflex sm-794."
That character's code contains a hex1A--a dread
midfile dos EOF. Before opening a COPY
of NB.DLG the first time (and only the first time)
one must change the way Signature+ normally handle
hex1A: i.e., must execute a d 1A=1 command,
and after storing the COPY--which
destroys i circumflex sm-794 access--must execute
a d 1A=0 command.
XW.DLG has no comparable gotcha.
Setting up U2 $[0-9/A-Z] is pointless for a frame
that's assigned once to one key, but I use $O and
a few other frames often in kbd macros. Enabling U2
$[X] couldn't be simpler. In each COPY of *.DLG I made
a frame for each $[X] I wanted to use directing *.DLG
to load a corresponding frame in my U2 file, e.g.:
That's it. That permits U2 frame names like
[ascii 2]JM (2.$I)«ex»[ascii 2]
[ascii 2]JM (2.$V)«ex»[ascii 2]
[ascii 2]JM (2.$O)«ex»[ascii 2]
and in custom.kbd sequences like:
Oh, well. Kbd macros aren't pretty. But consider the
for xyWin/nbWin port BackTag macro that uses U2 frames:
BX,s,e,b, , ,<,+,*,+,Q2BX,s,e,b, , ,<,Q2CRXDDWCLXDDF
BX,s,e,b, , ,<,Q2CRDFBX,s,e, , ,<,Q2SI,/,CPXDCI,>,RCRCDF
BX,s,e, , ,+,*,+,Q2BDBDBDDFRD$GGT
Obviously, all U2 $[0-9/A-Z] code (irrelevant here)
could simply be in the *.DLG $[0-9/A-Z] frames instead
of instructions to load U2 $[X]s, but this is about
regaining a xyWrite instrument Signature+ took away,
not about rewriting *.DLG.
BX,s,e,b, , ,<,+,*,+,Q2BX,s,e,b, , ,<,Q2CRXDDWCLXDDF
BX,s,e,b, , ,<,Q2CRDFBX,s,e, , ,<,Q2SI,/,CPXDCI,>,RCRCDF
BX,s,e, , ,+,*,+,Q2BDBDBDDFRDJM,(,2,.,#,g,O,l,d,),GT
- After reading this, Signature+ xpl guru Carl Distefano
commented that using this frame in *.DLG
Q2 [ascii 2]
- enables any func $[X] definition
in *.U2. I haven't tried it.
Coding Signature+ U2s with xyWrite 3
I zapped MY_NB.DLG's midfile eof with xyWin because I find,
alas, that !xyWise FizFix1A can't process files that big.
Otherwise, I use xyWrite 3 for all Sig+ U2 programming.
That includes editing copies of *.DLG.
Files nearly 2.5 times as large as *.DLG (the largest
I've had occasion to edit) don't faze my xyW3 installations.
But anyone who fails to conserve xyW3 memory rigorously
should think twice about editing big files.
A xyW3 ex-user devoted to an xpl-heavy v3 Help
file describes severe xyW3 instability while
editing files less than half the size of *.DLG.
My installations exhibit none of the
weirdnesses v3 Help xpl advocates report.
Loaded, my Help file is 9600 bytes. Except when
printing hard copy I load a <1500-byte screen
driver, not a print driver. At this moment, func
ME under win95 reports that those files occupy 1mb
of memory each. SPELL + 1522-byte MY.SP3 use 4mb.
429mb are free.
Sig+ haven't the courtesy to respect the
programmer's choice of xpl case. When I was
trying (failing) to adjust to xyDos4, Sig+ all-caps
xpl drove me to such distraction I wrote
a kbd macro, now a !xyWise !O.LIB module,
that lowercases many operators. Every time
!xyWiz !!! opens an xpl file it invokes the
module in the event a Sig+ app has stored
it. In a PC that meets its unreasonable
demands on graphical hardware resources,
xyWin is rewarding enough to put up with Sig+
vexations, but I'd never program with a Sig+ app.
Funcs toward the end of the ascii 130 list are intriguing.
The last that xyW3 and Sig+ render the same are SA, TB,
and TC. xyW3 renders Sig+'s OV as TX, SG as LO, XH as
TG, FT as SG, MN as TM, MK as NM, NM as MR, RX as XT,
KF as OV, JC as HG. NN wildcard funcs that Sig+ render
variously are all XX to xyW3. Sig+ ES and recent funcs
get real ugly in xyW3 and are best pfunc'd in Sig+ or
lifted from *.DLG.
Forgetting to type BX and JM instead of CG and FT
in Sig+ kbd files is counterproductive.
Never mind NBSTART.INT and NBMAIN-S.AUX.
things nbWin does at startup are hidden
deep in button set configurations in
[d:\...]\NB\USERS\DEFAULT\NB.INI. When editing NB.INI,
before xyW3 and nbWin are switched to expanded view
they throw a fit over code under [Note Defaults].
Except for zapping nbWin i circumflex menu access,
when I store copies of *.DLG I know I do no harm. NB.INI
[Note Defaults] I'm not so sure about. I back up and
forge ahead. If I knew what Note Defaults do, I might
be less sanguine. My NB.INI [Startup] section looks
Before explaining the disabled *.AUX &ldpm commands,
I want to discuss the source
of some of nbWin's more diabolical behavior.
At first glance default.lib appears to be an
ordinary stsgt. Surprise, surprise. When SmartWords
falls behind the curve and sends me one of its
frequent "too many program calls or
program loops" messages, xpl code that
SW can't process goes to ... default.lib?!?
Studying the detritus may reveal where the pgm broke
down, but that's not much help when there's no
logical reason why it should have broken
down; xyWin has no trouble running identical code.
When default.lib is thus corrupted and a crash
occurs, the file is write-protected in a way that
makes it unavailable to normal file management utils.
Then, thanks to the load command buried in NB.INI,
the corrupted default.lib prevents a fresh start.
Not loading the file at startup has no down side
that I've noticed (it also unlocks the file so
it can be overwritten with a clean stsgt, but
that's irrelevant if NB.INI doesn't load it).
; load &user&main.hyp=
; ldlib &user&default.lib=
; ldpm &root&nbmain-c.aux,&c=
; ldpm &root&nbmain-d.aux,&d=
; ldpm &root&nbmain-i.aux,&i=
; ldpm &root&nbmain-e.aux,&e=
; ldpm &root&nbmain-x.aux,&x=
; ldpm &root&nbmain-g.aux,&g=
; run &root&nbmain-s.aux=
It may be that I haven't noticed because I don't use
built-in session-to-session continuity; I'd guess that
default.lib has something to do with continuity beyond
stsgts. I question its implementation and, given its
susceptibility to misadventure, the advisability of
making it so inaccessible. Don't we have enough necessary
evils without having to cope with one that's avoidable?
Here's how I replaced
nbWin's intemperate &ldpm *.AUX overlay
with a more conservative system.
Instead of calling the multitudinous &ldpms,
all kbd calls go to MY_NB.DLG $N:
In mycustom.kb5, where once were|
$N loads NB_AUX.U1 frame argNB. Responding
to the char that follows $N in mycustom.kb5,
NB-style code in frame argNB--
[ascii 2]JM (1.argNB)«ex»[ascii 2]
--loads U1 frame auxC, auxD, auxE, auxG, auxI,
or auxX, each of which corresponds to the first
section of each ex-whatever-AUX. From that point on
code in each section does what the &ldpm would do
normally. Did NB_AUX.U1's load line in my NB.INI catch your
eye? Bet you can't find that line in yours. I consolidated
all *.AUX &ldpm code in NB_AUX.U1, eliminating the need
to load any NB &ldpms. U1 files are U2s that belong
to the developer, but nbWin SW doesn't have one. Didn't.
[ascii 2]«sx90,«rc»»«sx90,"aux"+«is90»»JM (1.«pv90»)«ex»[ascii 2]
What the *.AUX &ldpm overlay does is extensive but
as xpl is quite simple-minded and NB coding is admirably
orderly, so converting &ldpm file «LB»'d
sections to U1 frames subordinate to frames auxC, auxD, auxE,
auxG, auxI, and auxX took less time than you might expect.
Wonder if the developer had a good reason for not
doing a similar conversion, or just unthinkingly stuck
with a dos model. If dosNB is structured similarly, no
wonder memory managers are such a critical issue.
Use of $C, $D, $E, $G, $I, and $X frames instead of the
$N->argNB switchbox would result in a cleaner kbd file
and would have no significant effect on NB_AUX.U1, but why
needlessly expropriate $[X]s users might like to implement?
Indeed, before I worked out how to implement $[X]s, $N was
&N in order to free up &C, &D, &E, &G,
&I, and &X. &[0-9/A-Z] are after all user
instruments. While NotaBene may need to borrow xyWrite
user tools, as a commercial enterprise the developer
at least could be considerate. (Of course *.DLG
repeatedly invade xpl user space. Tim Baehr, who helped
write the original, commented that with IBM pressuring
them to dump the CMline, etc, variable numbers were
the least of the programmers' concerns.)
NB_AUX.U1 is complete but largely untested and, having
no need for what the NB overlay and SmartWords do, I
don't expect to do any more work on the file. Determining
that the NB.DLG $N->U1 argNB concept is workable with
the rather highstrung nbWin was a satisfying exercise.
(And won't I be surprised if NB has
done away with the &ldpms and default.lib since
releasing the never-upgraded nbWin I use.)
This bears repeating:
Proceed at your own risk!!!
Trying to make Signature's gui progeny, Windows
releases of xyWrite and NotaBene, perform as
much as possible like my xyWrite 3 interface
involved converting some complex xyWrite xpl to
U2 xpl, a job I'd abandoned in frustration in the
past before reaching a point where I could use the
app confidently for routine work (not synonymous
with trusting the app). I load the same
>127k U2 to both (SmartWords--nbWin--version
laboriously corrected for ANSI and inflated by
kludges that try and fail to compensate for
SW's absolutely malevolent refusal to shell
out gracefully from xpl).
If your xyW3 xpl is extensive, the porting barrier
is formidable. Although some syntactical differences
are documented and experts are eager to promote
xyDos4 U2, nobody but you is going to debug your U2.
xyWrite-Signature inconsistencies are inexplicable,
unpredictable, undocumented, and unending. A manual
that reportedly (I've never seen it) helped users port
v3 xpl to Signature wasn't distributed with Sig's progeny.
Since The Herb bailed after xyW3 (who could blame him?),
if you hit a wall you have no Book to turn to, just
a mailing list where you may get an answer or may be
told to download and decipher someone else's code.
Just now, e.g., I can't persuade a subroutine to go
to a Sig+ AlternateScreen to open the file listed at
the cursor--a trivial xpl operation that can be coded
in xyWrite 3 literally in about 10 seconds. No doubt
it can be done in Sig+, but why waste more hours--and
I mean hours--trying to work out how? !xyWise
succeeded, and a !xyWiz module searches and
replaces wildcards with wildcards, because I have
unshakable faith that any programmer clever enough can
make xyWrite 3 xpl do anything. I'm not
all that clever, I just had more confidence in xyW3
than the xpl programmers who laid the foundation !xyWise
is built on. Signature+ xpl doesn't inspire similar
trust, thus a willingness to persist till the solution
to a real problem emerges, since dealing with problems
that shouldn't exist at all (like opening a file listed
on another screen) consumes so much time.
Lest you suspect that fooling around with the guts
has made my nbWin installations misbehave, keep in
mind that I started fooling around with the guts
because nbWin was misbehaving. I modified
the xpl overlay later. I see so many SmartWords
"too many program calls or program loops"
msgs from xpl that xyW3 and xyWin run
uneventfully I have no choice but to consider SW
a giant leap backward as a vehicle for xpl. I'd
guess that SW optimization for VisualBasic is
behind the trouble. Once NotaBene invited xyWrite
users to buy nbWin, the developer had to expect
adventurous xpl users. So don't tell me
not to try to get SmartWords to perform at least
as well as its predecessor, xyWrite 4--especially
since I have no hope Signature and its offspring
can perform as well overall as their predecessor.
- Later: Carl Distefano has volunteered
that to open a file listed on the adjacent screen--which
xyWrite 3 xpl does with
- --Signature+ require
BX ca «pvNN»
- . . . Who'd've
known? Entirely typical of the kind of inexplicable,
unpredictable, undocumented, and unending
inconsistencies to be expected when porting
v3 xpl to Sig+.