Member Avatar for JRM

hello all,
I have an old database that was written for xenix 386 using the old a.out binary format. Since then most unix/linux OS s have adopted the ELF format. These binaries will not run on a modern OS.

I don't have the source code, just the binaries. Is there any way of tricking the interpeter into using the appropriate ld.so lib and whatever else? there have been some half-hearted attempts to support a.out in the distant past, but I think they all dies out due a general lack of interest. modern kerrnels don't even deal with the update_binfmts module any more.

My only interest is to get the thing operational enough to output some data, then migrate it into an SQL setup in the near future.

Anyone been there, done that?

Thanks in advance.

  • 6 Contributors
  • 10 Replies
  • 144 Views
  • 1 Year Discussion Span
  • Latest Post Latest Post by vijayan121

Recommended Answers

All 10 Replies

Member Avatar for John A

Don't know, but since you don't have the source code, regardless of whether it's C/C++ or not, why post in this forum? Perhaps the *nix forums would be a better place for this thread.

Oh, and I kind of doubt you can migrate the executable, unless you maybe use a really old kernel...

Member Avatar for JRM

why post in this forum? Perhaps the *nix forums would be a better place for this thread. l...

It's a last-ditch effort. I've googled it to death. I could only find very old references to a.out support, nothing NEAR current. Nobody knows (or cares) about a.out anymore. It's a VERY DEAD binary format.

I though since this forum has some very experienced and talented folks, someone may have had to deal with this problem before...

Just a shot in the dark before I convert the data files! It would have been a hoot to see it run on a modern server, though.

Thanks

Member Avatar for jwenting

an executable created for one operating system isn't going to work on another, period (and Xenix is NOT Unix).
And there's no way to convert one into another.
Unix supports a.out just fine, but it will have to be a.out compiled for the exact Unix flavour you're using. You're not for example going to run a Solaris executable on AIX, despite both being a.out style binaries (or elf for that matter).

Member Avatar for Salem

> My only interest is to get the thing operational enough to output some data
Perhaps you could install xenix 386 inside a virtual machine, then run your old app inside that?

Member Avatar for JRM

an executable created for one operating system isn't going to work on another, period (and Xenix is NOT Unix).
And there's no way to convert one into another.
Unix supports a.out just fine, but it will have to be a.out compiled for the exact Unix flavour you're using. You're not for example going to run a Solaris executable on AIX, despite both being a.out style binaries (or elf for that matter).

Aha! I learn so much here! I was under the mistaken assumption that binary formats would be portable as long as they were compiled for the same processor.

Now that i think about it, the compiler is local and will read the ENVIRONMENT variables as well. Is this more like what's going on?

Also, I was also under the impression that Xenix was Unix-lite. It does use the same conventions and commands for the most part. If the binary was i386 Xenix, wouldn't have chance to work on a i386 unix?

Member Avatar for JRM

> My only interest is to get the thing operational enough to output some data
Perhaps you could install xenix 386 inside a virtual machine, then run your old app inside that?

A very good idea! Now to find those old 51/4 install floppies and a drive to run them. I might even have a few-SOMEWHERE. If the hunt proves successful, i'll let you know how it worked out.

Member Avatar for jwenting

Now that i think about it, the compiler is local and will read the ENVIRONMENT variables as well. Is this more like what's going on?

The environment settings have nothing to do with it. What matters is that each operating system has its own instruction set, which maps to the hardware instruction set.
You can't run software compiled for one OS on another even if they run on the same machine.
Often you can't even compile it under another OS running on the same machine, especially if it uses operating system specific libraries.

Member Avatar for procom1

I know that SCO Openserver Unix 6.0 is able to run the Microsoft a.out binaries that we run... We also don't have source to the binaries... But they were compiled for SCO Xenix and still run today on SCO's newest version of unix (SCO Openserver 6.0).

So far, we have not found another flavor of Linux or unix that will run these binaries.... but are hopeful that since SCO's future is looking dim, there will be some O/S vendor that will support them going forward... I see your post and know some others on the SCO forums that are in the same situation that I am....

Member Avatar for vijayan121

> Anyone been there, done that?
no, i haven't done anything of the kind. but i do know that the *bsd unixes do provide (sometimes limited) binary emulation for a variety of operating systems. i think NetBSD would be the best option for attempting this. the part of the kernel source tree you would want to look at is /usr/src/sys/compat/svr4. compat_svr4 provides binary compatibility for several systems, SCO/Xenix on i386 among others.

information on the NetBSD kernel source tree http://ezine.daemonnews.org/200205/netbsdsrctree3.html

binary emulation http://www.netbsd.org/docs/compat.html
http://www.netbsd.org/docs/compat.html#ports

compat_svr4 man page http://netbsd.gw.com/cgi-bin/man-cgi?compat_svr4++NetBSD-current
all the best.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.