'FreeCOM User' writes:
I am impressed by your email as it discusses one very critical area of the overall 'smooth' operation of DOS which are correctly executing BAT files. More importantly are correctly written BAT files. The primary point in question though is more out of all the bat files CURRENTLY written, how many will run without any errors?
There's 2 thoughts to this, the first is running such bat files against a current build of FDOS (say the RipCord edition or the latest release on a bottable CD). How do the BAT files run, but remebering that you should NOW be labeling your bat files by number so you can MARK the ones that passed/failed. People in general do not give as much credit to the power of bat file processing as they should. In stead of waiting for a bug to get fixed, just KNOW the propblem exists and get on with the task of testing & labeling your BAT fill collection. Besides, you want to know where things currently fail, so that can be addressed and fixed (possibly even automatically).
Secondly, such bat files you have the more direct question is running such bat files against different ... though I hate to say it ... different versions/flavours of DOS (I currently count 8 each having between 1 to 4 different primary releases [4.x,5.x,6.22 etc.]). One cannot say though ...
"Well this bat file runs ok on PC-DOS and its called main.bat, so I guess we'll use that dos operated gravel moving machine over there as the DRDOS one didnt echo HI correctly."
So what to do about "compatability" with DOS, what IS the bench mark we can use to find a DOS that runs everything? Well I'd like to answer that now, but I'll wait a few months.
Until then, I still want to point out one of Thomas's view points as I totally agree with the one part he said ...
A) is definitely breaking compatibility with existing (and complex) batch files
The part in brackets is the MOST important test for DOS itself as being a primary platform to operate BAT operations on. It's ability to run "complex" bat files successfully is much more important than before as there are systems now (and ones in development) that run DOS as thier primary OS. Telephones and even allot of the palm type handhelds are using DOS in thier oprtation. Nokia has a number of DOS executable programs that turn ON and OFF the backlight on some of thier cell phones. there are more examples I can list, but the point is DOS is being used now more in smaller electronics than ever before. Having the knowledge that you can run complex BAT code without any stress, will be makijng DOS a very desirable platform. BAT code to me can do that much (if you have the tools available)
Placing DOS in smaller devices and operating large scale physical world objects (opening a draw bridge) is not happening as much as it WILL be in the up comming years. A BAT file can move any part robotically via the serial/paralell port, even if it weights several tonnes. TRUSTing that this process will not fail is what will make/break DOS moving into serious imbedded "everything-on-one-pcboard" systems.
Not that I'm trying to make this sound scarry or something DOS can do allot of things, the whole point is that if we begin writting BAT code seriously again, the whole DOS community is going to want (and should) have a functional, powerful, and robust BAT operating environment.
Again a quote from the retired freecom developer Mr. Hirsch (hay he said he quit) ...
A) FreeCOM IF/FOR and Redirection (does not work like ms-dos))
link at http://www.freedos.org/bugs/bugzilla/show_bug.cgi?id=1469
I read the report in full along with all with the comments. Here are my simple thought's about the reported bug.
I have also seen the same things regarding the redirect with the IF command. Another fellow here in Topica commented a few weeks/months about that already. I agree it does not redirect like that with the current FreeCOM (I call PL1-wXMS swap). My problem with redirecting first started with an older version of FReeCOM. I could not get the FOR loop to redirect to NUL correctly (it kept generating output to the screen when using COPY). The latest PL1 FreeCOM version this problem went away in most cases though I implement a work around should it generate output I dont want the user to see ... change the screen to black-on-black! I have 2 bat files, BLACKON and BLACKOFF. They works great. Sometimes not reporting a problem lets it get fixed itself since I figured redirection was already an issue with the FreeCOM developers, anyway, it works better NOW in PL1 command.com than it ever did, so thats positive news right there.
My advice on using the IF? Use an 'actual' IF and FOR program written for DOS (its what I use for complex statements). Branching in a BAT file is quite important, ESPECIALLY when your trying to perform complex logic in 1 IF statement. Having the power of ELSEIF (even CASE with logic to branch into the CASE itself) is one of the most CRITIAL things a BAT file can have access too. Obviosly the FreeCOM IF cant compete with an IF program thats been worked on over the past few YEARS. Heres some thoughts about things you want when doing the examples like the bug report #1469 talk about
I use every tool I have to get the capture output & file creating I want regardless when I'm using FreeCOMs or external IF/FOR statements.
a) I use a LOG program that captures any output and puts it into a file, regardless of size or run duration. Using > ... like yes it works, but is that really the WAY to cature important data being generated by a program? I think not. Using >> to append? Sorry copy file1+file1 is the way as you ALWAYS must ensure if your wanting binary or text MURGE of the two files (append to the start or to the end of the file).
b) A FILEMAKE that creates blank files and 0-bytes a file if it already exists (a HUGEly powerful delete this program also doubles for, as if you know what 0-byting does over a DEL command then you'll understand). Never let an IF create a file by a redirect, use a program to do this. Again though this allllll comes back to, HOW can I doo all this in ONE if command ??? Stressful as it was to make complex ones in the first place, you didn't have a nice tool set to rely on to makeing branching and redirecting easy. That will come.
c) STRINGS (v2.6 only), need I say more about this one? Its almost commong now to perform a STRINGS command and always base the IF on the environment variable you pick. Example it can detect if a file exists, the date of it, name, a whole PILE of funtions, that 'basic' dos programmers would attempt to incorporate into the single IF command.
d) PREPROCESS the IF into variables to test and break the step the IF file is doing in to steps. Think about it a little, why cram 5 operations into a single command. Example : IF no file exists make the file, and capature the contents of 2 files and dont fail if one of the files doesnt exists during the redirect which may be > or even >> etc etc etc, all into 1 line of code. If I was using that link to operate a door release hatch on a 747, I'd really question how GOOD that code will be when it needs to run 2 times every flight. Whats the backup the same but in a FOR loop? Its ok to have a bunch of steps performed and have the IF nothing for that checking for a TRUE/FLASE flag and do a GOTO. Why teachers continue to practice saying GOTOs are bad ... well they are GOOD, the LABEL you use is a different matter, especially when no nameing standards have relly been set.
e) to z) : a while bunch more tools including colour and sound
Closing the thought on this, I cant bash anything the IF anf FOR currently provide. They both work for me, AND I know that if I want to create important files or record output there are much better ways of doing such tasks. The problem is you currently dont have access to such cool programs. Summer time might harvest out some nice ones.
On the less positive side of FreeCOM, what I would love is a flag telling the command.com NOT to use its interal command, but to bypass and let it run a better program (so I dont have to do bat re-codding). Any command would be nice to bypass, PAUSE is a really good example ...
I use the HOLD command (its nonFDOS a program) instead of the PAUSE command. HOLD sees the mouse (if installed) and both left and right buttons allow the pausing of processing to continue (you can still press any key to continue as well, its just like a really enhanced pause). The problem here again though is if I code the word PAUSE (without specifing an exact program PAUSE.COM to run for example if I renamed the hold.com), the interal PAUSE command is run and only the keyboard (or stuffing the KB buffer if your good) can be used to break the pause. As always I like to provide a real world example, if DOS was the OS for a power trigger operated screw driver, the HOLD can see the TRIGGER mechinism itself (via the trigger is installed and seen as a mouse) to allow for FORWARD or REVERSE to fire without having to use data from the keybard to process. Point is take DOS to the next level in BAT coding, but once you get the right BAT making environment and tools to generate nice BAT programs.
I'd like to bring up one more example, the DIR command with FreeCOM, WHICH I may add now has ordering working! GREAT JOB for getting that done, you have no idea how I feel that was needed to get implemented. Redirecting DIR contents to spool files in the order you want has also been important, regardless of the OS your using. I again use other DIR type programs to get more ... well more of what I'm looking for should FreeCOMs dir not have everything. Something I did want FreeCOM to do is ALWAYS use yyyy format (default should always be with the /Y to show the full 4 digit year, it isnt). My quick solution (and is pretty much required) is a DIR.BAT that passed the /Y always. Works great, not the best, but my redirects always are [Y2K-OK]. The env variable I even use for a time is 00:00:00.00, there are not as many standards set for time as for the date. However a 4 digit year is JUST as important as millisecond timing which is always traced in FDOS accuratly, hence I always code 4 digit for the year. How many BAT files currently written have the /Y in the code? ahahhahahah ya that's about the same small number I thought, no calculator required there.
I love DOS bat coding, for some reason done right, its like coding in a whole new language, except using allot of nice dos programs for utilities, you CAN make your BAT code very complex and FAR more reliable than any m$dos configuration could match (file cutting and parsing included). You just cant do that with something that aims to be 100% M$DOS compatible. Think of what the future of BAT coding will be and you will see that we unfortunatly were stuck in a 1 line IF statement to do everything. Thats 100% compatability, which I dont conform too. Not enuf programming power in the least, but like I had said earlier, wait a little bit.
This 100% compatability your reffering to is for the next generation of DOS comming. As of the dawn of 12:00am Dec 31/2002, dos is now in the control of us (awsome mistake by M$, but so be it) , WE in the coding community can make the IF/FOR statements run better than it ever did before. I personally dont want to see FreeCOM 100% like it was, how horrible a thought. However without the cool tools, its just not possible. New tools are comming.
Much like any email reply should be I always like to share my views on what some had said, why reply if your not going to talkabout everything a little bit. Thomas's points out ...
B) fdxms: Does not work with MS smartdrv.exe
Good, I'm glad it doesnt work. I dont use a disk cache program of anykind, though I have tried the FDOS one and it operates without much speed delays or memory interuption. It didnt crash put it that way so its an incedible good start no doubt. Why don't I really care about that smartdrv product? Its FAR to important a critical system should it fail. It would hault the computer no doubt and its always running caching data when the time could be spent running the task at hand. I love hard drives don't get me wrong, but this is almost like the IF problem. USE a better and more correct way of solving the problem, but doing it even more RELIABLY, use a physical hard drive memory cache controller. Having sims the size of a stich of gum that can hold 128M of data (which easialy can fit on the bottom of the hard drive itself), is a much better an idea than trying to make a 128M XMS cache. Enuf said about that, don't use it, having a 10+k byte environment space is much more import.
I guess thats enuf writting from me, I didnt proof read allot of this so forgive a typo or two. Had to share my thoughts, FReeCOM and the BAT world, nothing wrong about that, though I do tend to type a fair amount when talking about something that is important. BAT files are .
Annnnnnnnd I hope Sir Thomas Hirsch comes out of retirement to contine the great command.com voyage and to see the next wild wave of DOS come to be. The XMS swap takes up 5k, how much more excitment do you want (heheheh)?
The future holds something very bright Thomas, I woulnd't want you to miss it.
Thomas Hirsch wrote:
In order to get a version 1.0 I would suggest to include the following two issues in ToDo-List (As they seem to be not included)
A) FreeCOM: Bug No. 1469 (IF/FOR and Redirection (does not work like ms-dos))
B) fdxms: Does not work with MS smartdrv.exe
. . .
A) is definitely breaking compatibility with existing (and complex) batch files
B) will avoid using FD for (Network-)Bootdisks/-CDs needed to make (unattended) Installs of Windows XP, as this _requires_ use of smartdrv.sys
Many thanks to all of FD-developers. I appreciate your work verry much. Unfortunately I am no developer and will be of no help in _fixing_ bugs.