Wednesday, September 26, 2012

Embarcadero Delphi XE3 New Features of Interest

Embarcadero Delphi XE3 Review of New Features

Although I am leaning toward using Google's Dart language along with HTML5 / CSS for my applications development needs lately, I find it hard to ignore my 17-year history of using Delphi for native executable desktop applications development. The fact is, Delphi has been an extremely important and productive RAD OOP language and IDE for me, and I find myself longing for the equivalent features and productivity (especially a VCL-like controls hierarchy) on the web side of things.

I previously wrote a review of the new features in Embarcadero Delphi XE2 — with much excitement too — as I was thrilled by the prospect of their new FireMonkey UI controls and 64-bit advancements. But a short time later, I wrote a followup article regarding the fact that more than a few Delphi developers were finding Embarcadero Delphi XE2 / FireMonkey full of bugs and incomplete features and suffering from lack of polish — clearly it was rushed out the door in order to make Embarcadero's annual-release-schedule, whether it was deserving of a label beyond "beta" or not.  I personally am very turned off by this experience, as I feel like I am being forced to constantly pay ever-increasing prices for a product that I am forced to continually upgrade in order to keep it "viable" (i.e., pay for what are "bug fixes" and/or feature-completions).

Contrast this XE2 experience to the superb Delphi 7 and Delphi 2006 releases which I could use for many, many years as-released and with only the free included updates/patches, and develop great applications with a very stable IDE and generated-executables.  Of course the main "problem" with those super-stable releases are how they stand to impact company cash-flow if product designers cannot otherwise create compelling features to entice me to upgrade to a newer version of Delphi. But, on the flip side (note to lame management at Embarcadero!), you have only driven me away with ever-increasing prices for unfinished products that I know I will have to upgrade every year (for substantial cost) in order to get a (hopefully) "finished" product and to get bug-fixes which should be part of FREE update-packs that will never address them; and, the more time I spend away from Delphi, the less likely I am to have a future "need" for it!

Furthermore, so many Delphi "features" of recent come from including a bunch of third-party crap that I don't need or want , like:

  • Embarcadero's stripped-down modeling software (whose clear purpose of inclusion is to attempt to generate an "up-sell" opportunity to their full product),
  • InterBase DB — seriously? I have NEVER encountered a company that uses this database in a production setting, let alone for development settings! Up-Sells are not happening guys, and I find it hard to believe this product is even worth developing in an age of great open-source free database options.
  • outdated versions of third-party controls,...
  • utterly useless junk like Intraweb — statistically totally insignificant market-share and again, I have not encountered a client in the past 5 or more years that has used this (let alone even contemplated using this)...
  • and, all the while, features I need are slow to emerge and/or are being stripped from the "Pro" version and pushed up into the "Enterprise" version.

    E.g., where is the support for SQL-Server 2012 in dbExpress controls (does not show in your literature for XE3 yet), should people want that.  Next, given Microsoft's push to go ODBC (vs. ADO) for SQL-Server connectivity, I find it detestable that Delphi's dbExpress ODBC Driver is relegated to an "Enterprise" version even as nearly all other development platforms consider ODBC to be an essential entry-level database-connectivity option.  I can currently use dbGO™ for ADO connectivity for Windows (MDAC 2.8) in the "Pro" version of Delphi, but what am I to use for SQL-Server's next version when MS says "ODBC is the only way"?  Wow, I see being forced to Delphi Enterprise at 2.5-times the price of "Pro" just to keep what I have had for years with "Pro".  Perhaps you can blame this on MS, but seriously: ODBC = "enterprise" only?
That said, let me continue with the new Delphi XE3 features for anyone that wants to risk upgrading only to have to upgrade again to get what they want, and/or be forced to move from the "professional" to "enterprise" version in order to get the database-connectivity they need, etc.


New Features in Delphi XE3

Now that the official Embarcadero Delphi XE3 release is available, the first thing I wondered was: is it "ready" this time? Time will tell, but for now, here are the features in XE3 that are supposedly worth pointing out:

Windows 8 "Metro" Applications


The Delphi RAD (Rapid Application Development) IDE and Component-Set framework now targets Microsoft Windows 8 "Metro" applications.  New Metro Project Templates and Application Styles for Delphi and C++Builder exist (including VCL Metropolis project templates blank, grid, split layout, plus Office 2013 styling), but there are apparently caveats to all this Windows 8 support with regards to WinRT.  Note that Embarcadero® literature regarding what's new in Delphi XE3 states that "Embarcadero® RAD Studio is preparing for full support of the Windows® 8 Metro® user interface".

