Shareware Grab Bag

home *** CD-ROM | disk | FTP | other *** search

/ Shareware Grab Bag / Shareware Grab Bag.iso / 098 / undoc.dqc / undoc.doc

Wrap

Text File | 1983-12-25 | 10.9 KB | 271 lines

D O S A N D M S D O S P R O B L E M S This is a list of PCDOS and MSDOS peculiarities, etc. You will have to guess from the text what the particular questions were, but you systems programmers will find it worth your while to rummage through it all. ........................................ There is a problem of compatibility between MS-DOS and IBM PC-DOS having to do with FCB Open and Create which has finally been tracked. The IBM 1.0, 1.1, and 2.0 documentation of OPEN (call 0FH) contains the following statement. "The current block field (FCB bytes C-D) is set to zero [when an FCB is opened]." This statement is NOT true of MS-DOS 1.25 or MS-DOS 2.00. The difference is intentional, and the reason is CP/M 1.4 compatibility. Zeroing that field is not CP/M compatible. Some CP/M programs will not run when machine translated if that field is zeroed. The reason it is zeroed in the IBM versions is that IBM specifically requested that it be zeroed. This is the reason for the complaints from some vendors about the fact that IBM MultiPlan will not run under MS-DOS. It is probably the reason that some other IBM programs don't run under MS-DOS. PROGRAMMERS NOTE: Do what all MS/PC-DOS Systems programs do: Set every single FCB field you want to use regardless of what the documentation says is initialized. ........................................ a) It seems there is a maximum of 19 handles, no matter what the files parameter is set to. Is this really the case? What does one gain by setting files to less than 19? Is memory for handles allocated dynamically? There is a maximum of 20 handles per process no matter what the files parameter is set to. There has to be a table in your process header for your handles, there is a limited amount of space down there. 40 bytes or so are taken up by each system FCB, setting files to less than 20 saves a little bit of memory. Memory for handles is not allocated dynamically, in general an attempt to do so would fail anyway. Recall that .COM files and most .EXE files are given the biggest piece of memory possible when they are EXECed because the DOS cannot make assumptions about how much memory these programs really use. This means they typically get ALL of the free memory, that means there is no free memory to allocate dynamically. You will find that almost all operating systems (CP/M is about the only exception) have a limit on the number of open files. MS-DOS has a limit of 20. CP/M has no such limits because it requires the user to keep FCBs in his own address space, managing FCBs is a pain. You get simplicity and you give up very little. What program needs more than 20 open files? If you can think of one, it is probably a poorly written program in that it probably only needs a few open files at a time and doesn't bother to close files after it's done with them. b) Execing a program eats 5 (I think) handles per try. Is this the passing of parent's environment that is mentioned (very briefly) in the documentatio n? What are these handles? They don't seem to be allocated with system calls, either. Is that true? std-in, std-out, std-err, std-aux, std-prn. I suppose you would like your program to be able to use the 1-12 system calls? That means there have to be 5, the first three are standard UNIX style fair and are required for the software tools approach to programming. Std-aux and Std-prn are required for system calls 3,4, and 5. Just because you are handed these default handles doesn't mean you can't close them. ........................................ "... 1) what exactly is meant by the dos being in an unstable state. (This is what the documentation says happens if one returns to a user program directly from an int 24 handler.)..." It means that the DOS has the notion of an error being in effect. All printer echoing is turned off, and some other stuff doesn't work. Also, there are dirty buffers that are not correctly flushed out. Thus the disks may not be consistent. "... 2) my experimentation shows that an abort from a hard error handler causes an int 22 without the value for int 22 being sucked out of the program header. every other way out of a program uses the terminate address in the header. is this difference intentional? Why? DOes one expect the value at int 22 to be different from the value in the header ever?..." False. No INT 22h is ever issued. The header is only used to save the previous process' vectors. The address contained in INT 22 is saved in a temp spot, the contents of INTs 22-24 are restored from the header, and then an indirect jump is taken through the temp location. Certain programs (such as COMMAND) may want to intercept themselves from terminating. Consider this case: You create a file on a write-protected drive. The system will read in a directory sector and modify it. It will then attempt to write it out, causing a write-protect error. If you catch the INT 24 and do not return, the dirty buffer still exists. To clear out the dirty buffer, you MUST return from the INT 24 saying to abort the process. You can then catch the terminate and restore your stack (you will be running on your parent's stack). ........................................ "... 1) Why does PCDOS exec function 3 (overlay) demand that there be some free memory that it can allocate...." It doesn't. IBM specifically requested that the Exec code be overlayable in the MSDOS. As a result, it lives in the transient piece of COMMAND.COM and gets loaded when needed: thus the requidement for enough free space to laod the Exec loader (about 1.5K). Under other MSDOS's there is no such problem as the Exec system call lives in system space. A general rule of thumb is: if you are not going to use some space, free it. You can do this either via SetBlock system call, or by twiddling the EXE file header. You should avoid .COM format files. "... what happens if I try to overlay an .EXE file with the high/low switch set to load the thing for high memory..." Nothing. The HIGH/LOW switch is only for process creation, not for overlays. "... Are all these answeres the same for MSDOS?..." Yes. ........................................ "... zeroing of the current record field ..." That incompatability existed between 1.1 PC-DOS and 1.25 MSDOS. 2.0 versions of both function identically (like 1.1 PC-DOS). ........................................ The Shell command on PC-DOS 2.0 works just fine. CONFIG.SYS shell = b:\command.com b:\ /P Putting a disk with command.com in drive B: when the system boots causes COMMAND to be read from drive B: and the COMSPEC in the environment is "B:\COMMAND.COM". If you are having trouble it's because you are doing something wrong. Recall that your given COMSPEC is checked, if you give it a bad one it will try to go back to the default which is the root directory on the default drive. Recall also that this is an undocumented 2.0 feature so even if it doesn't work nobody is going to be all that hot to do something about it. ........................................ My error on the shell stuff, IBM hid it real well. The "b:\" is also documented on page 10-9 (the [d:][path] part). They did an equally poor job here. The /P and the path spec have absolutely nothing to do with the SHELL command, they are arguments to command. Expecting SHELL to know stuff particular to command is not reasonable because you are not restricted to running command as your top level shell. You can run DEBUG as your top level shell by saying SHELL = debug.com But watch out!! debug is not designed to run as a top level shell. if you ever say "q" to this debug the system will crash. Command on the other hand is smart enough to run as a top level shell. If you give the /P switch to it Command does some special things to insure that typing EXIT to it will not cause the system to crash as with debug. There is absolutely no way for command to assume the /P switch because he must run as a top level shell, and as a utility. The smart user has to tell him what to do. Similarly the "b:\" tells command where to look for himself. For instance: SHELL = A:\BIN\COMMAND.COM D:\COMMAND\BIN /P The "A:\BIN\COMMAND.COM" tells SYSINIT where to load the initial command.com, the "D:\COMMAND\BIN" tells command where to look for himself when he needs to locate his transient. As you can see they are not restricted to being the same things. I suggest you foreward any complaints about the manual to ........................................ The volume ID attribute is very special, and is treated differently from all the other attributes. It is very "sticky", in order to find one you must look for it and it alone. And when you do look for it, you find only it and nothing else. The volume ID is constrained to be in the ROOT directory, and there can be only one file in the ROOT with the attribute. The FCB flavor calls have special code to enforce these rules. The new calls were supposed to enforce the same rules, but they are not working correctly, and unexpected results are possible. You should use the old FCB calls to diddle with volume ID for the moment. ........................................ Thanks for the info. The causes of your problems are: (a) ^Z on output to a device in cooked mode will terminate the output. This is for CPM-compatability: you don't want stuff after the ^Z output to your printer for example. As a result COMMAND.COM issues a write to stdout and then checks to see if the number written is equal to the number requested. If they are not the same, then a redirection error is assumed. ECHO ^Z is supposed to output a single character. It outputs NO characters and thus the strange message. Programs that use old function calls, get redirected, and then read more than is expected will behave bizarrely: how do you indicate EOF on a read-byte-from- console system call? I believe that it returns ^Z. Most of these programs were never expecting to get redirected and thus, the failure to handle the boundary conditions properly. (b) The main crock about CP/M is that the extention on a file name determined the type of the file. This is bogus: a file should be distinguished by its contents, not by its name. When you are loading a file with the name *.EXE, it does NOT assume that it is an EXE format file. It looks at the first two bytes for a signature telling it that it is an EXE file. If it has the proper signature, then the load proceeds. otherwise, it presumes the file to be a COM-format file. If the file has the EXE signature, then the internal consistency IS checked. Pre-2.0 versions of MSDOS did not check the signature byte for EXE files.