Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Want to run Sco-unix program on Caldera Linux

208 views
Skip to first unread message

FS

unread,
May 1, 2001, 12:13:04 PM5/1/01
to

Hello,

I've read somewhere that I should be able to install and run Sco-unix
programs on
Caldera Linux. To be honest, I am a bit new to Linux, so my first problem is
to
mount the installation floppy of that Sco-program... Please advise me in how
to
do this...

Best Regards,

Fred Sirevag

sir...@hotmail.com

Jim Bonnet

unread,
May 1, 2001, 5:45:42 PM5/1/01
to
FS wrote:

you are going to have to compile filesystem support into linux to get
the floppy read. why not just tar up the floppy and FTP over? much
easier than rebuilding the kernel just to read a floppy or two.

Jim

Jean-Pierre Radley

unread,
May 1, 2001, 7:21:19 PM5/1/01
to ScoMisc [c.u.s.m]
Jim Bonnet propounded (on Tue, May 01, 2001 at 02:45:42PM -0700):

Jim, why do you assume that the installation floppy isn't a tar archive
in the first place?

--
JP

Brian K. White

unread,
May 1, 2001, 8:22:37 PM5/1/01
to

"FS" <n...@emails.please> wrote in message
news:XaBH6.4919$gX3.2...@news3.oke.nextra.no...

That depends what form the installation floppy takes.
if the instructions say "insert floppy and run custom"
then you have to install on a sco box and tar up the files after they are
installed.
if the instructions say something along the lines of "insert the floppy and
run tar xvf /dev/install , then run sh /tmp/install.sh" then you can go to
http://www.aljex.com/bkw/filepro/ and get "scotar"
In no case I have ever seen yet does one mount install floppies. sometimes
you mount install cd's, but never floppies.

There are a bunch of little issues you need to be aware of when running a
sco binary under linux. none of which are too bad, but there are usually
more than a few snags to work around and it means you can't expect to just
run it immediately as easily as if you were installing on sco.

shell scripts that assume /bin/sh behaves like SCO's /bin/sh, which linux's
/bin/sh does _not_ (easy fix is to install pdksh and edit the top line of
all shell scripts that came with the app)

common built-in system commands, like lp commands, need to be modified
(change "lp -dsomething -s", to "lpr -Psomething". or if you're me, write a
wrapper script that does it automatically on the fly)

you will probably need to hack your termcap

you will probably need to hack your apps termcap if it came with one

you may need to hack your terminfo

modern versions of linux, with Unix98-pty's and/or devfs enabled in the
kernel will generate device names that some legacy programs simply never
counted on and can't handle. (I have an app that can't handle the fact that
`tty` spits out /dev/pts/3 instead of /dev/ttyXXX like god intended)

you may need to be aware of the TZ variable

you may need to be aware of the LANG variables

and most importantly, you need to either compile the stand-alone module
"iBCS2" if on kernel 2.2.x or less, or compile yourself a new kernel with
the new linux-abi patch applied, if on kernel 2.4.x

you may need to be aware of the stty command, depending what you plan to use
for a terminal emulator.

you may need to be aware of "mapchan -n" on sco, and the equivalent
incatation on linux, "tput smpch" or if that is a no-op due to
insufficiently configured terminfo, echo -e "\033(U" will always work.

you may need to be aware of the differences between the default xterm on
sco, vs the default xterm on linux.

I'm sure I'm not thinking of a dozen more things, but I'm also pretty sure I
got all the biggies...

None of these are too big of a deal for someone who is very familiar with
both sco and linux, otherwise you are in for a lot of reading, or you could
just pay one of us to do it for you in about a half-a-day.

--
Brian K. White -- br...@aljex.com -- http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx Linux SCO Prosper/FACTS AutoCAD #callahans Satriani


Jean-Pierre Radley

unread,
May 1, 2001, 10:58:56 PM5/1/01
to ScoMisc [c.u.s.m]
Brian K. White propounded (on Wed, May 02, 2001 at 12:22:37AM +0000):

| "FS" <n...@emails.please> wrote in message
| news:XaBH6.4919$gX3.2...@news3.oke.nextra.no...
| >
| > I've read somewhere that I should be able to install and run
| > Sco-unix programs on Caldera Linux. To be honest, I am a bit new to
| > Linux, so my first problem is to mount the installation floppy of
| > that Sco-program... Please advise me in how to do this...
|
| That depends what form the installation floppy takes. if the
| instructions say "insert floppy and run custom" then you have to
| install on a sco box and tar up the files after they are installed.

Not necessarily. A tar archive can perfectly well be custom-installable.
example: BackupEDGE.

--
JP

Jim Bonnet

unread,
May 2, 2001, 10:01:17 AM5/2/01
to
Jean-Pierre Radley wrote:

>
> Jim, why do you assume that the installation floppy isn't a tar archive
> in the first place?

:) No particular reason.. Good point.

Jim

FS

unread,
May 4, 2001, 7:15:03 PM5/4/01
to

Thank you, Brian, this is definitely interesting information!
FS


Brian K. White

unread,
May 4, 2001, 7:35:44 PM5/4/01
to

