The first thing I knew about the release was when I received my SA email yesterday afternoon, as opposed to having to wait a few days or even weeks to get my upgrade as has happened in previous years.  Big improvement there, and I hope Embarcadero keeps it up for subsequent releases. Good.

No OSX support, which we all thought was going to be in this release up until a few weeks ago. Bad. But it’s not there because the people at Embarcadero preferred to focus on quality and not release something that wasn’t ready. Good. No one wants to see (or pay for) another D8.

So I open it up and start browsing through some code.  My settings from D2010 didn’t get migrated forward. Annoying. There really should be some way to import them as part of the installation process.

ErrorInsight is the same old same old, with false positives all over the place because it can’t find basic standard library units. Annoying. But at least it doesn’t choke on methods of objects from a generic list anymore. Good.

Speaking of Generics, huge improvement here.  I was able to go through my codebase and remove all the annoying workarounds for generics-related glitches, and it compiles and runs properly now! Good.

When it’s time to debug, I immediately noticed a few improvements.  We finally, finally, after all these years, have debug DCPs available for the standard libraries.  (For those not familiar with them, DCPs are to Delphi packages as DCUs are to units.)  That means that people like me who build stuff with packages are able to trace into the RTL when debugging.  Good.

Also, something that always drove me up the wall about the debugger has been fixed.  When you put the cursor in an expression and hit CTRL-F7, it pops up the Evaluate/Modify window and evaluates whatever you had the cursor on.  But if you moved the cursor and hit CTRL-F7 again without closing the Evaluate/Modify window, it would focus the Evaluate/Modify window, but it wouldn’t evaluate the new expression you had selected.  You’d have to close the window and hit CTRL-F7 again to get a new evaluation.  (Or copy/paste or type it in, of course.)  That always bugged me, but it’s been fixed in XE.  Good.

And while we’re on the subject of Evaluate/Modify, you can now select more than whatever the limit used to be (80 characters?) and have your entire selection copied when you hit CTRL-F7. Good.

But while poking around in there, I found a new way to crash the IDE.  Try to evaluate a call that will open a form, and it locks up Evaluate/Modify.  Then hit CTRL-F2 to kill the debugger, and it brings the whole program down. Bad. (Not sure if this was in earlier versions, though. I’ve never run across it before.)

Oh, there’s a new regular expression library in the RTL.  Some people will probably find this a good thing.  I personally see it as Annoying. Delphi code is supposed to be easy to read.  That’s an explicit design goal going all the way back to Wirth.  But PCREs are anything but, and having it right there in the standard library will just encourage people to use them in code that I might end up having to debug some day.

In addition to Generics bugs getting cleaned up, the Generics.Defaults and Generics.Collections units got a bit of polish.  There were some minor tweaks to speed up various low-level comparison functions in Generics.Defaults.  Over in Generics.Collections, all the collections have gained a ToArray method, TStack<T> and TQueue<T> gained a Capacity, and there’s a new TThreadedQueue<T> class that looks a lot like the Blocking Collection that Primoz Gabrijelcic set up for OmniThreadLibrary, only without all the Omni stuff.  These new features look Good.

The Math unit has been given overloads for Single, Double and Extended precision versions of just about all its calculation routines, which is Good because there’s no more implicit conversions to introduce rounding errors.  However, I had this bite me when compiling some code at work.  Someone was passing an array of integers to Math.Sum, which worked before, but now the compiler gave an ambiguous overload error for that. Annoying, but not too hard to fix, since there’s a SumInt function right after Sum.  Not sure why the original author of this code didn’t use it in the first place.  Oh well…

In RTTI.pas, there’s a new class called TMethodImplementation.  You create it and give it data that describes the signature of a method, then pass it an anonymous method that takes an array of TValues and returns a TValue, and it creates a little thunk of machine code that builds a function with the correct signature that invokes your anonymous method.  Very cool, lots of potential… except that you can’t use it.  The constructor’s private, and there’s a public constructor that raises an exception, so you can’t get at it via TObject.Create.  It’s apparently for internal use only.  Annoying. I asked Allen Bauer about this, and he said that it’s because they weren’t sure they had the final form of the class worked out yet, and they didn’t want to make it publicly available yet in a form that they’d end up having to preserve and support forever afterwards.

