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).
Login
Register
FAQ
Search
