[fpc-pascal]Synapse for FPC

[Marco van de Voort]

> > 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

That isn't. I was more hinting at the TSystemTime example. Sysutils is 
platform independant, and Windows is dependant.
 
> > > 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!

Therefore, don't mix it with a windows unit call!

I see a getlocaltime function in sysutils for obtaining the time, using
sysutils.TSystemTime record.

> Now I try to port this my code to FPC. What is this? lot of functions
> in Syutils is missing!

You must make a difference between functions that are missing or slightly
incompatible on purpose
(e.g. because there are multiplatform considerations), and that are simply
missing.

The first categorie won't be fixed out of principle, though sometimes new
discoveries/opinions can often change the behaviour.

The second categorie will be remedied in time, and patches that fix them are
usually accepted with gratitude. Open Source must come from both sides.

> Well, lot of this functions is in another units.. and some of this
> functions have different names..

It is hard to say. I'll look at synapse some more, but the important reason
is _why_ they are in other units. Portability, or are you just searching
equivalent functions in TP functions, while there is no reason to not add
them to sysutils too?

>.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! ;-(

In time it should get less, but some will stay. 
 
> > 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?

We have to regard _our_ community. So we are only interested in the part
of the Delphi community that is possibly interested in FPC. 

And interested in FPC because of its features and possibilities, not just a
way to circumvent Borlands fee. Users that donate code back, and report fixes
(like yourself) are much more important to us than people that only want to
avoid Borlands money.

> How many third-party code is available for
> Delphi? 

What is the advantage to use FPC at all if it is not portable? (there are
some other technical reasons like linking to gcc etc, but I mean _important_
ones here)

So yes, compability issues that can be adressed, have to be addressed, but
this is open source, and users are partially responsible for that too.

Only active users are responsible users that contribute to FPC. The rest are
just people avoiding fee's.

> How many is available for FPC? How many programs is created and used by
> FCP... how many is created by Delphi?

Does it matter at all?
 
> 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!). 

How much free code exactly is not-visual do you think?

> 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...

True, but it is much less than you'd expect.

> > 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...

You're welcome to submit it :-)