There’s also a new class called TVirtualMethodInterceptor that is publicly available, and uses TMethodImplementation internally to allow you to replace virtual methods on a class.  I’m a bit curious as to what this is useful for, but apparently the team thought it was good for something, because a lot of work went into setting it up. Good?

Oh, and apparently certain aspects of the compiler have slowed down.  Most things will compile about the same speed or even a little faster, but for really large projects (millions of lines) with complex interdependencies between units, you’ll notice some slowdown, and it’ll apparently get worse the larger your project is.  I timed it at work, on a project of about 3.5 million lines of code.  It builds in about 2 minutes on D2010, closer to 3 minutes on XE.  Bad, but still a heck of a lot better than the C family could do.  And apparently it has something to do with making Generics work right, so I can tolerate that.  Hopefully they’ll find some way to regain some of that lost speed in updates, though.

Oh, and there are little {$IFDEF POSIX} and {$IFDEF MACOS} tags scattered throughout the RTL and VCL, even more than there were in Delphi 2010.  This is Good if you’re looking forward to OSX or Linux cross-platform development in the next release(s).  I haven’t seen any 64-bit ifdefs, but that could be because it doesn’t require much change at the Pascal level, the way a completely different OS platform does. (UPDATE: According to PhiS, there’s a lot of {$IFDEF CPUX64} tags in System.pas.  I was poking around the libraries with BeyondCompare last night but I didn’t bother to look in there because I knew that, with all the cross-platform stuff and all the ASM they’ve got in System.pas, the diff view would be a big, confusing mess no matter what.)

Well, it’s getting late and I haven’t had time to dig through too much of the new stuff yet, (and with a new 1000-page novel and a new video game, it might be a while,) but overall this is looking like a pretty good release.  Not a huge leap forward like the last two were, but a lot of polish and incremental improvements.  I think this is going to be a pretty good release overall.

They’d have something almost ready, and then person A says “No, we can’t do this, we shouldn’t have X on there, it needs to be Y instead,” so they take X off and replace it with Y.  Then person B looks at it and says, “hey, what happened to X? That was critical!”  So Mike has to explain that it was removed because of person A, and get those two in a room together where they can discuss it and work out a compromise, and then they update the roadmap so it says XY.  And then of course, person C comes by and says, “hey, what’s with all this X stuff in there? I thought we took it out, because we won’t be able to get it implemented on this schedule!” And it’s back to square one.

Repeat a few dozen times, over a period of a few months, until finally they reach the Ultimate Compromise that everyone can bring themselves to agree upon, and then they finally publish the new version.  That’s the easy part.  Once everyone’s signed off on it, it takes about five minutes to get it posted to embarcadero.com.  He said that he’d have liked to publish the updated roadmap before the XE sneak previews started, but that just wouldn’t have worked on the timetable they had.  It was a real eye-opener, talking with him about the process.  It makes the roadmaps being the way they are a bit more understandable.

Mike also mentioned that a lot of people, including himself, don’t like the “PowerPoint slide” format that the last few roadmaps have been done in, and the next one will probably be done a different way.  Of course, working out what the new format will look like will be another long round of negotiations and compromises…

Again, apparently this is all completely normal for trying to publish a roadmap for a commercial product.  What do you guys think?  Has anyone out there been in a similar situation?  Are roadmaps always that messy, or has Mike just had a run of bad luck?

Then they mentioned AQTime, which looked interesting but IMO brings up more questions than it answers.  For example, “Since this is the standard edition, not all of the profilers are enabled.” (9:13)  But I don’t see any of the profilers on that list grayed out.  And again, will this be in all editions, or just the high-level ones?

