Posts Tagged ‘Mac’

hcOPF - Time to Start Monkeying Around

Monday, April 30th, 2012

I’ve put quite a bit of effort as of late getting hcOPF ready for Win64 compilation, and as part of that effort, re-factoring it to support FireMonkey.  The actual code and package changes were relatively minor when compared with trying to understand what was required.  To me this validates the design of the framework that it can be adapted rather easily to support new frameworks and platforms.

There are no new recommended guidelines for DesignTime and RunTime packages AFAIK now that XE2 supports FMX and VCL.  To complicate things further, add in Unit Scope Names, the fact that the IDE automatically renames FMX package projects when you target the OS/X, and all the conditional directive permutations, and it can drive you bananas!

On top of that, the IDE does not provide default guidance when upgrading packages from earlier IDE versions.  It does not default the unit output directory to .\$(platform)\$(config) as it does for new ones, so when you compile for one platform you overwrite your DCUs for another, and really confuse things.  For this reason, you might notice that for All configurations - All platforms hcOPF uses a unit output directory of $(hcOPF)\Lib\D16\$(Platform)\$(Config) where $(hcOPF) points to the root directory of the framework.  It would be great if there was an environment variable for the IDE version.  Then you could use something like $(hcOPF)\Lib\$(DelphiVersion)\$(Platform)\$(Config).

I am pleased to announce that hcOPF now supports FireMonkey (Win32/64 and OSX32) as well as VCL Win32/64 targets with a few caveats:

1) when compiling for the Mac or any 64 bit target you must skip compilation of the design time packages.

2) The HengenOPFValidatorsFMX/VCL packages do not support 64 bit targets since it uses the open source PerlRegEx component instead of the RegEx support present in XE and above.

3) Certain packages of course cannot be used on certain platforms like ADO and the Validators on the Mac since they have Windows specific implementations.

4) As always some packages require third party commercial libraries, such as the HengenDevExpressXXX packages which require the Developer Express Quantum Grid suite (highly recommended).

5) Win32 BPLs go into the default $(BPLDir) and those for OSX32 and Win64 go into their respective subdirs

In a future version I hope to add support for iOS as well as providing validator support for FMX.  Currently hcOPF will not compile using FPC because it does not support the implements interface delegation syntax that EMB’s compiler does.  Eventually I plan to support FPC and SQLite.

If you want to start Monkeying around with hcOPF, check out the FireMonkey SVN branch.

X Platform Development in Delphi

Thursday, April 9th, 2009

In order for Delphi to maintain and grow it’s market share it, IOW, continue to be successful, it needs retain current developers and attract new ones.  To do so, it must become the only development platform capable of X platform development in either native code, or .NET CIL.  To support this goal, the IDE itself must be X platform, demonstrating the capabilities of the compiler, VCL and supporting tools. This premise is supported by the efforts of Borland in the Kylix days.  Although much of the Kylix effort was the result of market hype and a non-validated developer survey, the underlying reason for X platform support is even stronger today.  

Developers want to make money, wherever and whenever they can.  The question is how?  Developers would rather spend less time learning new languages and technologies and more time writing applications that may make them money.  Unfortunately, learning new technologies is often required to produce unique and better applications, especially when it comes to the Web.  Also, Microsoft seems to love changing the development technologies platform substantially every 5 or so years, and maybe that is how they have maintained dominance.  While everyone else is trying to figure out how the new APIs work, and when to use them, Microsoft continues to write software and make money at it.  It’s not as if their software is necessarily better, they just know how to market it.  Interestingly enough, they continue to develop native code solutions for more than low level solutions such as the OS.

How can Delphi continue to grow their market share when .NET is the predominant platform?  The answer is leverage.  Now, to maximize leverage you have to be able to produce X platform applications.  Why?  Well for one, there are competitors who have been doing so for quite some time using Widget libraries like Qt. Now there is also .NET which may actually deliver on Java’s promise to Write Once Run Anywhere/Everywhere (WORA) or (WORE).  .NET is not only a major threat  to Embarcadero’s Developer Tools specifically, but also the Object Pascal language as well.  .NET supports multiple languages, and the premier language, C# is cleaner in many respects than OP.  Add to that, the ease of integration with third party .NET libraries, the plethora of open source projects most of which are in C#, and the number of jobs requiring .NET expertise and you have a very compelling argument to go with C# .NET.  Somehow CodeGear has to ensure the survival of OP to ensure the survival of the VCL and it’s RAD Studio IDE.  One major way to ensure the survival of OP is to facilitate X platform support.  Another would be to open the language and the VCL.  Today Firebird is a very successful open source project with a large community.

The mere existence of Lazarus and the Free Pascal Compiler’s Delphi compatibility directive is a testament to the fact there are many developers who want to use Delphi for X platform development.  As of January 2009, you can even use the Free Pascal compiler to target the iPhone!   

Embarcadero may want to pay some attention to Apple.  Apple knows how to commercialize open source projects and contribute back to the community.  If Embarcadero followed Apple’s lead, we would not only have a much better Windows product, but we would also likely have Delphi for the Mac, Linux and the iPhone as well.  

Time to quit following Microsoft and carve your own niche…that’s just my 2 cents.