#WShell 2.0 vs Whap!
18 messages in this thread
Bill (and Steve Ahlstrom),
I think I've found a problem with either WShell 2.0 or View! (or
Whap!?). If I use the SetExecute program, View! won't start up. More
precisely, I would click on an "R" button, Whap! would access the disks,
and the Workbench would pop to the front. However, View! would not start.
The Whap! screen would be behind the Workbench. Clicking on any Whap!
function buttons (like QUIT) would cause the button to "light up", but
nothing would happen. Occasionally, there would be garbage on the
Workbench screen. More occasionally, MemWatchII would complain (write to
location $0), and the Guru would pay a visit ($8000 0003.).
I know this sounds like a Whap! bug report, but it only started after
I finished installing WShell. I backed out the WShell functions one at a
time, until View! started working again. The only thing that caused the
error is SetExecute, which I had in my User-Startup. This may well be a
bug in View! or Whap!, since this is the only problem I've had with
SetExecute. Are there any caveats to using SetExecute?
–dds (dales@teksce.SCE.TEK.COM)
Whappeta-whappeta-Whap!
Dale,
I don't use WShell. I am a registered owner of WShell but haven't used it
since I got a 3000. I haven't received an upgrade notice for WShell 2.0 so
it's extremely unlikely I'll purchase it (again) at full retail or install
it permanently if I had it. The problem you report may very well be a fault
of Whap! but without WShell 2.0 I can't duplicate it or track it down.
Steve,
Wow, that was a fast reply! (To the Lurkers out there, the sequence
of events was: Type message. Run Whap! to gather message headers and post
message. Select threads for download. Run Whap! to retrieve message
threads; note that a reply is waiting…)
You might give Bill a nudge wrt your upgrade notice. (Likely the
Postal DisService lost it.) WShell 2.0 is well worth the cost of the
upgrade (IMO). I should note that I wasn't running SetExecute when I was
running 1.3.2 & WShell. For all I know, the old version of SetExecute may
cause trouble wMith Whap!, too. BTW, you can run WShell 1 under AmigaOS
2.04. Bill released an archive with a modified library and a program named
"callres", which allows you to use commands that used to be in C: from
WShell. I used that setup for a while, until I got my upgrade, and it
seems to work fairly well.
I do understand about not being able to troubleshoot the problem
without all the pieces at hand. So until you get WShell 2, I'll simply not
use SetExecute. I'm honestly not sure about all the
advantages/disadvantages of that program, anyway. Certainly everything
seems to work fine without it.
–dds (dales@teksce.SCE.TEK.COM)
Whappeta-whappeta-Whap!
Dale, I've only once (about 3-4 years ago) received an ungrade notice for
either WShell or ARexx. A couple of times I requested info on the lastest
version and then purchased them.
With AmigaShell 2.0, I find that for _my_ uses, I have no use for WShell
any longer. I'll grant you that WShell is much more powerful than
AmigaShell but since they are features that I use I see no reason to run
it.
I will upgrade ARexx immediately upon any upgrade announcement — for that
I'd call Bill and give him my credit card number so it would be shipped
asap.
Er, …are features that I DON'T use …
-sja
Steve,
"…but since they are features that I use I see no reason to run
it."
Um, should'nt that read "…they are NOT features that I use…"?
Otherwise I can't parse that sentence… 🙂
Well, I guess if you don't need it, you probably shouldn't spend the
money on it. For me, I found FComp alone to be worth the price of WShell
1.2. I jumped at the chance to upgrade to 2.0. I've no regrets. As for
ARexx, I waited for AmigaOS 2.04, thinking — since Bill had announced the
release of ARexx v1.15 -that the OS release was imminent. I forgot that
for Commodore, "imminent" is any time within a geological era. 🙂 Next
time Bill announces an ARexx upgrade, I'll have that card off like a shot!
–dds (dales@teksce.SCE.TEK.COM)
Whappeta-whappeta-Whap!
Dale,
Just make WShell the default 2.0 user shell, and forget about SetExecute.
Everything should work fine in that situation.
The User Shell facility only works with software using the new System()
function, so SetExecute will still be required if you're using older
applications that still use DOS Execute().
The DOS SYstem() call is much improved over Execute(), so I would expect
all developers to use it when possible, but if an application hasn't been
revised for AmigaDOS 2.0 it may still be using Execute().
-Bill Hawes
Hmm… I think maybe I see the problem. WShell was set up to be the
default user shell (still is, for that matter), AND I was running
SetExecute. Now that I'm not running it, all is well. I'm happily typing
this into View! right now.
It never occured to me that there might be an interaction between
SetExecute and the resident wshell.library. I wonder if I just missed a
warning in the manual, or if Bill never considered anybody to be silly
enough to do something like that. No matter, it's all working just great
now.
Thanks for the hint!
–dds (dales@teksce.SCE.TEK.COM)
Whappeta-whappeta-Whap!
Steve, You should have received an update notice for WShell 2.0 a while
ago; has your address changed in the past year or two? If not I'll go
ahead and send out another update notice.
What commands does Whap! issue via the DOS Execute() function? Sometimes a
difference in the search path used by WShell will afect whether a command
can be found.
-Bill Hawes
Bill,
My address hasn't changed in 10 years or so — the upgrade notices (with one
exception) just never make it here.
Here's what Whap! does with Execute() …
static void exec(string)
char *string;
{
BPTR inlock;
BPTR outlock;
inlock=Open("Nil:",MODE_OLDFILE);
outlock=Open("Nil:",MODE_NEWFILE);
(void)Execute(string,(BPTR)inlock,(BPTR)outlock);
Close((BPTR)inlock);
Close((BPTR)outlock);
}
Steve, I'll send out another WSHell update notice tomorrow — let me know
if it doesn't arrive within a week or so.
The call to Execute() looks harmless enough; what strings are being
executed though? Are some of them commands that might not appear along a
standard search path?
-Bill
Dale,
I'm running WShell 2.0 and have not experienced any problems with
Whap!… or View!. I am also using SetExecute. I'm running 2.04 on a
2500/30.
Hope you are able to track this down.
– BobR
Bob,
The system is working fine now (or would, if I could type tonight).
I'm not running SetExecute, but I do have L:wshellseg as my resident shell.
(I.e., I have a line in my S:User-Startup file that read:
"Resident Shell L:wshellseg SYSTEM PURE".
Also, see my reply to Denny Atkin on this subject. Evidently, one doesn't
want (or need?) to run SetExecute if the default shell is already a wshell.
Are you residenting a wshellseg, by any chance?
–dds (dales@teksce.SCE.TEK.COM)
Whappeta-whappeta-Whap!
The SetExecute program is still required to intercept calls to DOS
Execute(), whether or not you've installed WShell as the user shell. The
user shell only applies to the new AmigaDOS 2.0 System() function, and many
older applications still use Execute().
-Bill Hawes
Thanks for the info re SetExecute. Then there must be some sort of
bug in Whap! Drat.
Could you explain a bit more about what SetExecute is supposed to do?
I never really understood it from the descriptions in the manuals. I
didn't use it with WShell 1.2 because I wasn't sure what the effects would
be, and how compatible it was with other programs. (I know other people
have used it quite happily. I'd just like to know better what it does.
Call me paranoid, I guess…)
Dale,
Setexecute patches the DOS Execute() function so that commands run by
calling Execute() will be processed by WShell. The Execute() function was
the only system-supported way to run an external program from within
another program under 1.3; AmgiaDOS 2.0 provides an improved function
called System() for this purpose.
By patching Execute() with SetExecute, you're able to provide a consistent
environment — same aliases, resident commands, ARexx interface, etc -for
commands run within a program and from the command line.
SetExecute also fixes some long-standing problems under 1.3, especially for
commands run from a program launched from Workbench. Under 2.0 it's less
important, as many applications are being revised to use the better
System() call.
Bill,
Thank you for the explanation. It helps when I understand these
things better.
–dds (dales@teksce.SCE.TEK.COM)
Whappeta-whappeta-Whap!