[fpc-devel] OS aware RTL proposal

Tomas Hajny XHajT03 at mbox.vol.cz
Fri Mar 10 15:53:37 CET 2006


Michael Van Canneyt wrote:
> On Fri, 10 Mar 2006, Marco van de Voort wrote:
>
>>> http://www.freepascal.org/wiki/index.php/OS_aware_RTL
>>>
>>> Tell me what you think
>>
>> First: only Linux has the main problem. BSD never renumbers ABI calls,
>> newer
>> abi calls have a different prototype.
>
> This is manifestly wrong:
>
> Sure, there are new syscall numbers in linux, but the old numbers
> still work as they always have. Proof:
>
> The current set of numbers already works since 10 years.
>
> I'm not saying you'll have the latest features with the old numbers,
> but that is irrelevant.
>
> Windows has the same issue. For almost each and every OS XYZ call,
> there is a XYZex call. It's normal if you want to maintain backward
> compatibility, but also want to give new version numbers.
>
> IMHO all we need to do is to decide which call (number) we want to
> use, and warn people that some things may not work on older systems.

That's the main point, I guess. As it is now, we have to decide and either
sacrifice the new features, or compatibility with slightly older
platforms. My understanding is that the proposal of Ales was related to
exactly this situation.

If I understand it correctly, his suggestion basically allows to extend
the support for older platforms (i.e. keeping your binaries working
properly on those platforms) while still supporting the new
functionalities if they are available (i.e. if running on a newer system
version).

It's obvious that this approach cannot work correctly under all
circumstances. In some cases there's just no fallback solution available,
so you might end up with an exception while trying to use the binary on
some old system version. However, your application can still handle this
situation and present it to the end-user in friendly way (e.g. notifying
him of this fact, but still allowing him to use the other functionalities
not relying on the particular new API call).

Tomas




More information about the fpc-devel mailing list