On Sat, 12 May 2007 15:40:49 -0500, ik <[EMAIL PROTECTED]> wrote:
Hi,
Ok, you dragged me into responding this subject as well :)
While it might sound as such, this is not Windows vs Linux fight, only
a point of view for an ex Delphi developer, and a 5 years of Linux
users (as only OS).
Correct. Well, it certainly sounds like, but it is not. I did not make a
single statement regarding which one is better. My claim is that they are
different - one is more popular, and I stress "popular", for desktop
applications, the other for server ones.
Ammm.. I'm a Linux user, so let me give you my point of view:
Microsoft on any given new version of Windows *changes* API, changes
libraries and technology, making even newer (the previous version was
the first to have it) technology obsolete on a new version of an OS or
a program. As example take a look at GDI+ (if I remember the name
correctly).
Of course it changes. But the majority of gui applications are compatible
with newer versions of windows (up to vista), all the way from 3.51. And
the compatibility comes at no cost (in terms of time) to the sysadmin.
There are exceptions, mostly confined to system level applications, such
as firewalls. This however is natural and cannot be helped on any OS. My
only point is: this feature of windows makes it really easy to develop and
forget. I am not claiming one is better, the other is not.
I do not know many people that changes their kernel and libc once
every new version.
My sysadmin recently changed to 2.6.?? which broke the kylix debugger
(2002). As a comparison, bcc 5.0 (1996) runs perfectly fine on xp.
... are you willing to help the team and add features that
are missing in your opinion ?
Yes. In particulr, I would like to do something about this item:
http://www.freepascal.org/mantis/view.php?id=8783
On Sat, 12 May 2007 16:42:43 -0500, Marco van de Voort <[EMAIL PROTECTED]>
wrote:
A.s. I already deleted it, but quite some older apps break on Vista now.
Including e.g. Delphi 7. MS is also deviating from the compat path.
Unfortunately.
Unfortunately, indeed.
i. Too many bugs in any official release. This is unavoidable,
considering the many platforms and targets supported. But it is a fact.
This is a bit vague. I assume you mean bugs of the blocking kind. Do you
have examples?
Well, I did not want to put any specific examples which would necessarily
be personal and would shift the focus of the discussion. I've mentioned a
few later on...
ii. In any stable release, there are always some incompatibilities
with
Delphi. Which means that Delphi developpers will have to put an extra
effort (in the form of $IFDEFs) to make their code compatible. In that
respect the lack of an "Object Pascal standard" in the form of some ISO
specifications is partially to blame.
Yes. Failure of Delphi users to have any consensus about what is compiler
behaviour, and what is language behaviour. Every bit of behaviour that
Delphi exposes is considered gospel.
That is true and is compounded by the fact that there is no ISO standard.
Furhtermore, delphi users cannot insist that an independent compiler group
should do something "their way".
IMHO this is also why Kylix failed. It was geared too much to float on a
Linux-on-desktop hype, hoping to force a lot of Delphi apps to be
recompiled on Linux because it-is-so-easy. It failed.Borland management
probably
assumed that the "recompilation" market was larger than the "invest in
new linux products" markets. However the "recompilation" market fell
victim
to its own assumptions because it had to deliver a way smoother
transition, which failed in a still to volatile delphi world.
I don't know if borland targeted the "recompilation market" or new linux
developpers. If they wanted the recompilation market they should have
single sourced the VCL. They should have released a reasonably bug-free
multiplatform VCL. They should have priced it much cheaper and integrated
the compiler into the win32 ide for cross-compiling and so on. It is
actually useful to study why they failed. Kylix is certainly dead, but
finding out why will help others... Some interesting views can be found
here:
http://delphiroadmap.untergrund.net/A_cross-platform_vision_for_Delphi/index.html
Compability is good, but should be a enabling factor to do stuff with
FPC/Lazarus, not the end target for blind recompilation itself. Because
then
it will be just-not-good-enough forever. One can also see this currently
with FPC. Major Delphi component builders start using FPC/Lazarus. They
want
to do things, and their customers are doing things, while FPC/Lazarus is
not
really registering en masse on
I agree. Actually, both are important and there should be a reasonable
balance. FPC is targeting several different cpu architectures on many
different os platforms. This alone is attractive to server side
developpers. On the other hand, say any stable fpc release should be able
to compile (on win32), without trouble the entire VCL of say, delphi 2-5.
Personally for me FPC is extremely attractive for server side development.
In the process of porting kylix server applications to FPC I've noticed
several things:
- Speed wise, especially floating point operations, applications are
generally similar or slightly faster than kylix.
- I've had recurring problems with open arrays on various final releases.
Some issues were fixed by the developpers, for other there was no
agreement what the language standard should be so I had to make
workarounds. Also, it is not clear if functions with open arrays can be
exported/imported safely in dlls, as I don't know what is the internal
representation of an open array in FPC.
- Static linking requires some minor code modifications in comparison to
kylix (they had their internal linker, so things can't be the same)
- Various linking issues on different platforms.
- Minor issues in the FPC RTL force various workarounds. E.g.
http://www.freepascal.org/mantis/view.php?id=8578
- Various features that use the internal RTTI of delphi. For example
delphi 2 generates useful RTTI for automated methods, Delphi 6 for
published method (in conjunction with a weird compiler directive). Clearly
this is not a language feature, so one cannot insist the FPC should do
things the same way. Unfortunately, currently this is a blocking issue for
me.
A final remark: the vast majority of pascal users use Delphi. So if fpc
is
to attract a lot of them, compatibility with delphi must be 100%.
These kinds of claims always promise heaps of users, but there are
several problems with it:
- Only a fraction of users will defect to run a clone.
True, but the delphi crowd is (well, still is) large. So a small fraction
is not bad at all. Besides it is not only about defecting. What if FPC is
available as cross-compiler inegrated in Borland's windows IDE? Personally
I can see FPC server applications running on a bizarre patform and a
client side compiled with delphi.
- The compability is never enough.
Well, as long as there are no blocking features and no necessity for
too-many workarounds/$IFDEFs people will accept it. Alternatively, someone
should define a language standard.
- At some point the amount of compability you can add without effectively
emulation e.g. winapi stops. We are building a compiler, not Wine.
.....
I hope to have explained that one must be very careful with compability,
specially the "effortless" kind. IMHO the focus must be on a kind of
people that are willing to invest in creating FPC apps. Delphi
compability is a
factor too (due to the heaps of sourcecode it makes accessable), but
don't think too much in an utopic "just recompile product" way.
True, point taken.
Best regards
Peter
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