This conditionalized-wording concerned me, so I went digging, and soon found this very active and lengthy Embarcadero  discussion forums topic regarding this issue where Allen Bauer (Embarcadero Chief Scientist) states that, in response to whether Delphi will be able to "support native Metro development using the unmanaged API", the following:
"Yes. We are very keen on supporting WinRT with native Delphi & C++ code. Right now, the issues surrounding the WinRT space center around the fact that many OS-supplied APIs which are required by anyone implementing their own language RTL are actually off-limits unless you're the VC++ RTL DLL. You know, little things like RtlUnwind for exception processing and VirtualAlloc (et. al.) for memory management... Any calls to those APIs from your application will automatically disqualify your application from being an "official" WinRT application capable of delivering through the MS app store. 
Right now the VC++ RTL DLL is given special dispensation since that is the library that makes the calls to those forbidden APIs and not directly from the user's app. We're currently rattling some cages at MS to find out how or if they're going to allow third-party tools to target WinRT. Until we can get past that, targeting WinRT isn't actually possible from a deliverable product sense. We are able to build WinRT applications with Delphi that work with a developer certificate, however they all fail the application qualification checks because of the aforementioned (an other) APIs
Like the APIs I mentioned above, there are lots of changes with WinRT that make targeting it a little more tricky. For instance, you cannot merely open any file, access the registry, and even use the loopback (127.0.0.1) adaptor. LoadLibrary cannot be used to load any arbitrary DLL; you must call LoadPackageLibrary and only on a DLL that is present in the digitally signed appx package. WinRT is a seriously locked down sandbox or "walled-garden" with some extremely high walls. 
This is a little known or understood "feature" of Windows 8. I see no press that even talks about this at all. IOW, it's Windows 8's "dirty little secret." "

So, I am just not totally sure what to make of all this. I understand where Embarcadero is coming from here and why WinRT applications are a challenge due to Microsoft implementation specifics, but how can one of the more substantial features of XE3 (Windows 8 support) be subject to such conditions yet? All I got out of this was: please wait for Delphi XE4 features that really make WinRT possible. Time will tell, but this is yet again another point of potential concern with regards to a paid upgrade for a feature I may not truly be able to fully exploit.

FireMonkey Changes for Delphi XE3 (aka, "FireMonkey2")


Given the incomplete state of FireMonkey in Delphi XE2, I was looking forward to seeing what the second full incarnation of the FireMonkey controls and technology in XE3 would yield — I essentially expected them to now be worthy of a "version 1.0" designation vs. what I considered an extended technology-preview in what came with the XE2-provided FireMonkey set.  Of course, Embarcadero calls them "version 2.0" for maximum marketing effect.

The new FireMonkey2 XE3 features include:
  • Bindings: TDatasource is no longer required for LiveBindings as you can now simply link a BindSource directly to a dataset like TClientDataset.
  • Actions: FireMonkey now supports actions and action lists, features that were previously supported only in VCL.
  • Anchors: Anchored controls "stick to" the sides of containers, and also stretch, if so specified. I really thought this was a substantial missing feature in XE2, especially seeing that I implemented anchor-support in my own SVG-UI-Widgets quite easily, but what do I know.
  • Audio-video: FireMonkey offers support for capturing media data (audio and video).
  • Layout management: new FireMonkey layouts (Flow layout, Grid layout) simplify the arrangement of controls in a FireMonkey application. Text Layout features were listed, but I have yet to see details of what that involves.
  • FireMonkey 3D enhancements: not that I give a darn, since I am one of the few software developers that care about business applications versus graphical "fluff". But, I guess it is neat to know that a new materials system and shader compiler exist to make better use of modern hardware and graphics frameworks (like DX9, DX10).
  • Gestures: FireMonkey now supports the gestures that are also supported by the VCL.  This is nifty and all, but the fact is, I have not encountered any clients that want a gesture-enabled Windows application: nobody has widely-deployed touch-enabled desktops, for starters.
  • New styling abilities, including Metro-look styling. And, these same FireMonkey2 components are supposed to be Mac OS Retina display optimized.
  • FireMonkey Sensor Components: Non-visual components for using device sensors (Location / Motion) have been added, though Motion sensor is Windows-only for now. Virtual keyboard is now supported too.

Other Delphi XE3 Features of Interest


One related (to FireMonkey mainly) feature of significance is the new Visual LiveBindings Designer and LiveBindings Wizard — bringing essentially a drag-n-drop approach to designing bindings. You can now create data sources (TPrototypeBindSource or TBindSourceDBX) from within the LiveBindings Wizard. Using a TPrototypeBindSource, now you can bind multiple properties of different objects to the same data. A set of Quick Binding Components components have been introduced in order to make LiveBindings links seamless — these produce auto-generated expressions for easy linking objects. LiveBindings can now be created from one control to multiple controls, seamlessly via the LiveBindings Designer.

