[comp.unix.microport] Impressions of DOSmerge 286

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)