I read the .NET FAQ http://www.freepascal.org/faq.html#dotnet.

I think the supposed advantage of portability should be refuted more clearly. I think object pascal code compiled with fpc is more portable than the Delphi.NET code. I propose the following change.

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.

What do you think.

Vincent

Originally that phrase was not just about Delphi.NET, but for "whole" .NET.

It was mostly against Mono which was quoted again and again as the perfect substitute, while not even working in theory. However this has changed somewhat, and I'm told most stuff works for at least avg 1.1 C# code. (still don't know anything about the practicality of Delphi.NET -> Mono, and if that only works if the code is crafted)

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.

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.

-Bee-

has Bee.ography at:
http://beeography.wordpress.com

Why Delphi has no problem supporting .Net without sacrificing backward compatibility (too much)?

There is a problem.

So a specially selected demo works. Interesting, but I make full apps, have a certain amount of code that I use that I haven't written. (components) etc.

In anything remotely portable, selected demoes work. That is the reason for the reference to "hello world level". Simple, clean stuff always work.

But the barrier between native and .NET is about full codebases and the associated components, not about demoes.

I know writing FPC port for .Net is far from easy. But the difficulty should be on compiler code side only.

You can't. Borland also didn't solve this. They did a reasonable job for clean code, but e.g. pointers are unportable.

Moreover, what you get is effectively a legacy codebase surviving on .NET, and next week some guy will say "we really have to convert VCL.NET to winforms", or "remove tlist/tstringlist, since they are slow in .NET and use native container types" etc etc.

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...

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.

Moreover, you then still only have a basic ported app in native Delphi style. To benefit from .NET fully, you need another migration/rewrite.

And there lies the core for the problem for FPC. For Borland the whole dual platform strategy is a migratory thing (look how neglected win32 is). It makes business sense to make the migration easy, to hold on to old win32 clients.

Our "customer" base is largely not interested in .NET though (starting with the fact that half or more of the serious users don't even use windows). And we can't get the dual platform (native/.NET) traject up and running as fast as Borland. There is a fair chance that when we get there, it will be irrelevant, and a split between native and non-native will have occured again.

A dual codebase puts limitations on both sides. Native can't use what it is good at (lowlevel interfacing, optimizing stuff for performance), and .NET can't access the gigantic .NET framework because it is not portable to native.

Regardless what you think of .NET, I think the dual platform stategy is only a transition horse in time.

Hello,
My understanding is that enhancing the compiler to generate code for .Net would be only the first step. Next, every single unit included with FPC will have to be
re-implemented in .Net .
The effort is huge, and the maintainance could be a nightmare. Maybe this is doable,
with some substantial sponsorship to support a team of full-time developers. But it's not clear at all that the benefits would cover the resources spent ...

<not_serious_suggestion>
By the way : why dotnet and not java ? At least java has been around for a longer
time, and there are compatible jdk's for more platforms ... So we wouldn't have to
deal with differences like those between Mono and the .Net platform. </not_serious_suggestion>

Cheers,
Adrian Maier

Hmm, then we'll be able to show the world the JVM's notorious startup time. In most cases, compiling will be much faster than the app's startup time. The J in JVM probably stands for Jabba the hut <chuckles>.

<serious_suggestion>
Why not target LLVM instead?
</serious_suggestion>

Cheers,
Krishna

Krishna wrote

Why not target LLVM instead?

What is LLVM?

Regards,
- Graeme -

Graeme Geldenhuys wrote

What is LLVM?

Check this out: http://llvm.org

Cheers,
Krishna

Krishna wrote

Why not target LLVM instead?

I've also thought about that, but haven't looked yet at the technical specifications of LLVM to see how easy/difficult it would be.

Jonas

Adrian Maier wrote

<not_serious_suggestion> By the way : why dotnet and not java ? </not_serious_suggestion>

Acctually I was considering (not so near in the future), to research about writing a java byte code target for Free Pascal.

Of course the faq says you guys aren´t much pro it, but there do is a real use for this, because some devices can only run java bytecode, like many modern cell phones. I was even thinking it may be easier to write a java port (j2me) to get Free Pascal running on Symbian OS, then writing a native port, because there are so many incompatible versions of this OS, but all of them support j2me.

There are GPLed assemblers for java bytecode out there, so we would only need to write a instruction generator that generates that assembler and port the rtl.

About .NET and LLVM, they don´t seam to add anything Free Pascal already cannot do.

We should also think it may be inevitable to write a .NET port in the very long future (10 years?), if microsoft decides to obsolete windows api by that time.

Felipe Monteiro de Carvalho wrote

About .NET and LLVM, they don´t seam to add anything Free Pascal already cannot do.

Donno about .NET but LLVM advertises itself as a target for compiler development. It does a wide range of optimizations and if memory serves right, osnews ran an article citing the use of LLVM inside the latest release of MacOS-X.

Cheers,
Krishna

They cannot. Most existing software would no longer work. And people are not eager to upgrade. Why would they ? Windows XP or Vista bring nothing new. No-one is waiting for it.

At my company, we still have a huge number of clients running Windows 95, who protest loudly when we even _suggest_ upgrading.

Which is not to say that we should not port of FPC, but this is not very high on the priority list. After all, .NET offers no advantages by itself.

Michael.

IMHO it would be better to start over legacy free for .NET and really target the .NET/JVM/LLVM platform 100%.

I think that single source combinations are already all gone by the time we would enter production with a .NET port. And even if, a single source system would put a break too much on the mutual development.

See e.g. Borland, the native port is at a virtual standstill, the only thing they do is incorporate other peoples source (FastCode) and backport .NET specific language features that are meaninless in native mode.

Marco van de Voort wrote

IMHO it would be better to start over legacy free for .NET and really target the .NET/JVM/LLVM platform 100%.

Refer them to Chrome ? ;-)

