[lazarus] Has anyone else read this!!!!
Michael Van Canneyt
michael.vancanneyt at wisa.be
Thu Sep 30 04:45:56 EDT 1999
On Wed, 29 Sep 1999, Sergio A. Kessler wrote:
> Michael Van Canneyt <michael.vancanneyt at wisa.be> el día Wed, 29 Sep 1999
> 17:47:43 +0200 (W. Europe Daylight Time), escribió:
> >On Wed, 29 Sep 1999, Michael A. Hess wrote:
> >> Michael Van Canneyt wrote:
> >> >
> >> So who is bull sh--ing who? Is the press release bull sh--ing the public
> >> or is R&D bull sh--ing you?
> >That's a good question, of course. I talked to more than one person in R&D
> >and they at least were very coherent in their statements :)
> >In my opinion, marketing always needs to make a big fuss, in order to get
> >clients/the market interested, it's their job, after all...
> >So let's blame it on that =-)
> Michael, without breaking your NDA :) can you tell us if the product
> is more promising or less promising that the announcemment ?
About the same; just WHAT they promise to do is different. A vanilla Delphi app
(database access excluded, I guess) would compile, so it seems to me;
anything going deeper would be in problems.
Also the idea of initially just providing mysql support is ridiculous; One strength
of Delphi is scalability; going from paradox to oracle with little changes
is possible. In principle it can be done by changing the BDE alias or changing
your TDataset descendent. Where is the scalability if you only support mysql ?
(assuming that they ONLY support mysql)
AFAIK, R&D planned simply (sic) to port Delphi and as much as possible of the
VCL to Linux;
It should be obvious to anyone that starting something from scratch and get to
the level of Delphi 5 (by then probably 6) in a time span of 1 year is an
impossible task. Especially while still maintaining the win32 version.
So you are forced to use the existing tool and port it as much as possible.
Here are some problems that the free-pascal team finds with that approach:
- Library on linux <>library on Win32
+ No guaranteed initialization on linux, so your host application MUST do
the initialization - this will break a lot of existing code.
+ Memory handling is radically different.
- Messaging ? Will they change the language as we did ?
- Resource strings - no dlls.
- Debugger !! they use the win32 API debugger calls (just look at the imported
Win32 DLL calls in Delphi and it's DLLs)
Going to stabs and ptrace calls will not be easy.
- Exceptions, they use win32 calls for it.
- Many, many win32 dependencies in the VCL.
- No Borland Database Engine. How to do database access ?
(unless they port that also)
- No quickreport components, since these are too Win32 based.
(I have modified the quickreport sources for my company,
so I know the problems it would present)
- All winsock components gone - very tough job. The http and ftp components
as well, they are based on win32 OCX's and dlls..
- Printing ? Everything must be done using postscript ! No win32 drivers...
- IDE : Very windows dependent. (Though built on top of VCL)
- Copy and paste, there is no clipboard...
- C++ libraries ?
And so on.
So there you have - part - of my analysis of the problems.
More information about the Lazarus