markz@microsoft.UUCP (Mark Zbiokowski) (10/10/83)
It didn't take long to discover that the environment CANNOT be expanded beyond 128 bytes. False. You cannot extend the environment beyond 128 bytes in a BAT file. This is because during the processing of BAT files, COMMAND uses the system call ALLOC to get some space to work with. DEALLOC and ALLOCing a larger block when the environment grows, fragmenting memory, causes quite some confusion in naive users (which outnumber the readers of this by > 1000 to 1). You can expand the environment to your hearts content OUTSIDE of BAT files. If you wish to execute a program in a different subdirectory than the on you are currently in, you'd better have a PATH telling DOS how to get there. Fact. Unfortunately, there are quite a few people who created BAT files that relied on a bug with the 1.0 command parsing: chkdsk.fixmydisk a: These BAT files were put into little packages and sold along with other applications. If COMMAND changed for 2.0 to do proper (ala sh) command parsing, there would be lots of unhappy naive users. Thus, the parsing scheme was left alone. COMMAND parses only one 8 character name off the command line. My programs just HANG at the end of the file... Do your programs correctly check for end-of-file on input? How does one define "end-of-file" on a system call that is documented as "read 1 byte from the console"? I suspect that your run-time support is lacking the smarts to use 2.0 system calls. Rewriting them to use handles should be trivial. Batch (.BAT) files cannot be nested. I don't recall if they could be in earlier DOS versions either. The documentation for 1.0 says that BAT file cannot be nested and cause chaining if such nesting is attempted. Changing this to do nesting would make lots of naive users unhappy with their packaged programs. Microsoft wants us to use DOS for everything. Has anyone timed the speed with which DOS writes to the screen? Is it 300 or 400 baud? Programs that output characters to the screen 1 at a time and check for ^C in between each character must certainly seem slow. Have you ever wrote a program that outputs 1 character at a crack on UNIX? If you want speed, buffer your writes and put the handle in raw mode. I currently have 30 COPIES of stdio.h and 45 COPIES of pe.pro (the key definition profiler for the Personal Editor). Too bad the software you purchased did not make full use of the OS. To make links work, you need to be able to centralize the allocation information for files. UNIX has inodes. MSDOS has the directory entries themselves. Snooping around for other directory entries that refer to the same file when performing writes is not a trivial task. The date does not always (usually) change at midnight. The IBM ROM for maintaining time presents a tick-count interface to the world. Among the information returned is a flag (not a count!) that the time overflowed the 16-bit counter. If you don't read the clock for 10 days, the ROM will say that an overflow occurred rather than how many. Having the DOS hook into the timer interrupt doesn't work either as there are many applications that steal (not link into) the timer interrupt.