And, by the way, TGrid is now supported by Live Bindings (given the widespread use of this control, that surely was a "need" for this technology to be useful). There is some new ability to group various Live Bindings together to form a "layer", which seems mostly about making complex groups of bindings easier to work with (layer data is saved in .vlb files).

There really was not much else in XE3 that got my attention.  There were some changes regarding the Mac OS X builds and such, but I am not experienced at all with deploying Delphi applications to OSX, so someone else will be able to review those features. So many other listed "new features" were simply included "junk" (as mentioned elsewhere in this review) or things I'd expect of any new release: like, updates to a list of supported databases, etc.

Conclusion

I would really like to believe that Delphi XE3 / FireMonkey is making strides toward relevance that could result in a resurgence in Delphi software development, but in an age of mass migration to "web based applications" and many, many alternatives (and much more popular ones at that, not to mention many lower-cost or free / OSS alternatives), I cannot help but think that Delphi will forever remain a niche product relegated to the few. It has potential to be so much more, but until Embarcadero gets over its hangup on including totally irrelevant products (like InterBase, IntraWeb, etc) and calling them "features" while simultaneously crippling the "Professional" version (i.e., the only "affordable" version) this product is destined to further obsolescence and obscurity.  Sad. It really had such incredible potential.

Continue to read this Software Development and Technology Blog for computer programming articles (including useful free / OSS source-code and algorithms), software development insights, and technology Techniques, How-To's, Fixes, Reviews, and News — focused on Dart Language, SQL Server, Delphi, Nvidia CUDA, VMware, TypeScript, SVG, other technology tips and how-to's, plus my varied political and economic opinions.

Wednesday, September 05, 2012

VMware ESXi 5.1 New Features and vSphere 5.1 New Features

This blog is a followup to the VMware ESXi 5.0 New Features posting from just over a year ago. VMware has released to the public the details of new features in VMware ESXi 5.1 and vSphere 5.1 and I will cover those new 5.1 features here, though if you are new to the 5.x series, the prior blog may still be quite interesting also. Spoiler: one huge new "feature" in 5.1 is removal of the vRAM limits! Let's look at all this more...


New Features in VMware ESXi 5.1


vRAM Memory Limits Removed: the biggest non-feature "feature"!

What does it say about a product when the biggest "feature" is simply un-doing / correcting a blunder made by upper-management at a company? If you remember the fiasco surrounding the new vRAM memory limits imposed by ESXi/vSphere 5.0, you know to what I refer. VMware's attempts to squeeze more cash out of customers by imposing what amounted to a RAM-tax upon their robust server boxes backfired (i.e., irked customers, like me). And, they have now un-done that mistake. ESXi/vSphere 5.1 is supposed to now be priced (solely) on a per-CPU-socket basis rather than on a strange and ridiculous combo of sockets/virtual memory used/VMs-being-managed. That is a good thing: I actually stuck with ESXi 4.1 due to the 5.0 vRAM bull@#! So, version 5.1 is on my radar.

Support for Newer Hardware

Not surprisingly, this latest 5.1 release includes support for bigger and more recent computing hardware (both Intel and AMD). In addition, the virtualization hardware-abstraction layer has been upgraded to a new "Version 9 virtual hardware" that includes support for Intel's VT-x with Extended Page Tables virtualization assistance features and the AMD-V with Rapid Virtualization Indexing (RVI) (nee, "nested page tables"). This VT-x/EPT and AMD-V/RVI support is to partially reduce hypervisor and virtual machine (VM) guest operating system overhead imposed on the physical processors (your server's CPUs).

One nice feature that comes along with this latest 5.1 version is, unlike with the 5.0 release, it is possible to allow any VM generated on VMware ESX Server 3.5 or later to continue to run on ESXi 5.1 unchanged (i.e., without being forced to shut down, update to the version 9 virtual hardware, and restart). Of course, if you want the latest features of the VM and hypervisor that come with "version 9 virtual hardware", you will have to update your VMs to get it, but at least you have the option to postpone the virtual-hardware upgrade task until it is convenient.

New Adobe-Flash Web-Based Management Client for vSphere 5.1

Yes, you read right: a new Flash-based management client! (actually, it was written in Apache Flex, which uses Flash to run applications built with Flex). I personally am OK with this as I have worked with some very capable Flash-based applications. The old management client is still able to interact with vSphere 5.1 applications, but features that are new to vSphere 5.1 will only be available in the Flash-based web interface client. Sure, it means that you need Flash installed on whatever machine you plan to manage your virtualization setup from, but such is. I already need Flash for so many other things that this is a given.

