[fpc-pascal] .NET FAQ

[Michael Van Canneyt]

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.