SvarDOS
CPU386 config.sys statement not implemented.
The CPU386 statement is present in latest DR-DOS versions (post OpenDOS 7.01). It allows cpu discrimination within the config.sys and prevents crashes when booting non-386 or better systems.
As a workaround, till it gets implemented, I use this program, that I am sharing:
This version of TESTCFG was designed for DR-DOS, Enhanced DR-DOS, OpenDOS, Novell DOS, and its siblings.
Within latest Novell/Caldera DR-DOS implementations, a CONFIG.SYS statement called "CPU386" was implemented to exclude driver loading which demanded a 386 or better CPU and skipped it if not present. This was particularly useful in the case when an 8086,8088, V20, V30, etc. system reached the loading phase of memory managers, which most often than not, results in a computer crash due to unsupported CPU. Unfortunately, this new CONFIG.SYS statement "CPU386" is not part of Enhanced/OpenDOS distribution kernel right now.
This particular new implementation of TESTCFG is really small in size at 508 bytes. Its goal is to check for a specific CPU and issue a warning before smelly things hit the fan.
It should be inserted in a CONFIG.SYS line "INSTALL=TESTCFG /3" (without double quotes). This will effectively check that the current processor is a 386 or better CPU, and in case it is not, it will immediately warn the user and halt the CONFIG.SYS processing, allowing the user to resume at their own risk and suggests to better reboot the system, selecting a suitable configuration that better matches their system's CPU.
TESTCFG is Public Domain Software. Binary release only.
Ignacio F. Gully TESTCFG's author
I think INSTALL= time is too late. DEVICE= lines are already processed by then.
I think INSTALL= time is too late. DEVICE= lines are already processed by then.
This is certainly true for the FreeDOS kernel (and probably MS-DOS), but not for the EDR kernel. The EDR kernel processes the INSTALL directives in the same pass as the DEVICE directives, and does so in order.
Config.sys processing differs significantly from how it is done by MS-DOS, and generally the order of the directives does matter.
But according to the source there is an INSTALLLAST, which runs at the last pass of config.sys processing, after all DEVICE and INSTALL directive have been processed, though I have not tested if this acually works.
Interesting, I did not know that. In lDOS I do COMPAT= in the very first pass, then DEVICE= as a pass, then INSTALL=, then INSTALLLAST=, then SHELL=
Within latest Novell/Caldera DR-DOS implementations, a CONFIG.SYS statement called "CPU386" was implemented to exclude driver loading which demanded a 386 or better CPU and skipped it if not present.
I do not find any reference to the CPU386 directive in the online help of DR-DOS 7.03. @igully can you please provide a reference for that specific directive?
TESTCFG is Public Domain Software. Binary release only.
How is this binary compressed? Is it done by a publically available tool?
It seems that /0 does nothing on my (dosemu2) system. /1 displays a warning about needing an "8088/86 CPU", /2 displays a warning about needing a 286 CPU, and /3 displays nothing again.
@boeckmann You can run the binary in lDebug, r, p 17, g 100, then d 100 di - 1 shows the entire depacked executable.
You can run the binary in lDebug, r, p 17, g 100, then d 100 di - 1 shows the entire depacked executable.
Thanks! I took the NDISASM approach before you wrote that (was only interested in the unpack routine). The reason I asked is that while igullys FASTOPEN executable is also packed, the depacker code seems to be different. So I wonder if it is the same packer used and / or whether the packer / depacker is some original implementation of him.
Hi, I usually use APACK 1.0 as a packer. When programs end up being smaller I use the "624" packer which has extremely little overhead and performs better. And I reserve UPX for .SYS and some TSR programs. When UPX fails on a TSR, I use as a last the resort the old and rusty PKLITE.
624 compressed files always start with "[ESP]" (without double quotes).
I am attaching the 624 packer
.
I do not find any reference to the CPU386 directive in the online help of DR-DOS 7.03. @igully can you please provide a reference for that specific directive?
I tested it working myself on DR-DOS 7.03 after reading about it on DR-DOS Wikipedia article which seems to have been elaborated by someone involved at that time in the particular section which starts: …"After beta releases in September and November 1997"...
It seems that /0 does nothing on my (dosemu2) system. /1 displays a warning about needing an "8088/86 CPU", /2 displays a warning about needing a 286 CPU, and /3 displays nothing again.
@boeckmann You can run the binary in lDebug,
r,p 17,g 100, thend 100 di - 1shows the entire depacked executable.
/3 displays nothing because you are already running on a 386 or better CPU. Which is what is expected to happen. Just shoot up an emulator session with a lower end CPU, and you should receive the same warning treatment with the 386+ being needed.
So, the idea is that you use INSTALL=TESTCFG /3 as a config.sys line before calling the offending memory manager that crashes on low end systems (like for example DEVICE=JEMMEX.EXE). So when a low-end (286 or lower cpu) user comes across it, it doesn't crash their system, and gives them a chance to do something about it). So in this way I could use a one config solution covering all cpu types.
The /1 and /2 were added just in case the need arises, as it was an easy inclusion from the perspective of the CPU detection code. Maybe, there is a use-case for them.
PTS-DOS implements a similar config.sys statement. I can't remember which of its many variants though (PTS-2000, PTS-32, Paragon 6.80, etc.).
I mentioned this ticket in https://github.com/dosemu2/dosemu2/issues/838#issuecomment-3217300437 which had a discussion about how lDOS resets the CDS upon every relocation and whenever a new block device driver is installed.
I think adding a compatibility option to handle INSTALL= and DEVICE= in the same pass will be easy, but that really should require the CDS be preserved. Otherwise installing a redirector (eg shsucdx) early would lose its drives once the CDS is rewritten.
drdos can.
I checked and yes, EDR-DOS does seem to preserve the CDS. As I learned in SvarDOS/edrdos#156 (comment) DR-DOS handles INSTALL= and DEVICE= in the same pass of processing dconfig.sys so it stands to reason it should preserve redirector drives installed by an early INSTALL= even if a block device driver is installed afterwards.
lMS-DOS resets the CDS by walking the current DPB chain every time, so it won't preserve redirector drives. If we want to support INSTALL= during the DEVICE= pass, all the more reason to preserve the CDS. However, that implies the block device installation should search for the next free drive in the CDS instead of allocating whatever drive number corresponds to the number of block devices installed yet.
I do not find any reference to the CPU386 directive in the online help of DR-DOS 7.03. @igully can you please provide a reference for that specific directive?
I tested it working myself on DR-DOS 7.03 after reading about it on DR-DOS Wikipedia article which seems to have been elaborated by someone involved at that time in the particular section which starts: …"After beta releases in September and November 1997"...
I found more information on the Caldera OpenDOS 7.01/7.02 IBMBIO.COM Update ALPHA 3 README (Last edit: 1997-09-30 by Matthias Paul):
CONFIG.SYS CPU386[+] directive added. Works similar to the (undocumented) ONERROR= directive, that is, on matching conditions executes the remaining part of the line. CPU386[+] will be executed on 386 (and higher), thus it allows for case decisions in networked environments, e.g. though using equally CONFIG.SYS files loading different memory managers on different machines. Examples:
CPU386+ ECHO This is a 386 (or higher)! :-)
or
CPU386+ GOTO 386 REM Assuming a 286 here... DEVICE=c:\opendos\HIMEM.SYS ... GOTO continue :386 DEVICE=c:\opendos\EMM386.EXE ... :continue REM ...
or using some special (undocumented) CONFIG.SYS directives:
ERROR 0 CPU386+ ERROR 3 ONERROR >= 3 GOSUB 386 ONERROR >= 2 GOSUB 286 ONERROR >= 1 GOSUB error GOTO continue :error ECHO Sorry, no memory manager loaded... :-( RETURN 0 :286 DEVICE=c:\opendos\HIMEM.SYS ... ONERROR > 0 RETURN 1 RETURN 0 :386 DEVICE=c:\opendos\EMM386.EXE ... ONERROR > 0 RETURN 2 RETURN 0 :continue REM ...
ToDo: At present, CPU386 and CPU386+ work similar, which may change in the future (for better compatibility with PTS/DOS). We also could add more directives like this, but we'd to develop very reliable detection algorithms for all the various CPUs out there.
For this I have no problems in providing fully tested assembler code that accurately detects the following CPUs:
cpu_8088 cpu_8086 cpu_V20 cpu_V30 cpu_188 cpu_186 cpu_286 cpu_386 cpu_486 cpu_Pentium "Pentium or better", In this last case, it will also indicate stepping, model and processor family which if queried against a database (which I haven't implemented) can further point out which specific processor is that one.
I am attaching a working program using that code. Program is Public Domain. Use CPUDET /? for usage details.