[fpc-pascal]Synapse for FPC

[Lukas Gebauer]

> 100% platform independance is indeed often counter-productive. However that
> isn't a good reason to don't do anything platform independant at all:-)

But I create tool for programmers and I hide all platform
differencies in my tool. By my tool other programmers must not
resolve any platform depending thinks in their socket programming.
What is bad on this? :-O

> > Now Look to FPC: windows.pas have one TSystemTime record... and
> > sysutils using another TSystemTime structure. Two different
> > structures with same name! Now I must get system time by API call, I
> > must CONVERT IT to another structure... and then I can continue.
> Yes. The solution is not to mix platform dependant and independant
> programming, and only use platform dependant calls if strictly necessary.

Fine.. but borland using sysutils unit as platform independent. In
this unit is lot of functions what hiding differencies between Linux
and Win32. By this Borlands programmers using this and similar units
as platform independent wrappers. I not need to mix platform
dependant and independent code, because I am using independent code!
All platform depended thinks is hidden inside this units...I can very
easy to create programs what running fine on Delphi and kylix.

Now I try to port this my code to FPC. What is this? lot of functions
in Syutils is missing! Well, lot of this functions is in another
units.. and some of this functions have different names... I have
platform independent code, but I must do lot of IFDEFS for FPC! This
IFDEFS is not for platform independency, this is for incompatibility
with Borland! ;-(

Mostly all FPC based IFDEFS in Synapse is for result similar
incompatibility problems.

> > 2. but someone not need multiplatform compatibility, they need use
> > existing code from delphi. For delphi exists very lot of code, Delphi
> > is biggest pascal community on world, I think.
> Yes. But most of the people using FPC use the multiplatform compability,
> except some educational users. It's FPC's main strength. Most of the Delphi
> code is copyrighted VCL dependant anyway, so can't be used without
> modifications.

Maybe most of the current people. ;-) How large is FPC community? How
large is Dephi community? How many third-party code is available for
Delphi? How many is available for FPC? How many programs is created
and used by FCP... how many is created by Delphi?

How many costs FPC? Nothing! But Delphi is very expensive. When you
can be better compatible with Delphi, then you get access to lot of
code (by third-party without Borland copyrights!). When you can get
FPC as replacement of delphi, then you can get lot of new
programmers, lot of new code, lot of new programs...

> That's why we strive for both. But the multiplatform issue has priority
> if those two interests collide. At least in most cases.

All problems have their results! It must not to be 100 compatible,
but you must have simple tools for good and quick Delphi porting. For
example, in FPC sysutils is missing some Delphi stuffs. Well, you can
create new unit with all missing Delphi stuffs. Porting programmer
only add this new unit to their program. It is easy...

--
Lukas Gebauer.

E-mail: gebauerl at mlp.cz
http://www.ararat.cz/synapse/ - Ararat Synapse - TCP/IP Lib.