Linux ELF semi-compatibility

Discussions on more advanced topics such as monolithic vs micro-kernels, transactional memory models, and paging vs segmentation should go here. Use this forum to expand and improve the wiki!
User avatar
AndrewAPrice
Member
Member
Posts: 2299
Joined: Mon Jun 05, 2006 11:00 pm
Location: USA (and Australia)

Re: Linux ELF semi-compatibility

Post by AndrewAPrice »

kerravon wrote:
AndrewAPrice wrote:If you ported your own libc you implement the compatibility layer via functions in a vtable. Then once at program startup (in your crt0) detect the OS and fill in the vtable with pointers to the OS-specific functions.
I agree that it would work, I just don't like the different code paths.

So with regard to the one place that has a different code path:

/* user pressing ESC will always be 1 character on MSDOS,
but not PDOS */
So in this case, you'd have a binary that uses libc, but there will still be things that function a little differently on different operating systems (especially if you deal with external processess - such as how the terminal emulator feeds characters into your program). Perhaps it would be best to build upon a higher level library such as SDL that hides many of these platform differences.
My OS is Perception.
kerravon
Member
Member
Posts: 278
Joined: Fri Nov 17, 2006 5:26 am

Re: Linux ELF semi-compatibility

Post by kerravon »

AndrewAPrice wrote:
kerravon wrote:
AndrewAPrice wrote:If you ported your own libc you implement the compatibility layer via functions in a vtable. Then once at program startup (in your crt0) detect the OS and fill in the vtable with pointers to the OS-specific functions.
I agree that it would work, I just don't like the different code paths.

So with regard to the one place that has a different code path:

/* user pressing ESC will always be 1 character on MSDOS,
but not PDOS */
So in this case, you'd have a binary that uses libc, but there will still be things that function a little differently on different operating systems (especially if you deal with external processess - such as how the terminal emulator feeds characters into your program). Perhaps it would be best to build upon a higher level library such as SDL that hides many of these platform differences.
For starters - I am aiming for public domain code - I just checked and that is under a license.

Secondly - I'm not sure what I want to "build upon" anything at all - PDPCLIB is already built. My question was more refinement or a feature within that already-built product.

And it is the C library's job to hide platform differences - and that has already been done (over the last 3 decades).

BTW, in the last 24 hours, pdld has started producing 64-bit ELFs. And I can thus produce them purely on PDOS/386. But the compiler I am using (a fork of gcc 3.2.3) is using Win64 function call convention. Because I have no external dependencies other than the syscalls, that is the point where I translate from Win64 to Linux syscall register convention (which is slightly different from Linux function call convention).
Post Reply