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