#WShell RESIdent Problem?
3 messages in this thread
I guess you missed the great debate on BIX, where I attempted to talk
Commodore out of recommending that developers put calls in their software
asking for 8 megabytes, thereby flushing all libraries out of the system.
WShell is built as a shared library and is designed to exit memroy cleanly
if someone asks for it, and since the aliases and resident commands are
anchored to the library, they go away too. Programs like DPaint apparently
flush memory to get rid of fonts or something, but it's a very
system-unfriendly thing to do.
Maybe when there are more developers building library-based software we can
get other vendors to not flush memory needlessly. Until then, the only
workaround is to keep the library open so it can't get expunged.
Yup, I did miss that one. Not that I would've contributed anything, but it
sure sounds like a monumental kludge to steal all possible memory unless you
plan on using all of it.
But now I'm even more concerned: does WShell itself go away, or just the
resident commands? I could've sworn that when I open up a new WShell nothing
bad happens (I mean o_pen up a new NewWSH).
BTW, when are the next updates to AREXX and WShell coming out?
>>>>Mark>>>>
Mark,
WShell comes back to life as soon as you click on its icon — it just
reloads the library from LIBS:. If you put commands in your
s:startup-wshell file to load the resident commands, it will re-do the
resident list when you next open a WShell. It doesn't really hurt anything
to have the library expunged from memory, but just takes a little longer to
reload it.
I'm thinking of adding a "lock in memory" flag to keep WShell from being
expunged, so the user will have more control over the issue.
The WShell update is still under development but will be announced fairly
soon; I'm also planning to extend the ARexx update policy to WShell, since
people seem to like it pretty well. No timetable yet for ARexx update —
will turn my attention there once WShell is squared away.