Un-Win32-ing your non-visual code?
We have a lot of lib code which has evolved on the Windows platform for years, and I am wondering what would be the best approach for making the code platform agnostic.
Has anyone been down this road?
What approach did you use?
What pitfalls did you stumble on?
One would be to add {$ZEROBASEDSTRINGS OFF}.
Then try to compile for other platform and see.
Cristian Peța zero based strings and ARC + etc is a separate set of challenges.
I am mostly curious about approaches for isolating/replacing OS specific types and functionality.
I have migrated 100k lines but with very little OS dependency.
One big dependency for me was TCanvas drawings and to let the code almost the same I have created an intermediate layer that will call one to one for VCL TCanvas functions and emulate for FMX.
First of all, the UI and the logic should be uncoupled.
Second, you should always write unit tests, run on all platforms ASAP.
Then, for low-level work, I tried to put all the OS-specific functions and types in a single unit, per OS/compiler (I write “compiler”, since I target both FPC and Delphi). Then a shared unit will publish high-level classes and functions for the rest of the code base.
In practice, our framework allows to compile for Windows and Linux for the servers. But we made a specific set of units for cross-platform clients, which target iOS and Android with Delphi also.
FPC has very good level of cross-platform units, whereas Delphi has much less integration, besides the SysUtils.pas unit (due to a shorter history).
Mostly worked by removing Windows, ActiveX & others from the uses clause, and then using some cross-platform units instead. Initially all those cross platform units do is offer functions that map to the Windows units functions, then one by one, the functions are either ported to cross-platform or outright eliminated from the source.
That works well for all non-visual, not-too-much-object-oriented stuff, as these can be worked on piecemeal. More complex libraries or objects present a different set of challenge, sometimes they can be refactored (if you have the source), other times they have to be replaced as a whole when they were just a superset or a helper for a Windows API library.
All in all, it can be quite time consuming and error-prone, testing and compiling on multiple platforms is very time consuming in an of itself.
/sub
My code choked on lack of 8-bit strings – UTF8String in particular. Haven’t moved past that obstacle…
“Thou shalt have no other platforms besides Windows.” :p
/sub