Also, will it come with an extension to the Open Tools API to allow other profilers to be integrated?  AQTime has some great features, but its core feature, performance profiling, uses instrumenting that slows your app down horribly, which makes it unsuitable for a lot of uses.  I prefer Sampling Profiler, which gives a good picture of what you’re spending your time doing without instrumenting your program.  It doesn’t provide the perfect counting accuracy that instrumenting does, but most of the time you don’t actually need that anyway in order to track down performance problems.  If there was a way to integrate Sampling Profiler into Delphi, it would make a good compliment to AQTime’s other profilers.

As for CodeSite, I don’t have too much to say about that, because I don’t know enough about how it works to discuss it very well.  Logging’s definitely useful, but usually in different ways than what they were demonstrating on the video.  For example, if CodeSite can only output to that popup window, it’s worthless IMO.  But if it can write to a file, or better yet if it allows you to create and register custom outputs of some kind, that would be a big help.

The one thing I’m a bit worried about is price.  Delphi’s got three general problems, which need to be resolved independently.

1. Missing features.  No 64-bit, no cross-platform, no data binding, no LINQ, etc.
2. Bugs and quality issues.  Glitchy generics, *Insight, the helpfiles, etc.
3. Price.  No explanation needed

Delphi 2011′s main point was supposed to be addressing a missing feature.  That ended up not happening, as the team members have been explaining, because they don’t have enough time to get it working at a good quality level.  That’s definitely a praiseworthy attitude, but I’m a bit worried at seeing all these expensive third-party tools being suddenly announced as part of the product.  They don’t actually do anything to solve the three main problems facing Delphi, and I’m a bit worried that they’ll end up taking the price even higher.

They’ve mentioned their commitment to quality several times, and specifically that they’ve done a lot of work to fix the generics issues.  That’s great, and if they’ve allocated some resources to getting a Error Insight and Code Completion working properly that’ll be even better.  But even so, not having the main missing feature we were expecting would be delivered is going to do a lot to reduce the perceived quality of the release, even if the objective quality has gone up quite a bit since D2010.  Quality improvements are generally expected to be part of an update, not a new release.  (The “I paid good money for this with the expectation that the promised features would actually work” argument.)

I really hope I’m interpreting this wrong, but what it looks like to me is that in order to avoid the new version being perceived as “just a bugfix release” that isn’t worth the price, Embarcadero decided to bundle a bunch of expensive tools to make it appear to be more worth the cost.  If that’s what they’re doing, there are two ways to do it, and both will hurt them.  Either the price stays about the same as it was for D2010, but they’re paying a share of it to the owners of AQTime, FinalBuilder, etc, so they lose a lot of revenue, or they pass that cost along to us, the price goes up, (without delivering the anticipated new feature,) and a lot of people end up not wanting to buy it at that price, so they lose a lot of revenue.

What I would prefer, and what I would do if it was my product, is to negotiate some sort of deal with the creators of these other products where people who buy Delphi XE can pick them up at a discount, and then sell the actual Delphi license to us at a reduced price.  That would help improve sales, or at the very least help stem the loss of sales resulting from not having cross-platform available, and no one ends up paying for add-on products they don’t need.  (And not everyone will need them.  Where I work we’ve got a bunch of developers and one build machine.  If we all got a copy of FinalBuilder… what would we do with it?)

I really hope I’m wrong about this, but this is what it looks like Embarcadero is doing.  I just wish they wouldn’t, since I don’t think it will actually be good for Delphi users, or for Delphi itself.

“Why can’t I pass a TList<TMyDerivedObject> to a function that’s expecting a TList<TMyBaseObject>?  You can pass a TMyDerivedObject to a parameter expecting TMyBaseObject, so why doesn’t it work for lists?”

It really looks like it ought to be that simple, but unfortunately it’s not.  Trying to do this gets into a tricky issue in type theory known as covariance and contravariance, which is a formal way of describing the relationship between different types when one inherits from another.

