I am using the base code without major changes through directives {$ ifdef fpc} and {ifndef fpc} so the same code is compiling in lazarus and delphiOk
another thing I needed to do to make compatibility was to make the code compatible with fpc's {$ mode delphi} directiveI would rather not do such thing. I would like to look at some example together with you to see what are our options here.
and the removal of style assignments such as "= +, = -, = *, = /" since delphi does not supports this syntax.:o That's a pity I like those very much. But I guess I could live without them.
I would like you (circular, lainz) after the changes in the project to be stable analyze and merge the sources to the original code so that the component improved every day more and with another platform delphi.That's understandable. Though if we identify all the type of changes to do and agree on it, it would be better not to wait to long to start implementing it because as time goes on, the code might change and this may be complicated to merge.
I think we can discuss it right here and don't keep it as a secret :)Indeed, I find it better to make this discussion public whenever possible.
For example renaming all types like Word -> BGRAWord seems unnecessary to me as there is no ambiguity in the meaning of this type. This may be useful when porting into another language but that's not what we are doing here. What are the types that are not compatible between Delphi and FreePascal that would necessitate an alias? NativeInt? UInt64?Not necessary, unless very old versions of Delphi will be supported (pre D2010, maybe even XE2). Many of those types were introduced in FPC because of Delphi compatibility....
Also about the function LEToN, NToLE, BEToN and NToBE, as they do not exist in Delphi I suggest to emulate those functions, so that the rest of the code is unchanged.These are functionally supported in some third party networking libraries and Windows units in Delphi (I believe in winsock? because similar routines are needed for network byte order, not only for processor endness). Also note implementation is platform!
Regarding removing the $PUSH / $POP when it is not FPC, I have some doubts. At the end of the $POP, the options are back to what they were. The switches $HINTS and $OPTIMIZATION are there to fix some compiler problems, so maybe they are not necessary with Delphi and you could include them inside the $IFDEF FPC.That's another matter and can indeed lead to code breaks if it can not be determined what the state was at {$push} time. Requires careful code analysis. Delphi does not support it in any version.
Not necessary, unless very old versions of Delphi will be supported (pre D2010, maybe even XE2). Many of those types were introduced in FPC because of Delphi compatibility....Sounds contradictory to me. Can you make full sentences here?
We introduced them, or re-named them, after Delphi started to support 64 bits: NativeInt, NativeUint, etc. This is not an issue if the minimum supported Delphi version would be XE2.Not necessary, unless very old versions of Delphi will be supported (pre D2010, maybe even XE2). Many of those types were introduced in FPC because of Delphi compatibility....Sounds contradictory to me. Can you make full sentences here?
We introduced them, or re-named them, after Delphi started to support 64 bits: NativeInt, NativeUint, etc. This is not an issue if the minimum supported Delphi version would be XE2.Well precisely I am trying to narrow down the types that may need some hack. And indeed, it is easy to declare NativeInt if it is missing rather than renaming in the whole source code.
Anyway, if, say D7, needs to be supported it is cheaper to declare them in a Delphi specific block than to introduce specific types.