[fpc-devel] OS aware RTL proposal

[Ales Katona]

Tomas Hajny wrote:

>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
>  
>
Yes that's the idea. IMHO the question is not if such a solution is the 
right thing to do in these situations but if it's POSSIBLE to do. I've 
looked at the uname syscall (which logicly cannot be "modernized" this 
way and there's no need to either).
I must say POSIX sux hard. The people who made this standard could save 
everybody lots of trouble by not doing it. As it stands out, I don't 
think there's any reliable way of finding out a version of OS in the 
unix world. They simply didn't bother with format specification.

Even if a parser is made which will "fall back" to "compiled-by-version" 
if the numbers don't make sense, there's still a possibility that you 
end up parsing it wrong thinking it's right, making the resulting binary 
malfunction. This is the biggest problem I see.

I guess Unix won another round of Stupidity vs ABI compaibility.

10:0 so far.

Ales