It’s important to remember that object types don’t really exist at the binary level.  They’re an abstraction that makes it easier for us to work with them, but when you get down to it, all that’s there is a sequence of bytes.  As a strongly-typed language, it’s up to the Delphi compiler to make sure that, when you have a TMyDerivedObject, it doesn’t get replaced with a TMyIncompatibleObject that will cause things to crash or corrupt your data when you try to use it.  This is why you’re not allowed to pass descendant classes to a var parameter, for example:  because in the function using the var parameter, you’re allowed to replace the object with something else, and if the compiler can’t guarantee that the replacement will be of a compatible type, it prevents you from passing it in order to preserve type safety.

This is basically the same problem you get when dealing with generic lists.  Let’s say you have a TList<TMyDerivedObject> and you pass it to a function that expects a TList<TMyBaseObject>.  As long as all it does is reads the items in the list, you’re just fine.  But if this function calls .Add on the list and adds a TMyIncompatibleObject, (which also descends from TMyBaseObject, and so is perfectly legal in this context,) then you’ve violated type safety.  You have a list that’s supposed to only contain one type of object, and now there’s something incompatible inside.  And since this is done by calling a method on the list object and not by directly assigning one variable to another, the compiler can’t check to make sure you’re not doing something dangerous like this, so it forbids the entire concept in order to preserve type safety.

There’s a solution to this problem.  You can extend the language syntax a little so that the compiler does have a way to check this.  You have to mark the methods on the list so that the compiler knows that it’s safe for them to receive an object that descends from, or is an ancestor of, the specified generic type.  For example, you could mark TList<T>.Add with a hint that it’s OK to add descendants of the T type, but not ancestors.  Then the compiler uses this to determine more relaxed type safety rules that allow you to pass around different generic types without the danger of mixing incompatible types together.

The latest version of Prism supports this, but the Delphi team hasn’t implemented it yet.  I haven’t heard anything to indicate that they’re working on it for Delphi 2011 either.  Hopefully it they’ll find some way to implement it for Delphi 2012.

The upside of all this, though, is a very simple scripting system that doesn’t look much like a programming language, with a simple interface that almost anyone can pick up.  I wanted to keep that simplicity as much as possible, while adding the full flexibility and power of a real scripting language.  So I dreamed up EventBuilder, a set of objects which represent a high-level scripting interface and can also express themselves as PascalScript code.

I needed some way to create EventBuilder objects that could form a hierarchical tree that can represent blocks of code.  They needed to be easily serializable to some human-readable format so people can copy and paste blocks of EventBuilder script in order to share scripts, ask for help with debugging, etc.  And it needed to be ready quickly, since I want to be able to present as much of this as possible at Delphi Live! in August.

So is there any pre-existing system that supports hierarchical trees of objects and easy serialization to a simple text-based format?  The answer should be obvious to any experienced Delphi user:  descend from TComponent and use its built-in serialization to “DFM format.”  I tried that and, once I’d figured out how to handle a few quirks related to object ownership, it worked great!  All the infrastructure was there for me, tested and tried and proven over the last 15 years, and I could focus on the actual Event Builder logic.  It’s taken me about a month to get the system to a workable state, and now it’s more or less all ready.

Then I tried running a very, very large RPG Maker project through my project importer, and it took a long time on converting the global script block.  That’s sort of to be expected, since there are almost 2000 event scripts in there, but even so it felt like it was taking far too long for the amount of work involved.  I looked at my code and couldn’t find any obvious issues, so I ran it through Sampling Profiler.

It’s a good thing I did, too.  It found a very clear bottleneck in a place I’d have never thought to look.  Apparently I was spending 77% of my time in TComponent.Notification.  And why would I have never thought to look there?  Because I’ve never heard of it!  But apparently every time I added a component, it would recursively call this on the entire subtree, turning what ought to have been a O(n) conversion into O(n^2).

With a bit of research, it turns out that TComponent.Notification is for dealing with linked components.  For example, when you link a TDataset to a TDatasource, it needs a notification mechanism so it can clean up references if you free one of them.  Since EventBuilder doesn’t use linked components, I didn’t really need this functionality.  Good thing TComponent.Notification is virtual!  I overrode it with a blank method, and suddenly the conversion time dropped from about 12 seconds to about 3 seconds, and everything’s running smoothly again.

