Porting on Linux

who is this

Just wondering if someone could tell me, is it inherently easier to port between architectures on Linux, compared to Windows?

I just ask because I have always wondered why people are hesitant to undertake the "huge" task of porting to Windows x64, in spite of the fact that I'm sure even the 64-bit Windows has more end-users than ALL Linux architectures. And yet nearly every program for Linux is easily available on almost every architecture known to exist

EvilMonkey

who is this wrote: »

Just wondering if someone could tell me, is it inherently easier to port between architectures on Linux, compared to Windows?

I just ask because I have always wondered why people are hesitant to undertake the "huge" task of porting to Windows x64, in spite of the fact that I'm sure even the 64-bit Windows has more end-users than ALL Linux architectures. And yet nearly every program for Linux is easily available on almost every architecture known to exist

If its open source anyone can compile the code so yeah it is.
In Linux if you really want something ported you can do it yourself or contribute to a community effort and submit it to the project.

In windows if the software isn't open source you need the owner to port it and it might not be worth their time etc...

Naikon

I am no expert on this subject, but most UNIX/UNIX-like variants have to at
least 'mostly' conform to the IEEE POSIX standards.

This ensures application code is portable across many architectures.

I am not aware of the specifics, but porting the kernel to other archs
is more involved. As most kernel code is written in C, it is less of a task
to port between say i386 and MIPS.

The endianess/byte order of each arch may cause subtle problems however.

On the other hand, porting applications/'user space code' is less
involved, as most UNIX variants conform to the IEEE POSIX standard.

POSIX describes platform agnostic services such as process creation,signals, pipes,
I/O and the like that service applications. The conforming code is written in a manner
as to never allow code that will work on one platform like Microsoft always do.

Systems calls are routines that are 'called' when an application wants to access say
the hardware, fopen() would read a byte stream from the disk.

The kernel can only directly access hardware on behalf of the application.

So applications that depend on the general fopen() or fork() ect, system call can be
ported from say FreeBSD to Linux.

This is because the standardized code ensures it will compile and run on Linux
if the correct libraries are installed, along with the C standard library.

Windows on the other hand, only works on i386/x86-64. So much of
the core kernel code/application code is tied exclusively to that platform.

Even trivial functions like the windows clear screen function may depend
on PC BIOS specific routines.

To port windows to say an exotic platform like MIPS, a total rewrite
would probably be required, as the OS and applications depend
on features only available to the intel platfrom.

Kinda waffling/going overboard here, but I hope this helps even a small bit
Interesting stuff.

who is this

EvilMonkey wrote: »

If its open source anyone can compile the code so yeah it is.
In Linux if you really want something ported you can do it yourself or contribute to a community effort and submit it to the project.

In windows if the software isn't open source you need the owner to port it and it might not be worth their time etc...

I meant the OWNER having difficulty porting it. Like even open source stuff rarely has Windows64 variants, and I have noticed a few saying doing so would be a task not worth the effort for the time being.

And thanks Naikon, I had a feeling there was something about how the kernel interacts with the software installed, which made it easier to port. And the explanation of why was much appreciated.

EvilMonkey

who is this wrote: »

I meant the OWNER having difficulty porting it. Like even open source stuff rarely has Windows64 variants, and I have noticed a few saying doing so would be a task not worth the effort for the time being.

I would say thats because 64 bit windows emulates 32 bit windows very well so there is no need to port unless its a driver or something that needs to run really fast or needs the extra resources.
If you code for 32 bit anyone can run it, if you code for 64 bit it will only run on 64 bit architecture. So 32 bit has a larger audience and easier than maintaining a 32 bit and 64 bit source tree.
Porting from 32 bit windows to 64 bit windows shouldn't need much more than a recompile for 64 bit architecture.