Re: NB bombs in OS/2

[Robert Holmgren holmgren@xxxxxxxx]

** Reply to note from xywrite@xxxxxxxx Thu, 11 Nov 1999 15:01:00 +0800 (WST)

> Well, the news from here on NotaBene at present is not good. I
> put in a full day's work with it yesterday and, after two bad
> experiences, have decided that I cannot use it under OS/2.
> Perhaps it is more stable in Win95/98.

If I read your note correctly, it sounds like Object Desktop is the
unstable program, not NBWin.

My experience is different. I haven't DLed v5.004 yet, but v5.003 seems
to work as well under Win-OS/2 as it does under NT. Which is to say,
that I get GPFs under both OSes with fair regularity. I've yet to
determine how much is due to my own ignorance (and the absence of
technical documentation), and how much attributable to NB directly. Now,
in fairness, I must admit that many of my problems were due to passing
some seemingly-innocuous XyWrite VAriables and facilities under NB's nose
that NB found terminally offensive: VA$SW, VAHI, any embedded 
command, VA[$]OB, any 3-byte character code in range 0-255, ,
problems with VA$WN due to the "smart windows" peculiarity (or "feature",
I suppose I should say), Speedo fonts, non-Windows PRiNter files, etc.
(I should say "etc. etc. etc." -- quite a few of these problems.)
And at present, I find myself in a bit of a bind, because every time I
try to SAve a file, any file, I get a "Sharing Violation" error #332.
*All* these things are problems under NT too.

But look, there's a learning curve here, for everybody. It's all happened
before. If you were around when 3+ became 4, you're aware that we tended
to blame XyQuest/TTG for incompatibilities, instead of simply adapting to
change. We were rigid rather than flexible. We're just beginning to get
to know NB, and they're just beginning to get to know us. They *want* to
get intimate. What we need to do is struggle to really understand what
the problems are, to be deeply diagnostic, and then to see if they're
helpful. But we need to keep in mind that this is a small company with
limited resources, and we can't ask for the moon. They've issued seven
versions in ten months: an impressive record of responding to problems.
Even NT 4.0 is only up to SP 6, after how many years? And still buggy
as hell.

My guess is that ignorance is the biggest hurdle here. NB doesn't realize
that we need some technical assistance, and that their "Help" facility
falls rather far short, in our case. We need to examine the history of
NB. When I bought v3.0 a decade ago, I was stunned to find all these
elegant, canned solutions to certain scholarly problems, which were highly
resistant to tweaking. NB has much more of a take-it-as-is philosophy;
indeed, it's quite the opposite of the XyWrite philosophy, which embraced
totally open user-adjustable facilities. Where NB hard-codes its
facilities in binary files, XyWrite used plain-text. NB seems to have
little or no expectation that users will require NB to dial their voice
calls or encode and decode base64, as XyWriters can and do. (The truth is,
that NB can do these things too -- I just tried, using XyWWWeb.U2 routines
without any modification -- but no NB user would have the tools or
information to know how to go about it, because NB simply doesn't publish
the nuts-and-bolts data that make it feasible. And you know, if you read
the NB maillist regularly, you'll notice that *nobody* is asking for it
either. They take what they get, and that's the end of it. In short,
there's a totally different mindset operating in NB's world.)

Now, in NB's defense, it should be said that NB may have determined that
it was simply too awkward and prolix to try to control Ibid etc. via XPL
or K-frames. But, you know, at the same time they've bound other things
up in compiled Visual Basic binaries and not published the source, or
described the interface, or even mentioned VB, much less afforded access.
What's the rationale? You gotta ask yourself... why? Why did Kenneth
Frank ask us, years ago, what macro language we wanted to use as a
replacement for XPL, and then go lock it up and deny us access? Nuts to
that.

