Board index » kylix » I - The Challenge

2005-03-14 04:08:25 AM
kylix0
Let's face it: Kylix is dead - desipte all the nice words we hear from Borland.
The FreeCLX project has not shown a sign of live yet, Delphi 05 has dropped CLX
alltogether and due to the NET 2.0 / Compact framework / Windows XY work Danny
and the Delphi team at Borland have to do, we won't get an update for Kylix in
near future (if ever). Additionally mono support of Delphi is pretty much non-
existant and the QT shipped with Kylix will soon be outdated by two majour
versions.
It's only due to us (most notably Andreas of course) that Kylix still runs on
Linux. However, this can not go on forever, as the class libraries (SOAP, WEB)
are outdating with each day passed even more and FreeCLX can't replace current
commercial CLX due to license and component issues.
The FPC guys have their own feature and class library set and are not willing to
build a bridge for current Kylix users to use their compiler (with CLX) in
future. Besides, even if they did, we still would have the problem of the CLX
being unsupported and the fpc compiler lacking some features (AFAIK).
In short, developing Delphi compatible applications that run on Linux is quite
impossible now and in no case future proof. It's a dying platform.
As you probably can imagine, I can not stand this situation: I like to have my
pet language (and framework) and I'm willing to invest time to reach this
goal.
So here is the idea: Jump on the Mono bandwagon and implement a Delphi com-
patible compiler plus add the VCL.NET (or CLX.MONO if you like) on top of
GTK#.
You might think "he's gone crazy now" or something along that line. It's obvious
that our small community can not build and maintain a class library (CLX, RTL,
WEB...), an IDE with De{*word*81} and a compiler at the same time (even if we would
have the source code), but let me explain why I think this idea is worth the
effort and why I think we can reach the goal:
Let us look at the chosen platform at first: Mono (or .NET). The downside of
course is that we don't get native executables if we take this path, but
because Novell stands behind this project with some full time employees, we
can be pretty sure that the platform will evolve. IIRC there is even a
version of python that runs on .NET. Regardeless - this downside is at the
same time also a very important strength: We will have to support only one
platform (.NET) that itself runs on all machines and operating systems Mono
is ported to.
Even more important is the key aspect of .NET, namely the "freedom of language":
Every line of C# code that is added to the mono libraries is automatically
available in Pascal. Basically this means that we only have to care about VCL -
everything else is done by other people not part of our project. It also means
we have a complete basic library from project start and can concentrate on
other things.
After the platform, it's probably the managed compiler that will need most
efforts. So let's think about it: As I see it (and please correct me if I'm
wrong here), we do not need to start from scratch. On the one hand there's the
Free Pascal Compiler that we can fork from and on the other hand we can use code
from the Mono C# compiler. If we take the Free Pascal approach, we can use
Delphi.NET for bootstrapping and I assume that the FPC community will be helpful
when we're hitting a wall. Going that route will probably be most beneficial as
we will get the ultimate unit test plus - by incorporating the FPC code base -
the complete experience of several million lines compiled Pascal code.
At the end we'll have our own Delphi compiler that probably won't be as fast or
efficient as Borland's product, but it will be future proof and truely ours.
(Note that we only have to emit IL-Assembler and let the dirty work do the
mono tool..)
All the things said above are - obviously - only half the fun, because without
any meaningful CLX.NET wrapper we get nowhere from Kylix. Personally I'd really
like to see CLX.NET on top of GTK# (which is the true Mono widget set) as this
would make an end to the desasterous license issues we have with QT. It might be
whishful thinking, but maybe Borland donates the old (complete) CLX under some
LGPL license, so we would not have to start from scratch and understands that as
new-old "Community Project".
Borland would not lose anything by doing that because practically noone is using
the CLX today - plus Borland does not update CLX and the CLX itself is
completely outdated. Additionally Borland would get a VCL.NET compatible wrapper
for GTK# for free while only having to maintain VCL.NET... This would - in turn
- also strengthen the position of Delphi on Windows.
I think this is a fair deal.
Now we have the compiler, the glue framework - but the package still lacks the
IDE: Fortunately there's MonoDevelop with included de{*word*81} that will only need
a few modifications to support Pascal as new language. Integrating the CLX.NET
will be more time consuming, but in the end we will only have to maintain the
"Pascal" part of the IDE: The rest already has a team responsible for it.
If you made it all the way down here, you're certainly interested and I want to
hear from you! What do you think about this? Can you imagine contributing some
pieces? Can you imagine taking over some part? Will you join the team?
To answer the question for myself: I'm terribly interested in compilers, so I'd
be happy to be part of the compiler team. I do have some insight into the mono
JIT engine and can help introducing new mono users to the Mono JIT code base.
I'm also the "owner" of a sourceforge project (if it's not deleted in the mean
time) that would be suitable for the compiler.
Now how about you?
Thanks,
Willi
P.S.: I'm also "discussing" the compiler issue on the mono-devel list.
 

