Hello Dave, hello everybody!
According to David Fiddes:
According to myself (Peter Gerwinski):
What Borland did with Delphi was to design the compiler to work together with exactly one library (VCL), exactly one set of development tools (object inspector etc.) on exactly one platform (Windows). I don't like this approach because it contradicts the general applicability of a compiler.
NO WAY! The only odd thing about Delphi is the compiler portion.
Sorry, but I don't understand this. I have the impression that we are referring to different things when speaking about "Delphi".
Since I think it is important for future GPC development that I understand what Delphi really is, let me please pose some questions - and sorry, if they sound stupid.
The whole system is designed to be cross platform(unlike C/C++,Pascal,et cetera) from the ground up.
What do you mean with "unlike C/C++, Pascal, etc."?
These are language definitions, which do not say anything about the platform the compiler and/or the compiled program have to run on. The only platform- specific think I find in the language definitions is that all of them require some terminal I/O for implementation of the `writeln'/`printf'/etc. procedures /functions.
The only thing preventing it is that Borland is too skint/not interested in doing it.
Here I agree: If Borland wished, they could make Delphi platform-independent. What I meant above is that they decided in a quite early stage to support only the Windows platform, and now it's way too late to adapt VCL to support, say, X11 as well. I would be glad if somebody proved me wrong.
You can replace the VCL if you so wish the only thing you lose is compatibility with the IDE.
This is the point where I must ask: What you mean with "Delphi"?
So far, I have seen four definitions:
1. the language definition,
2. the compiler (including compiler switches and such),
3. the compiler and the VCL, or
4. the compiler, the VCL, and development tools (the IDE plus all the tools for "visual programming").
When speaking about Delphi compatibility for GPC I refer to meaning #1 above. #2 is out of range, but one can work around this by using (*$ifdef*)s for incompatible compiler switches. (* There is only one thing in GPC preventing us from really doing so: the missing {$ifopt x+}. That's still planned. *) Most people who want to have a Delphi-com- patible system mean #4, but could live with #3, too. What I personally aim is #1, but I am almost sure that once we have #1, somebody else will create #3, and perhaps even #4. :-)
The Windows VCL implementation could quite easily(and I mean this)
Why do you think this would be easy?
I doubt that it is, but (as I already wrote) I would be glad if somebody proved me wrong.
be swapped out and replaced with an X-Windows-VCL, Mac-VCL, NEXT-VCL, etc,etc,etc. It should be possible to build(as in compile) a standard(i.e. not using Windows fns direct) Delphi application on any compatible compiler/processor/OS combination without touching the source at ALL.
You mean the source of the program, not that of VCL.
You are probably right. The point where we disagree is the "quite easily" above. As far as I have understood Delphi's internals up to now (which is not much, sorry), you need a lot of compiler magic for a working VCL. (That's what I meant with the compiler being designed to work together with exactly VCL.)
For example, when I create a Delphi project (Thanks, Larry!) with one form containing three `CheckBox'es, Delphi considers the following as the source of my program:
-- project1.dpr --
program Project1;
uses Forms, Unit1 in 'UNIT1.PAS' {Form1};
{$R *.RES}
begin Application.CreateForm(TForm1, Form1); Application.Run; end.
-- unit1.pas --
unit Unit1;
interface
uses SysUtils, WinTypes, WinProcs, Messages, Classes, Graphics, Controls, Forms, Dialogs, StdCtrls;
type TForm1 = class(TForm) CheckBox1: TCheckBox; CheckBox2: TCheckBox; CheckBox3: TCheckBox; private { Private declarations } public { Public declarations } end;
var Form1: TForm1;
implementation
{$R *.DFM}
end.
From this example I can learn that Delphi
1. allows to pass class types as arguments of procedures somehow (see the call to `Application.CreateForm'), and
2. allows some magic for the other parts of VCL to locate the data fields `CheckBox[1-3]' in `TForm1'. (* Is this the meaning of the famous `published'? *)
While I can accept most general-purpose language extensions (#1 could be such a thing), I don't like compiler functionality specifically designed for one library - which I suspect in #2. Please correct me if I am wrong.
GNU-Delphi is a real possibility. The only thing you would lose is the pretty IDE which, naturally, remains the property of Borland...afterall, everyone has a Windows box to do the initial development on.
(* One of the reasons why I started with GPC was because I cannot stand Delphi's IDE ... ;*)
Not everyone has one, but everyone who wants to use such a "GNU-Delphi" probably has.
How should such a GNU-Delphi look like?
I would be really interested in a command line cross-compiler for Delphi that would allow me to port my existing Delphi software to the Mac,
(The Mac is likely to cause trouble here, because MacOS is not supported by GNU, AFAIK.)
X Windows,etc for nil effort.
"Nil effort" isn't realistic - at least the compiler switches will have to be adapted - but let's aim "minimum effort".
I build educational software for a living which gets sold to the general public/consumer(all PC based) and to teachers/schools/colleges,etc which for various political reasons use a wide variety of muck including Macs....I want to sell to these folk...these folk want to buy from me...but they don't want to have to re-equip with PCs....
... which I can understand well ...
and doing serious development on anything other than Delphi is out of the question as it would quadruple the lead time/number of staff required to complete a given project.
(* For me it's vice-versa: Using Delphi for serious development would quarter the time needed to produce a running program (10%), but would quadruple the time/number of staff required to get it stable (90%). ;*)
fyi, this is why I like GNU-Pascal.
I hope - and am doing my best - that you won't be disappointed.
yours (rantingly),
:-)
Yours,
Peter
Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970624] - http://home.pages.de/~gnu-pascal/ [970125]
-
Peter Gerwinski