Message-Id: <199704170858.KAA19770@math.amu.edu.pl>
Comments: Authenticated sender is <grendel@[150.254.113.14]>
From: "Mark Habersack" <grendel AT hoth DOT amu DOT edu DOT pl>
Organization: PPP (Pesticide Powered Pumpkins)
To: Matthias DOT Paul AT post DOT rwth-aachen DOT de
Date: Thu, 17 Apr 1997 10:53:40 +0100
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: FYI: 4DOS and TaskSwitch
Reply-to: grendel AT hoth DOT amu DOT edu DOT pl
CC: opendos-developer AT delorie DOT com
In-reply-to: <126FC765ABD@ibh.rwth-aachen.de>
Precedence: bulk

Once upon a time (on 16 Apr 97 at 19:01) Matthias Paul said:

> On Wed, 16 Apr 1997 Takashi Toyooka replied to Mark Habersack:
> 
> > Really?  I haven't had any such problem.  The Task Manager ran fine 
> > for me in both switching mode and multitasking mode.  
> 
> In fact TASKMGR does some odd things with COMMAND.COM, which caused 
> some problems with 4DOS (I tested 5.0-5.52a).  Solutions:
> 
> - Set TASKMGR.INI Exec=TRUE:
>   On creating tasks this will cause TASKMGR to spawn new shells, 
>   rather than 'instancing' a master shell.
>   It works nice, but costs more memory. Also, one cannot start TASKMGR
>   from CONFIG.SYS starting some background tasks, because AUTOEXEC.BAT
>   will be suspended. (This problem should be solveable.)
In case of 4DOS this memory overhead is unacceptable, IMHO.

> - Other problems are 4DOS.INI UMBxxxx directives.  While they work
>   fine on my systems, other people reported to me, they had to 
>   disable 4DOS' usage of UMBs.  On the other hand, they did not 
>   need to set Exec=TRUE...  
4DOS probably uses some custom relocation code to put itself to the UMBs - 
that might be a problem.

> - If in a given configuration TASKMGR crashes on creating new tasks
>   from its menu, one can try to create new tasks from the command
>   line (/C c:\opendos\command.com).  This will help.
Haven't tried it, thanx!

> - Some of the Novell DOS updates may help.  I was able to run Update 
>   13 with Exec=FALSE and 4DOS 5.50c using UMBs, both as a taskswitcher and
>   as a multitasker. While 4DOS 5.52a is better, I was not able to run 4DOS
>   without Exec=TRUE with Update 15/2.
This is probably due to the new W95 support code in 4DOS 5.52a

> - I'm not sure, but maybe the undocumented COMMAND.COM /T option
>   has something to do with these oddities of TASKMGR and 
>   COMMAND.COM.
>   When giving "/T /C cmd", COMMAND.COM will spawn a new shell, but
>   won't execute cmd.  After the new shell returns to the old shell,
>   cmd will be executed.  The system crashes, if the current command
>   processor is not COMMAND.COM, so it appears to me, that this 
>   undocumented interaction between the current and the new shell
>   might cause TASKMGR refuse to run 4DOS successfully.
Hmm... 

> - (More details on several combinations of configuration options,
>   and on /T can be found in NWDOSTIP.TXT from MPDOSTIP.ZIP...)  
Still cannot d/load it ;-))) from any of the places on your web page ;-((
==================================================
Stand straight, look me in the eye and say goodbye
Stand straight, we drifted past the point of
  reasons why.
Yesterday starts tommorow, tommorow starts today
And the problems seem to be we're picking up the
  pieces of a ricochet...