Mail Archives: opendos/2003/12/02/07:12:19
[Well, most of this is already out-dated and others have given
good advice, but since it was written already, here it is anyway ;-)]
On 2003-11-27, Donald Pedder wrote:
> 1. I could never get taskmgr to work properly on this computer -
> that is, until I saw someone mention "taskmgr /s", which got it
> going (this was a new option since I'd used the previous version).
> However, I am still having a problem with it.
That's strange. Assuming the posted CONFIG.SYS is actually
the CONFIG.SYS file which gets executed on boot-up, you load
EMM386.EXE *without* the MULTI=ON option, so "Vladivar",
the 32-bit Protected Mode OS core is not loaded.
Hence, no multitasking or multithreading is supported by the
system. In other words, specifying TASKMGR /S or just TASKMGR
does not make any functional difference in your case, as TASKMGR
will load as a task switcher instead of a multitasker in case
the underlaying support for multitasking is not available.
While both have a very similar user interface (the TASKMGR menu),
both modes of operation have almost nothing (even no code) in
common. The TASKMGR.EXE file is actually a multi-partite .EXE
file containing:
- a loader which gets executed when you run TASKMGR.EXE from the
prompt and which decides which other internal modules to load
and run depending on circumstances
- a multitasker module (consisting of a few sub-modules)
- a taskswitcher module (consisting of a few other sub-modules)
- a Windows TASKMAN replacement application (so you can
smoothly switch between Windows and "Vladivar" tasks even
under Windows, otherwise Windows could only see tasks
started while Windows was loaded already)
In multitasker mode, the actual multitasker is located in EMM386
and TASKMGR is nothing but a small menu frontend in order to
control the multitasker. It may also serve as a VxD loader.
The main advantage of this mode is true pre-emptive multitasking
(background tasks keep running on a virtual DOS machine on a
virtualized hardware unless several race conditions are met
which may force a task to be suspended until another task
has finished some operation and/or the task is switched back
into the foreground). It has also the advantage of having only
a very small visible DOS memory footprint since the menu
program is located in Extended Memory and runs in Protected Mode
as well. And finally there are very short task switching times,
you can switch between tasks many dozen times a second.
In taskswitching mode, the multitasking core in EMM386 is
neither needed nor used (in case it is still loaded). All
the taskswitching logic is provided by TASKMGR itself.
Since this mode runs in Real Mode it has a much larger visible
DOS memory footprint and you are more likely to run out of
Conventional Memory. Also, only one task can run at a time,
because the other tasks are swapped out to XMS, EMS or disk
until brought back into the foreground. Due to all the swapping
you will experience up to several seconds task switching times
on slow machines. The advantage of taskswitching mode is that
it does not require any memory managers, hence it will even
run on the oldest PC/XT, and it should only marginally interfere
with whatever setup you may have. If MS-DOS DOSSHELL works,
TASKMGR /S should work as well. They are very similar by
design, and if you fire up ViewMAX or PC/GEOS as a task under
TASKMGR you will even get a DOSSHELL-like feeling as these
graphical desktop environments will take over control of
the TASKMGR menu program and will smoothly integrate the
task switching into their GUI environment.
While the multitasker is a bit flakey on some systems, the
task switcher (which basically resembles the old DR DOS 6.0
TASKMAX) is rock-solid on most any system. If it still does
not work, this indicates some serious system configuration
problem, which will most probably also affect the general
stability of the system, not only under TASKMGR.
> I can get several sessions started, but if I try to swap sessions
> while one of them has the editor loaded, I get "exception 6", and
> the session crashes. The reason I use several sessions to start
> with is so that I can edit/reference several files at a time, so
> needless to say this problem means I still can't use taskmgr for
> what I want it for.
Your tried application of TASKMGR is a valid scenario, but
still, there must be something fishy in your setup, and I'm
quite sure it's not TASKMGR as is.
Since there really isn't much unusual stuff in your configuration
files, I suspect either GREEN or DRMOUSE to be the culprit.
So, for a first test, please check if unloading them will help.
If it does, try a newer version of DRMOUSE, that is, try a
current version of FreeDOS' CTMOUSE instead (DRMOUSE was based
on an early issue of CTMOUSE). Alternatively, try the latest
*original* mouse driver available for your mouse. In particular,
PS/2 mice can very easily crash any multitasker, if they are not
set up properly since in this case they may generate interrupts
while the corresponding interrupt handler has been swapped out,
which would lead into a crash on the next mouse interrupt...
Further, try adding a line:
STACKS=9,512
to your CONFIG.SYS (the default is 0,0 under DR-DOS, and some
drivers expect more, because there is a different default under
MS-DOS/PC DOS). If it still does not help, try to add a line
to EMM386 to exclude all upper memory. If any of this will help,
please report back and we should be able to narrow down the
problem and find a workaround.
Please also check if you have a DCONFIG.SYS or DCONFIG.* file
on your C: or other drives. I have the suspicion that the
posted CONFIG.SYS is not the actual CONFIG.SYS executed during
boot... Do you have or had a multi-OS loader like DR-DOS LOADER
installed?
> 2. I am using bitcom as my dial-up software. It has an option to
> drop back down into DOS, but several things that I try to do
> (like using the editor) tell me "insufficient memory", even
> though I have 64Mb of memory (and I ran this software okay
> when I only had a 386).
Well, from the viewpoint of DOS, there is very little difference
between a 386 and later generation machines. EMM386 will take
advantage of the virtual interrupt flag available since the
Pentium, and NWCACHE may adapt its internal memory transfer
routines for highest speed on a given target platform, but
otherwise a Pentium will be treated just as a faster 386
with more memory etc.
Most probably, the insufficient memory message you see indicates
insufficient Conventional Memory. This is, because you don't take
full advantage of DR-DOS' powerful memory management and load-high
facilities. Please post a MEM /A (for 'All') report here, so we
can learn about your current memory setup and help you optimize it.
> 3. I have a problem which is isolated to the root directory on
> one partition. I notice that Windows has touched it (despite my
> efforts to keep it clean). It has a "recycled" directory in there,
> and I'm unable to clear it out with deltree (deltree says no such
> file exists, but it's there if I do a "dir /s"). This may or may
> not be relevant.
Yes, you're not alone with this problem. This is one of Windows'
annoying habits... ;-)
Most probably Windows has created some VFAT LFN entries in this
hidden directory, and since DR-DOS (without the LONGNAME driver
loaded) does not know anything about long filenames, it cannot
clear the directory and will either not be able to touch the
files/directories (treat them as if they were password protected)
or it may leave orphanted LFN entries in the filesystem. While
you will no longer see any actual files in the directory, these
obsolete LFN entries will cause DR-DOS to see the directory as
being not empty, hence it will refuse to delete the parent
directory... Kind of a deadlock situation...
> Anyhow, when I want to use the editor in this directory I get
> "internal error 82". I also get it if a do a "type filename|more",
> however it works with just "type filename" (which is no good
> for multi-page files).
Two issues:
Well, while this will not help the underlaying problem, you do
not need MORE for paged output under DR-DOS, since TYPE and most
any other commands which can generate lenghtly outputs under
DR-DOS have always had an option for paged output. Please try:
TYPE filename /P
Further, output redirection implies the temporary creation of
a scratch file. This will be created in the current directory
unless you have set up a so called "temp directory" and set
up a "temp variable" to direct it elsewhere.
In case, you still have several Mb of free space on C:,
create an empty directory C:\TMP and add the following
to your AUTOEXEC.BAT file:
SET TEMP=c:\tmp
SET TMP=%TEMP%
After the next reboot this should fix your problems with MORE
as well as the problems with .$$$ files mentioned below.
> Ditto if I try to re-direct. For a while I was able to get around
> the editor problem by deleting the .$$$ files, but that no longer
> works. I am able to edit my files if I move them to another directory.
> Any ideas on how to clear up this directory? (I'd rather not re-format
> if it can be avoided).
No need to reformat. The easiest way to get rid of the directory
is to use Windows 9x. The best way to avoid the problem is disable
the creation of these recycle directories completely.
In case you have already deleted some of its contents under DR-DOS,
I would recommend to run SCANDISK under Windows on that drive.
This should fix the filesystem again.
In case you haven't already deleted some of the contents in
the directory, you could have loaded LONGNAME or any other
LFN provider under DR-DOS, and *then* delete the directory
and all its files.
In case, there are already orphanted LFN entries since you
deleted some of the files under plain DR-DOS (without LONGNAME)
and you don't have a working Windows 9x setup any more, you
could still delete them using a disk editor (but since this
can be very dangerous if you don't know exactly what you are
doing, I would rather not like to describe the details here
for now). It's a last resort, but still more convenient than
reformatting the drive.
Hope it helps,
Matthias
--
<mailto:Matthias DOT Paul AT post DOT rwth-aachen DOT de>; <mailto:mpaul AT drdos DOT org>
http://www.uni-bonn.de/~uzs180/mpdokeng.html; http://mpaul.drdos.org
"Programs are poems for computers."
- Raw text -