larry@UUCP (Larry Williamson) (08/17/89)
SCO markets a Xenix/Unix version of Microsoft Word. The
version is 3.0.4, (according to an SCO sales rep). How does
this version of MSWord compare with MSWord 5.0?
SCO claims that it works with SCO Unix 3.2. Will it work
with any of the other versions of Unix 3.2? (ie. ISC, Bell
Tech, AT&T).
SCO's sales rep said, "We don't try our software with anyone
else's Operating System - you have to try it yourself". (Which,
to me, does not sound like the best way to sell MSWord).
We would like to use it with Interactive's 386/ix 2.0.x. Does
anyone have any experience with this product?
Thanks,
Larryjohnl@esegue.uucp (John R. Levine) (08/18/89)
In article <LARRY.89Aug17095648@focsys.UUCP> larry@UUCP (Larry Williamson) writes: >SCO markets a Xenix/Unix version of Microsoft Word. The >version is 3.0.4, (according to an SCO sales rep). How does >this version of MSWord compare with MSWord 5.0? Word 3.0 is a very obsolete version, several years old. I wouldn't get it. It's missing a lot of the nice new features like graphics import and a usable speller. Even though I prefer Word to Word Perfect, if I wanted a program for my Unix box I'd go with Word Perfect because the vendor acts a lot more like they're serious about supporting and maintaining it. -- John R. Levine, Segue Software, POB 349, Cambridge MA 02238, +1 617 492 3869 {ima|lotus}!esegue!johnl, johnl@ima.isc.com, Levine@YALE.something Massachusetts has 64 licensed drivers who are over 100 years old. -The Globe
palowoda@megatest.UUCP (Bob Palowoda) (08/19/89)
From article <LARRY.89Aug17095648@focsys.UUCP>, by larry@UUCP (Larry Williamson): > > SCO markets a Xenix/Unix version of Microsoft Word. The > version is 3.0.4, (according to an SCO sales rep). How does > this version of MSWord compare with MSWord 5.0? > > SCO claims that it works with SCO Unix 3.2. Will it work > with any of the other versions of Unix 3.2? (ie. ISC, Bell > Tech, AT&T). > > SCO's sales rep said, "We don't try our software with anyone > else's Operating System - you have to try it yourself". (Which, > to me, does not sound like the best way to sell MSWord). > > We would like to use it with Interactive's 386/ix 2.0.x. Does > anyone have any experience with this product? I was thinking the same thing. I was also wonder what compilier SCO is going to compile there apps packages with? If it going to be compiled with MSC that it's got to go through the 286/386 emulator and that slows things down. At least I notice it. It would be great if SCO offers packages compiled with your choice of compilier. ---Bob -- Bob Palowoda *Home of Fiver BBS* login: bbs Work: {sun,decwrl,pyramid}!megatest!palowoda Home: {sun}ys2!fiver!palowoda (A XBBS System) 2-lines BBS: (415)623-8809 2400/1200 (415)623-8806 1200/2400/9600/19200
darryl@ism780c.isc.com (Darryl Richman) (08/20/89)
Only Xenix 286 programs go through the x286emul environment emulator program. Xenix 386 programs execute natively. 286 programs vary in speed, but are often faster than under either Xenix 286 or Xenix 386 because the memory management is significantly faster under x286emul. --Darryl Richman -- Copyright (c) 1989 Darryl Richman The views expressed are the author's alone darryl@ism780c.isc.com INTERACTIVE Systems Corp.-A Kodak Company "For every problem, there is a solution that is simple, elegant, and wrong." -- H. L. Mencken
jbayer@ispi.UUCP (Jonathan Bayer) (08/21/89)
darryl@ism780c.isc.com (Darryl Richman) writes: >Only Xenix 286 programs go through the x286emul environment emulator >program. Xenix 386 programs execute natively. 286 programs vary in >speed, but are often faster than under either Xenix 286 or Xenix 386 >because the memory management is significantly faster under x286emul. How is the memory management faster in emulation mode than in native 386 mode? JB -- Jonathan Bayer Intelligent Software Products, Inc. (201) 245-5922 500 Oakwood Ave. jbayer@ispi.UUCP Roselle Park, NJ 07204
darryl@ism780c.isc.com (Darryl Richman) (08/22/89)
In article <1115@ispi.UUCP> jbayer@ispi.UUCP (Jonathan Bayer) writes: "darryl@ism780c.isc.com (Darryl Richman) writes: ">Only Xenix 286 programs go through the x286emul environment emulator ">program. Xenix 386 programs execute natively. 286 programs vary in ">speed, but are often faster than under either Xenix 286 or Xenix 386 ">because the memory management is significantly faster under x286emul. " "How is the memory management faster in emulation mode than in native 386 mode? The emulator actually gets memory a 64k segment at a time and doles it out as the XENIX program sbrks for it. Requests for memory that the environment emulator already has never go into the kernel and only take a few instructions to map into the 286 program's address space. I don't recall the exact numbers, but frequent requests for small amounts of memory can be an order of magnitude faster. Of course, when the program asks for 64k segments, things are close to equal. They are still faster than under 386 XENIX because the emulator knows that it is running a 286 XENIX program, but XENIX memory management code must check this at each place where handling the memory request must be different between a 286 and a 386. PLEASE NOTE: when I speak of 386 XENIX, I'm talking about version 2.3 or earlier. SCO XENIX V.3.2 is the same code base as UNIX V.3.2. I am not attempting to compare current products. --Darryl Richman -- Copyright (c) 1989 Darryl Richman The views expressed are the author's alone darryl@ism780c.isc.com INTERACTIVE Systems Corp.-A Kodak Company "For every problem, there is a solution that is simple, elegant, and wrong." -- H. L. Mencken
peter@ficc.uu.net (Peter da Silva) (08/25/89)
In article <31897@ism780c.isc.com>, darryl@ism780c.isc.com (Darryl Richman) writes: > The emulator actually gets memory a 64k segment at a time and doles it > out as the XENIX program sbrks for it. This behaviour indeed speeds up most UNIX programs. However, programs written using Intel's UDI interface, such as their PLM286 compiler and associated tools, end up requesting 64K for all memory requests. This tends to lead to processes that are very large, creates inordinate amounts of thrashing, and even runs out of virtual memory space if the program makes frequent requests for small amounts of memory. The problem seems to be caused by intel's UDI returning a new segment for every memory request. In real Xenix-286, small segments are returned for small requests. In the emulator, all segments returned by x286emul are 64K in size. We'd really really like to see this fixed, since it makes the difference between being able to upgrade to System V and staying with the System-III-based Xenix-286. -- Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation. Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-' "export ENV='${Envfile[(_$-=1)+(_=0)-(_$-!=_${-%%*i*})]}'" -- Tom Neff 'U` "I didn't know that ksh had a built-in APL interpreter!" -- Steve J. Friedl
darryl@ism780c.isc.com (Darryl Richman) (08/25/89)
In article <5864@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
"This behaviour indeed speeds up most UNIX programs. However, programs written
"using Intel's UDI interface, such as their PLM286 compiler and associated
"tools, end up requesting 64K for all memory requests. This tends to lead to
"processes that are very large, creates inordinate amounts of thrashing, and
"even runs out of virtual memory space if the program makes frequent requests
"for small amounts of memory.
I'm surprised that you see a significant amount of thrashing, since, if
you don't use the memory, it stays paged out. And pages that aren't
touched don't get allocated real memory in the first place. If you are
running out of virtual memory space in the emulator, you can up your
ulimit. Obviously there is a limit to the process size, and there is a
jump in process overhead every 4MB for the extra page table directory,
but these seem like they should be a long way off for a 286 environment
program.
"The problem seems to be caused by intel's UDI returning a new segment for
"every memory request. In real Xenix-286, small segments are returned for
"small requests. In the emulator, all segments returned by x286emul are 64K
"in size.
Actually, the segments seen by the 286 program are the size that they
requested. The segment descriptor used by the 286 program prevents
access beyond the request. But the emulator does allocate 64k each
time a new segment is needed. This would seem to put a strain on swap
space and region table size more than anything else. Have you tried
tuning your system?
This is a surprising way to handle memory on a 286 considering that it
is so expensive to load a segment register, the limited (4k-1) number
of segments allowed to a user process, and the added overhead in
process switching incurred by large LDTs. We have not encountered a
problem like this one in the large number of commercial XENIX products
we, Microsoft, and SCO tested. Have you discussed this problem with
INTEL?
In designing and implementing the environment emulator, our goals were
to provide backward compatibility and the same or improved performance
in existing products compared to running native on a 286. We (ISC,
Microsoft, and AT&T) explicitly decided that we were not providing a
platform for new development work (hence, the absence of support for
debuggers and system maintenance functions) on the 286 since it was
perceived to be an aging and limited market.
--Darryl Richman
--
Copyright (c) 1989 Darryl Richman The views expressed are the author's alone
darryl@ism780c.isc.com INTERACTIVE Systems Corp.-A Kodak Company
"For every problem, there is a solution that is simple, elegant, and wrong."
-- H. L. Menckenpeter@ficc.uu.net (Peter da Silva) (08/26/89)
In article <32271@ism780c.isc.com>, darryl@ism780c.isc.com (Darryl Richman) seems surprised by the fact that we're running programs large enough to cause problems on a 386 even when they're using a hundred times the memory they were using on the '286. > Obviously there is a limit to the process size, and there is a > jump in process overhead every 4MB for the extra page table directory, > but these seem like they should be a long way off for a 286 environment > program. Not at all. We're talking about 286 programs that have to spill to disk on Xenix-286 even with a MEMPOOL (rough equivalent to ulimit) set to 3 megabytes. These are not small programs. [stuff about tuning the system deleted... we're dealing with big 286 programs suddenly using maybe 100 times as much memory as before when loaded on the 386 ] Regarding intel's UDI library: > This is a surprising way to handle memory on a 286 considering that it > is so expensive to load a segment register, the limited (4k-1) number > of segments allowed to a user process, and the added overhead in > process switching incurred by large LDTs. We have not encountered a > problem like this one in the large number of commercial XENIX products > we, Microsoft, and SCO tested. Have you discussed this problem with > INTEL? These programs were originally intended to run in RMX-286, which shares the same LDT among all processes so does not have this problem. The Intel UDI is very much dependent on this behaviour, and tends to use a segment where a more conventional system uses an offset. It's not possible to change this behaviour of the programs. Not only is it designed into the PL/M runtime library but many of them are no longer supported. The only realistic solution for us would be to change the behaviour of x286emul. If this can't be done, we'll have to stick to our old systems. > In designing and implementing the environment emulator, our goals were > to provide backward compatibility and the same or improved performance > in existing products compared to running native on a 286. I'm not surprised that you haven't run into this problem, since there are very few folks still running the system-3 based Xenix and intel development tools. I can't argue about the size of the market people like us represent, but to move out of the 286 we need an upgrade path. We'll be happy to move into the 80386 world, but we need a way to support our existing 80286 software on whatever hardware/operating system combination we use. You haven't given us one. It's frustrating to be told we have to stick to the 286 for the very reason that the 286 is obsolete... :-<. -- Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation. Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-' "export ENV='${Envfile[(_$-=1)+(_=0)-(_$-!=_${-%%*i*})]}'" -- Tom Neff 'U` "I didn't know that ksh had a built-in APL interpreter!" -- Steve J. Friedl
kdg@nirvo.uucp (Kurt Gollhardt) (08/28/89)
In article <32271@ism780c.isc.com> darryl@ism780c.UUCP (Darryl Richman) writes: >In article <5864@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >"This behaviour indeed speeds up most UNIX programs. However, programs written >"using Intel's UDI interface, such as their PLM286 compiler and associated >"tools, end up requesting 64K for all memory requests. This tends to lead to >"processes that are very large, creates inordinate amounts of thrashing, and >"even runs out of virtual memory space if the program makes frequent requests >"for small amounts of memory. > >I'm surprised that you see a significant amount of thrashing, since, if >you don't use the memory, it stays paged out. And pages that aren't >touched don't get allocated real memory in the first place. If you are >running out of virtual memory space in the emulator, you can up your ulimit. Actually, with this kind of allocation going on, you might very well have to up *swap space*. Think of it: say the app allocs 1000 (what it thinks are small) segments, for each of which the emulator allocs 64K: poof! you've got 64M w/o even trying hard. In fact, this probably *is* the source of the thrashing, because the emulator *clears* all of the memory it allocates (using a C *char_p++ = 0 loop, no less). This causes the demand-zero pages to become real pages which are then cleared twice: first (efficiently) by the kernel, then again (inefficiently) by the emulator. These pages will now have to be written out to swap when they are reclaimed. Thrash city. A simple fix to the thrashing problem would be for the emulator to only clear the memory which is actually used by the 286 app. You'd still be in danger of running out of swap space, though. An environment variable to control the min allocation size (default to 64K, set to something like 4K for the UDI apps) would be nice. Shouldn't be too hard to implement (given the source, of course). -- Kurt Gollhardt \ Nirvonics, Inc. -- Plainfield, NJ Kurt.Gollhardt@nirvo.uucp /\ Software Design and Consulting ...!rutgers!nirvo!Kurt.Gollhardt / \ "It's all about people; not you and me or him and her, but *us*."
hays@zeus.hf.intel.com (hays) (08/29/89)
In article <5890@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
[long discussion about using XENIX Intel UDI tools under SYSV, pointing
out that the emulator allocates 64K segments for every memory request,
causing system performance degradation]
Peter,
this is not an official Intel position, but I have found that using the
DOS based versions of the 286 tools under a DOS emulator on SYSV works
much better than the XENIX emulation - and leverages off a much larger
marketplace than the obsolete XENIX versions.
Also, it might help, in the long run, to call your Intel sales office
and say that you want UNIX native versions of these tools available
(you've probably already done this, right?)
Compile times average 3-6x faster, DOS emulator vs. XENIX emulation.
-----
Kirk Hays -- "I'm the NRA!"
"Be responsible for your own actions." -- Me
"Don't let TV shape your values." -- Me
"Legalize freedom." -- Libertarian Partytneff@bfmny0.UUCP (Tom Neff) (09/02/89)
In article <432@zeus.hf.intel.com> hays@farside.UUCP (Kirk Hays) writes: >In article <5890@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: > [long discussion about using XENIX Intel UDI tools under SYSV, pointing > out that the emulator allocates 64K segments for every memory request, > causing system performance degradation] >...Also, it might help, in the long run, to call your Intel sales office >and say that you want UNIX native versions of these tools available >(you've probably already done this, right?) There seems to be some question about how "official" its status is, but the RMK386 Developers Kit (for Unix V/386) comes with an OMF loader and UDI emulator called UNXUDI, and brother, NOTHING touches it for performance. Compiles and links run lightning fast. Using the DOS hosted tools for everything is such a royal pain I've completely given it up. The groaning latency required to get all of VP/ix's little doohickies up and running from the UNIX shell will drive you nuts. And there are limitations on where and how VP/ix will work, as we all know and rejoice. :-) I don't think this works for the 286 tools, but I could be wrong. There may be something else that does. 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. -- Annex Canada now! We need the room, \) Tom Neff and who's going to stop us. (\ tneff@bfmny0.UU.NET
peter@ficc.uu.net (Peter da Silva) (09/05/89)
In article <14615@bfmny0.UUCP>, tneff@bfmny0.UUCP (Tom Neff) writes: > There seems to be some question about how "official" its status is, but > the RMK386 Developers Kit (for Unix V/386) comes with an OMF loader and > UDI emulator called UNXUDI, and brother, NOTHING touches it for > performance. Yes, we've been testing it. It is faster than the 286 tools under x286emul, but not that much faster. It's still slower than the 286 tools under Xenix-286. I suspect because it runs in 8086 mode and is limited to a Meg of RAM... as I mentioned in a previous message, we're talking about programs that typically chew up 2 megabytes and not infrequently over 4 megs. It 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). 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. > I don't think this works for the 286 tools, but I could be wrong. You're wrong, it works with the 286 tools. See... sometimes it's nice to be wrong :->. > 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. -- Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation. Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-' "The Distribution: field on the header has been modified so as not to 'U` violate Information Export laws." -- eugene miya, NASA Ames Research Center.
tneff@bfmny0.UUCP (Tom Neff) (09/06/89)
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 <shudder> 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
peter@ficc.uu.net (Peter da Silva) (09/06/89)
In article <14629@bfmny0.UUCP>, tneff@bfmny0.UUCP (Tom Neff) writes: > 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. OK, then the problem is moving stuff into and out of the UDI world. Which is based on RMX/ISIS. Since ISIS begat CP/M which begat MS-DOS it's pretty much a toss up which silly little acronyms you use. > 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. Not to mention giving you severe indigestion when you try to retain some sort of compatibility between your Xenix-286 based scripts and your System V based scripts. :-< > [intel brainwashed] into believing that OS/2 was somehow the answer to > something [?!], and [...] the systems people sneered at Unix. Yargh. -- Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation. Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-' "The Distribution: field on the header has been modified so as not to 'U` violate Information Export laws." -- eugene miya, NASA Ames Research Center.