Golly…Macs Really Do “Just Work”!

I was recently lucky enough to grab myself an iMac; in that time it has solved more problems than the time I have spent trying to solve a single problem on Windows.

Computer Specs

Memory Windows= iMac =4GB
CPU Windows=Intel Core 2 Extreme Quad @ 3GHz,  iMac=2.8GHz Quad-Core Intel Core i5
Video Windows=dual nVidia 8800 GTX,   iMac=ATI Radeon HD 5670

Before

Here is a list of my prior issues:

• iTunes on PC and generation 1 Apple TV would “forget” their network connection
  • meaning my Apple TV could no longer sync/stream TV shows and movies from my PC
  • typically you buy on the Apple TV and after watching it is “archived” on your PC to make room for other purchases
  • I had lost a few purchases because of this.  Apple does not allow you to download to Apple TV again
• Could not connect to a Canon MX850 printer via the network if it was connected to one PC via USB
  • basically allows you to share the printer over a single USB cable instead of a network cable
  • USB allows you to do certain things network cable cant
• Lacie 4big Quadra 4TB RAID “big blue button” not recognized
  • allows for quick backup
  • Windows Backup is inefficient, slow and poorly designed
• Access to Apple’s MobileMe email via Microsoft Outlook/Windows Live Essentials IMAP is incredibly slow – 5 seconds to delete a message
• Opening the majority of any document takes considerable time on Windows
  • PDF
  • videos
  • Word/Excel documents
• MSN Messenger takes considerable time to load; consumes excessive computer resources
• Games such as the recent Civilization V consume excessive resources; takes considerable time to load considering nature of application – “its no Crysis!”
• Windows Phone developer registration is more complex than applying for a home mortgage.  Took approximately 7 days to complete including various to and throw e-mails to Microsoft
• Visual Studio has historically shown that with each new version requires a level of magnitude more computer memory and CPU resources.   VS is very expensive to buy for the Pro version. Express as a tool for serious development is questionable

After

• Apple TV and iTunes on iMac just work; do not forget each other
• Canon MX850 was automatically detected over wi-fi when plugged into Airport Extreme Base Station USB socket
• Lacie 4big Quadra 4TB RAID was automatically detected and iMac kindly asked if I wished to use it for TimeMachine
  • Pressing big blue button on Lacie launched the brilliant TimeMachine app
  • TimeMachine is fast, intuitive, reliable
• Apple’s iMail automatically configured e-mail server settings just by me typing in my @me.com address
  • iMail is fast
  • Like the central inbox
• iMacs have a Preview application that very quickly opens a document for reading rather than loading bloatware Acrobat, Microsoft Word, Excel or similar
• MS Messenger for iMac (via Office Mac) is much like pre-Windows Live Essentials meaning it doesn’t have the annoying ads but more importantly, uses less computer resources like memory and CPU in wlcomm.exe
• Civilization V for iMac loads considerably quicker and exits to mac desktop much faster than Windows
• Apple’s Mac Developer MacOS/iOS registration completed in 12 hours
• Apple’s Xcode IDE is only $5.00 and uses minimal CPU and memory
• Though Apple may make use of seemingly vertical standards such as Bonjour, historically it can be shown that Apple is more likely to adopt more popular standards with more realized use cases than say MS.  Calendering is a good example.

In summary, in only a short time does one really appreciate the high quality of the iMac, but also comes to the realization that pretty much everything PC is by way of poorly designed, badly integrating bloatware produced by capitalist-corporate-hugging software houses.   Take Microsoft Office 2010 is not only bloated but is also unintuitive and bloated; similarly for VS2010 as mentioned.

Don’t Touch or You’ll Break It!

XNA is broken!…there I said it.

Like many seasoned developers, I’m fairly sure I have used quite a few software development APIs, class libraries and frameworks.  Some were rather useful in their approach to providing extensive features but with the minimal amount of effort required by ones’ behalf (Windows Forms via .NET) whilst others, though very powerful, required you to tinker quite a bit before you could actually do anything with it (Win32 GDI via c/c++ – pre MFC ).  Though these two examples of APIs are vastly different in terms of user-friendliness and skill set, they do share one thing in common – arguably very little has changed in APIs over the years that would cause your application to break or at least require a major rewrite, assuming of course your application was implemented as per guidelines too.  Unless of course you were unfortunate enough to be using Borland c++ and their odd message pump model.

e.g.  a well thought out API together with skilled application developers much of the following were incident free:

• Moving a 16-bit c/c++ Windows 3.x application to 32 bit Windows 95 (new helper macros were introduced prior to Win95).  Generally, the majority of issues in c/c++ was that newer versions of the c/c++ compiler default to newly-introduced compiler warnings regarding the language itself rather than a reflection of the API.
• .NET 1 apps to .NET 2 then finally to .NET 4 64 bit!  Conversion is merely loading it up in the new version of Visual Studio.  What could be more easy?

