Why not use the @echo off syntax, then simply use the cls command to
clear the screen before moving on to the later pieces of the autoexec.
It then won't show the @echo off command onthe screen.
The caveat of course is that all driver messages also get erased, but
that may or may not be an issue depending on what you're loading, and
how important it is to see those messages.
The other solution may be to put the ver command into a variable, then
check that to see if the @echo off will work.
Barring those solutions, you could always redirect the @echo off line to
null, which would prevent it from displaying on the screen.
Honestly I'd love to have a setup like yours, that would be the best toy
ever.
Did you ever purchase PTS dos? That could be another one to add to your
list of os versions as well.
I don't know if paragon still offers PTS dos for sale or not, but since
it is one of the few commercial dos clones that comes with source, it
may be worth asking them if you're interested. I've had my version for
many years, and I'm always paranoid of loosing my source files, so I
always make sure I have several backups to ensure I don't loose them,
and I don't remember exactly when I bought my copy of PTS dos, but I
think it was round the 99/2000 timeframe.
I like it pretty well when dos is required for something, PTS dos is
usually the one I use, since I did manage to loose my sources for
opendos, which is a real shame, because I downloaded those when it was
being offered freely with a license file and everything. :)
On 2/25/2022 8:54 PM, Bret Johnson wrote:
This question is more about DOS in general than specifically about FreeDOS.
But, there are enough experienced and creative users around FreeDOS that
someone may be able to help me come up with a solution.
I have a large set of DOS environments I use for testing. Basically, I have a
bunch of different versions of DOS that I can boot to (MS-DOS, PC-DOS, FreeDOS,
DR-DOS, from versions 3.0 to the latest of each). DOS versions 1 & 2 were so
lackluster that I don't bother even testing with them. I have a copy of the
commercial program called System Commander which allows me to install and boot all
these different versions of DOS from a single partition on a hard drive. I know
there are other ways to accomplish the same feat, but I bought a copy of System
Commander a long time ago so that is what I use.
I have all these DOS's installed on a Virtual hard drive so that I can run them
in different Virtual Machines with different types of CPUs (from the lowly 8088
all the way up to modern CPUs). Again, this is a test environment so that as I
write programs I can verify they work whenever and wherever they're supposed to.
On the Virtual hard drive part of what System Commander does as you boot is "restore"
the hidden boot files (IO.SYS & MSDOS.SYS for MS-DOS, IBMBIO.COM & IBMDOS.COM for PC- and
DR-DOS, or KERNEL.SYS for FreeDOS), along with the COMMAND.COM, CONFIG.SYS, and AUTOEXEC.BAT
files so that the virtual machine boots with the correct test environment.
The problem is that the older versions of DOS don't work exactly like the newer
versions, particularly when it comes to batch files. For example, prior to DOS
version 3.3 you couldn't CALL one batch file from another, and also prior to
DOS version 3.3 you couldn't use the @ symbol at the beginning of a line in a
batch file to hide the output of the line (sort of similar to what happens with
the ECHO OFF you normally put at the beginning of batch files but the @ symbol
only works for a single line instead of the entire batch file like ECHO OFF
does).
So, I have a relatively short AUTOEXEC.BAT file set up for each OS I boot, which is unique to each OS. The main thing this small
AUTOEXEC.BAT does is set up some environment variables to identify the OS that booted which can be used later in other batch
files. At the end of the "simple" AUTOEXEC.BAT file, I then jump to a "master" AUTOEXEC.BAT file that is
common to all the booted DOS's. Because each version of DOS is a little different, the "master" AUTOEXEC.BAT file
needs to do some "IF-THEN" scenarios based on which version of DOS is running. I want the overall environment to be
pretty much the same (as much as I can, anyway) no matter which DOS is running. Having a "master" AUTOEXEC.BAT file
lets me make most of my changes in one common place instead of needing to do the same thing a bunch of different times for each
DOS version.
One problem I haven't figured out how to handle correctly is the ECHO OFF vs @ECHO OFF issue. In older versions of MS- and PC-DOS (prior to version 3.3),
and all versions of DR-DOS, the "@ECHO OFF" command does not work at the beginning of batch files. You need to use a simple "ECHO
OFF" instead. If they see an "@ECHO OFF" they display an "unknown command" error (it tries to find an executable files called
"@ECHO"). I'm trying to figure out a way for all the "common" batch files (all batch files other than the small AUTOEXEC.BAT file) to
detect whether they can put the "@" at the beginning of the line or not to keep the screen from getting unnecessarily cluttered and confusing.
I cannot figure out a way to do this. I'll go through some of the things I've tried (to no avail -- the all put "unnecessary stuff on the screen).
I've tried creating an ECHO environment variable. With older versions of DOS:
SET ECHO=ECHO OFF
and with newer versions of DOS:
SET ECHO=@ECHO OFF
then at the beginning of all batch files I put a:
%ECHO%
That works with older versions of DOS but not newer versions. With newer versions, it sees the "%" at the beginning of
the line instead of the "@" and looks for an executable file called "@ECHO" instead of seeing the
"@" as the "hide this line" character.
Another option would be to create an actual @ECHO.BAT file and always put an @ECHO as the
first line of all batch files, but that won't work either. The "@ECHO OFF"
line will show up on the screen (which is what I'm trying to avoid), and in addition you
must CALL the @ECHO.BAT file instead of just running it. And you can't use CALL in older
version of DOS.
I've also thought of trying to use aliases/macros with ANSI or DOSKEY (or
clones of those) but that won't work either. ANSI will only create
aliases/macros for single characters (not entire words like ECHO or @ECHO), and
DOSKEY (or a clone) macros only work at the
command-line and not in batch files. Something like aliases in FreeDOS or 4DOS might
work (I'm not sure), but that defeats the purpose of the testing which requires
"native" DOS versions.
I'm stumped. Right new it seems as if my only viable option is to always use "ECHO OFF"
instead of "@ECHO OFF" and just live with the cluttered screens in later versions of DOS
even though they could be avoided if I wasn't trying to boot so many old DOS's on the same machine.
I realize this is a minor issues in the grand scheme of things, but would still
like to figure out a solution if there is one. It's also interesting when you
experiment with the different DOS's to see what kinds of compatibility issues
there are. I've found DR-DOS isn't nearly as compatible with MS-DOS as it's
supposed to be. I've also heard/read that MS-DOS and PC-DOS were for all
practical purposes exactly the same up through version 6.1, but I've found that
not to be true either. From a compatibility perspective, FreeDOS is actually
pretty good (not perfect, but definitely better than DR-DOS).
Anyway, any other ideas on how to resolve the ECHO/@ECHO issue?
_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
