Delphi.NET Running on .NET Compact Frameworks

While I’ve been buried in meetings for the past few weeks, Seppy’s been a busy fellow. I asked him to get started on figuring out exactly what .NET bits are missing in CF that the Delphi compiler codegen and RTL rely upon. Here’s his reply:

 

Wahoo! He found the easiest way to figure out what was broken was to build an app and have the compiler report what wasn’t available.

So I immediately copied it to my MPX220 SmartPhone, with this result:

 

Nuts. Ok, so the .NET Compact Framework on PDAs has significant differences from .NET Compact Framework on SmartPhones. SmartPhones don’t have a clickable button. When you consider the fact that PDAs have a pointer device (stylus) but SmartPhones do not, this makes sense (how can you click a button without a pointing device?), but it’s still another fragmentation factor to make CF development more complicated.

A few minutes of tinkering, and we have this:

 

 

Wahoo!

These screenshots show minimal WinForms application written in Delphi syntax. The WinForms functionality is provided by the .NET Framework; the language binding and core RTL are Delphi.

This is the second Delphi “hello world” app running on .NET Compact Framework. The first was a quick test performed on the Delphi for .NET technology preview compiler that shipped with Delphi 7. We now know that that test worked mostly because the Delphi compiler was incomplete – the codegen model was so primitive at that time that the hello world test didn’t trip over any of CF’s now famous functionality voids. As the codegen model evolved to flesh out the Delphi language requirements, dependencies on .NET Framework methods crept in. A surprising number of those .NET methods don’t exist in CF.

What’s Working

From Seppy’s investigations so far, it’s looking very likely that all of the Delphi for .NET language support will work in CF without major modification. He’s got the core RTL up and running and is working on fleshing out the rough spots. Using the Delphi language to build WinForms apps on CF is a sure thing.

What’s Missing in CF

Here’s a snapshot of the Delphi RTL items that are affected by things that appear to be missing in .NET Compact Frameworks and/or Windows CE. This list is a work in progress, and may contain errors. It’s definitely not complete, but it should give you an idea of what kinds of Delphi things are simple to do in CF and which are not.

Unit	Function/Class	Status	Reason/Notes
System	_Halt	Stub	System.Environment.Exit not supported, does nothing
System	CmdLine	Stub	System.Environment.CommandLine not supported, returns empty string
System	IsLibrary	Stub	Assembly.GetEntryAssembly not supported, returns False
System	ParamCount	Stub	System.Environment.GetCommandLineArgs not supported, returns zero
System	ParamStr	Stub	System.Environment.GetCommandLineArgs not supported, returns empty string
System	VCL Locale Override	Removed	Intentionally removed from CF/RTL
SysUtils	AnsiPos (AnsiString)	Removed	CompareStringA API not present, WideString overload will get called which will yield incorrect results for MBCS
SysUtils	CharLength (AnsiString)	Removed	CharNextA API not present, WideString overload will get called which will yield incorrect results for MBCS
SysUtils	CheckThreadingModel	Removed	System.Threading.Thread.ApartmentState not supported
SysUtils	ExceptionErrorMessage	Changed	System.Exception.StackTrace not supported (uses blank)
SysUtils	ExceptionHelper.HelpContext	Removed	System.Exception.HelpLink not supported
SysUtils	ExtractShortPathName	Stub	GetShortPathName API not present, returns original path
SysUtils	FindCmdLineSwitch	Removed	System.Environment.GetCommandLineArgs not supported
SysUtils	GetEnvironmentVariable	Removed	System.Environment.GetEnvironmentVariable not supported
SysUtils	NextCharIndex (AnsiString)	Removed	CharNextA API not present, WideString overload will get called which will yield incorrect results for MBCS
SysUtils	SafeLoadLibrary	Stub	SetErrorMode API not present, acts like LoadLibrary
SysUtils	TLangRec	Removed	Used by TLanguages
SysUtils	TLanguages	Removed	Intentionally removed from CF/RTL
SysUtils	TMultiReadExclusiveWriteSynchronizer	Removed	System.Threading.ReaderWriterLock not supported
SysUtils	VCL Locale Override	Removed	Intentionally removed from CF/RTL
Math	Log2	Removed	System.Math.Log(X, Base) not supported
Math	LogN	Removed	System.Math.Log(X, Base) not supported
Registry	TRegistry.LoadKey	Removed	RegLoadKey API not supported
Registry	TRegistry.RegistryConnect	Removed	RegConnectRegistry API not supported
Registry	TRegistry.RestoreKey	Removed	RegRestoreKey API not supported
Registry	TRegistry.UnLoadKey	Removed	RegUnLoadKey API not supported
Variants	OleVariantHelper	Removed	Intentionally removed from CF/RTL
Variants	VariantHelper (CustomVariants)	Removed	TMultiReadExclusiveWriteSynchronizer not supported
WinUtils	FinalizeNativeVariants	Removed	Support function for dbGo
WinUtils	FreeNativeVariants	Removed	Support function for dbGo
WinUtils	GetCmdShow	Stub	GetStartupInfo API not supported, returns SW_SHOWDEFAULT
WinUtils	GetNativeVariantsForObjects	Removed	Support function for dbGo
Classes	CheckSynchronized	Changed	TimeOut not supported, ManualResetEvent.WaitOne doesn’t support TimeOut
Classes	TThread.Resume	Removed	Not supported by System.Threading.Thread
Classes	TThread.Suspend	Removed	Not supported by System.Threading.Thread
Classes	TThread.Suspended	Removed	Not supported by System.Threading.Thread
Classes	TWin32Thread,ThreadID	Removed	Not supported by System.Threading.Thread
Classes	TWriter.WriteProperty	Remove?	Browseable (published) attribute not supported.
IniFIles	TIniFile	Removed	GetPrivateProfileString/WritePrivateProfileString API not supported

