Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!gem.mps.ohio-state.edu!ginosko!uunet!bfmny0!tneff From: tneff@bfmny0.UUCP (Tom Neff) Newsgroups: comp.unix.i386 Subject: Re: Microsoft Word & (SCO) Unix 3.2 Message-ID: <14629@bfmny0.UUCP> Date: 6 Sep 89 00:50:47 GMT References: <7227@megatest.UUCP> <14615@bfmny0.UU.NET> <6031@ficc.uu.net> Reply-To: tneff@bfmny0.UU.NET (Tom Neff) Organization: ^ Lines: 67 In article <6031@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >[The UNXUDI slick] > also has the annoying problem of translating file names into and out of >the DOS world (yes, I know it's not really DOS... it hooks into the UDI in >the DOS tools at a higher level). Note that everything having to do with DOS, *including* the stuff in the EXE header, is completely out of the picture. It's quite legal to remove the 0x3a00-byte UDI2DOS generated header entirely and feed the raw .86 or .286 file to UNXUDI and I often do. UNXUDI provides a *direct* UDI-to-UNIX functional emulation. Why this matters, among other things, is that the 8+3 character file name limitation does not apply as it must when going through the EXE header services. A one meg V86 task is indeed created but it has no resident OS and no PC hardware mapped architecture. Just a raw meg to play with, and all INT 088H (UDI traps) zapped out to the companion task. Like VP/ix, a kernel hack is provided so that UNXUDI can be trapped directly from the V86 box for performance's sake. Unlike VP/ix, no other lengthy setup is required (merely starting a V86 task takes very little time) so the startup is negligible. Where this feels loveliest is with things like LIB86 or AEDIT -- under VP/ix the startup latency would stun an ox. > It's almost impossible to get both the >command line arguments and file names to work the same way as the Xenix tools, >no matter what combination of -F, -C, and -S I try. This IS darn difficult, and under-documented in the manual. Generally you have to UPPERCASE the keywords and lowercase the filenames, but some things seem cantankerous. I believe the culprit is inconsistent behavior on the part of the tools themselves. The UDI spec doesn't explicitly require uppercase filenames, but the RMX and Xenix implementations forced all non-quoted command line arguments to upper case so as to retain filename compatibility with ISIS. Some of the tools get overeager and do their own uppercase translation of filenames before making UDI calls, so if you use one of the case pass-through switches to UNXUDI and try to get at lowercase filenames, the tools puke. LIB86 is real friendly this way. And the Force-case switch seems to work OK with data files but NOT with directories, compounding the confusion. On at least one occasion I have had to do "mv inc INC" and modify my UNIX scripts to match, in order to get stuff to compile. Oh well that's why we get the big bucks I guess. :-) >> I'm hopeful that having bought Bell >> Tech, Intel will see the light and come on board to UNIX as a fully >> hosted environment for all tools. > >Well, I'm hoping for it, but hopeful is a little strong. They've been moving >*away* from UNIX for too long. Scuttlebutt is that when Intel and IBM got snuggly under the sheets a few years ago, a major sales job was done on OS/2. (The odd FAE will still buttonhole you and hawk its virtues.) Having been brainwashed into believing that OS/2 was somehow the answer to something [?!], and apparently having been provided lovely PS/2's to match, the systems people sneered at Unix. Of course over at the iRMK386 shop where the kernel of the semi quasi abandoned RMX386 was being put together, they had no use for 386-dumb OS/2, and used the V/386 port as their base. Hence UNXUDI which you have to scream bloody murder to find out about from the rest of Intel. Ah, such is life with our favorite love/hate vendor... :-) #2 PS I can't wait till some lurker mails me the REAL dope on this! -- Annex Canada now! We need the room, \) Tom Neff and who's going to stop us. (\ tneff@bfmny0.UU.NET