[DUG] Cross platform musings

[John Bird]

The reason I see a decreasing use of desktops (and Windows) is multiple:

1 - Most pcs are getting smaller.  The fastest growing areas of sales are in laptops and netbooks these days.  As these get smaller and more powerful more and more users find they do not need anything more, and they are now comparable in price.

2 - Even faster growing is mobiles.  The highest customer satisfactions ratings I read recently are from those with (1) iPhones and (2) Android phones.

Once serious computers become portable then there are a whole new world of issues to solve to do with screen layout, mutlitasking or single tasking, input devices, battery life, memory size etc.   Windows and other desktop OS are not really well suited for that transition, especially Windows as it is for current state of the art desktops and laptops, not really suited to netbooks and low ppwer devices - it needs mainly Mains power or heavy batteries for hot processors and large amounts of memory.   However with the iPhone SDK  (which must have a lot of OSX ancestry in it as it runs on a flavour of OSX) and Android (which must have a good ancestry in linux which it is a version of) - these are environments to target from the beginning.   not sure about Windows mobile, but it does not seem to get the best press as it is not really from Windows ancestry,  it seems to be a specially tailored and highly limited OS of its own designed to look like Windows although it is not.   iPhone and Android are at least built on the unix or linux kernels for which there are very lean and efficient versions out there  (eg running in a few MB of memory) - such as the Carnegie-Mellon version kernel.   I read on one recent linux firmware device that was able to boot into full running in about 0.5 seconds by optimising various things - eg no compressed boot image and special drivers.   I don't see much chance of Windows being able to achieve that kind of performance although I would like to be proved wrong.

3 - reliable internet connectivity means that many grunty services can be off-loaded to heavy iron servers which could be Windows or Unix or Sun or IBM or whatever - think of gmail, Google search, Google maps,  iTunes store, You-Tube, Hotmail, Yahoo and all online services etc.   This is the strong point of phones like the iPhone and Android which do just this, and not through a phone company interface (read expensive) but direct to the Internet (read cheap).    A phone with a reasonable OS that can do a RDC or VNC connection to a server has all the advantages of the server while portable.    It is in a sense a return to thin client (but portable).

Embarcadero here is a prediction and I suggest you consider these as a direction:

(a) an easy to learn language (pascal is that) with a cross platform VCL that is reasonably able to write applications (with various framework flavours and considerations) for Windows, OSX, linux  but more importantly into iPhone and Android would absolutely be the killer app like Turbo pascal was.

The goal would be to produce a compiler/language that uses the respective OS to render the standard controls - windows uses Comctl32.dll, Apple and Linux etc must have their own, so there needs to be something that drives the OS native graphics libraries and controls.  That is not relying on some added party framework like wine that may lag behind the state of the art.   Much better to tap into what the latest version of any OS is capable of rendering. If VCLX on windows is inferior to VCL then either people won't want to use it, or there would need to be some automated tool to port code to VCLX (renaming component types etc) as a batch process to produce the other OS flavours.

As far as I am concerned it would be fine for Embarcadero to say we will only make VCLX portable within certain constraints, it may well be less than the current VCL in some areas, but it does not have to be more than VCL, as those who want easy portability may be happy to give up third party components and win32 calls and live in well defined boundaries in order to get code they can compile and run on various OS's.  If some win32 calls could be given some equivalents it would be neat,  but this would be icing on the cake.

(b) The other way to go would make a really easy way for a browser to run any Delphi app, so it could be put on a web site.   Now others have pointed out that can be done via browsers that can call up some RDP client or terminal services client.  It is not easy yet however.  I don't know how one could do that, but there must be something possible.   I would certainly be paying close attention to whatever the Google OS is likely to do, as I would imagine thats the sort of direction they would be thinking too, some way to web enable any desktop applications via some RDC or VNC connections into a browser or particularly the Chrome browser.

(c) make Delphi grunty to.  64 bit and 128 bit - why not go to 128 or 256 bit compilers in one jump? ok so the processors to run it are not there yet, well one can only dream eh?  I would settle for int128 for now (extension to int64).

Thinking beyond mobiles, the generation beyond them will be smaller not bigger.   Maybe there will be display glasses that can be put on to get the advantage of a huge screen display just like we have earphones these days rather than speakers.  Maybe virtual keyboards - projected onto a wooden desktop from a small projector. Likely it will have a fast broadband online connection to ones home server where the data and programs actually are.

For Microsoft my prediction would be to bite the bullet, evaluate the Windows kernel, and if it is inferior to the various linux and Unix ones out there ditch it and put Win32 and ..Net and all the other API's over such a kernel.   Its been spectacularly successful for Apple to do that with OSX,   and the Windows development environment is particularly good

John
 
I have also been through the same era and agree.  They should agressively pursue the cross-platform verison but make a decent job of it this time.
 
Eric
 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listserver.123.net.nz/pipermail/delphi/attachments/20091015/708ea7e1/attachment.html