[FIXED] What is the difference between Platform-Independent and Cross-Platform?

Issue

I have seen a lot of C/C++ Libraries and Gui Toolkits. Among them there are some like GTK+ , Qt , Swing etc. which claim to be platform-independent. While some , like WxWidgets, SWT etc. which claim to be cross-platform. At first I thought it to be just a change in wording, but the terms have been used with such consistency that I have started to wonder. What is the difference?

Solution

Cross-platform only implies that you support multiple platforms. It usually means Linux, Mac, and Windows. Platform-independent implies that you support any platform that your language supports- i.e., you depend on no behaviour that is not specified in the language specification. However that's just my personal opinion and most uses just take both of them to mean "multiple platforms", usually "Windows and ...".

Answered By - Puppy

Answer Checked By - Senaida (PHPFixing Volunteer)

Read More

[FIXED] How to prepend "./" to a path in a platform independent way?

Issue

I need to prepend ./ to paths in my code, which I'm currently doing like this:

let path = Path::new("foo.sol");
let path_with_dot = Path::new("./").join(path);

However, I want to maintain compatibility across multiple platforms while adding ./ in front of the path. How can I do this?

Solution

A platform dependent const for path separators is stored at std::path::MAIN_SEPARATOR. You can use this to create platform dependent paths. However, by default the Path.join method already uses this const so instead of writing:

let path = Path::new("foo.sol");
let path_with_dot = Path::new("./").join(path);

You would just write:

let path = Path::new("foo.sol");
let path_with_dot = Path::new(".").join(path);

And the result will automatically be platform dependent.

Answered By - pretzelhammer

Answer Checked By - Dawn Plyler (PHPFixing Volunteer)

Read More

[FIXED] How Cross-Platform or Platform-independent is achieved in .NET Core?

Issue

We all knows that .NET Core is platform independent and can run on any OS like Windows, Linux or Mac.

I am just little more curious to understand, how the Cross platform is achieved in case of .NET Core, where the same was not available in case of .NET Framework.

Would be helpful, if somebody explains.

Thanks in Advance

Solution

There are multiple factors contributing to that. important ones include:

• Integrating with operating system specific APIs

The operating system provides many low-level functionalities from file access over networking to scheduling. Just as in C/C++, you may need to implement things differently for Windows than for Linux or macOS.

.NET Framework was windows-specific so many things had to be abstracted and implemented differently for Linux / macOS for compatiblity. E.g. using unix socket APIs for networking instead of Winsock.

Also note that Garbage Collection makes use of more advanced uses of memory and scheduling APIs which also don't exists 1:1 on all platforms so there are implementation differences.

• Reimplementing some Windows functionality wrapped for .NET

Some features like Graphics (System.Drawing) or WCF hosting are acutally more a feature of Windows than of .NET Framework. Some of these had to either be reimplemented in pure .NET or separated out into support packages that you could use on .NET Core / .NET 5+ but would only work when run on windows. Others (WCF hosting) have been dropped altogether.

Another good example of this is globalization support, so handling language-specific details in .NET. This is used for many string operations, string formatting (e.g. formatting a month name in various languages) and so on. On Windows this used to use the National Language Support APIs but for Linux and macOS this was implemented for .NET Core using the International Components for Unicode (ICU) libraries. This causes some behavioral differences between these versions. In .NET 5+ even the Windows version of .NET will try to use ICU when available as it was included in Windows 10 in 2019.

• Generating native code for different architectures

.NET uses an intermediate language (IL) that user code compiles to that is not a machine executable format but can be translated into optimized for the native machine code of the system that the code is run on. This just-in-time compiler (JIT) needs to support all machine architectures (Intel archicture, ARM architecture, 32/64 bit, now WebAssembly is coming as well, ...). The JIT compiler in .NET Framework only supported the Intel instruction sets.

And some architectures / operating systems even have specifics for that. E.g. macOS 64 bit ARM (e.g. M1 chip) has some slight differences in calling conventions (needed for integration with the OS and libraries) than Linux. Furthermore the security system around running JIT compiled code requires some changes as well (write-XOR-execute memory pages).

Answered By - Martin Ullrich

Answer Checked By - Mildred Charles (PHPFixing Admin)

Read More