On Fri, 29 Sep 2006, Bisma Jayadi wrote:
> > Current text: > > There is nothing practical known yet about how portable an average .NET code > > will be. Little experiments with hello world level code mean nothing, that > > kind of code works with plain C too. > > > > Proposed text: > > There is nothing practical known yet about how portable an average .NET code > > will be. Little experiments with hello world level code mean nothing. At > > this moment object pascal code that can be compiled with fpc is more > > portable than .NET code that can be compiled with Delphi. > > I think the proposed one is better. Agree with you. :) > > I'd also like to question this statement on the same page: > > > Moreover that also means that existing apps would have to be > > rewritten for .NET, since it would take more than a simple > > recompile with a FPC/.NET compiler. > > Why Delphi has no problem supporting .Net without sacrificing backward > compatibility (too much)? If I'm not mistaken (CMIIW), during Borcon 2005, > Borland demoed a Delphi 1 application (the famous FishFact demo) that can be > run on .Net by simply recompile it on BDS 2005. A similar demo is also > presented when Borland launched Kylix, simply adding a few $ifdef for q-prefix > and then recompile, the Delphi demo application can be running on Linux. Yes, but the fishfact demo is not a real-world application. They might as well have shown a simple "hello-world" application. (ok, stretching it a bit here...) I looked at porting my delphi code at work to .NET. It was simply not possible without an almost complete rewrite of all components we use... own code, third-party code, etc... > > I know writing FPC port for .Net is far from easy. But the difficulty should > be on compiler code side only. On the user/app code, it shouldn't cause > significant changes. Since Delphi and FPC has same language root, object > pascal, I wonder why existing FPC apps can't be simply recompile on FPC/.Net? > Of course, I never meant it'd work for EVERY kind of apps and codes, but it > should work for most common apps. You underestimate the difficulties. The .NET CLR does not know the 'untyped pointer' type. That means that a lot of RTL code must be rewritten; if not most of it. I'm not saying it can't be done, but none of the core developers sees this as a need or even a challenge. Maybe something for the Lazarus bounty system ;) But I'm guessing this would be a rather expensive one ;-) Michael. _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal