[fpc-pascal]Synapse for FPC

[Marco van de Voort]

> (and this is for huge platform differents, for example: Linux compute
> checksum of ICMPv6, but under Windows must compute by your
> hands...etc. Sorry, but create special library for platform
> independent ICMPv6 checksum computing is not right way.. it only
> create tons of other units... ;-()

100% platform independance is indeed often counter-productive. However that
isn't a good reason to don't do anything platform independant at all:-)
 
> > > When I porting Synapse into FPC, then i find lot of incompatibilities
> > > between Win32FPC and LinuxFPC. For example, look to Kylix
> > > sysutils.pas... in FPC is not here lot of stuffs!
> > Stuff that was there in D3? Don't forget that basically the _fixes_ (1.0.x)
> > branch delphi compability is roughly D2-D4 level! (though michael added
> > quite some later stuff from time to time from later 1.0.x versions)
> 
> I know, some stuffs from newer versions is added by my requests.
> ;-)))
> But when I porting Synapse to FPC, I found lot of incompatibilities
> with my D3 (and with all higher versiopns of Delphi too!)...
> 
> For little example: On Delphi workd exists structure TSystemTime.
> Thjis is defined in Windows.pas, and all related time functions on
> delphi using this structure. For example, lot of functions inside
> sysutils.pas. it allows get system time by Win32 API call and then
> you can handle returned value by lot of functions in Sysutils.pas.
> This is great...

This sucks big time. 

I'm stuck with half a windows api on non windows platforms. 
 
> 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.

IOW, use a solution in sysutils that is platform agnostic to get the time.
 
> All this and similar problems is reported by me to Michael. He really
> very help me with porting of Synapse by adding lot of stuffs, what is
> missing and I need it.

But I don't think the platform dependant issues like this should be "fixed",
but Michael probably agrees with that.
 
> > Also keep in mind that FPC is aiming for much more platforms than Delphi
> > ever will. That's a strength of FPC, but no strength comes without
> > compromises.
> 
> I know, it is not easy.
> 
> here is tw ways, and both is needed:
> 
> 1. easy to create multipltforms programs. You need lot of platform
> independent units.

The solution I choose. However it takes time.
 
> 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.

> I say, multiplatform compatibility is important, but compatibility
> with delphi is important too! Maximum compatbility with Delphi is
> very strategic.

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