Re: [Freedos-user] ECHO vs @ECHO
Liam, > On Tue, 1 Mar 2022 at 20:02, Bret Johnson wrote: >> >> Actually, no it's not. It's fairly easy with System Commander. And AFAIK, >> System Commander is the only multi-boot manager that works this way >> (manipulating the boot files instead of manipulating disks or partitions). >> Both approaches have advantages and disadvantages. > That's not the point here. > Can you roll back changes? Can you make a snapshop of one system and > then revert to it? Can you duplicate a system and send it to someone? > Can you keep backups of just one system? Can you store backups on a > server or a removable drive? > All those are trivially easy with VMs. just about everything above is close to trivial. this is DOS, and XCOPY (or ZIP) will do all of the above. now YOU explain to the rest of the world how to keep all the different systems synchronised. given that there will never be a direct communication between different VMs. fixing a program requires synching this for multiple VMs. VMs are very useful, and Bret's approach might even be to a *single* virtual machine. but Bret's problem is to have ONE program (and possibly one batch file) to be tested against multiple OS versions without too much fuss. your approach doesn't help at this. just shut up. Tom ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] ECHO vs @ECHO
On Tue, 1 Mar 2022 at 20:02, Bret Johnson wrote: > > Actually, no it's not. It's fairly easy with System Commander. And AFAIK, > System Commander is the only multi-boot manager that works this way > (manipulating the boot files instead of manipulating disks or partitions). > Both approaches have advantages and disadvantages. That's not the point here. Can you roll back changes? Can you make a snapshop of one system and then revert to it? Can you duplicate a system and send it to someone? Can you keep backups of just one system? Can you store backups on a server or a removable drive? All those are trivially easy with VMs. > As are QEMU Can with hardware assist run native code, but that is harder. Works with KVM on Linux to do it, but also harder. > BOCHS Not the same thing. This is an emulator. > PCem Also an emulator, not a VM. Also no longer maintained. DOSbox is also an emulator. These are not the same sort of tool as the 2 I mentioned, which I picked for good reasons. They are true hypervisors, they run real unmodified OSes at full native speed, and they do not not require any particular host OS. > All the VM's have advantages and disadvantages in various respects. 3 of the things you mentioned are not VMs. This makes me suspect that perhaps you are not as familiar with this tech as you think you are, and I urge you to at least evaluate it. > In addition to the VMs mentioned above, I also have others including VMWare > and DOSBox and do tests with all of them. DOSbox is not a VM. > VMWare and DOSBox are somewhat unique in that they can mount physical hard > drives instead of just virtual hard drives. As can VirtualBox. https://www.virtualbox.org/manual/ch09.html#rawdisk > There are lots of different ways to "skin the cat" and there is not one > "correct" way. There are tradeoffs and problems with every approach. But, > for what I'm trying to accomplish, I think my setup is better (at least > easier to track and maintain) than what you're recommending. I am not saying there isn't. I am saying that there are easier ways than a tool you happen to know well and be familiar with. I am not telling you you're wrong or anything, just suggesting something to make life easier. -- Liam Proven ~ Profile: https://about.me/liamproven Email: lpro...@cix.co.uk ~ gMail/gTalk/FB: lpro...@gmail.com Twitter/LinkedIn: lproven ~ Skype: liamproven UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] ECHO vs @ECHO
I normally don't use DOS < 3.3 myself, either. But I do have programs that claim to work with DOS 3.0 or 3.1 so I want to make sure they actually work where they claim to. I guess hardly anybody really uses DOS < 3.3 any more, except maybe the few people who still have working PC/XT/Jr hardware. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] ECHO vs @ECHO
> On Mar 1, 2022, at 3:29 PM, tom ehlert wrote: > [..] > I'm still surprised the > > ECHO Off | VGoToXY Up | VEcho /N /E > > line doesn't work, but as I don't care about MSDOS 3.x anyway I will > be able to live with that > > Tom +1 I don’t spend much time using MS-DOS 1 & 2 or any other < 3.3. So, I can live with it too. :-) Jerome ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] ECHO vs @ECHO
> if I wrote > anything I think it would be something that actually tries to > manipulate the ECHO state (if that's even possible without a WHOLE lot of > work). 1'st) you still get the output of your ECHOSTATE OFF program on screen, which started the whole discussion. 2'nd) there is no ECHO state variable, other then a local variable for each version and release of command. forget it. > But, I still think this provided an interesting discussion and > generated some good ideas people may be able to use in other > situations. I definitely found it interesting how the different DOS > versions handle something as seemingly benign as processing the ECHO command > in batch files. > I'll probably end up just learning to live with the screen clutter and leave > it at that. I'm still surprised the ECHO Off | VGoToXY Up | VEcho /N /E line doesn't work, but as I don't care about MSDOS 3.x anyway I will be able to live with that Tom ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] ECHO vs @ECHO
> There is one other thing to try via v8power tools. Instead of using > vgotoxy up | vecho /n /e, there is another combination to do it as > well. > > echo off | vgotoxy up | vdelete > > Anyhow, vdelete is a far simpler program than vecho. You may even > have better compatibility results. I'll try it and see, but am still not expecting it to be a universal solution, especially for DOS < v3.3. > However, you may be better off writing a HUSHECHO program that does > all of this. It could test the DOS Version and perform any > additional stuff required. As you find exceptions, just add a little > more to it. Probably only be 100-200 byte com file total even with > the exceptions. Unless I get a really strong urge for some screwy reason, I don't think I'll be writing a custom program for such a trivial and obscure issue. In fact, rather than fixing the screen, if I wrote anything I think it would be something that actually tries to manipulate the ECHO state (if that's even possible without a WHOLE lot of work). But, I still think this provided an interesting discussion and generated some good ideas people may be able to use in other situations. I definitely found it interesting how the different DOS versions handle something as seemingly benign as processing the ECHO command in batch files. I'll probably end up just learning to live with the screen clutter and leave it at that. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] ECHO vs @ECHO
>> Multi-booting all those OSes off a single partition is very *VERY* >> much a hard way of doing this. > Actually, no it's not. It's fairly easy with System Commander. +1 while I didn't use System Commander, *ALL* of us were booting multiple systems from the same disk (and possibly also partition) in 'the good old times (tm)'. it was just a problem to be solved, and all of us solved it one way or the other. no rocket science necessary. VHD's simply weren't an option. VHD's came 15 years later. >> VirtualBox is free. It runs DOS with aplomb. You could run all these >> DOS versions in separate VMs, with no overlap, and custom config >> files. > As are QEMU, BOCHS, PCem, etc. All the VM's have advantages and > disadvantages in various respects. The way I have my system set up > I only need one VHD and it will work with (almost) any VM, including > VirtualBox, and a bunch of different versions of DOS. In terms of > the amount of work it takes to set things up, I think my setup is > less work than creating 20 (or whatever) different VHDs (each for a > different OS). My setup is definitely less work than trying to > track and maintain all the different VHDs to make sure they remain consistent > with each other. +1 >> You could have a separate D: drive on a separate virtual disk, with >> the programs you're testing in it. > That's what I do now (or at least can do if I want). But, I can > also put the test program on the common VHD if I want instead of a > separate VHD (and if it's small enough I usually do that). With > your setup it MUST be on a separate VHD or I would need to copy it > 50 (or whatever) times instead of just once. So, my setup is more flexible > in that sense. >> Or you could use VMWare Server, which is freeware, and in which this >> is a built-in facility. > In addition to the VMs mentioned above, I also have others > including VMWare and DOSBox and do tests with all of them. VMWare > and DOSBox are somewhat unique in that they can mount physical hard > drives instead of just virtual hard drives. That allows you to have > similar setups in both a VM and on the real hardware (if you boot > the real hardware to DOS, which I also sometimes do). > There are lots of different ways to "skin the cat" and there is not > one "correct" way. There are tradeoffs and problems with every > approach. But, for what I'm trying to accomplish, I think my setup > is better (at least easier to track and maintain) than what you're > recommending. +1 Tom ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] ECHO vs @ECHO
> Multi-booting all those OSes off a single partition is very *VERY* > much a hard way of doing this. Actually, no it's not. It's fairly easy with System Commander. And AFAIK, System Commander is the only multi-boot manager that works this way (manipulating the boot files instead of manipulating disks or partitions). Both approaches have advantages and disadvantages. > VirtualBox is free. It runs DOS with aplomb. You could run all these > DOS versions in separate VMs, with no overlap, and custom config > files. As are QEMU, BOCHS, PCem, etc. All the VM's have advantages and disadvantages in various respects. The way I have my system set up I only need one VHD and it will work with (almost) any VM, including VirtualBox, and a bunch of different versions of DOS. In terms of the amount of work it takes to set things up, I think my setup is less work than creating 20 (or whatever) different VHDs (each for a different OS). My setup is definitely less work than trying to track and maintain all the different VHDs to make sure they remain consistent with each other. > You could have a separate D: drive on a separate virtual disk, with > the programs you're testing in it. That's what I do now (or at least can do if I want). But, I can also put the test program on the common VHD if I want instead of a separate VHD (and if it's small enough I usually do that). With your setup it MUST be on a separate VHD or I would need to copy it 50 (or whatever) times instead of just once. So, my setup is more flexible in that sense. > Or you could use VMWare Server, which is freeware, and in which this > is a built-in facility. In addition to the VMs mentioned above, I also have others including VMWare and DOSBox and do tests with all of them. VMWare and DOSBox are somewhat unique in that they can mount physical hard drives instead of just virtual hard drives. That allows you to have similar setups in both a VM and on the real hardware (if you boot the real hardware to DOS, which I also sometimes do). There are lots of different ways to "skin the cat" and there is not one "correct" way. There are tradeoffs and problems with every approach. But, for what I'm trying to accomplish, I think my setup is better (at least easier to track and maintain) than what you're recommending. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] ECHO vs @ECHO
Hi, > If I run either TEST1.BAT or TEST2.BAT with MS-DOS 3.0, 3.1, or 3.2, it > crashes. That is definitely possible. Since the earliest version of DOS I really only every used was MS 3.3, I never have worried about pre-3.3 compatibility. > If I run them with MS-DOS 3.3 or 4.01 the session looks like this: > > C:\>test1 > > > C:\> ECHO Test Line 1 > Test Line 1 > > C:\> ECHO Test Line 2 > Test Line 2 > Test Line 2 > > C:\>test2 > > Test Line 1 > Test Line 2 > Test Line 2 > > C:\> Interesting, I wonder where the duplicate “Test Line 2” is coming from. vecho does not use STDOUT to display text, it uses the BIOS. Same for scrolling, etc. > If I run them in MS-DOS 5.0 thru 6.22 the session looks like this: > > C:\>test1 > > > C:\> ECHO Test Line 1 > Test Line 1 > > C:\> ECHO Test Line 2 > Test Line 2 > > C:\> > C:\>test2 > > Test Line 1 > Test Line 2 > C:\> > > If I run them in DR-DOS 6.0 thru 8.0 the session looks like this: > > C:\>test1 > > Test Line 1 > Test Line 2 > C:\>test2 > > Test Line 1 > Test Line 2 > C:\> > > If I run them in FreeDOS 1.2 or 1.3 the session looks like this: > > C:\>test1 > Test Line 1 > Test Line 2 > C:\>test2 > Test Line 1 > Test Line 2 > C:\> > It looks like the OS is forcing a CR after execution. Which is down right inconvenient. A possible remedy would at boot set a env variable for the OS (which you probably already do). The after erasure, if not running on FreeDOS, perform a additional vgotoxy up or possible or double that vgotoxy up up. echo off | vgotoxy up | vecho /n /e if not “%OS% == “FREEDOS” vgotoxy up up > As you can see, there are extra blank lines (though that problem is not a > deal-killer), extra ECHO's, and extra DOS prompts (extra keys being > pressed) depending on the specific environment. I think FreeDOS is the only > one works the way I think it should (no extra "stuff" appearing on the screen > anywhere). There is one other thing to try via v8power tools. Instead of using vgotoxy up | vecho /n /e, there is another combination to do it as well. echo off | vgotoxy up | vdelete vdelete doesn’t display text. It literally deletes a row and feeds a blank line in from the bottom. It can be told to remove multiple lines. However, defaults to 1 line. Outside of a couple rare situations they rarely get used. So, I sometimes forget about them. Anyhow, vdelete is a far simpler program than vecho. You may even have better compatibility results. However, you may be better off writing a HUSHECHO program that does all of this. It could test the DOS Version and perform any additional stuff required. As you find exceptions, just add a little more to it. Probably only be 100-200 byte com file total even with the exceptions. :-) Jerome > > > ___ > 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
Re: [Freedos-user] ECHO vs @ECHO
On Sat, 26 Feb 2022 at 02:57, Bret Johnson wrote: > > 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. ISTM that just because you bought a $30 program years ago, you're making an awful lot of work for yourself. Multi-booting all those OSes off a single partition is very *VERY* much a hard way of doing this. VirtualBox is free. It runs DOS with aplomb. You could run all these DOS versions in separate VMs, with no overlap, and custom config files. You could have a separate D: drive on a separate virtual disk, with the programs you're testing in it. That same virtual drive could be attached to 2 or 10 or 20 different DOS VMs, so long as you didn't boot 2 at the same time. But you can't do that now anyway. It could also be attached to a Windows XP VM, and that could be networked to your host OS to get stuff in and out of the VM easily. Or you can mount the drive from Linux: https://ubuntuhandbook.org/index.php/2021/05/mount-virtualbox-vdi-ubuntu/ Or from Windows: http://www.winmount.com/ Or you could use VMWare Server, which is freeware, and in which this is a built-in facility. https://docs.vmware.com/en/VMware-Workstation-Player-for-Windows/16.0/com.vmware.player.win.using.doc/GUID-896E61F5-0865-4D3B-975E-DE476AFC7168.html -- Liam Proven ~ Profile: https://about.me/liamproven Email: lpro...@cix.co.uk ~ gMail/gTalk/FB: lpro...@gmail.com Twitter/LinkedIn: lproven ~ Skype: liamproven UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] ECHO vs @ECHO
Bret, > 3. Just let the problem happen and "fix" the screen afterwords Jerome's approach is probably the only sensible solution, like >> echo off | vgotoxy up | vecho /n /e > This to me seems like a solution that could actually do what I'm > wanting to accomplish. I may experiment with that and see what > happens. As you note, there may be compatibility issues with some > DOS versions (V8 power tools may not work with older versions of DOS). very unlikely. besides that, writing a utility get cursor position, subtract one, set cursor position, output " \r" exit is left as an exercise to the reader(s). > With batch files, including AUTOEXEC.BAT, the default is "ECHO ON", > which is backwards from what CONFIG.SYS does. Anyway, I was > wondering if it might not be a good idea in a future version of > FreeDOS to have something like a "BATCHECHO=OFF/ON" and > "CONFIGECHO=OFF/ON" setting (probably in CONFIG.SYS) to set the > default ECHO values for those, and maybe have the "@" do the > opposite of what it does now when ECHO=OFF (display a line instead > of hide it). Just a thought (maybe a stupid one). this would 'solve' the problem for future FreeDOS/FreeCOM versions ONLY. however FreeCOM has the well known @ECHO OFF feature to begin with ;) Tom ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] ECHO vs @ECHO
Hi Bret, > On Feb 28, 2022, at 6:42 PM, Bret Johnson wrote: > > This to me seems like a solution that could actually do what I'm wanting to > accomplish. I may experiment with that and see what happens. As you note, > there may be compatibility issues with some DOS versions (V8 power tools may > not work with older versions of DOS). As for compatibility, I was just referring to the “piped one-liner”. 99% of the code in the V8Power Tools talks directly to hardware or the the BIOS. The exceptions being things like loading resource (translation files), performing stdout/in (file handles, not FCBs), looking up environment variables and termination. Other than program terminate, none of that would be used in the two line “vgotoxy up + vecho /n /e” combo. So, it would definitely be good down to a very low version of DOS. I need to dig out the books to see if it would work in DOS 2.00 (exit code + PSP structure). :-) Jerome ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] ECHO vs @ECHO
Thanks everybody for the input! Lots of interesting suggestions/ideas. I think the proposed solutions generally fall into four categories: 1. Always use ECHO OFF without the @ and don't worry about it 2. Try to fix the problem before it happens 3. Just let the problem happen and "fix" the screen afterwords 4. Create distinct AUTOEXEC.BAT files for every situation and don't try to create a "master" version As far as I can tell, none of the suggestions will do #2 (at least not reliably in all cases). I think almost every suggestion that tries to do #2 just replaces the unwanted "ECHO OFF" on the screen with something else unwanted (like an "@ECHO OFF" or a "CTTY NUL" or an "IF ..."). I'll try to address my thoughts on all of them received thus far in this single response. * Mercury Thirteen: > Would it be feasible to throw together an "@ECHO.COM" application > which would manually execute a normal "ECHO OFF" line if the DOS > version is below 3.3 and simply terminate otherwise? The only caveat > to this is that I''m not 100% certain that a command executed from > within a .COM file from within a batch file like this would > work back "upstream" and turn ECHOes off for the rest of the > original batch file. I thought of this, but unfortunately it won't work. First of all, it needs to test for more than just the basic DOS version since things like DR-DOS and PTS-DOS (and even FreeDOS to a lesser degree) can get "weird" since they are not always as compatible as they should be. In addition, you would still see the "@ECHO OFF" line, so all you're doing is replacing "ECHO OFF" with an errant "@ECHO OFF" and would still need to issue a real ECHO OFF (without the "@") to actually turn ECHO OFF. An @ECHO.COM (or .EXE) file could be interesting, though, except it would actually need to legitimately tell the command/batch processor to turn ECHO OFF and I don't think there's a way to do that from inside an executable file. It would be nice if there were some INT 21h functions to manipulate the ECHO state (and perhaps also other things like determining if you are running from a command-line or batch file or being EXEC'd from another program, or determining the state of the CALL stack if being run from a batch file, or other similar things) but none of that exists. An executable file could manipulate the screen (similar to the V8 Power tools suggested below by Jerome) but since it can't actually manipulate the ECHO state it won't do any good. * Jose Senna: > I have not used any DOS for some months but, as far as I > remember, @ECHO OFF worked with DR-DOS 5. I don't have DR-DOS 5 installed. But I do have DR-DOS 6, 7, and 8 installed and the "@" trick does not work with any of those. It's conceivable it works with DR-DOS 5, but I really doubt it. * Jim Hall: > The simplest solution is to use ECHO OFF without the @ at the start > of your BAT file. That will work everywhere. If you don't like > seeing this line on the screen at boot, you could run CLS after > that. Running a CLS afterwords is sort of a "nuclear option" to fix a small problem. I normally want to see all the output of the various programs and CLS blows away everything, including things I want to see. Jerome's V8 power tools suggestion below I think is a better option than CLS since it only does a "selective cleaning", but it's definitely more complicated than a simple CLS. > I suppose another way to solve this is with a simple tool that > detects the DOS version. Unfortunately, this would not be a "simple" tool. I've never seen a tool that reliably detects all the different manufacturers and versions of DOS. If there's one out there, I've not seen it. > So your MKENV program would detect the DOS version and write a BAT > file that looks like: > > SET VENDOR=MS > SET MAJOR=5 > SET MINOR=0 That's what I do now (albeit manually) with the individual AUTOEXEC.BAT files (except I call the environment variables DOSMfg, DOSMajor, and DOSMinor), but same idea). > If you need AUTOEXEC to do different things depending on the DOS > version, you could carry the MKENV idea further by having a set of > "stubbed" AUTOEXEC files like AUTOEXEC\MS50.BAT, and so on for other > versions, that you could load as needed. But I'll leave that for > you. Again, that's basically what I'm doing now, except in the reverse order. I do the OS-specific stuff in a small AUTOEXEC.BAT file and the jump to the "master" or "common" AUTOEXEC.BAT file. Your suggestion is to try and create more levels of complication (more "levels" of batch files) instead of creating a "master" like I'm trying to do. The problem with that is when I want to make a "global" change to what I'm trying to do (like add or remove one more utility to all OS's while
Re: [Freedos-user] ECHO vs @ECHO
>> in addition, neither I nor you know if 'CTTY NUL' works on MSDOS 3.0 > The original requirement was MSDOS <3.30. > I tested with MSDOS 3.21 and it worked. > Test with MSDOS 3.0 was okay too. correcting myself, CTTY NUL probably always worked, from MSDOS 1.0, as MSDOS was supposed (I never tested) to be able to run on a serial terminal. so CTTY COM1 would redirect input and output to COM1. and you could move the cursor on the screen (and other stuff) using ESCape sequences. ANSI.SYS was used to simulate this (I think a VT100 terminal) on the CGA display, so software could be written that would work 'everywhere'. Tom ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] ECHO vs @ECHO
Hi tom, >> Once you have debugged ALL your batch files you can place `CTTY >> NUL' before the command(s) and `CTTY CON' after to avoid output to screen. > > > excellent idea. > > now you have exchanged the annoying > > echo off > > for the much better > > CTTY NUL Indeed. > in addition, neither I nor you know if 'CTTY NUL' works on MSDOS 3.0 The original requirement was MSDOS <3.30. I tested with MSDOS 3.21 and it worked. Test with MSDOS 3.0 was okay too. But as you already mentioned above, it won't help to prevent display of the first line of a batch file. Cheers, Robert -- +++ BTTR Software +++ Home page: https://www.bttr-software.de/ DOS ain't dead: https://www.bttr-software.de/forum/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] ECHO vs @ECHO
Hallo Herr Bob Pryor, am Sonntag, 27. Februar 2022 um 06:44 schrieben Sie: > Once you have debugged ALL your batch files you can place `CTTY > NUL' before the command(s) and `CTTY CON' after to avoid output to screen. excellent idea. now you have exchanged the annoying echo off for the much better CTTY NUL in addition, neither I nor you know if 'CTTY NUL' works on MSDOS 3.0 Tom ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] ECHO vs @ECHO
Once you have debugged ALL your batch files you can place `CTTY NUL' before the command(s) and `CTTY CON' after to avoid output to screen. See below to find how to chain/call another batch file. Place the 'CTTY CON' first so you don't forget! You need to be sure there are no interactive commands and no errors stopping processing between them. I used this in the 1980's-1990's to keep my kids from messing with the text-based menues I setup for them. [Lost the citation for this one] (Note that these two commands must be used in a batch file because typing `CTTY NUL' would transfer control away from your keyboard and monitor, thus no input from the user would be recognised when typing `CTTY CON' afterwards.) https://everything2.com/title/CTTY Another difference between using CTTY and conventional redirection is that CTTY will redirect stderr as well as stdout. If there is an error in the batch file that prevents the whole file from being processed, then the CTTY CON may never be executed, rendering the system unusable. https://web.archive.org/web/20070503163833/http://www.chips.navy.mil/archives/96_oct/file14.htm The usual CTTY NUL command won't work since it's only good in AUTOEXEC.BAT files, and that's too late in the process. We needed an equivalent command in the CONFIG.SYS file. The syntax for our CONFIG.SYS file is: SHELL C:\COMMAND.COM NUL /E:1536 /P. The first command in the AUTOEXEC.BAT file is: 'echo off'. We placed CTTY CON as the second command in the AUTOEXEC.BAT file which sets the I/O back to the keyboard and monitor. CONFIG.SYS REM Set environment to 1536 and direct console I/O to NUL. SHELL=C:\COMMAND.COM NUL /E:1536 /P AUTOEXEC.BAT echo off REM Re-establish normal console I/O (i.e. change NUL to CON) CTTY CON This is documented back to PC-DOS 2.0. Type COMMAND /? to see that the second optional parameter to it is a device name, used for input and output. https://www.robvanderwoude.com/command.php COMMAND NUL /C some.bat [??? COMMAND NUL /C call some.bat] [It should stay NUL until the chain/call ends, then return to CON.] COMMAND NUL /C gives the same results as CTTY NUL CTTY CON https://en.wikibooks.org/wiki/First_steps_towards_system_programming_under_MS-DOS_7/Internal_commands#3.07_CTTY_–_redirection_of_I/O_links CTTY command affects only implicit I/O settings, but it doesn't affect redirections, which are specified in command lines explicitly. For example, let's consider the following piece of a batch file: @ctty nul copy /B Trial.dat Suit.dat echo Press any key to exit > con pause < con ctty con Here a message from the COPY command will not reach the screen, even if it will be an error message. But the message "Press any key to exit" will be shown, because it is directed to the CON device explicitly. The next PAUSE command will work properly too, because its input is explicitly linked with keyboard. This form of CTTY usage needs some caution, but opens attractive opportunities to affect interaction with the user. Note: Having been banned by CTTY NUL command, the STDERR messages can't be redirected explicitly and are lost. On Sat, Feb 26, 2022 at 10:10 AM wrote: > On 26 Feb 2022, 02:54, Bret Johnson wrote: > > 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. > > > Anyway, any other ideas on how to resolve the ECHO/@ECHO issue? > > I don't think that this can be solved -- because there are so many > different command interpreters out there, and every one acts at least a > tiny little bit differently... > > I just tried "SET ECHO=@ECHO OFF" and "%ECHO%" in a batch file with 4DOS > (a replacement for the COMMAND.COM command interpreter of any given DOS) > and it worked. > > How about using 4DOS as a default SHELL, i.e. set SHELL= in CONFIG.SYS > (you already rely on SET ECHO for your batch files...) and this will > solve your issue on every DOS, regardless of the exact version. > > A. > > > ___ > 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
Re: [Freedos-user] ECHO vs @ECHO
Hi Travis, > 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 wrote mails to Paragon/PhysTechSoft several times, but never got ANY replies. Cheers, Robert -- +++ BTTR Software +++ Home page: https://www.bttr-software.de/ DOS ain't dead: https://www.bttr-software.de/forum/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] ECHO vs @ECHO
On 26 Feb 2022, 02:54, Bret Johnson wrote: 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. Anyway, any other ideas on how to resolve the ECHO/@ECHO issue? I don't think that this can be solved -- because there are so many different command interpreters out there, and every one acts at least a tiny little bit differently... I just tried "SET ECHO=@ECHO OFF" and "%ECHO%" in a batch file with 4DOS (a replacement for the COMMAND.COM command interpreter of any given DOS) and it worked. How about using 4DOS as a default SHELL, i.e. set SHELL= in CONFIG.SYS (you already rely on SET ECHO for your batch files...) and this will solve your issue on every DOS, regardless of the exact version. A. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] ECHO vs @ECHO
It seems trying to redirect the echo off command (at least under windows in a cmd prompt) does indeed create the echoed test on the screen because of the STDERR being directed to the screen as stated above. Regular echo commands however do redirect just fine I'm fairly certain though that at some point I did solve this issue, and I'd seriously thought it was via redirects. Perhaps other dos versions (PTTS/open handle things differently, though I'd not expect it. I don't currently have either one of those environments available for testing though, so can't say for sure if they'd behave identically or not. On 2/26/2022 9:37 AM, Travis Siegel wrote: On 2/26/2022 9:14 AM, Mateusz Viste wrote: On 26/02/2022 15:09, Travis Siegel wrote: Barring those solutions, you could always redirect the @echo off line to null, which would prevent it from displaying on the screen. It would not, since the error message is output to stderr. That's not been my experience, but it has been a while since I've used MSDOS, so perhaps on that particular version, your statement is true. I've generally stuck to PTS dos, or opendos where ever possible, and redirecting batch file output to null works just fine on those dos versions. (at least it did when I last used them, which admittedly has been a few years). ___ 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
Re: [Freedos-user] ECHO vs @ECHO
Hello Have you tested with a command with @ ex:. @dir ? On Sat, Feb 26, 2022 at 1:57 AM 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 >
Re: [Freedos-user] ECHO vs @ECHO
Oh, one more thing... It could also possibly be a one-liner, like so: echo off | vgotoxy up | vecho /n /e But, it will display all of that before erasure. Also, I have no idea if there would be compatibility issues under some DOS platforms or their different versions. But, it works fine in FreeDOS as a one-liner. :-) ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] ECHO vs @ECHO
On 2/26/2022 9:14 AM, Mateusz Viste wrote: On 26/02/2022 15:09, Travis Siegel wrote: Barring those solutions, you could always redirect the @echo off line to null, which would prevent it from displaying on the screen. It would not, since the error message is output to stderr. That's not been my experience, but it has been a while since I've used MSDOS, so perhaps on that particular version, your statement is true. I've generally stuck to PTS dos, or opendos where ever possible, and redirecting batch file output to null works just fine on those dos versions. (at least it did when I last used them, which admittedly has been a few years). ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] ECHO vs @ECHO
Well, I guess I’ll put in two cents worth of a non-standard solution… If you don’t want to have the “echo off” on the screen and don’t want to clear the screen either, you can do it using two utilities in V8Power tools (available and provided with FreeDOS). It would look something this… —— TEST.BAT —— echo off vgotoxy up vecho /n /e echo hi —— END —— So what happens is this: echo off# displays the command echo off vgotoxy up # moves the cursor back up one line vecho /n /e # tells vecho not to perform a CRLF when finished and tells it to clear everything from the cursor to the end of the line. echo hi # prints hi where “echo off” originally was located. While technically, echo off is printed then erased. It happens very quickly. Also, if you redirect output to a file, you will see the “echo off” that appears first. :-) Jerome ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] ECHO vs @ECHO
On 26/02/2022 15:09, Travis Siegel wrote: Barring those solutions, you could always redirect the @echo off line to null, which would prevent it from displaying on the screen. It would not, since the error message is output to stderr. Mateusz ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] ECHO vs @ECHO
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
Re: [Freedos-user] ECHO vs @ECHO
Hi Bret The simplest solution is to use ECHO OFF without the @ at the start of your BAT file. That will work everywhere. If you don't like seeing this line on the screen at boot, you could run CLS after that. I suppose another way to solve this is with a simple tool that detects the DOS version. You said that the AUTOEXEC sets some environment variables needed for later BAT files. So write a simple tool that detects the DOS version and writes a BAT file that your AUTOEXEC then runs. Not all DOS versions can CALL a BAT from one another, but a BAT can certainly execute another BAT. So maybe your last two lines in AUTOEXEC look like: MKENV env.bat ENV.BAT (That example suggests you might list the BAT filename to save to. Or the tool could write to stdout and you use redirection. Whatever.) So your MKENV program would detect the DOS version and write a BAT file that looks like: SET VENDOR=MS SET MAJOR=5 SET MINOR=0 If you need AUTOEXEC to do different things depending on the DOS version, you could carry the MKENV idea further by having a set of "stubbed" AUTOEXEC files like AUTOEXEC\MS50.BAT, and so on for other versions, that you could load as needed. But I'll leave that for you. On Fri, Feb 25, 2022, 7:57 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
Re: [Freedos-user] ECHO vs @ECHO
Hallo Herr Mercury Thirteen via Freedos-user, am Samstag, 26. Februar 2022 um 03:47 schrieben Sie: > Would it be feasible to throw together an "@ECHO.COM" application > which would manually execute a normal "ECHO OFF" line if the DOS > version is below 3.3 and simply terminate otherwise? The only caveat > to this is that I''m not 100% certain just because this is complete nonsense? Tom ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] ECHO vs @ECHO
Would it be feasible to throw together an "@ECHO.COM" application which would manually execute a normal "ECHO OFF" line if the DOS version is below 3.3 and simply terminate otherwise? The only caveat to this is that I''m not 100% certain that a command executed from within a .COM file from within a batch file like this would work back "upstream" and turn ECHOes off for the rest of the original batch file. Sent with ProtonMail Secure Email. --- Original Message --- On Friday, February 25th, 2022 at 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