Moral of the story?  Be careful that you understand what you’re inheriting from, otherwise you might end up with killer kangaroos or other unwanted features.

Unfortunately, I don’t always get what I’d like.  I can’t really talk about stuff like that because I haven’t reached that point yet, due to various bugs and other implementation hurdles.

The installation and setup phase went quite well, actually.  The package was a 19 MB installer including full source code, DPKs and other requisite files for building the AnyDAC packages under anything from Delphi 5/C++ Builder 5 to RAD Studio 2010 (or FPC 2.2.x), a nice big helpfile and a fairly comprehensive Samples folder.  The download was nice and fast, and the only real annoyance was the installer getting a few paths wrong.  The helpfile is quite well-written in good, understandible English, which is good to see; that’s not always the case when working with libraries written by people from non-English-speaking countries.

I loaded up the TURBU project, backed up everything to source control, and went into dm_database.pas, where I keep my client datasets.  Time for the trial by fire:  Open the form designer, switch to text view, Select All, SyncEdit, replace all “TClientDataset” with “TADMemTable”, switch back to form view.  IMO, if something is presented as a replacement for something else, you ought to be able to swap it out and have it “just work.”  In practice, it’s rarely that simple.

TADMemDataset has the same support for filtering as TClientDatset, and it has a CloneCursor function, which is good because I use it pretty extensively.  What it doesn’t have, though, is the same public interface as TClientDataset.  For example, TClientDataset has a property called LogChanges, where if you turn it on it will save all edits to an intermediary datastore instead of the main one until you call MergeChangeLog or CancelUpdates.  Among other things, this makes implementing an editor dialog with Apply and Cancel buttons very simple.  TADMemDataset supports the same functionality, but the property that controls it is called CachedUpdates, not LogChanges, and to merge the change log you call CommitUpdates.

I got a bit of a rude surprise when I tried to convert one of my ClientDatasets to a TADMemTable: it didn’t like one of the fields.  The field was a TSingleField, and the internal storage table doesn’t know what a Single is, so it converts it to a Double, which causes errors when trying to open the dataset.  When I reported this to Dimitry, he replied that “ftSingle is not supported for a while.”

Also, using custom filtering with the OnFilterRecord event handler seems to break CloneCursor.  It looks like an order-of-operations issue inside TADDataset.InternalOpen: X needs to happen before Y, which needs to happen before Z, which is the way it’s currently set up, except that Z and Y both need to happen before X if you’re cloning a dataset with an OnFilterRecord event handler.  Apparently this is because X is doing too many different things, and needs to be reworked a bit.

I’ve reported all these issues to Dimitry and he says he’ll get a fixed version to me as soon as possible.  What I’ve seen so far of the dataset’s API looks interesting, but it’s kind of difficult to test for the moment, until the rough edges are polished.   I’ll post another update once I’m able to.

One other strange thing: In order to use the dataset, it requires access to some interface that has to be initialized by dropping a certain component onto your project that seems to have no other purpose except to make this interface available.  (Sorta like the XP Manifest component that does nothing except link a resource into your EXE.)  I’m not quite sure why TADMemTable can’t manage its own dependencies, but that’s kind of disappointing.  Hopefully that will get fixed in an update.

So over the next few weeks, I’m going to be trying AnyDAC out and writing up what I find out.  In the interests of disclosure, I’m not under any sort of contract to do or say anything specific with it, just an informal agreement over email.  I received a free license for AnyDAC, but no money or other compensation.  I’ll take a look at their components, and especially DatS, and post on here about my experience with it.  I hope the AnyDAC people don’t think they’re getting paid advertising, because I plan to be honest and objective about the whole thing.  What I like, what I don’t like, what’s good and what needs improvement.  And if it turns out that I enjoy my experience, and something in my reviews causes some of my readers to buy some licenses, then maybe it’ll be worth it for them.  I guess we’ll see.