Some of the best APIs are the ones that are well designed from day one.  Though many pubescent up-start programmers poo-poo’d the MFC framework, particularly the document-view model, I rather liked how, at the time, the same code when run many years later could take advantage of document persistence over the Internet without major changes to your code!  Back to APIs, generally if a new API is released you don’t want to break your apps and as this example shows its nice when client code gets a free set of steak knives over time.  Black-box technologies such as COM and OLE Automation objects are some of the best ways to enforce this.  Because no actual classes are exposed but rather contracts in the form of interfaces, a developer can usually be confident that future versions won’t break mainly because COM technologies allow for side-by-side deployment of APIs.  Of course it is up to the API writer to follow this pattern or at least follow the golden rule of interface contracts – a previously published interface should never be changed! Whack your new methods and properties in new contract and expose that in addition to the prior one.

e.g. of some great COM and/or OLE Automation APIs that proved their resilience:

• OLEDB and ActiveX Data Objects (ADO)
• DirectX
• Windows Shell

So what’s my beef with XNA?

In case you didn’t know, XNA is a .NET wrapper of sorts around DirectX for 2D and 3D graphics amongst other things.  It is also a framework as opposed to a class library not that that is the issue.  Well, we .NET developers have in my opinion (which goes without saying since this is a blog) been subjected to what it seems to be an apparent lack of long-term vision with regard to developers by the makers of all things .NET-DirectX related.     The current stable release is XNA 3 though there is a XNA 4 CTP.  Prior to XNA 1 there was a beast called Managed DirectX (MDX).  MDX was rather good, you could actually have a 3D viewport in .NET Windows Forms application! Marvellous! It was infinitely easier than c++ COM-based DirectX even to COM-experts like lil-old-me.  The only bad thing about MDX was that anyone with an inkling of framework deign knows you never expose classes! [2]  Where the devil were all the interfaces?!  I fear a storm is coming.

Fig 1. Ahh…the good old days of MDX, where one could actually render 3D in a .NET Windows Forms window.

Sure enough a storm did come in the form of XNA V1 – a replacement for MDX and MDX was never spoken about again at dinner parties.  Not only could we no longer render inside say a .NET Windows Forms window[1] (boo!!) but the API was completely different (boo ^ 2).  Time to rewrite your app!  To make matters worse it was still a silly class-based framework.   Like the oil spill in the gulf, no one seemed to care and things just got worse.

XNA 2 came and sure enough it broke your app, not because of the use of some undocumented feature, but pretty much because the primary API changed.  Similarly XNA 3 was just a big a bully.

Now we have XNA 4 CTP.  Having heard of some exciting titbits about the new version, I quickly installed it; created a new project in Visual Studio 2010; grabbed myself a nice cup of tea and proceeded to attempt to draw a series dots on the screen with code that was familiar to me from XNA 3.  Alas, it seems that such tasks are too far beneath or cumbersome for modern GPUs to be interested in for I was rudely informed in a nice shade of red lettering that PointList is now politically incorrect.  Maybe if I put in 8 video cards or sacrifice a gerbil or two it will let me? One helpful chap in the XNA forums even said that:

“…Points and point sprites are just different words for the same thing…You can draw single pixel dots using SpriteBatch…” [3]

Hmmm, I admit I’m no XNA expert but surely the XNA 4 framework could have merely exposed the same contract as XNA 3 and performed the above for us behind the scenes?  This gets back to what I was saying about introducing new framework versions in general. By all means publish a new contract but don’t touch the old one.  Merely redirect it internally to achieve the same logical behaviour as the previous framework version.   If its a performance thing, then I’d would have thought that makers of GPUs concentrate on trying to implement realistic and fast shadowing technologies.  Just how often does one render a single pixel anyway for this feature to have been dropped because of a rumoured GPU performance penalty?  Perhaps this is a plot to finally whack a nail in the coffin for us would be space-sim developers?

Anyway, more red lettering was to follow.  Drawing sprites, setting up anti-aliasing, preparing effects, saving states are all completely different now so like back in the Autumn days of MDX, its time to throw away all your XNA 1, 2, and 3 books because they are about as useful as books on ODBC.

Looking back over the years, it seems that perhaps XNA has taken a very agile or scrum-based approach (not necessarily a bad thing) with little thought of the future which can be disastrous when one is making a software framework which will be utilised by third parties!   By all means use agile or scrum, just don’t be schizophrenic and change your mind all the time with regards to the API.

I wonder how OpenGL programmers have been treated?  Perhaps it’s time to start programming for the iPhone and iPad.

As one famous lady once said:

Not happy Jan!

---

[1] apparently the reason was because to support Xbox 360.  When you consider that one must explicitly compile for 360 and Windows anyway and the binaries are not compatible, allowing for rendering inside a form on Windows should have been trivial one would have thought.  And before you say message pump I’ll just say one can play back a video in a Window so what’s the difference?  QED.

[2] It’s actually interesting to see that .NET is class-based and yet does not suffer anywhere near the problems that MDX-XNA has had in its short life.  Then again c++ allowed the same thing – it just required discipline.

[3] XNA Creators Club Forums

“Not happy Jan” is copyright © Yellow Pages Australia, Sensis, Telstra.  All rights reserved. Used without permission.