CPU386 config.sys statement not implemented.

[igully]

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

TESTCFG.ZIP

[ecm-pushbx]

I think INSTALL= time is too late. DEVICE= lines are already processed by then.

[boeckmann]

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.

[ecm-pushbx]

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=

[boeckmann]

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?

[ecm-pushbx]

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.

[boeckmann]

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.

[igully]

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.

[igully]

624 compressed files always start with "[ESP]" (without double quotes).

I am attaching the 624 packer

624.zip

.

[igully]

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"...

[igully]

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.

/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.).

[ecm-pushbx]

I mentioned this ticket in dosemu2/dosemu2#838 (comment) 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.

[igully]

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.

[igully]

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.

CPUDET.ZIP