Broader issues

The AnsiPos(AnsiString) and CharLength(AnsiString) items above are the tip of an iceberg: While Windows CE does provide locale information, it does not appear to support Ansi (multibyte) strings in the API functions. If you write code using AnsiStrings and want to carry locale or multibyte char data in those strings, these will run into conversion problems in CF. Best solution: Don’t use AnsiString in .NET code. Use String, which is wide (Unicode).

VCL.NET for CF?

So far we’ve talked about the Delphi language, core RTL and WinForms apps. What about VCL for .NET on CF? Windows CE is after all very similar to the Windows API. The answer is still up in the air. Divergence from the Windows desktop platform increases dramatically when you venture into the realm of user interaction and display models. We’ll have to sink a lot more effort into backfilling missing OS functionality critical to VCL or finding alternate solutions with what’s available to produce a VCL based UI framework on CF devices. Developing VCL apps for mobile devices will never be a seamless migration from desktop VCL apps, but it certainly would be nice to have something (anything) less severe than CF’s stripped down WinForms classes.

The System.Browseable attribute is not present in CF. Delphi uses this attribute to implement Delphi’s published visibility. One option would be for us to define our own Browseable attribute for CF and just plow ahead. The VCL.NET streaming system relies on this Browseable attribute to decide which properties of a class should be streamed out (because they were marked as published in the original source). Another option would be to retain VCL stream reading (TReader) but jettison VCL stream writing (TWriter) on the CF device. DFM reading happens in almost every VCL app, but DFM writing is almost never done at runtime by VCL apps.

With the exception of a few operations such as Arc and Chord, TCanvas survives the CF transition rather well. TBitmap, however, does not fare as well. We chose to implement VCL.NET’s TBitmap class using System.Drawing.Image.FromStream to load a bitmap from a file, for example. Guess what’s missing from .NET CF’s Image class? FromStream. I guess someone decided small devices are too small to display graphics? It’s certainly not because of storage constraints, because I have more storage in my phone’s SD storage card (512MB) than in all of my first 5 desktop computers, combined (RAM and HD)!

We will continue to explore the feasibility of adapting VCL to the .NET CF platform, but no promises with this post.

Ongoing Research

If you see something here that you know (by your experience in writing Windows CE or .NET CF applications) is available but not in the usual place, please let us know in email or in a blog comment. We definitely welcome advice from developers with experience in this field.