X-Authentication-Warning: delorie.com: mail set sender to opendos-bounces using -f Date: Tue, 02 Dec 2003 01:11:39 +0100 From: Matthias Paul Subject: Re: several technical problems To: opendos AT delorie DOT com Message-id: <000401c3b8cb$c93261e0$c03dfea9@atlantis> Organization: Aachen University of Technology (RWTH), Germany MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook Express 6.00.2800.1158 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Reply-To: opendos AT delorie DOT com [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 -- ; http://www.uni-bonn.de/~uzs180/mpdokeng.html; http://mpaul.drdos.org "Programs are poems for computers."