WShell and WB/KS 3.1
16 messages in this thread
Bill,
I've had some unexpected behavior from WShell 2.0 since installing KS/WB
3.1 on my Amiga 2000 with 2630 accellerator. When an application opens a
CNC: window for output, the window title doesn't get displayed properly.
Instead, the title bar variously displays a couple of hex numbers in
inverse video, a couple of alternate character set characters, or nothing
at all. The only exception seems to be NewWsh, which briefly displays a
couple of hex characters in inverse video and then switches to the
expected "Shell process No. x" title. When I removed WShell as the
default console device and used the system CON: device, the windows had
the expected titles (but, of course, not the extra nice features of
WShell!). Any comments, suggestions, etc.? Thanks for your help.
Darron
Darron,
It sounds as though you need to supply the DisplayHandler with more stack
space, if its window titles are being clobbered. Just add a STACK 5000 (or
more, if you need) to your DHOpts command line.
-Bill Hawes
Bill,
Thanks for the quick reply — when I get home tonight and hook up again with my
Amiga, I'll try your suggestion of increasing the stack for the DisplayHandler.
Darron
Bill,
Why would a larger stack be needed just because of the change in OS?
I've had similar problems with shell titles, but I thought it might have been
the font I was using.
Steven,
For what it's worth, jacking up the stack in the DHOpts command line in my
user-startup file cleaned up the CON: window titles. The problem does
appear to be solved.
Darron
Darron,
Hmmm. Well, I don't have any problems with WShell's initial window,
but Term's ARexx window has garbage characters in it, as will my pop-up shell
window. However, I think I did something quite different from you. I merely
set a large stack prior to running DHOpts, but that's not apparently what you
did. I need to go back and check the DHOpt command line and make the change
there, I guess.
Steven,
Yes, the change I made was in the DHOpts line in S:User-Startup. I, too
had a large stack set before getting to DHOpts, but that did no good. I
guess what's needed is a large stack for the WShell process itself, not
just the processes launched from the WShell.
Darron
Darron,
Yep, that indeed turned out to be the case. Bill said that OS 3.1 may
require more stack for soem programs. In fact, I'd been puzzled by some
strange goings on in Turbotext, so on a hunch that those problems may have been
caused by the same thing as DHOpts, I set TTX's stack higher, and lo and behold
the problem disappeared. Guess I'll have to think about stacks, now, when
something doesn't quite work right that worked before. Frankly, tho, I'm sort
of puzzled as to why the program needs larger stack just because the OS
changed.
The DHOpts commands is used to configure WShell's DisplayHandler. It allows a
lot more configuration flexibility and does away with having to create a
mountlist entry for the handler. Once of the settable options is the amount of
stack space required by the DisplayHandler instances, in order to allow for
future changes in the OS stack requirements.
Instances of the DIsplayHAndler are created when you open a console window, not
at the time the DHOpts command is run. The stack space used by the handler is
a separate issue from the stack setting for commands run from a shell.
Hope this makes the issues clearer …
-Bill
Bill,
Thanks for the elaboration — it does make things much clearer, at
least for me.
Darron
Steven,
Apparently later versions of AmigaDOS have been using more and more stack space
for some library calls, especially when opening a window. To guard against
increased requirements the DisplayHandler supports a STACK option in its
command template.
-Bill Hawes
Bill,
Well, I guess I misunderstood the previous reply, because what I did
was to simply change the stack by running Stack 40000 before running DHOpts,
but that apparently isn't what you were recommending, so I need to go back and
try this again, because I still get some garbage characters in some windows.
BTW, check out David Junod's new ZedRexx host for developing GUIs in
ARexx programs. It's very nifty and much easier to use and learn than Apig and
RexxArpLib. There's a full demo version in one of the AmigaUser DLs.
Which DL is ZedRexx in?
C. Davey
Don't know. I believe it's in the AmigaUser DLs. Do a BRO AGE:20 LIB:all. It
was uploaded recently. Or do a key search on zedrexx or rexx.
Lib 7
ZEDRX1.LHA/Bin Bytes: 108556
Title : ZedREXX 1.0 for Amiga – GUI Extensions to REXX
Keywords: REXX GUI JUNOD REXXUTIL REXXDOS LIBRARY SHAREWARE
ZedREXX 1.0 for Amiga, a REXX Language Extension that adds
sophisticated Graphical User Interface (GUI) capabilities using an
easy-to-use yet extremely powerful syntax. Minimum system requirements
are an Amiga running 2.04 or beyond of the Amiga Operating System.
==Shareware==
Note: Evaluation archive includes updated rexxutil.library and
rexxdos.library by David N. Junod.
——
If an OS call changes the amount of stack it consumes, a program which
uses that OS call may need more stack.