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
les@chinet.chi.il.us (Leslie Mikesell) (07/07/89)
In article <14439@bfmny0.UUCP> tneff@bfmny0.UUCP (Tom Neff) 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 redirect VP/ix output all the time. Just to be perverse, I logged in to a 386 running AT&T unix over a starlan network, started an interactive shell in GNU emacs and ran some DOS commands. They mostly worked, except for the CR's at the ends of lines, which can be fixed by loading the kermit library and setting kermit-clean-on. I couldn't quite get an interactive command.com to work. Even with kermit-default-cr it seemed to lose most of the input characters. It did look like it would be possible to run something like dos ndmake with the compile command and parse the results with next-error. >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. I see a real problem with the reverse effect (i.e. under DOS executing a unix command by typing its name). If you happen to have your DOS current drive set to something that unix doesn't understand (like the floppy or a dos partition of the HD) the unix command will execute in the directory where you started the dos process. For example, you might start dos from your home directory, change to the A: drive and accidentally type rm * to delete everything instead of del *.*. Guess what gets erased... Les Mikesell
tneff@bfmny0.UUCP (Tom Neff) (07/08/89)
In article <8886@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >In article <14439@bfmny0.UUCP> tneff@bfmny0.UUCP (Tom Neff) 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 redirect VP/ix output all the time. > >Just to be perverse, I logged in to a 386 running AT&T unix over a starlan >network, started an interactive shell in GNU emacs and ran some DOS commands. Is any of this actually redirection? Or is it just a particular choice of terminal. Redirection to me means piping to files and processes within the shell. >They mostly worked, except for the CR's at the ends of lines, which can be >fixed by loading the kermit library and setting kermit-clean-on. I couldn't >quite get an interactive command.com to work. Even with kermit-default-cr >it seemed to lose most of the input characters. With CU(1) and EMACS running their greasy hands over everything going in and out of your DOS session, character loss seems possible. It's important to make sure you have the right terminal type. VP/ix uses curses/terminfo to translate stuff from the virtual PC screen onto your actual terminal screen, if you're not on the AT386 console display. If a program stores an "X" into text memory, it gets translated to the whole escape sequence necessary to move your terminal's cursor to the matching place and write an X. Wonderful concept, but sometimes it can bog down. >>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.... >I see a real problem with the reverse effect (i.e. under DOS executing >a unix command by typing its name). If you happen to have your DOS >current drive set to something that unix doesn't understand (like >the floppy or a dos partition of the HD) the unix command will execute >in the directory where you started the dos process. For example, you >might start dos from your home directory, change to the A: drive and >accidentally type rm * to delete everything instead of del *.*. Guess >what gets erased... I can confirm this dumb behavior. The little charmer known as "rununix", to which lots of things like "cat.com" and "ls.com" are linked, has its problems. One of the ways I can crash my box HARD with VP/ix is dos -c "ls.com -l" | cat Boom. In general I find very few UNIX programs I want that badly to run under DOS. Especially with the virtual terminal facility, I can just flip to the next page and do it there. -- "My God, Thiokol, when do you \\ Tom Neff want me to launch -- next April?" \\ uunet!bfmny0!tneff