On 2005-03-13, Willibald Krenn < XXXX@XXXXX.COM >wrote:
You can't create a Delphi compiler in .NET. Period. You can only
create a Delphi.NET compiler. Different horse.
Second. How long you think is this going to take? Do we grant you as much
time as you gave the current FreeCLX effort?
Third. It sounds a bit odd that there is an initiative to start from rock bottom
nothing, that is considered easier than efforts that have come a long way.
Fourth. Why you? What makes you so special that we would trust you over proven efforts
of Andreas, Simon and the decade old FPC team? A bit of cheap advocacy and dreaming is
quickly put together, but what do you actually have to show, that justifies trust in
this project? A start? Other projects you've done of this magnitude?
all so anxious to keep working, have to be thrown out.
This because the widget set is different, OS interfacing has to be
rewritten, and the language is so different it doesn't even support a basic
language feature pointers.
This is not entirely true, e.g. there are functional .NET languages, but
show me a typical solidly compiled language that can be compiled to
(managed) .NET without mods to the sourcecode, and I'll take that back.
(Wasted enough time on this cheap advocacy attempt)
 

Marco van de Voort wrote:
--
Regards,
Andreas Hausladen
(www.kylix-patch.de.vu - unofficial Kylix 3 patches)
 

{smallsort}

Marco van de Voort schrieb:
recently, because I don't follow the FPC development.
project months ago, but nothing has surfaced so far. We have to work with a
class library that is outdated and Borland did not even care to donate us a new
QT binding. There was no compiler update and no IDE update. I wonder what
happens if everything will be NPTL only. There are officially no plans for Kylix
for this year AFAIK and it's questionable if thereafter Kylix even exists.
What else do you call this than dying? Phasing out?
The next thing Borland will do is to announce a new Kylix that compiles
applications for the managed runtime of mono/whatever, so that Borland can reuse
the Delphi.NET compiler. I'm pretty sure there won't be any new native Delphi
compiler for Linux in future and I highly doubt that the CLX will be used in
it's current form if Borland decides to introduce a new version of Kylix.
that license and even if I could, very important parts are missing. But if you
want, I can show you my backported unofficial CLX patches for Delphi 6. I hope
that counts in your eyes, even if it's not FreeCLX related and not GPLed.
has changed all over time...
BTW: You're always talking about the current FreeCLX effort - other than Andreas
working on a QT 3 binding, that is GPL only (and therefore has some quite
limited use) and does not solve the IDE and compiler problem, I can't see any
efforts. All I did notice was the announcement that something inside Borland has
to be done. This was months ago. Since then nothing - except Andreas' screens -
happened. Lastly the FreeCLX effort is about the CLX - but what about the
compiler, the IDE? Do we have the source for these?
FreeCLX is crippled and GPL only, the CLX patches are no real solution because
it's still Borland's code, so we'll never be able to set up a public repo with
all the CLX files and fix/improve on that. Simon's cross compiler is cool,
because that eliminates the Kylix IDE, but if you want to develop under Linux
this doesn't help. FPC's framework will always be some island: Not Delphi/Kylix
compatible, not .NET compatible.
Realistically - what choices do we have? .NET/Mono is pretty much the only
answer I can think of.
It's cross platform, the architecture more or less Delphi(.NET) compatible, it
has people working on it full time and last, but not least, it's minimizing our
work while maximizing our access to third party libraries. I consider
FPC/Lazarus to be much more work than implementing a Kylix.Mono compiler on top
of the CLI with the addition of some CLX.NET on top of GTK# and some additional
stuff to make the Mono IDE Pascal aware. (If it was not for Kylix compatibility,
you would not even need the CLX.NET)
you seem to think I can't do anything. Besides it's an open source project, so
hopefully there will be a team with the same goal and not just *me*.
But to answer your question: Sure, I've not done the 'big' thing yet! Until
today I've more experimented with things:
I was part of the Delphi Web Scripting team and made some proof of concept
implementation of using native Delphi packages from within DWS scripts without
any additional software layer (= writing wrappers). I thought this was pretty
cool stuff, but .NET was quicker.
In another project I experimented with a C version (Kylix 3 actually) of Martin
Waldenburg's Delphi parser to extend the Delphi language with simplistic
generics. (Compile Delphi+Generics to normal Delphi.) It's this project which I
now want to revive with different goals.
I did a D6 interface compatible backport of Andreas' patches that you can
download from my homepage. (Not quite up to date I'm afraid.) You can also find
scripts to re-build your D6 runtime packages there.
Lately I investigated the topic continuous optimization in mono and added some
initial continuous optimization framework for Mini on AMD64. (Not in the
official tree, the 100k patch that will surface on mono-devel waits for admin
approval due to size.)
I started Pascal back in the Turbo Vision days and I'm since {*word*60}ed.
agree, lots of changes are necessary, but the RTL is more or less part of the
compiler; On the positive side: We probably can use parts of the existing C#
compiler backend of Mono. Plus we get the complete framework, a working JIT
(Linux 32/64, Windows 32, Sparc, MAC AFAIK) and a non GPLed widget set.
It's the large and ever growing framework that makes this approach so
beautifully in the long run. What do we currently have for Kylix on 3D party
components?
Furthermore we only have to make this change once, afterwards we get every
single new platform for free.
turned out as proof of concept 'it can be done'.
Even more
some exceptions. Java, Delphi, C# - all are somewhat similar.
but
because every new platform introduces the need of modifying the source here and
there. Take Delphi Windows (VCL) and Kylix (CLX) as an example..
Regardeless, there is interest on the mono-devel list for a free Delphi compiler
for Mono, so I think the compiler part already stands. It's just a question of
the CLX.NET now, I guess.
Willi
 

that Kylix has been abandoned and Delphi is moving towards .net and away
from Win32/Win64, The best advice I would have would be to install
Lazarus on your machine, subscribe to the developer's newsgroup and help
it grow. Test it, find a problem, report it and include the fix. The
community is energized there and its exciting to be a part of it.
Think of it as Kylix 4.0. After all Kylix had its roots in open source.
Maybe things will change around here. Maybe Borland could somehow work
with the Lazarus team. Until then, Lazarus is my new home.
 

Willibald Krenn wrote:
from VCL. And the CLX is not really a good framework to reimplement. It is
a crippled Delphi 5 VCL.
And "procedure xxx(var Msg: TMessage); message xxx" is the better approach
that to override EventFilter.
Qt3/CLX is a patch against the original CLX. In other words: If you own a
valid commercial copy of Kylix and Qt 3 you can do anything the Borland
no-nonsens and the Qt 3 commercial license allow you to do.
But Qt3/CLX is far away from being released.
--
Regards,
Andreas Hausladen
(www.kylix-patch.de.vu - unofficial Kylix 3 patches)
 

You are not the first to think along these lines.
see:
www.chromesville.com/
You can already request a beta version for testing from them.
You also should read the newsgroup remobjects.public.chrome
-Michael
 

Andreas Hausladen wrote:
cannot create a commercial closed source product without buying a
commercial licence from Trolltech. The above statement is as close to
it as you have been.
B
 

On 2005-03-13, Andreas Hausladen < XXXX@XXXXX.COM >wrote:
 

On 2005-03-14, Andreas Hausladen < XXXX@XXXXX.COM >wrote:
 

On 13 Mar 2005 23:19:58 -0800
"Andreas Hausladen" < XXXX@XXXXX.COM >wrote:
Micha
 

Marco van de Voort wrote:
--
Regards,
Andreas Hausladen
(www.kylix-patch.de.vu - unofficial Kylix 3 patches)
 

Micha Nelissen wrote:
Messages have syntax support in Delphi.
message occurs the platform dependent code translates it to an event. This
event is then sent to the QApplication where QApplication checks for
installed eventFilters and passes the unprocessed event to all
eventFilters installed for QApplication until one returns True (=Handled)
or the last QApplication eventFilter has passed. Then the event is sent to
the receiver. The receiver passes the event to all eventFilters which are
installed for the receiver and if non of them return True the event it
passed to event() where the widget reacts on it.
Because Delphi/Kylix cannot override the virtual QObject::event() method
Borland decided to install a hook object that redirects the eventFilter()
method to a cdecl function pointer (the place where CLX can hook in).
eventFilters are a great thing but you have to write long "case of"
statements where you can simply use a message method for a message based
system.
The best solution meight be a combination of both.
--
Regards,
Andreas Hausladen
(www.kylix-patch.de.vu - unofficial Kylix 3 patches)
 

On 2005-03-14, Andreas Hausladen < XXXX@XXXXX.COM >wrote:
prefer Object Pascal as designation btw). (extreme) subsets can be converted
to nearly anything, but except as academic exercise it is pretty pointless.
If I'm concerned about migration, I have a significant codebase, and proving
portability with homework assignment level code has no relevance, specially
if one knows up-front that elementary language features are missing.
Pointer code that works on _all_ Borland pascal dialects, and even a good
deal of non-Borland dialects and on all OS/Architectures fails on
Delphi.NET. I'd say that is a pretty good reason to call Delphi.NET a
separate language.
That doesn't mean it is evil, it just makes a win32->Delphi.NET migration
a totally different magnitude than say D<x>->D<x+1>with x=2..6, and
probably even to D2005/win32.
Borland probably realises all this, which is why there is a d2005/win32.
Win32 and compiled languages don't go away for the next 5 years. (and
happens in longer timeframes is unpredictable). I don't want to imply that
.NET will go away either, it will probably pick up most of the
business/database oriented programming, while hw interfacing and control
apps will remain compiled.
To put stuff in perspective: my companies app uses more pointers than
memproof can count. So that pretty much makes .NET impossible.
 

Marco van de Voort wrote:
So you must not justify you point to me. I also have applications that
cannot be migrated to .NET even they are VCL applications. Delphi Win32
supports pointers so you use pointers without thinking 5 year in future.
For example the VirtualTreeView component is a candidate for pointer
usage. It will not port to .NET without rewriting the component and the
interface of the component. PVirtualNode = ^record does not work in
managed code.
--
Regards,
Andreas Hausladen
(www.kylix-patch.de.vu - unofficial Kylix 3 patches)