<an...@anon.com> wrote in message
news:t7s5ftksplkjktuir...@4ax.com...
> In <hrIH6.2840$K5.2...@news1.rdc1.nj.home.com>, "Brian K. White"
> Seems like you got most of it, and some I haven't run into.
>
> For terminfo, I haven't run into any problems with the compiled
> descriptions. The only thing I've had to do special is make a link
> ln -sf /usr/share/terminfo /usr/lib/terminfo

I have an app (pcmiler) that won't run unless the terminfo includes rows &
cols. Thus it wouldn't run on the linux console until I figured out what
was wrong and added the fields to the linux entry. I also *think* I had to
make the linux entry smaller. I'm not 100% sure if that's so, but I know I
started out thinking I had to make the entry smaller for it to work, and
had ripped some stuff out of it, still didn't work, then I finally puzzled
out the rows & cols thing by comparing terminfos of terminals that did
work (xterm). the smaller entry, with rows & cols added, works. the
original linux entry, with rows & cols added, does not work. *shrug* some
day I may examine it closer, but probably not, now that it's working.

I have a terminal emulator (FacetWin) that I almost _have_ to use in many
cases, which has no "linux" emulation, and even if it did, I almost _have_
to use the "scoansi" emulation, because the users and my boss and the
other developers in my company don't want to learn new keystrokes. (they
want "Del" for break, they don't want Ctrl-Z to screw up the shell, etc...
This involves all of stty/termcap/terminfo) and the scoansi terminfo and
termcap that come with linux are junk. I have to import both from a real
sco box.

I actually have a fair little "SCO personality" bag of scripts and stuff
aggregating with each new customer who crosses over or needs to run
something that just doesn't exist on linux in the first place.

all of the things I mentioned, though I said he "may", these are all
things I did in fact have to adjust in some way before some sco app would
work.

> Similarly, if you use IPC (shared memory, messages and semaphores) you
> need to link create a link for the ipcs command.
> ln -sf `which ipcs` /bin/ipcs
> (Don't have linux booted, don't recall where it normally is on linux.)

That's one I've not hit yet, nor would I probably have had a clue what to
do about if I had. Thanks.


> You can run most SCO binaries with iBCS, but there as some shared
> libraries that just won't go. Some fiddling with iBCS may get past
> this. iBCS searches a limited span at the top of the file for some
> commonly used routines. It might be the area is too small; it might be
> that the routines they're looking for just aren't bound into the
> library.

Happily, I have not had to run anything but statically linked coff
binaries, Xenix386 up to osr5.0.5, and nothing but plain file & screen IO.
nothing with exotic streams usage or anything, though the ibcs docs list
various X apps that work.

There is another wierd issue that I haven't hit, though I might, and it
actually applies to running old Xenix apps on modern versions of Open
Server too, not just linux.

Someone once pointed out to me that there might be a problem with running
some xenix apps because of the fact that on xenix there was a hard limit
to the size of any single filesystem, (512 MB?) while today a single file
as well as a filesystem can be much more than that, and there might be
some kind of problem with some apps trying to access addresses that were
outside of xenixes limits?

I have an old xenix bbx app running on osr5.0.5 and linux, the linux copy
is my home box and my laptop for me to develop on easier, the osr5 box is
in live production ever since.. you guessed it, y2k. no wierd data
scambling like from writing data to wrong locations on the disk so far...
though maybe just because the largest single file has simply not grown to
the magic size yet?

John DuBois

unread,
May 8, 2001, 8:08:07 PM5/8/01
to

In article <k1HI6.14201$K5.17...@news1.rdc1.nj.home.com>,

Brian K. White <br...@aljex.com> wrote:
+Someone once pointed out to me that there might be a problem with running
+some xenix apps because of the fact that on xenix there was a hard limit
+to the size of any single filesystem, (512 MB?) while today a single file
+as well as a filesystem can be much more than that, and there might be
+some kind of problem with some apps trying to access addresses that were
+outside of xenixes limits?
+
+I have an old xenix bbx app running on osr5.0.5 and linux, the linux copy
+is my home box and my laptop for me to develop on easier, the osr5 box is
+in live production ever since.. you guessed it, y2k. no wierd data
+scambling like from writing data to wrong locations on the disk so far...
+though maybe just because the largest single file has simply not grown to
+the magic size yet?

The maximum file size under XENIX was the same as it is under OpenServer - 2GB.
The maximum filesystem size is now much larger than it was under XENIX, but
user programs are unlikely to have a problem with that.
The most likely issue for you to encounter is that inode numbers under XENIX
were 16 bits, while under current OpenServer they are 32 bits. A XENIX binary
which stats a file with an inode number >65535 will receive a truncated inode
number. This can cause problems, particularly when a utility is trying to
compare inode numbers to determine whether it has seen a file before or whether
two filenames refer to the same file. I migrated many, many utilities from
XENIX to OpenServer and saw only two cases of this.

John
--
John DuBois jo...@sco.com KC6QKZ/AE
I wish to God these calculations had been executed by steam. - Charles Babbage

0 new messages