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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
