plocher@uwspan.UUCP (John Plocher) (12/27/87)
[ In this and all other submissions, my editorial comments are enclosed in square brackets and include my name. -John Plocher, moderator ] John, There is a lot of info so I'll try my best organize it. Also most of the general observations about the process limitations apply only to the 286 product, as I understand it. 1) Installation: When configuring dosmerge the user has the option of either keeping a dos partition on his disk or building the disk without one. The documentation recommends keeping at least a 2.5M dos partition for applications with copy protection schemes which prevent them from being installed on the combined dos/unix partition. I kept my disk intact when I installed it simply because I didn't have time to do the very large back up necessary for a complete repartitioning of the disk. So far I haven't experienced any problems. [ You shouldn't - DOSmerge does NOT require a DOS partition -John ] If a dos partition is maintained dos refers to it as drive E: and the dos/unix partition (which I will call the unix partition from now on) is recognized as the C: drive. [ Actually, C: is your unix filesystem with an initial chdir to the directory you were in when starting DOS -John ] Installation is straight forward and takes about 45 minutes for someone familiar with both O.S. I won't go into the details suffice it to say that the installation procedure is menu driven and very clear. DOS is loaded to a directory /usr/dbin; DOS applications are loaded to /usr/ldbin and both are placed in the user's $PATH variable. [ ^^^^^ == "should be" -- the install procedure does not do it for you -John ] 2) User Interface: There are two user interfaces to dosmerge. The user has the choice of executing with either the dos of the unix user interface. Programs and data in the dos partition (drive E:), the unix partition (drive C:), dos formatted floppies (A:[and B:]) or unix formatted floppies (mounted file systems at /mnt...) are available to either interface. A) The Unix Interface: Of course entering unix commands in this interface is the same as always. To execute a dos command or dos application installed on the unix partition it is simply typed in the dos syntax. For instance $ dir c:\usr\dbin\t*.exe of course here the c: is not strictly necessary. But $ dir e:\dos\*.exe requires the drive specifier. [ This seems wrong. The DOSmerge manual on page 3-7 says: "When you run programs from the Unix shell, you use a language the shell understands whether you run unix programs or DOS programs" ... "When you use DOS from the unix shell, observe the following rules:" ===>>> 1) Use the UNIX path separator (/) and switch character (-) instead of the DOS ones (\) and (/). 2) Use lower case for DOS commands 3) Watch out for Unix wildcards. -John ] Unix commands may be executed against dos files in the unix partition, e.g. $ ls /usr/dbin/*exe I haven't found any way for unix to execute commands against files in the dos partition. B) The Dos Interface: The command $ dos & invokes the dos interface (the & is optional, but provides some additional flexibility). Upon invocation: i) dos is "booted" from /usr/dbin ii) /config.sys is consulted to configure drivers, buffer, etc. iii) /autoexec.bat is executed iv) $HOME/autoexec.bat is executed if it exists in the users home directory v) and finally the prompt C> is issued. At that point the user is running normal dos with unix enhancements available to him if he knows about them and cares to use them. Dos commands can be executed against unix files symmetrically with dos files, C> dir c:\usr\include\*.h C> dir c:\dos\*.exe Unix commands can be executed via the dos command on.exe. For instance to run grep against the autoexec.bat file to find say an entry for sidekick (yes sidekick runs) the command C> on unix grep sk \autoexec.bat is used. The on.exe checks the name under which it is invoked and executes the command of its alias so that C> copy \usr\dbin\on.exe \usr\dbin\grep.exe C> grep sk \autoexec.bat accomplishes the same thing as the previous example. Actually a link will suffice so that C> on unix ln /usr/dbin/on.exe /usr/dbin/grep.exe would be the optimum way to alias the on command. 3) Limitons: There three two basic limitations to the 286 product (I beleive they are absent in the 386 version). A) Only one dos process can exist at a time. That means that even if a dos process is executed in the background it is the only dos process that can be so executed. Also since in the unix interface pipes are unix pipes, and since unix executes all processes in a pipe simultaneously, only one dos command can exist in a unix pipe. This is generally not so bad since unix filters can usually be substituted for dos filters. B) Merge divides dos programs into those which directly access screen memory ("display oriented") and those which invoke dos services to do displays ("stream oriented"). Only stream oriented programs can be executed in the background. This is also no a major problem since display oriented programs are for the most part interactive and are not really suited to backgrounding. Unix applications can run in the background while display oriented programs are running. So for instance uucp can still be active even while say word processing. The display oriented programs can be suspended by typing Ctl-SysReq. At that point the unix screen for the current virtual terminal appears and unix commands may be executed with the dos environment suspeneded. If the dos environment or display oriented dos command was invoked in fore- ground (i.e. without the "&"), it is necessary to change virtual consoles before executing unix commands. C) The final major limitation is that dosmerge can only be executed from the system console (again 286 only) so that it is essentially single user. The documentation is somewhat ambiguous about whether stream oriented programs can be executed from remote terminals but I don't think that they can. [ They can't. DOSmerge is only usable from the Keyboard/Screen of the system console or one of its virtual consoles -John ] 4) Miscellanous: Executing in the dos environment, as opposed to executing dos commands from unix, is useful in two circumstances. The first is if the user is unfamiliar with unix. The benefits of standalone dos are clear in that case. The second is if a unix user intends to do extensive work in dos. In that case execution of the autoexec is very helpful, and the overhead of switching between protected and real memory modes is eliminated. [ Actually, only the overhead of booting the DOS image from the swap area for each command is eliminated. Most system calls eventially do I/O and that requires the UNIX kernel to handle it. This in turn requires a switch to protected mode and back again. -John ] A session of debugging with constant compiling, linking editing and execution would normally be carried out in the dos environment. However I am editing this message with a dos editor, but executed the edit command from within unix. I see no reason however to actually boot dos (I mean really boot it not enter it from unix), although it is possible. I've been running dosmerge about two weeks now and have never had the need to boot dos. My wife has been using the system to write papers and her knowlege of unix is limited to logging in and typing the "$ dos" command. That's enough for now. If you have any particular questions I'll be happy to answer them for you. [ So would I -John ] Suffice it to say that dosmerge serves my needs, which are certainly less stringent than many other peoples. Also I am not in a position to compare dosmerge to any other similar products (SCO offers VP/ix for XENIX). I can only compare it to not having anything at all, and it sure beats the hell out of that. -reqards bruce -- Email to microport-request@uwspan with questions about the newsgroup microport, otherwise mail to microport@uwspan with a Subject containing one of: 386 286 Bug Source Merge, "Send Buglist", "Send Versions", or "Send Info" (uucp: rutgers!uwvax!uwspan!microport & rutgers!uwvax!uwspan!microport-request)