Anyway, we're at a genuine crossroads. We've got SmartWords "beta" (if it
exists), we've got NBWin, and we've got Xy4-DOS. By any measure, NBWin is
better than XyWin, so we can forget the latter; and by most measures, Xy4
is better than Xy3+, ergo that's out too, at least in my book. So:
either we stay where we are -- and I personally think Xy4-DOS is about the
best, most bug-free WP in existence, which I'd be privileged to use for
the foreseeable future -- or we go GUI. Between the two GUIs, NB has a
future, whereas SW... who knows? Past experience teaches us that it is
insane to believe that one take-it-or-leave-it SW beta will not be bug-
ridden, especially given TTG's lamentable habit of never running the code
by any of us in advance for criticism or suggestions. The truth is, we
push their software to the limits, whereas TTG is satisfied if their
canned implementations work OK. We've come a long way, unfortunately,
from the old philosophy that these canned setups are just *one example* of
what can be done, one possible template -- toward a philosophy that the
canned setup is THE setup. Whereas, in NB's case, I don't think there's
ever been any other attitude than that NB is selling *one* particular
factory implementation with specialized facilities -- period. In short,
there's a real philosophical difference here. But, to be clear, I remain
hopeful (and thus far encouraged) that we can strip away the specialized
baggage from NB, reveal the basic engine (which appears to be
considerably advanced and debugged compared to XyWin), and then build
from the ground up. Time will tell.

I'd cut the NB folks a generous amount of slack, and see where it goes.
It needs to simmer. And I'd persevere with NB under OS/2. I find that
this matchup works fairly well, and I perceive zero difference (read:
improvement) under NT. Neither do I understand why anyone would presume
that NT would run a Win3x program better than OS/2; I would assume the
opposite, because the one Win3x is a patent mess, and the other is totally
rewritten by IBM in order to "get it right this time". Hey, there were
real reasons why IBM claimed to offer a better DOS than DOS, a better
Windows than Windows! Anyway, where NB doesn't work, I'm thinking -- at
this stage -- that it's mostly my fault, along with ignorance. Which fits
the pattern of past transitions.

If it's any help, you might take a look at your Win-OS/2 properties.
Here's what I've got:

WIN_RUN_MODE (3.1 Enhanced Compatibility)
WIN_DDE 1 On
WIN_CLIPBOARD 1 On
WIN_ATM 0 Off
DOS_BACKGROUND_EXECUTION 0 Off
DOS_BREAK 0 Off
DOS_DEVICE G:\TCPIP\BIN\VDOSTCP.SYS
DOS_FCBS 16
DOS_FCBS_KEEP 8
DOS_FILES 99
DOS_HIGH 1 On
DOS_LASTDRIVE Z
DOS_RMSIZE 640
DOS_SHELL G:\OS2\MDOS\COMMAND.COM G:\OS2\MDOS
DOS_UMB 0 Off
DPMI_DOS_API ENABLED
DPMI_MEMORY_LIMIT 64
DPMI_NETWORK_BUFF_SIZE 8
EMS_FRAME_LOCATION AUTO
EMS_HIGH_OS_MAP_REGION 0
EMS_LOW_OS_MAP_REGION 336
EMS_MEMORY_LIMIT 5072
HW_NOSOUND 0 Off
HW_ROM_TO_RAM 0 Off
HW_TIMER 0 Off
IDLE_SECONDS 0
IDLE_SENSITIVITY 75
INT_DURING_IO 0 Off
KBD_ALTHOME_BYPASS 1 On
KBD_BUFFER_EXTEND 1 On
KBD_CTRL_BYPASS NONE
KBD_RATE_LOCK 0 Off
MOUSE_EXCLUSIVE_ACCESS 0 Off
PRINT_SEPARATE_OUTPUT 1 On
PRINT_TIMEOUT 15
SESSION_PRIORITY 1
VIDEO_8514A_XGA_IOTRAP 0 Off
VIDEO_FASTPASTE 0 Off
VIDEO_MODE_RESTRICTION NONE
VIDEO_ONDEMAND_MEMORY 1 On
VIDEO_RETRACE_EMULATION 0 Off
VIDEO_ROM_EMULATION 1 On
VIDEO_SWITCH_NOTIFICATION 1 On
VIDEO_WINDOW_REFRESH 1
XMS_HANDLES 32
XMS_MEMORY_LIMIT 2048
XMS_MINIMUM_HMA 0



-----------
Robert Holmgren
holmgren@xxxxxxxx
-----------