Last year’s conference was a lot of fun, and I really enjoyed having four days to relax, learn some new stuff, and hang out with a bunch of really talented coders.  (And about an hour and a half of completely stressing out and hoping nothing would go wrong as I presented my session!)  They haven’t posted the schedule yet, and I haven’t heard much from the other participants, but this is being put on by the same people who did last year’s DelphiLive!, and they did a really good job of it, so I’m looking forward to this one.  If any of you can come, you’ll have a good time.  Hope to see you there!

After a bit of digging, I found out that when CloneCursor builds the field structure for the cloned dataset, it copies the FieldDefs from the original.  And FieldDefs only define data fields.  The field I was trying to display was a Calculated field, so I ended up without it.  Well, OK, that’s not such a big problem.  Just add a new calculated field, right?

begin
   calc := TWideStringField.Create(nil);
   calc.FieldName := 'DisplayName';
   calc.Size := 255;
   calc.FieldKind := fkCalculated;
   calc.Dataset := DataSet;

That ought to work, but it raises an exception.  “Cannot perform this operation on an open dataset.”   OK, I can understand that, almost.  It makes sense for data fields, because the underlying data store has to be set up in a certain way.  But for lookup and calculated fields that aren’t bound to the data store, it doesn’t make any sense.  Unfortunately, TField.SetDataset doesn’t care what kind of field you’re adding.  It checks to see if the dataset is inactive, and if not, boom!  It blows up in your face.

So I can’t add a calculated field to the dataset after CloneCursor has run, because CloneCursor calls Open and after that it’s too late.  So maybe I can add it before CloneCursor has run?  That almost works.  You end up with that calculated field in your cloned dataset… and nothing else.  Why?  Because about 2/3 of the way through TClientDataset.InternalOpen, it says “if DefaultFields then CreateFields;”  And DefaultFields is set by the method that calls InternalOpen, which starts like this:

procedure TDataSet.DoInternalOpen;
begin
  FDefaultFields := FieldCount = 0;
  InternalOpen;

Oops!  Again, not making any distinction between data fields and auxiliary fields.  FDefaultFields is a private field, and DefaultFields is a read-only property, so that makes it very difficult to change.

I could have created an entirely new TClientDataset on my DFM that duplicates the entire field structure of the dataset I’m trying to clone, including the calculated field, and that would have solved the immediate problem.  But then I’d have to make another copy of another dataset every time I find myself in a situation like this.  I’d really prefer to make it recognize that there are some predefined fields that it can integrate into the field structure.

Fortunately, InternalOpen is virtual.  All I need to do is create a subclass of TClientDataset that overrides InternalOpen and resets FDefaultFields to the correct value before calling inherited.  Except… how do you do that?  It’s a private field of TDataset, accessible only through a read-only property.

Prior to Delphi 2010, I wouldn’t have been able to do this.  But now, there’s a way to fix this sort of problem with extended RTTI. The solution looks like this. (This solution works specifically for TClientDataset, but you can apply it to any TDataset descendant easily enough.)

unit extensible_cds;

interface
uses
   DBClient;

type
   TExtensibleClientDataset = class(TClientDataset)
   protected
      procedure InternalOpen; override;
   end;

implementation
uses
   db, RTTI;

{ TExtensibleClientDataset }

procedure TExtensibleClientDataset.InternalOpen;
var
   context: TRttiContext;
   field: TField;
   value: boolean;
begin
   value := true;
   for field in self.Fields do
      value := value and (field.FieldKind <> fkData);
   context.GetType(self.ClassInfo).GetField('FDefaultFields').SetValue(self, TValue.From(value));
   inherited InternalOpen;
end;

end.

If this sounds overly complicated, that’s probably because it is. TField.SetDataset should only care about the dataset being open if you’re trying to add a data field. That would have solved everything. I submitted a report to QC about this a few months ago.  Hopefully it’ll be one of the things they fix for Delphi 2011.

Apple released the latest iPhone development license yesterday, and I suddenly find myself a lot less grateful.

In case you haven’t already seen, it contains the following provision:

Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