The new UI is peppy, stable, and secure from what reviewers are saying so far. And, it offers an advantage of performing some potentially-long-running-tasks asynchronously (threaded) so as to prevent UI lockup that could occur in the previous management UIs. And, the fact is, Flash-based UIs should look and behave identically on any device that can run Flash — which surely cannot be said of HTML-based UIs!

Virtual Machine Hardware-Accelerated 3D Graphics Support

Maybe VMware read my past blog where I stated (how in ESXi 5.0) that I felt "something is amiss: where is the Nvidia CUDA / vGPU support in ESXi 5.0? Well, it turns out VMware is noticing the importance of offloading processing to GPUs after all:
With vSphere 5.1, VMware has partnered with NVIDIA to provide hardware-based vGPU support inside the virtual machine. vGPUs improve the graphics capabilities of a virtual machine by off-loading graphic-intensive workloads to a physical GPU installed on the vSphere host. In vSphere 5.1, the new vGPU support targets View environments that run graphic-intensive workloads such as graphic design and medical imaging.

Hardware-based vGPU support in vSphere 5.1 is limited to View environments running on vSphere hosts with supported NVIDIA GPU cards [well, duh] (refer to the VMware Compatibility Guide for details on supported GPU adapters). In addition, the initial release of vGPU is supported only with desktop virtual machines running Microsoft Windows 7 or 8. Refer to the View documentation for more information on the vGPU capabilities of vSphere 5.1.

NOTE: vGPU support is enabled in vSphere 5.1, but the ability to leverage this feature is dependent on a future release of View. Refer to the View documentation for information on when this feature will be available.
Hmmmm... I am not too keen on that final caveat / disclaimer (about "future release" and timeline), but it sure sounds better than the lack of information about NVidia GPU support in previous releases! I am definitely intrigued by this since I play around a bit with CUDA code, but I am not specifically seeing "CUDA" mentioned here. I wonder how far this "off-loading" goes?

Other New and Enhanced ESXi / vSphere 5.1 Features

In no particular order...
  • Windows 8 desktop and Windows Server 2012 support. Nothing I personally plan to use in production anytime soon, but support is there for the latest Microsoft operating systems. I do have intentions of trying these latest OS offerings out, and VMs are the only way I would even consider it; so, good thing they are supported.
  • ESXi 5.1 has improved CPU virtualization methods ("virtualized hardware virtualization", or VHV) that is supposed to allow near-native-access to the physical CPU(s) by your virtualized guest OS's. We all like more speed in our VMs, so this sounds like a plus.
  • ESXi now has the ability to perform a VM-live-migration between two separate physical servers (running ESXi) without the need for both machines to be attached to the SAN. I need to read up on this and fully understand what that means... like, do I need a SAN at all anymore for this?
  • CPU counter and hardware-assisted-virtualization information can now be exposed to guest operating systems (useful to developers that need to debug / tune applications meant to run in a VM).
  • New Storage Features including: read-only file sharing on a VMFS volumes have been increased to 32 (from 8); Space Efficient Sparse Virtual Disks with automated mechanisms for reclaiming stranded space plus a dynamic block allocation unit size (tune-able to storage/apps needs); 5 Node MSCS Cluster (vs. 2 node); jumbo frame support for all iSCSI adapters (with UI support too); and, Boot from Software FCoE.
  • The reliance on a shared "root" user account (for administrators) was eliminated and support was added for SNMPv3. Local users assigned administrative privileges automatically get full shell access and no longer must "su" (sudo) to root to run privileged commands. This makes for finer-grained auditing and monitoring, which is a plus in shared environments.
  • With vSphere 5.1 Guest OS Storage Reclamation feature: when files are removed from inside the guest OS, the size of the VMDK file can be reduced and the deallocated storage space returned to the storage array’s free pool (utilizes new SE sparse VMDK format available with View); but note, this feature carries with it the same disclaimer that the NVIDIA stuff did — i.e., "dependent on a future release of View". Argghh. Wonder how far in the future that may be?


Conclusion

There are a fair number of new features in this latest release of ESXi 5.1 and vSphere 5.1 that are worth checking out, even though some significant ones are "dependent on future releases of View". The timing of this ESX / vSphere release goes along with the latest VMware Workstation, which I discuss here too: VMware Workstation 9.0 New Features of Interest — if you are interested in the desktop-product side of things.

Continue to read this Software Development and Technology Blog for computer programming articles (including useful free / OSS source-code and algorithms), software development insights, and technology Techniques, How-To's, Fixes, Reviews, and News — focused on Dart Language, SQL Server, Delphi, Nvidia CUDA, VMware, TypeScript, SVG, other technology tips and how-to's, plus my varied political and economic opinions.