Windows 8 and Silverlight/HTML5

A good read about Windows-8 and the life and death (and continued life) of Silverlight.
The author is a former product manager from Microsoft, so the reader should keep salt handy and bear any axe-grinding and shoulder-chips in mind.

(one particularly funny point:
…whilst at the same time we had to find a way to make Steve Sinofsky believe that Silverlight was killed off. )

One interesting thought (quote from the article):

Q. So… you saying Windows 8 is really Silverlight 6?
A. Yeah in concept yes. Technically no, but if you take a step back from our bad messaging, public realtion screw-ups and lastly our idiotic executive we pretty much did what you asked – we fixed WPF and Silverlight parity & performance and we made it also work on both desktop and mobile. I give you Windows 8.
(quote from the above referenced article)



Blast From the Past – Same PBL in Different Targets

This PowerBuilder shortcoming popped up again in some emails this week…
The issue – having the same PBL in different targets (all in the same solution).
We first discovered this problem ages ago (even before ‘targets’ existed) – where one PBL is shared between different applications.

The cause of the issue is that the compiled P-Code (stored with the PBL) is dependent on the other PBLs in the target (the code generated depends on its ancestors in the inheritance tree).  IOW – the P-Code became slightly application and environment specific.

The result – sharing that P-Code between different targets, with possibly different ancestors, will lead to difficult/impossible to debug runtime errors. Needless to say, this led to a long history of customer issues…

However – if the ancestors were the same (and same order!), and if all the applications had the same compiler switches, sharing a PBL between targets would work.  Unfortunately, there is that one time where something was changed, and the system would be inconsistent.  This is that difficult/impossible to debug runtime error.

In PB.Net – we wanted to relax this distinction, but we ran into the same code generator issues.  The intermediary code and other cache information is stored in the PBL directory, next to the SR* files (in the ‘obj’ directory) hence locking in a target dependency (sigh).
There was some reason (I don’t remember what) the compiler guys wanted the files in the same directory structure rather than a parallel directory somewhere else (I can imagine a host of housekeeping logistics there, so I can sympathize).

One other thing – PB-Classic would attempt to prevent you from having the same PBL in multiple targets, but its checking was quite imperfect.  This checking was improved in PB.NET (having a fresh slate makes those things easier).

In short – don’t share PBLs between targets.