Newsgroups: comp.os.linux.help
Path: gmd.de!xlink.net!howland.reston.ans.net!europa.eng.gtefsd.com!
library.ucla.edu!whirlwind!hurricane.seas.ucla.edu!jerijian
From: jerij...@hurricane.seas.ucla.edu (Arthur D. Jerijian)
Subject: Linux and X WordPerfect
Sender: n...@seas.ucla.edu (News Administrator)
Message-ID: <CLsnCq.BIr@seas.ucla.edu>
Date: Fri, 25 Feb 1994 18:57:52 GMT
Distribution: usa
Organization: School of Engineering and Applied Sciences, UCLA
Keywords: Linux, X, WordPerfect
Lines: 9
Does Linux support the X WordPerfect package?
--
Arthur D. Jerijian
School of Engineering and Applied Science
University of California, Los Angeles
E-mail: jerij...@hurricane.seas.ucla.edu
izzy...@mvs.oac.ucla.edu
Newsgroups: comp.os.linux.development,comp.os.linux.help
Path: gmd.de!xlink.net!howland.reston.ans.net!usc!elroy.jpl.nasa.gov!
decwrl!netcomsv!netcom.com!boutell
From: bout...@netcom.com (Thomas Boutell)
Subject: Re: Linux and X WordPerfect
Message-ID: <boutellCLx4J0.n1x@netcom.com>
Followup-To: comp.os.linux.development
Keywords: Linux, X, WordPerfect
Organization: Nerdsholm
References: <CLsnCq.BIr@seas.ucla.edu>
Distribution: usa
Date: Mon, 28 Feb 1994 04:59:24 GMT
Lines: 31
In article <CLsnCq....@seas.ucla.edu>,
Arthur D. Jerijian <jerij...@hurricane.seas.ucla.edu> wrote:
> Does Linux support the X WordPerfect package?
>
No, but thanks for asking the question properly.
What I mean by this is that you've got the order right!
Linux will be able to run WordPerfect and just about every
other major commercial package not written by Microsoft
as soon as compatibility with the binary standards of other
80x86 Unixes is achieved. Since this is obviously less
effort than porting and maintaing every single application
under the sun in a unique Linux version, I encourage those
who want to know why commercial product XYZ isn't available
for Linux to instead ask why Linux doesn't yet fully
support COFF, ELF, IBCS, etc.
(There's work being done in this area, but I'd like to
hear more from those doing it and I'd like to hear
how I might be of help. This is a very important
area for Linux.)
Followups directed to comp.os.linux.development in hopes
of opening further discussion on the subject among the
kernelmongers.
-T
--
bout...@netcom.com, purveyor of fine HTML pages to the biology trade.
<a href="http://siva.cshl.org/boutell.html">Click <em>here</em></A>
Newsgroups: comp.os.linux.development
Path: gmd.de!xlink.net!howland.reston.ans.net!news2.cac.psu.edu!
news.pop.psu.edu!ra!tantalus.nrl.navy.mil!eric
From: e...@tantalus.nrl.navy.mil (Eric Youngdale)
Subject: Re: Linux and X WordPerfect
Message-ID: <CLx909.JDJ@ra.nrl.navy.mil>
Keywords: Linux, X, WordPerfect
Sender: use...@ra.nrl.navy.mil
Organization: Naval Research Laboratory
References: <CLsnCq.BIr@seas.ucla.edu> <boutellCLx4J0.n1x@netcom.com>
Distribution: usa
Date: Mon, 28 Feb 1994 06:36:08 GMT
Lines: 51
In article <CLsnCq....@seas.ucla.edu>,
Arthur D. Jerijian <jerij...@hurricane.seas.ucla.edu> wrote:
> Does Linux support the X WordPerfect package?
I suppose a status report is in order here. I was meaning to post one
this weekend, and this thread is a good enough place as any. The iBCS2 code is
currently pre-ALPHA, and all of the development code is stored in private
directories. The effort is coming along quite nicely, thank you, and it is
used to run SVr3, SCO and SVr4 binaries. Obviously there are some differences,
but these are being addressed. The COFF and ELF binary loaders are essentially
done, and it is only the iBCS2 portion of the kernel code that still needs
work.
Anyway the big news is that quite recently someone reported that they
indeed are able to run an SCO version of WordPerfect under Linux, and yes it
*does* run under X11 as well as in a regular VC. I have not seen this with my
own eyes, so I do not know how well this actually works or how usable it is,
but this should give an indication of how far we have come along.
Also, the iBCS2 module can now be used as a loadable kernel module.
The COFF and ELF loaders can be loaded as part of this module, and no longer
need to be part of the regular kernel. This can reduce the development time
quite considerably.
There is a iBCS2 compatible version of libc under development that will
be usable for both SCO and SVr4 binaries (you have to compile it separately for
each of these two cases, of course).
My own interests are in being able to run SVr4 binaries under linux.
Currently I can get Emacs compiled for SVr4 to come up under linux (non-X only
right now), but it only has a limited usability right now. You can modify and
save files, however. While it may sound silly to get Emacs working, it makes a
good test case because it is free, comes with source code, and because it
stresses the system in quite a number of different ways.
>(There's work being done in this area, but I'd like to
>hear more from those doing it and I'd like to hear
>how I might be of help. This is a very important
>area for Linux.)
Simple. Join the iBCS2 channel. This is where all of the activity is
taking place. Once you join you can get the development code and join in. One
area that needs a lot of work right now is simply in testing the iBCS2 code
with various test programs to verify that everything is being handled
correctly.
-Eric
--
"The woods are lovely, dark and deep. But I have promises to keep,
And lines to code before I sleep, And lines to code before I sleep."
Newsgroups: comp.os.linux.development
From: ja...@purplet.demon.co.uk (Mike Jagdis)
Path: gmd.de!xlink.net!howland.reston.ans.net!pipex!demon!purplet!jaggy
Subject: Re: Linux and X WordPerfect
Organization: FidoNet node 2:252/305 - The Purple Tentacle, Reading
Date: Mon, 28 Feb 1994 23:06:00 +0000
Message-ID: <529.2D73BB8E@purplet.demon.co.uk>
Sender: use...@demon.co.uk
Lines: 32
* In message <boutellCLx4J0....@netcom.com>, Thomas Boutell said:
TB> I encourage those
TB> who want to know why commercial product XYZ isn't available
TB> for Linux to instead ask why Linux doesn't yet fully
TB> support COFF, ELF, IBCS, etc.
It does. It's alpha but it does. Or, more specifically, we can load COFF
format binaries, we can load ELF format binaries and we can emulate both
SVR4 (popularly refered to as iBCS2 compatibility by commercial vendors with
SVR4 based offerings) and SVR3 kernel interfaces - SVR3 in, at least, SCO,
ISC and Wyse Unix V/386 flavours including TCP/IP.
Even more specifically I have the Uniplex office automation suite,
Informix SQL/SE and WordPerfect 5.1 (all SCO versions) running happily.
WordPerfect works in X mode as well when talking to the display via TCP/IP
at localhost:0.
TB> (There's work being done in this area, but I'd like to
TB> hear more from those doing it and I'd like to hear
TB> how I might be of help. This is a very important
TB> area for Linux.)
Join the IBCS2 channel on the linux-activists mailing list. Right now you
can write tests - lots of tests :-). Everything from short programs that
exercise a single system call - return values, boundary conditions,
over/under runs, bad data handling - to great monolithic stonkers! It's
easier to debug from code than to employ psychic abilities on real
applications :-).
Mike
Newsgroups: comp.os.linux.development
Path: gmd.de!xlink.net!howland.reston.ans.net!news.intercon.com!udel!
MathWorks.Com!news.kei.com!eff!cs.umd.edu!ra!tantalus.nrl.navy.mil!eric
From: e...@tantalus.nrl.navy.mil (Eric Youngdale)
Subject: Re: Linux and X WordPerfect
Message-ID: <CLytv1.E6z@ra.nrl.navy.mil>
Sender: use...@ra.nrl.navy.mil
Organization: Naval Research Laboratory
References: <2kstci$9cn@renux.frmug.fr.net> <CLyI7G.6wz@ra.nrl.navy.mil>
<2ktvff$cbc@bradley.bradley.edu>
Distribution: usa
Date: Tue, 1 Mar 1994 03:04:12 GMT
Lines: 17
In article <2ktvff$...@bradley.bradley.edu> g...@camelot.bradley.edu
(Jerry Whelan) writes:
> Other than the size difference, is there any technical reason why
>Linux shouldn't just adopt the ELF format as the native binary format?
>(Debugging C++?)
Yes. The GNU as and ld do not support ELF shared libraries. No one is
working on this right now, so it is not at all clear when this will become
available. Switching the native format has been discussed, but until we get
gas and ld going it will just be idle talk. If anyone wants to dig into the
bowels of ld and bfd (not for anyone with a weak heart), this would make a good
project.
-Eric
--
"The woods are lovely, dark and deep. But I have promises to keep,
And lines to code before I sleep, And lines to code before I sleep."
Newsgroups: comp.os.linux.development
Path: gmd.de!xlink.net!howland.reston.ans.net!gatech!swrinde!ihnp4.ucsd.edu!
library.ucla.edu!news.mic.ucla.edu!unixg.ubc.ca!nntp.cs.ubc.ca!
newsserver.sfu.ca!darwin.mbb.sfu.ca!ken
From: k...@darwin.mbb.sfu.ca (Ken Clark)
Subject: Re: Linux and X WordPerfect
Message-ID: <1994Mar1.222449.1050@sfu.ca>
Sender: n...@sfu.ca (seymour news)
Organization: none
References: <CLyI7G.6wz@ra.nrl.navy.mil> <2ktvff$cbc@bradley.bradley.edu>
<CLytv1.E6z@ra.nrl.navy.mil>
Distribution: usa
Date: Tue, 1 Mar 1994 22:24:49 GMT
Lines: 27
In article <CLytv1....@ra.nrl.navy.mil> e...@tantalus.nrl.navy.mil
(Eric Youngdale) writes:
>In article <2ktvff$...@bradley.bradley.edu> g...@camelot.bradley.edu
(Jerry Whelan) writes:
>> Other than the size difference, is there any technical reason why
>>Linux shouldn't just adopt the ELF format as the native binary format?
>>(Debugging C++?)
>
> Yes. The GNU as and ld do not support ELF shared libraries. No one is
>working on this right now, so it is not at all clear when this will become
>available.
I thought that the folks at Cygnus were working on this. Wasn't there
the implication in the last release of gld that ELF would be readly RSN,
or was that just a wishfull dream on my part? I thought gas allready
supported ELF sort of.
Right now this seems to be what everyone is holding their breath for
(Linux, FreeBSD, BSDI BSD/386). I think that a working ELF gld would
also allow a completely free development system (libs and all) for
Unixware and friends, no?
Eric, you mention that finishing ELF for gld would be a daunting task
(which terrifies me, since there seems to be no limit to Eric's talents
at writing Linux kernel code). What exactly needs to be done to gld and
the GNU BFD to get this working? I thought that BFD was invented exactly
to make such a job "easy" (obviously not :-).
- Ken
Newsgroups: comp.os.linux.development
Path: gmd.de!urmel.informatik.rwth-aachen.de!newsserver.rrzn.uni-hannover.de!
ina.zfn.uni-bremen.de!marvin.pc-labor.uni-bremen.de!news.uni-stuttgart.de!
rz.uni-karlsruhe.de!xlink.net!howland.reston.ans.net!news.cac.psu.edu!
news.pop.psu.edu!ra!tantalus.nrl.navy.mil!eric
From: e...@tantalus.nrl.navy.mil (Eric Youngdale)
Subject: Re: Linux and X WordPerfect
Message-ID: <CM3nF5.MqE@ra.nrl.navy.mil>
Sender: use...@ra.nrl.navy.mil
Organization: Naval Research Laboratory
References: <2ktvff$cbc@bradley.bradley.edu> <CLytv1.E6z@ra.nrl.navy.mil>
<1994Mar1.222449.1050@sfu.ca>
Distribution: usa
Date: Thu, 3 Mar 1994 17:33:04 GMT
Lines: 75
In article <1994Mar1.222449.1...@sfu.ca> k...@darwin.mbb.sfu.ca (Ken Clark) writes:
>I thought that the folks at Cygnus were working on this. Wasn't there
>the implication in the last release of gld that ELF would be readly RSN,
>or was that just a wishfull dream on my part? I thought gas allready
>supported ELF sort of.
ELF is supported but it only works for staticly linked binaries. It is
only the shared library support that is missing. Without it, very few people
would be willing to switch.
>Right now this seems to be what everyone is holding their breath for
>(Linux, FreeBSD, BSDI BSD/386). I think that a working ELF gld would
>also allow a completely free development system (libs and all) for
>Unixware and friends, no?
Quite true. I am developing a libc.so.1 for SVr4 binaries under linux,
and it needs to be compiled and linked under SVr4.
>Eric, you mention that finishing ELF for gld would be a daunting task
>(which terrifies me, since there seems to be no limit to Eric's talents
>at writing Linux kernel code). What exactly needs to be done to gld and
>the GNU BFD to get this working? I thought that BFD was invented exactly
>to make such a job "easy" (obviously not :-).
There are lots of things that need to be done. I started in a week
ago, just to get a feel for what would be needed. I am enclosing a list,
and I have indicated the stuff that I have already done. Some of it is bfd
and some of it is ld proper, and my main complaint is that bfd programs are
very hard to trace because they jump all over the place through dispatch
tables. Also, ld now uses a scripting language, and to really see what is
going on you almost need to study the parser to see what is is likely to want
to do.
-Eric
Remove stuff from existing sections that does not belong at all. Stuff with
"*" has been done already.
* 1) Allow sharable images to be loaded, mark as DYNAMIC.
* 2) Set SHARED_LIBRARY bit for all symbols from the sharable libraries.
* 3) Do not copy sections (i.e. text) from sharable libraries.
4) Remove all sharable library symbols from the symtab.
Add new sections to the image to hold stuff required for dynamic linking.
5) For images linked to sharable images, add the reference to the
program interpreter. Add .interp section to hold this.
6) Generate a _DYNAMIC section, put it somewhere (at the end of
.text??). Initially this section would be empty, but create primatives
to add entries. Add this to the program header.
7) For each sharable image, add the DT_NEEDED entry in _DYNAMIC so that
the dynamic linker knows which sharable images are needed.
8) Generate the second symtab which contains the symbols needed for
dynamic linking. Generate the second string table which contains the
symbols for dynamic linking (.dynsym, .dynstr).
9) Generate the hash table, and generate the buckets and chains needed
to describe all of the symbols in the new symbol table. Add reference
to this in _DYNAMIC (.hash).
10) Generate the PLT for this image for referenaces to sharable
functions. (.plt).
11) Generate the relocation section (.rel.plt) for references to
sharable functions. Add appropriate pointers to _DYNAMIC.
12) Generate GOT for references to objects in the sharable images.
Add (.got) section to hold this.
13) Generate the relocation section (.rel) for references to non
function stuff. Add appropriate pointers to _DYNAMIC.
14) Ancillary project - fix up binutils as required.
--
"The woods are lovely, dark and deep. But I have promises to keep,
And lines to code before I sleep, And lines to code before I sleep."