context || back to xyWrite resources | xyWin|nbWin|NoteTab: compare and contrast

How I got winSig+
to cough up
one xyWrite
xpl instrument
Sig had confiscated

at your
own risk!!!

 new! 4 july 2001

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

[ascii 2]JM (2.$I)«ex»[ascii 2]

[ascii 2]JM (2.$V)«ex»[ascii 2]

[ascii 2]JM (2.$O)«ex»[ascii 2]
That's it. That permits U2 frame names like
and in custom.kbd sequences like:
BX,s,e,b, , ,<,+,*,+,Q2BX,s,e,b, , ,<,Q2CRXDDWCLXDDF
BX,s,e,b, , ,<,Q2CRDFBX,s,e, , ,<,Q2SI,/,CPXDCI,>,RCRCDF
BX,s,e, , ,+,*,+,Q2BDBDBDDFRD$GGT
Oh, well. Kbd macros aren't pretty. But consider the alternative--the BetterThanAverageTaggingTool 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, , ,+,*,+,Q2BDBDBDDFRDJM,(,2,.,#,g,O,l,d,),GT
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.

After reading this, Signature+ xpl guru Carl Distefano commented that using this frame in *.DLG
[ascii 2]«sxNN,«va$fr»» JM 2.«pvNN» 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.

Some nbWin
tech notes

Never mind NBSTART.INT and NBMAIN-S.AUX. The important 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 like this:
load &root&mycustom.kb5=
uwf 3=
load &root&my_nb.u2=
load &root&my_nb.dlg=
load &user&my_nb.dfl=
load &user&my.sp3=
; 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=
load &root&nb_aux.u1=

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

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.
In mycustom.kb5, where once were
59=BX,(,N,T, ,/,1,),&E

etc, etc
are now
59=BX,(,N,T, ,/,1,),$N,E

Instead of calling the multitudinous &ldpms, all kbd calls go to MY_NB.DLG $N:
[ascii 2]JM (1.argNB)«ex»[ascii 2]
$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]«sx90,«rc»»«sx90,"aux"+«is90»»JM (1.«pv90»)«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.

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

Later: Carl Distefano has volunteered that to open a file listed on the adjacent screen--which xyWrite 3 xpl does with
AS  BC ed XC 
--Signature+ require
AS «sxNN,«va$dr»» BX ca «pvNN» Q2 
. . . 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+.

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.
     back to xyWrite resources

adpFisher nyc 17 october 2001