Among other things, that means no Object Pascal for the iPhone.  At Delphi Live last year, the Embarcadero folks talked about “Native Delphi everywhere.”  Everywhere but the iPhone and the iPad, apparently.  Oh, and not on any phone that runs on Windows Phone 7 either; only .NET apps that use Silverlight or XNA are allowed there.  Google’s Android is only slightly better.  You’re “officially discouraged” from using anything but Java, but not outright prohibited.  (Language choice is alive and well on Palm’s WebOS, but phones that run on it aren’t doing so well in the market.)

This also slams the door hard right in the face of all the folks at the Lazarus project and the fascinating work they’ve done on Objective-Pascal, and it calls the future of the Delphi team’s cross-platform work into question.  With all of the blog posts about Delphi for the Mac in the upcoming “Fulcrum” project, it’s clear that Embarcadero is putting a lot of effort into making Delphi work on the Mac, and does anyone doubt that they had the iPhone/iPad in their sights as part of the long-term plan?

I spent a lot of time thinking about what makes this new policy so offensive to me.  Apple has every right to build the iPhone however they want to.  The design of the phone is their own intellectual property.  And they have the right to build an App Store as a centralized place to buy and sell iPhone content.  And if they own the App Store, it logically follows that they have every right to decide what apps people can offer on it.  The store’s their property, after all.  I’ve seen plenty of brick-and-mortar stores with signs that say “we reserve the right to refuse service to anyone for any reason,” and this is just the electronic version of that.

But here’s where we come to a problem.  The design of the iPhone is Apple’s property.  The App Store is Apple’s property.  But the individual phones and iPads are not.  If Apple sells an iPhone to me, it is transferring ownership of the device from Apple to me in exchange for an agreed-upon sum of money, and once this transfer has taken place, they no longer own it.  It becomes my property, to do with as I please.  That’s a very simple, intuitive concept that anyone can grasp, and it’s been a fundamental principle of capitalism since before Adam Smith wrote the how-to guide:  as long as I do not use a personal possession in such a way as to cause actual harm to others, I can do whatever I want to with it.

This principle’s under attack now.  The only way to get a new app on your iPhone is through the App Store, or by uploading it directly from your Mac if you have a Mac and the iPhone SDK.  On my PC, I can go to some random website, download a new program and install it, but you can’t do that on an iPhone, even though it has a built-in Internet connection.  In effect, Apple has decreed you only theoretically own the iPhone; you don’t own the part of it that receives new applications.  That still belongs to Apple 100%.

Well, to be frank, that’s a bunch of crap.  Apple has no right to tell me that I can’t download an iPhone app from some random website and install it on an iPhone if I want to, and Microsoft has no right to say that I can’t write non-.NET apps for the Windows Phone 7 OS if I can figure out the bindings.  Any law that says they do have such a right is evil and needs to be repealed.

This isn’t just about the iPhone, or even phones in general.  This is about the future of personal computing itself.  What Apple’s managed to pull off with the iPhone looks a whole lot like Microsoft’s vision of the future, in which every computer contains a TPM chip that will place the ultimate control of the system’s functionality under the control of the owners of the software that runs on it, not the owner of the computer.  This isn’t some hypothetical bad future bogeyman that Richard Stallman is cooking up to scare people into using Free Software, folks.  This is what is really happening, right in front of us, today.

In any other context, taking control of the functionality of a computer away from the computer’s owner and using it against his will and against his interests is known as hacking that computer.  It’s universally regarded as a form of computer crime, and rightfully so.  But when DRM technology is involved, it’s not a crime; instead it’s a legally-protected “access control.”  That’s what the DMCA and similar laws in other countries are all about: they explicitly give copyright owners the right to hack your computer, at any time and for any reason, if your computer runs their copyrighted material.  And until this notion is reversed, and the use of DRM technology is legally recognized as the crime it is, we can expect to see the future of computing looking more and more like the iPhone.

It would seem that Apple has come full circle.  Thanks to Apple Macintosh, 1984 was not like “1984″. But thanks to Apple iPhone, 2010 might be.