Micha

So you would go the VB way: VB.NET completely broke existing VB code. The advantage of Delphi was exactly that it offered a transition path...

I don't consider that wise.
What is more, we don't have the manpower to maintain 2 source systems.

Michael.

No. I didn't say I even want to keep the appearance that I kept that.

The advantage of Delphi was exactly that it offered a transition path...

In the few cases I actually bothered to try, it was more on paper than in reality. Components, lowlevel code, nonsupported database drivers, you name it, it all meant rewrite of most of the code to a library (VCL.NET or at the website ASP.NET 1.x) that was already considered a transition horse, and another rewrite already appeared on the horizon "to really make good use of the nice features that .NET has to offer". And then again when Borland finally manages to push a 2.0 version out of the door.

I don't consider that wise. What is more, we don't have the manpower to maintain 2 source systems.

I did't have the even larger manpower to rewrite twice or thrice shortly after eachother. (in the end it was decided to put the native code into maintainance, and to develop a new system directly in VS2005 and finance it with the customers that directly benefitted from going to the new system. (e.g. because they integrated with existing .NET stuff)

HOWEVER, even _if_ I give you the Borland case (I don't, but everybody is entitled to his own opinion of course, and everybody can be wrong), do you think that philosophy holds true for us too?

From a marketing perspective (for Borland) it is perfect:

- They show a path of least resistance, a lot of users are going to take, even though it is actually the hard way.
- They get paid for it.
- They avoid mass evaluation of alternate solutions.
- If .NET somehow stalls, they still have win32.
- give them a C# compiler for the same money, and then hope a percentage will slowly transition. Mainly because it is the perceived .NET language of preference. Then tighten the noose of the legacy Delphi.NET. Result: same conversion with less defection to MS then saying directly "Delphi is dead, use Borland C#".

So now apply the above points to us? Do we gain from that? We won't get a single additional user till we are at least somewhat in the league of Delphi, while we have to neglect and compromise native to actually pull it off. Even Borland only managed to include some open source routines from Fastcode and some minor .NET language compat stuff in post D7 native versions.

IF .NET really is so succesful, we only will have something productworthy when native is already dead, and most backwards compat is already abandonned.

If it is not so succesful (e.g. a certain double digit percentage of users stays native) , or it is, but we can't get a piece of the pie because we are late, and legacy carrying non sexy, we have put gigantic effort in something new for nothing, drawing resources away from native development, like Borland did from win32.

It took us over 7 years to get on par with native Delphi after starting Delphi compat mode. Do your really want to start Delphi.NET now? I've seen the shear size of e.g. C# in VS2005 when I worked with it for a few weeks. It absolute dwarfs Delphi syntax in size, and worse, there are a lot of additional tools to be developed to take actual use of this (e.g. all the database binding directives). And all the while when we are implementing this, we'll get the standard reaction "nice, but not ready yet".

I sent this once already. Sorry if it duplicated, but I didn't see it showing up on the list:

JMO:

The last thing we want the FPC team to consider is a port to .NET. Delphi already does .net, and MSFT C# does it even better. Additionally, porting to .net invites FPC to become mired in the same mud that Borland has been stuck in since it decided to allow MSFT to dictate the terms of its market. Lots of good stuff in .net, but let's face it, our spending our brain cells developing for .net is better for MSFT than is it for us. I'll be happy to argue why that's the case.

There is functionality in .net that we all like, but FPC is going in exactly the right direction, albeit slowly without the commercial help that I wish the team would consider. The direction is the right one because it's serving a growing need represented by how the internet is evolving into it's own platform and devaluing the OS. So what's the presentation engine for this new platform? The browser. A great example of what can be done with a browser user interface is Morfik. Guess what one of the compiler targets is for Morfik applications. Morfik has a way to go, but their effort is looking much better than it did even several months ago.

What's the other part of this equation? The server side. As the internet becomes a platform in its on right, endpoints could care less about what the server OS is, as long as it efficiently provides services. That means we developers should become platform agnostic, and mono is **not** the solution for this. FPC is, and as computing power becomes more centralized, quality, scalability and efficiency will be even more valued. Hopefully FPC will evolve into a tool that will help us to address these issues so that we can build optimized server software, regardless of OS. Again, some judicous commercialization would help FPC in this regard.

So instead of supporting .net, I'd like to see FPC evolve into a language that has a personality that is radically different from anything MSFT is developing (and unfortunately by extension, Delphi). Imagine a FPC that supports Design by Contract, or has a Ravenscar profile. I'm convinced that future development will demand this sort of programmable quality assurance, so it would be another sales advantage for developers and companies using FPC. Whatever the example, the point is to be willing to put good ideas into code without letting MSFT decide what those good ideas will be.

James

Marco van de Voort wrote

HOWEVER, even _if_ I give you the Borland case (I don't, but everybody is entitled to his own opinion of course, and everybody can be wrong), do you think that philosophy holds true for us too?

Cut all your text out, I agree with most of if, but I just want to point out that I am not a proponent of a .NET port, far from it. I don't see the use of .NET, or Java for that matter, or any other language that runs in a VM...

Michael.

Interpreters are nice and can be handy. Somehow, people (and big corporations) have managed to turn them into multi megabyte monsters. CLISP, OCaml, Lua, GNU Smalltalk all have nice, small and reasonably fast VMs. IIRC, atleast one popular Pascal compiler targetted a VM (pcode?).

Cheers,
Krishna

Michael Van Canneyt wrote

Cut all your text out, I agree with most of if, but I just want to point out that I am not a proponent of a .NET port, far from it. I don't see the use of .NET, or Java for that matter, or any other language that runs in a VM...

Java is the only thing that runs on many cell phones. It´s impossible to port Free Pascal (and thus our pascal softwares) to these platform without making a java port.

So that´s the use of Java. To add support for phones.

Your statement answers the question
'what is the use of a Java port of Free Pascal'

My statement is
'There is no use for a language that runs in a VM, like Java or .NET'

These 2 statements can peacefully coexist.

Java and .NET VMs are an (unfortunate) reality with which we must learn to live... But that does not mean we should accept their existence without critique.

Michael.

IMHO the correct way is to gain access to the native API's, not add support Java.

Marco van de Voort wrote

IMHO the correct way is to gain access to the native API's, not add support Java.

It's not, because then your application will potentially only work on a specific phone model, possibly even only on a single revision of a particular phone model. The Java layer allows manufacturers to break binary abi and hardware compatibility at will (i.e., don't get bogged down by legacy design decisions or backward compatibility requirements).

The ease of third party providers which can distribute a single "binary" (jar file) that can run on multiple phones is a nice plus.

Jonas

Yes. However that is the vendors problem, not mine. He can also supply a adapted pascal compiler. So are compability problems.

In short, if the product sucks, and you can't get a decent interface to it, don't buy it.

Well, I'am still waiting for the java killer application for a mobile ;) Most java applications for mobiles I saw were simply a pain: inconsistent user interface, dog slow, freezing the phone etc.

Florian Klaempfl wrote

Well, I'am still waiting for the java killer application for a mobile ;) Most java applications for mobiles I saw were simply a pain: inconsistent user interface, dog slow, freezing the phone etc.

Quite possible, but we obviously have FPC users writing such applications for a living (in Java) and wanting to use FPC instead.

Jonas

Along these lines, I was wondering if anyone had built FPC for Windows Mobile 5.0 by any chance?

Robert Wolfe ( / )
Computer Programmer/Analyst & Web Programmer
SRDAR, Roswell Park Cancer Institute, Buffalo, New York 716-845-5788 | http://www.srdar.org

This email message may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for the delivery of this message to the intended recipient(s), you are hereby notified that any disclosure, copying, distribution, or use of this email message is prohibited. If you have received this message in error, please notify the sender immediately by e-mail and delete this email message from your computer. Thank you.

On 10/4/06, Wolfe, Robert > > Along
these lines, I was wondering if anyone had built FPC for Windows Mobile 5.0 by any chance?

Just use the Windows CE Lazarus snapshot. It should work for Windows Mobile 5.0 afaik. You can find a download link to that snapshot on the lazarus wiki.

Ummm ... I have doubts about that.

Suppose a Java port of Free Pascal is developed. Then Pascal will be running on the Java VM. Now, if we apply your statement we can conclude that there is no use for Pascal.

Maybe your statement would be more precise if it was:

'Software that runs in a VM, like Java or .NET are of inferior quality when comparated to native software'

Marco van de Voort wrote

IMHO the correct way is to gain access to the native API's, not add support Java.

In the case of phones, there is no native API.

The hardware isn´t documented, and the underlying OS also isn´t. There is no way to write a native application for them. In some cases the hardware is a physical implementation of the JVM.

I didn't say it was of inferior quality, although performance is an issue;

I just don't see the need for a VM.
On the run-time side, it is not needed if the OS is good. On the compile side it is not needed if the compiler supports many CPUs. You need to compile the VM anyway for any CPU you want support for, so why not compile the software at once...

The effort remains the same, and you eliminate a layer on the end system.

But let's stop this thread. If someone wants to develop a Java or .NET backend for FPC, he is free to do so... Regardless of my or your opinion of the desirability or usability of such a backend.

Michael.

For future reference, someone sent me a link of a commercial pascal compiler that generates java bytecode:

http://www.mhccorp.com/pascal.html

It claims to be compatible with Delphi 2 (not sure if it supports VCL) and targets J2SE.

There is also MidLET Pascal, that targets J2ME, but it´s abandoned and has very poor support for pascal standard RTL.

Canterbury yes, pretty wellknown. Quite OK, but nowhere near compatible. In fact they don't even SAY they are compatible!

From http://www.mhccorp.com/pas3release.html :

"Object Oriented Language Syntax similar to Borland Object Pascal"

Probably more something like Chrome, and even more incompat than Delphi.NET. (in which Borland at least TRIED to remain as compat as possible, even against impossible odds).

But we can cut this discussion short. I'd _LOVE_ to see FPC run on bytecode. If you find such a compiler, compile the compiler with it ( :-) )

Marco van de Voort wrote

But we can cut this discussion short. I'd _LOVE_ to see FPC run on bytecode. If you find such a compiler, compile the compiler with it ( :-) )

Since FPC is written in the FPC dialect, probably the only thing that will ever compile it is FPC itself.

Jonas

I won't make a problem of minor changes.