vjs@calcite.UUCP (Vernon Schryver) (06/29/89)
I've encountered difficulties with DOSMerge (yes, what else is new?). My
latest problem is that a Logitech Bus mouse panics the kernel. Thinking
that rumors that VP/ix was done by people who had heard of UNIX before they
started the project (DOSMerge was obviously done by IBM experts), I decided
that VP/ix would solve all of my problems. Unfortunately, it seems that
VP/ix is a pure DOS-in-a-window sort of thing. Interactive tells me that I
cannot run INTEL's PLM386 development stuff from a makefile, as I now do
with DOSMerge. DOSMerge allows a DOS program which does no more than
character stuff to the console and keyboard to talk with UNIX standard
I/O.
Another restriction of VP/ix is that DOS programs can only talk to devices
that have drivers in the UNIX kernel. DOSMerge was more ambitious and
tried to let the virtual 8086 machine reach out and have its way with the
AT bus. It almost works, but obvious hassles with UNIX drivers make me
think that it is a idea which cannot be implemented reliably.
Interactive is running a very pleasant sales and pre-sales-support
operation, the 75% credit for Microport makes the price reasonble even if
they do force you to buy X, and good things are said of their SVR3.2, but
VP/ix does not do it for me. Does someone sell DOSMerge for Interactive
UNIX? Is there a version of SVR3 with DOSMerge with fixes since Microport
3.0e/1.1? Is there something other than DOSMerge that would do what I
need, DOS in shell scripts and makefiles?
Before buying Microport 2.2 I tried to talk to Bell Tech. That experience
and more recent statements by Bell Tech bosses in this forum have made it
unlikely that I will ever deal with Bell Tech in any incarnation. I have
recently tried to talk to Everex, but they seem like either the old
Microport or Bell Tech--I cannot tell which.
Vernon Schryver
vjs@calcite.uucp or ...{sgi,pyramid}!calcite!vjsoleg@gryphon.COM (Oleg Kiselev) (06/30/89)
In article <51@calcite.UUCP> vjs@calcite.UUCP (Vernon Schryver) writes: >Does someone sell DOSMerge for Interactive UNIX? If you are talking about Locus Computing's DOSMerge, then you should probably contact LCC's marketing or support and ask them. It was my impression that there were versions of Merge for many available 386 UNIX ports. -- "No regrets, no apologies." -- Ronald Reagan Oleg Kiselev ARPA: lcc.oleg@seas.ucla.edu, oleg@gryphon.COM (213)337-5230 UUCP: [world]!{ucla-se|gryphon}!lcc!oleg
tneff@bfmny0.UUCP (Tom Neff) (07/01/89)
In article <51@calcite.UUCP> vjs@calcite.UUCP (Vernon Schryver) writes: >VP/ix is a pure DOS-in-a-window sort of thing. Interactive tells me that I >cannot run INTEL's PLM386 development stuff from a makefile, as I now do >with DOSMerge. DOSMerge allows a DOS program which does no more than >character stuff to the console and keyboard to talk with UNIX standard >I/O. VP/ix absolutely allows this. A command of the form dos -c "myprog" | nocr | less works as intended. VP/ix detects the pipe or redirection of stdout and forces the DOS program output to handle 1. >Another restriction of VP/ix is that DOS programs can only talk to devices >that have drivers in the UNIX kernel. VP/ix doesn't care what devices are linked into the kernel. It has a special hook called the Virtual Device Interface (VDI) which allows Direct Device Access (DDA). There is a set of utilities (dda*) that let you configure nonstandard devices into VP/ix without a kernel rebuild. I have successfully used it to add things like a Scanjet interface card, which then worked perfectly under Simul-Task (the name for VP/ix on this AT&T 6386E system). -- "My God, Thiokol, when do you \\ Tom Neff want me to launch -- next April?" \\ uunet!bfmny0!tneff
clewis@eci386.uucp (Chris Lewis) (07/06/89)
In article <51@calcite.UUCP> vjs@calcite.UUCP (Vernon Schryver) writes: Tom Neff answered some of your questions well, but left a little out... >Interactive tells me that I cannot run INTEL's PLM386 development stuff >from a makefile, as I now do with DOSMerge. You can run any DOS program from a UNIX makefile, but you cannot run the make in the background or redirect output of the make (VP/IX needs a console). I do this all the time. You may have to write a small shell wrapper because make doesn't know about DOSPATH explicitly, and DOSPATH will need to point at the executable for the DOS things you want to run (and the DOS things you want to run shouldn't be in a "DOS disk as UNIX file" like "C:"). >Another restriction of VP/ix is that DOS programs can only talk to devices >that have drivers in the UNIX kernel. In older versions (eg the VP/IX that came with ISC 1.0.5) this is true. In 1.0.6 and later (as Tom points out) there's DDA's and so on that allow "registered" DOS sessions to reach out and touch the real hardware. And, there is now also a way to add DOS drivers to VP/ix. >It almost works [DOSMerge driver access], but obvious hassles with UNIX >drivers make me think that it is a idea which cannot be implemented reliably. Unrestricted access is one way to completely blow your machine out of the water. Which is why I prefer VP/ix. >Does someone sell DOSMerge for Interactive UNIX? Both VP/IX and DOSMerge require special kernel hooks - and they're not the same ones. (My guesses:) Microport, Bell Tech and SCO supply (or used to) both sets of hooks (but not necessarily at the same OS level). AT&T and ISC only supply the VP/IX hooks. (Considering who wrote VP/ix, it's no great surprise that ISC wouldn't include support for the competition) >Is there a version of SVR3 with DOSMerge with fixes since Microport >3.0e/1.1? Doubt it - Microport's more or less gone under. -- Chris Lewis, R.H. Lathwell & Associates: Elegant Communications Inc. UUCP: {uunet!mnetor, utcsri!utzoo}!lsuc!eci386!clewis Phone: (416)-595-5425
tneff@bfmny0.UUCP (Tom Neff) (07/06/89)
In article <1989Jul5.174059.27378@eci386.uucp> clewis@eci386.UUCP (Chris Lewis) writes: >You can run any DOS program from a UNIX makefile, but you cannot run the >make in the background or redirect output of the make (VP/IX needs a console). >I do this all the time. I redirect VP/ix output all the time. Here's an excerpt from a Korn shell script I use in building one of my products: =================================================================== addcr <<- EOF > $Rootbat # DOS batch needs full CRLF set FILL1= set :F0:=$Rootdir unixpath asm86 $Rootasm oj($Rootobj) print($Rootals) if errorlevel 2 quit link86 & < $Linkcmd if errorlevel 2 quit loc86 & < $Loccmd if errorlevel 2 quit EOF dos -c "$Rootbat" | nocrf | tee $Rooterr =================================================================== In the above example, "nocrf" is a ^M-stripper filter I wrote which forces fflush(stdout) on ^J's, thus allowing me to see the compiler status messages immediately without cat(1) buffering. "Dumb" inelegant program, anyway here's the source. =================================================================== #include <stdio.h> main() { register c; while ((c = getchar()) != -1) { if (c != '\r') putchar(c); if (c == '\n' || c == '\r') fflush(stdout); } fflush(stdout); exit(0); } =================================================================== (I originally wrote 'nocr' without the extra fflush() calls because the "rmcr" program that came with VP/ix was UNFORGIVEABLY BUGGY!!! It munches source files occasionally and if you're doing BULK file conversion in place during a platform move, as I recently did, it's MEGADEATH to come back 3 weeks later and find zorched source. Grrrrr.) So, anyway, yes you can certainly redirect VP/ix output. If you do, and you cancel the running pipe with <Del>, you may get kicked off and have to re-login, sometimes. Who knows why. Although VP/ix won't run in the background, it's very happy to run on a virtual terminal (vtlmgr). So you can still do many things at once while a DOS application runs, just by flipping to the next VT. >You may have to write a small shell wrapper because make doesn't know >about DOSPATH explicitly, and DOSPATH will need to point at the executable >for the DOS things you want to run (and the DOS things you want to run >shouldn't be in a "DOS disk as UNIX file" like "C:"). You only need DOSPATH if you want to be able to fire off EXE/COM/BAT files from the shell prompt as if they were UNIX commands. If you are willing to type 'dos command' rather than 'command', you can run anything DOS can get at, even stuff in pseudodisks like "C:" or in real DOS partitions on your hard disk (if you have VP/ix set up to access it), whether or not it lies in DOSPATH. In a production environment you should be operating out of shell scripts anyway, so sticking the 'dos' in (as I do in the example above) is easy and wise. At the interactive shell prompt, you can use aliases or (as Chris points out) shell wrappers to do it. dir () { dos -c "dir $*" | nocr } -- "My God, Thiokol, when do you \\ Tom Neff want me to launch -- next April?" \\ uunet!bfmny0!tneff