[openbeos] Re: Binary compatibility with Linux, and Be OS

  • From: "Solaja, Zenja" <solaja@xxxxxxxxxx>
  • To: openbeos@xxxxxxxxxxxxx
  • Date: Thu, 7 Nov 2002 08:54:18 +1100 

I remember reading the BeWine list ages ago (when BeInc was still focused on
BeOS) and their biggest problem was that BeOS, unlike Win and Linux, used
the opposite 2Gb memory segment for user land apps and kernel apps.  Since
its early in the morning in Australia and I still haven't had my morning
coffee, my powers or reasoning aren't that great, but here is what I recall
(and I may be completely wrong).  Apparently, user land apps live in one 2Gb
segment while the kernel lives in another.  Just by checking one bit of a 32
bit jump  address you can determine whether you need to jump into kernel
mode or remain in user mode.  Linux and Windows coincidently (or by design,
who knows) share the same partitioning scheme, so Wine was easier to
implement.

BeOS on the other hand, has an opposite layout to Windows and Linux.  From
some ancient mailing list I remember reading that the decision was by design
(sometime when BeOS switched from PEF to ELF), to prevent clueless users
accidently launching a app designed for another system.  This was the
biggest problem for the BeWine team, since they had to figure out a way to
swap the memory space.  I have no idea how this problem was addressed.
Coincidently, another stumbling block was mmap(), but the new kernel should
take care of that :-)

Take care.


> -----Original Message-----
> From: Mark A Johnson [SMTP:hotplasma@xxxxxxxx]
> Sent: Thursday, November 07, 2002 8:12 AM
> To:   openbeos@xxxxxxxxxxxxx
> Subject:      [openbeos] Binary compatibility with Linux, and Be OS
> 
> Yeah, I know this thread was meant for the making of RealPlayer open
> source, but this should bring up a point.
> Ok, well my take on it is, that maybe this would be a good idea. Do what
> the people at SkyOS did. Integrate a LinuxVM, so you can run Linux
> programs on O/BeOS or whatever the new name will be. And have a third
> party developer develop X for BeOS (even further than what has been
> done). Or under this VM (probably going to be ran as a server maybe
> linvm_server) And with this server have all the system calls adapted to
> OBOS's calls and add some compatibility between the two and you will have
> Linux programs running on BeOS, I know it is more complicated than what
> it sounds but if enough determination and effort, it can happen.
> 
> Mark
> 
> On Wed, 06 Nov 2002 10:29:46 -0500 "Michael Phipps"
> <mphipps1@xxxxxxxxxxxxxxxx> writes:
> > >Finn Bastiansen <finn@xxxxxxxxxxxxx> wrote:
> > >> > Well, when we support the codec API from the player, there is 
> > no 
> > >> > reason 
> > >> > why we can't use those close sourced codecs.
> > >> Ok, if you say it, I believe it :-) I am not a programmer. 
> > Doesn't it 
> > >> have 
> > >> to be compiled for BeOS, or is it enough that the executable 
> > format 
> > >> (ELF) 
> > >> is the same?
> > >
> > >It would be helpful if they are using ELF, it would be much nicer 
> > if 
> > >they are using the same compiler, etc.
> > >Else it could get very hard to do it, but it wouldn't be impossible 
> > ;-)
> > 
> > To clarify this a little bit (or maybe muddy the waters):
> > 
> > An ELF file is a standard, with all that entails. It exports (i.e. 
> > contains and
> > will allow others to use) certain functions. It imports (i.e. uses 
> > and needs) 
> > certain functions. With some exceptions (more in a minute), an ELF 
> > x86 file
> > *CAN* run on any x86 operating system. So long as all of the 
> > imported 
> > functions are available. Think about it - what is a program (esp in 
> > today's world)
> > but a set of x86 operations and some function calls to the OS. If 
> > those exist, you
> > are golden. In fact, IIRC, back 4 or 5 years ago, someone 
> > successfully built some
> > very simple Linux apps and ran them unmodified on R4. 
> > 
> > There are some issues though. One is system calls. While I don't 
> > know for sure what mechanism
> > Linux uses, I am very sure that they aren't exactly the same as 
> > BeOS, and I won't promise
> > that they will be the same for R1, either. There is certainly a 
> > temptation to go that route. 
> > Esp if there were a native X implementation, like BeX used to be 
> > (any real old timers out there?).
> > How convenient would it be to be able to use every Linux app? Very. 
> > But there are certainly issues
> > to make that happen. I think that some enterprising hacker could do 
> > it, with effort, but it would not
> > be easy and I think that time would be better spent getting an R1 to 
> > work...
> > 
> > 
> > 
> > 
> > 
> 
> ________________________________________________________________
> Sign Up for Juno Platinum Internet Access Today
> Only $9.95 per month!
> Visit www.juno.com
> 
----------------------------------------------------------------------
IMPORTANT NOTICES
This email (including any documents referred to in, or attached, to this
email) may contain information that is personal, confidential or the subject
of copyright or other proprietary rights in favour of Aristocrat, its
affiliates or third parties. This email is intended only for the named
addressee. Any privacy, confidence, copyright or other proprietary rights in
favour of Aristocrat, its affiliates or third parties, is not lost because
this email was sent to you by mistake.

If you received this email by mistake you should: (i) not copy, disclose,
distribute or otherwise use it, or its contents, without the consent of
Aristocrat or the owner of the relevant rights; (ii) let us know of the
mistake by reply email or by telephone (+61 2 9413 6300); and (iii) delete
it from your system and destroy all copies.

Any personal information contained in this email must be handled in
accordance with applicable privacy laws.

Electronic and internet communications can be interfered with or affected by
viruses and other defects. As a result, such communications may not be
successfully received or, if received, may cause interference with the
integrity of receiving, processing or related systems (including hardware,
software and data or information on, or using, that hardware or software).
Aristocrat gives no assurances in relation to these matters.

If you have any doubts about the veracity or integrity of any electronic
communication we appear to have sent you, please call +61 2 9413 6300 for
clarification.

Other related posts:

  1. Home
  2. haiku
  3. Archive
  4. 11-2002