A.s. I already deleted it, but quite some older apps break on Vista now. Including e.g. Delphi 7. MS is also deviating from the compat path. Unfortunately.
> i. Too many bugs in any official release. This is unavoidable, > considering the many platforms and targets supported. But it is a fact. This is a bit vague. I assume you mean bugs of the blocking kind. Do you have examples? > ii. In any stable release, there are always some incompatibilities with > Delphi. Which means that Delphi developpers will have to put an extra > effort (in the form of $IFDEFs) to make their code compatible. In that > respect the lack of an "Object Pascal standard" in the form of some ISO > specifications is partially to blame. Yes. Failure of Delphi users to have any consensus about what is compiler behaviour, and what is language behaviour. Every bit of behaviour that Delphi exposes is considered gospel. > To summarize, if there is any chance for a large number of developpers > adopting FPC, they will have to come from the delphi crowd in the form of > people willing to do a little extra work of compiling their existing code > with FPC. This is the essence of Simon Kissel's proposal to Borland for > cross-kylix compiler. I sincerely hope that one day this will become a > reality with FPC. I've some doubts about that. One possibly end up in the same catch-22 we somewhat have been in TP/BP times. In the Turbo Pascal NG, there was sb declaring for about a decade that FPC was close, but not there yet, because it could not compile his TP code full of dosisms and 16-bit asm. IMHO this is also why Kylix failed. It was geared too much to float on a Linux-on-desktop hype, hoping to force a lot of Delphi apps to be recompiled on Linux because it-is-so-easy. It failed. Borland management probably assumed that the "recompilation" market was larger than the "invest in new linux products" markets. However the "recompilation" market fell victim to its own assumptions because it had to deliver a way smoother transition, which failed in a still to volatile delphi world. Compability is good, but should be a enabling factor to do stuff with FPC/Lazarus, not the end target for blind recompilation itself. Because then it will be just-not-good-enough forever. One can also see this currently with FPC. Major Delphi component builders start using FPC/Lazarus. They want to do things, and their customers are doing things, while FPC/Lazarus is not really registering en masse on > A final remark: the vast majority of pascal users use Delphi. So if fpc is > to attract a lot of them, compatibility with delphi must be 100%. These kinds of claims always promise heaps of users, but there are several problems with it: - Only a fraction of users will defect to run a clone. Most will either move on to the next big thing (Java/.NET) that has a lot of publicity, or stay as long as possible with Delphi. This also because they will never leave Delphi in the first place till it is really dying (because of its OS, or the toolchain competition) - The compability is never enough. Compromises (e.g. for portability) are not accepted, because their goal is only to get the code running, regardless of its quality or portability aspects. The "big break" is always another year away, when the compability is another magnitude bigger. - At some point the amount of compability you can add without effectively emulation e.g. winapi stops. We are building a compiler, not Wine. - At the same time you are alienating and neglecting your real users that do stuff with FPC. - At some points the heaps of commercial components are the real limitation, not the compiler. Porting is hard due to practical concerns relating to their closed source nature. Also there is another big danger: Even if bunches of users would convert to recompile their old Delphi stuff with FPC to give it another few years, what does it yield for FPC? These are all people planning to abandon the platform. Do you think they are going to invest majorly? > f there is only one incompatibility with a known workaround, a delphi > developpers will live with it. If there is a single major thing, one can > try to fix it himself. But if there are 10 or 20 small things then most > delphi users will give up supporting multplaform/fpc targets. How much will they add to FPC/Lazarus if they are not willing to invest that? Of course it is not black and white, but sb must report and fix those 10 or 20 things, (and those are not necessarily the same people). Somebody working on a project that invests real time in a FPC solution are way more likely to play a part in that, than people looking for a quick recompilation fix. > Unless your boss pays you to port delphi apps to FPC. > Now, I can understand that the FPC team has put a lot of effort in making > a compiler from scratch and it is natutal to do things differently. But it > will be a big boost for FPC if delphi compatibility stops being and issue. Every so and so many months, the number of delphi component retailers and people working fulltime with FPC reaches a new level. Also the number of people contributing with FPC increases. Of course these numbers are hard to measure, but having several Borland partners on FPC implementations and even selling them is a strong sign. Of course we could throw this slow, but steady progress all away and go for a quick fix hoping for large numbers of converts. I hope to have explained that one must be very careful with compability, specially the "effortless" kind. IMHO the focus must be on a kind of people that are willing to invest in creating FPC apps. Delphi compability is a factor too (due to the heaps of sourcecode it makes accessable), but don't think too much in an utopic "just recompile product" way. _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel