Nor for that matter can any other unmanaged compiler except Microsoft’s own C/C++, apparently.
Who would have thought that in a forum reply in a thread about and entitled “HTML Builder” you would stumble across crucial, technical information relating to the paucity of WinRT support in Delphi ?
But it’s there all right.
Now, I see no point in replicating Allen’s post here. You can read it for yourself at the source. But in summary: there are severe technical constraints imposed by Microsoft that have Embarcadero’s hands completely tied.
Some have said that in the light of this I now look foolish for not having given Embarcadero more time to deliver their WinRT support before complaining.
I honestly don’t see how.
My complaint wasn’t that they didn’t support WinRT it was the fact that they have obfuscated and obscured this fact by trying to present what they have done as something that it isn’t and, as we now learn unless Microsoft change their stance, can never be!
So much for those putting their faith in the promise to have “WinRT support soon“.
If anyone looks foolish it’s the people who were saying “don’t be so hasty, given them time. After all Windows 8 and WinRT hasn’t been out long, of course it will take them time to catch up.”
But now we learn that the problem wasn’t time but an absolute, technical barrier beyond their control. So buying their products based on a belief that, given time, they could and would deliver, would be a wholly uninformed purchasing decision. And who gave that impression, might I ask ?
Once the technical barrier has been removed then yes, it becomes a question of time. But whether the technical barrier is ever removed is up to Microsoft. There is nothing Embarcadero can do except… ironically… complain about the situation.
I say ironically because when I complain about a situation apparently I am being “negative” and told to hold my tongue because it doesn’t help.
I wonder if those people think the same advice will serve Embarcadero well in this situation or, by consequence, their customers.
XE3 and Beyond Belief!
I am sure I am not the only one that is absolutely flabbergasted that this information should have come out in the way that it did. Indeed, that is the theme of the immediate responses to Allen’s post. And as some have mentioned, this is hardly likely to be something that has happened only recently, in the past days or weeks. Embarcadero have surely known about this, and presumably been struggling with it, for some time.
Yet at the launch event of their flagship compiler products that are hamstrung by this state of affairs, they say nothing !? And then they express surprise that nobody is talking about it ?!
Well, it’s difficult to talk about a problem when you haven’t been made aware that it even is a problem.
And that, if nothing else, is the value of complaint and criticism. It brings things to people’s attention that might otherwise continue in ignorant oblivion, and thereby increases the chances that the problem might actually be dealt with to the benefit of the wider (interested and concerned) community.
-
IMHO, users should know such kind of details like limited WinRT support.
But i m happy to see that Delphi is improving and live!)
So, to be more positive, WinRT can be in Delphi after MS allow this. IMHO, this is monopoly position on MS side, and should change in future. For ex, even Apple finally allow third-party compilers on iOS!
-
That is NOT monopoly position. You can develop with native compilers for Windows 8 – just not for WinRT. Native compilers for i OS were unavailable at all.
Who knows what would be hidden in ARM WinRT model, but providing they do not have to be backward compatible on ARM, MS can just not implement dangerous features, rather than prohibit their using. Hopefully on ARM all those functions would be limited to safe isolated work, rather than p[resent but prohibited to use.
-
-
No wonder you’re so unhappy.
You don’t like it when Embarcadero doesn’t give enough information, and when they do, you mistake it for complaining.
-
The posting of the information isn’t the complaining. The part where Allen says they are “currently rattling some cages at MS” seems quite clear that they are complaining at/to/with Microsoft though, no ?
It’s particularly puzzling given that Microsoft have previously said that they want other tool chain builders to target WinRT. Why is Embarcadero finding it so difficult to push at – what should be – an open door ?
-
Clearly it’s not an open door
-
Maybe it was an open door with a trip wire attached … ?
-
It could be an open door with a face control.
And Emb could fail that control, or try to pass through windows working around the control, or could be cynically turned away without sincere reasoning.And we would hardly know it in the reasonable timespan. Maybe 10 years later when neither WinRT nor Delphi would matter any more.
-
-
-
-
If noone complained, probably that information would never have surfaced. But frankly I can’t understand why Emb didn’t start to talk about it well before. “We’re investigating WinRT support but the actual implementation allows only VC++ code to work through special permission given to it runtime DLL. We’re asking Microsoft to allow etc etc.”.
-
-
I don’t know if MS will ever drop that WinRT wall, but one thing is sure: If they don’t, I’m deeply sure that WinRT will follow other dead technologies once born in Redmond. Most mobile developers are using Apple tools or other open tools targeting Android. If you have to be locked down to MS tools to develop targeting WinRT, then MS is shooting itself in the foot. Windows history of commercial success is not due MS, but due to the huge number of Windows applications, created by a vast number of tools and compilers out there, both commercial and free/open sorce. If you consider all programming languages and compilers, you will see that the number of VC++/C# developers is not that big…
-
I am surprised that this infotmation was released informally in a blog post as this has major implications for Delphi developers wanting to target WinRT directly. Also, given that David I in a blog post in one of your other topics, said something along the lines that “All will be revealed..” and “We have you covered…”. Well yes, it has been revealed, but not in a very constructive manner! And as for having you covered, fake Windows 8 apps is not going to cut it for the majority of developers and users.
So realistically, they have 3 choices:
1. Do not support native WinRT development in Delphi
2. Develop their own runtime lib and plead/beg with Microsoft to lift the restrictions in the same way that the VC++ runtime lib has been treated. This will probably only mean minor modifications to the Delphi RTL.
3. Go the whole hog and redevelop/reengineer the Delphi RTL to use the VC++ runtime lib. This might need changes to the compiler and obviously major modifications to the Delphi RTL. It will take time but has the advantage that Delphi will be ebale to support future releases of Windows.It seems that are going for option 2 but I doubt that Microsoft will concede.
-
To be fair, Allen DID also say that, to implement WinRT would be non-trivial.
Assuming Anders Hejlsberg were to put a good word in for us
, the technical data transfer to EMB would be quick.For EMB then to move on and do the necessary adaptations is going to take much longer. And the culture shock most of us will experience is also not to be underestimated.
But it is very important for EMB to make a plan. Tablet/phone applets are tearing away market segments from us desktop folks. These are not only “toy” apps. I do industrial applications and am getting inquiries. It is imperative for me to get into WinRT leu leu, with Delphi or without Delphi.
-
why ? Before Delphi/ARM released you anyway have no reasons to care of WinRT/ARM.
And Win8/x86 tablets are promoting as Win32-compatible.
So you can launch your Delphi 5 or Delphi 7 and make industrial applications for Win8 tablets today.Why does WinRT matter for industrial apps ?
AppStore Market ? Aren’t industrial apps to work with closed intranet information, that is for most part not public?
Would some CEO want any punk to download his monitoring application from
rapidsharebittorrentAppStore Market and have chances to getting all inside information by guessing password like qwerty1234 ?WinRT and market are important for consumer @home users, that prefer iOS/Android style of infortainment. But how does it relates to industrial apps at all ?
-
Yes, D5/D7 apps run in the Windows Desktop app, but that is not what my client was talking about. They want a Tablet UI program.
I hope MS does not force users to go through a store. That’s fine for global markets, but I write programs requested by single clients, for that client only.
How does it relate to industrial apps? Imagine a plant diagram. An alarm blinks. The user just zooms in with a gesture. Touch the alarm, see what caused it. Touch again to acknowledge. Wipe to another part of the plant diagram. See if the motor is running.
So easy. Engineers don’t want to mess with laptops, scrollbars and mice anymore.
And if I say I can do it, I get the contract.
-
Touch screens were far before Windows 8.
Same for touch-enabled applications for WinXP at least.I cannot think WinRT is a requirement to support touch.
-
-
-
-
Hans Passant’s SO answer here is informative: http://stackoverflow.com/questions/10279458/is-new-jit-ed-programming-language-in-windows-8-metro-winrt-possible
Note the date. This is in fact old news.
Do you have a link to an official Emba promise of “WinRT support soon”? If they did promise that, then it would be bad. You should add that link to your article.
As for the comparisons with Apple, I think the situation is pretty much the same for Apple and MS. Emba can create tools that produce WinRT targets, but they can’t get them onto the app store. Isn’t that the same as Apple. To get on Apple App Store don’t you have to use one of the Apple blessed dev tools?
-
David I:
Our R&D team is also working on WinRT support, but that will be for a future release.
The R&D team is also working on ARMv7 and WinRT support for the future.
Are these quotes strictly, and literally speaking true, even in the light of the information we now know. Absolutely.
Do they fail to convey the precise problems that prevent R&D from delivering today and which might – being beyond the control or ability of Embarcadero R&D – never be resolved ? I think it’s fair to say that is so.
The impression given is that “it’s just a question of time”.
As for the stackoverflow question/answer, interesting and yes it’s a relatively old post. And it is curious that this didn’t kick up the storm that Allen seems to think should have been brewing on this topic. Also very curious was Kate Gregory’s answer to that question, referencing this observation from a Microsoftee (Charles Torre).
Specifically:
we not only want language designers and implementers to add WinRT to their list of target platforms for their language and toolchains, but we will help and advise
Which begs the question, why are Embarcadero finding it so difficult?
But is the situation the same with Apple ? I don’t think so. You have to have signed your app which I believe requires Xcode – but I’m not so sure that the code has to be compiled with an Apple “approved” compiler as such. But let’s say that it does.
Even if the various non-Apple dev tools that exist ultimately use an Apple compiler to spit out “approved code”, clearly it doesn’t stop people from creating their own compilers and languages that manage to deal with this situation quite comfortably. iOS Build environment for Visual Studio, OCaml compiler … these dev tools are not “blessed” by the Church of Apple, yet they can create applications that can get on the Apple Store, no problem.
Heck, for that matter even Embarcadero managed it with iOS, using FPC.
So if the situation is – as you suggest – no different with WinRT and Microsoft than with Apple, how to explain the difference ?
-
My statements are still true. R&D is working on all sorts of platforms for post XE3 and the coming years. In my 27 years here there have been technical and licensing details that we’ve had to work out and continue to work out with Microsoft, Apple and others. We don’t need to write in advance about every little detail or nuance that we have to deal with. We definitely need to document what the details are for customers when we release field test and RTM versions/editions. Since we are not shipping WinRT support in XE3, there is still plenty of internal (technical and other) work to do before we get to that point.
-
Yes, your statements are still true – and stand as classic examples of the half-truths I referred to before.
Yes, you want to support WinRT and are working it. Great. That’s true.
The bit that’s missing from those statements – the other half of the truth – is that it’s not just a question of your wants and efforts.
The ability and willingness of your R&D people to do their job is not in question; whether or not Microsoft will remove the apparent barriers that prevent them from completing that job is the key, which we only find out now after the online equivalent of having to beat it out of you.
-
Half Truth? We are working on WinRT support for the future is the truth, the whole truth and nothing but the truth.
-
Seriously ? You are putting this statement out here for all to see, without a [tongue-in-cheek] ?
Unbelievable.
-
-
-
-
-
-
Jolyon —
Just curious. Have you ever been wrong about anything?
-
Yes. I was wrong to believe that XE2 was the great herald of a brighter Delphi future that I thought it was.
My bad.
When I am wrong I admit it. When people tell me I’m wrong when I’m right, or suggest I look foolish for having said things I never said or for things I said having been proven unfounded when they have in fact been confirmed, then by jove I will defend myself and to the hilt sir!
Besides, it’s my blog.
All comments welcome, even the negative ones.
-
-
…and also, to be fair, EMB cannot afford to throw a Delphi solution at every hype that blows by.
Criticism of Windows 8 / Metro has so far been deafening. Another Vista or WinPhone7 disaster, is what most commentators have been saying.
Recently Microsoft announced it’s ‘Surface’ devices and it’s beginning to look like the real deal. Who would have thought?
Even so, Win8′s Metro/Modern UI has yet to prove itself in the marketplace.
-
“…and also, to be fair, EMB cannot afford to throw a Delphi solution at every hype that blows by.”
That’s so true. I know it’s important to be “early” to establish a foot hold. But, it’s also important not to be “too” early.
-
-
I know this might sound as blasphemy but here it goes:
This might turn to be a GOOD THING overall. Will give people a real reason to turn to VS/.NET and friends to get their Win8 fix. This will give long-time Delphi devs a chance to try new things.
If, sometimes in the future EMBT does come up with a proper WinRT implementation, it will need to win developers by offering REAL advantages.
Milking developers with false promises needs to end and I think this might just be the start of it.
-
This, a thousand times
-
-
I’m not sure at what stage Microsoft actually locked down Windows 8. It might as well have been that in the Microsoft beta cycle, this lockdown has taken place late.
But I do agree that Embarcadero should do better at communication. I know that is hard (not being native English speaking makes it harder, but I’m still learning to improve myself), but it is important to keep trying.
-
So, without going deep into the technicals. What does this mean to app devs? Can EMBT work around this? Is it important at this point when MS tablets don’t have any significant market share?
-
Told people that Prism would be what they expect from Delphi to be when we talk about a comparable alternative to what Delphi had been in the 90s, not knowing about WinRT. Anyway.
It is not clear to me is unless I will have started to hack it, what WinRT is really about. I have the impression a new operating system, ok and WinXX will stay until .. this is the point. I think maybe ‘MS does not know’ too or don’t want to say.
The wording in one of the articles below WinRT is going to replace Win32 – is more at the Box level of Microsoft’s landscape or stack paintings usually subject to change every year . maybe they want to say, what you use Win32 for will very likely be better off on a mobile device on a mid term … technical reality is another one… this sound reasonable.
The question is – is MS interested in other compiler vendors when it comes to native coding … not sure. Somehow this shined through in some articles … but EMB will have to say.
http://blogs.microsoft.co.il/blogs/sasha/archive/2011/09/15/winrt-and-net-in-windows-8.aspx
e will see. Maybe MS simply does not want anyone to develop native on WinRT, because it is maybe to early … or they changed their strategy and this does mean switch to MS if you believe in Apps and the Microsoft Stores … In best case it’s about tablets at the moment … I think.
Found some articles once …
http://www.zdnet.com/blog/microsoft/heres-the-one-microsoft-windows-8-slide-that-everyone-wants-to-redo/10736
It links to many related articles …http://msdn.microsoft.com/en-us/library/windows/apps/br205757.aspx
http://blogs.microsoft.co.il/blogs/sasha/archive/2011/09/15/winrt-and-net-in-windows-8.aspx
Very valuable source inmo
http://blogs.microsoft.co.il/blogs/sasha/Nice game … tw.
http://puzzletouch.com/ -
Allen’s post seems to miss critical information. We know that VC++ team asked WinRT team to make special privileges to certain checked builds of MCVCRT.DLL (i would not believe that i can circumvent the protection just by renaming any my custom library into MSVCRT.DLL). We can expect, that Delphi team could ask the very same thing of WinRT team – make special priveleges for special built and signed rtl17.bpl Well, that maybe would cast aside exception tracers like Eureka/madExcept/Jedi/mORMot/etc – dunno if they’d use RtlUnwind directly, or maybe through some wrapper in RTL. That would make heap managers cast aside – unless rtl17.bpl would provide safe wrappers. But well, the basic Hello World with standard stock rtl would work at least!
So, VC++ team addresses WinRT team, got their guides and rules, adhered to them and got the special privilege for MSVCRT.DLL of interested version.
That also means Delphi team addresses WinRT team, got their guides and rules, adhered to them and got the special privilege for RTL17.BPL for us to use it in XE3. Or not ? Where that chain was broken? Delphi team did not asked for RTL17.BPL special treatment ? Failed to follow WinRT guides ? Did all that but was denied without reason ? What ?Allen does not compare his team actions and VC++ team ones. Maybe he is again disallowed to speak openly and is asked to conceal facts? Then Emb willfully chosen to be blamed instead of MS and why not to blame them like they want!
Or maybe Emb did not asked for RTL17.BPL exceptions, or failed to follow technical guidelines? Then why should anyone blame MS ?
Recently GCC made changes in exceptions handler. It was mentioned in debates of MSYS vs Cygwin. Are they affected by RtlUnwind prohibition ? Either they are not or they do not care.
Other compilers ? Silence.
It looks then like Delphi is the only team that is both concerned and affected. Then did they do anything to make that special treatment they are envy ?
Jeez, why should anyone play guesswork yet again! My coffee cup is empty and washed already. Embarcadero did not told they asked for special treatment of RTL17.BPL, that theoretically could resolve that issue, like MSVCRT.DLL resolved it for VC++. Occam razor tells that means – until more info maybe would be dipped – they just did not ask for it. And now it looks like they blame MS for not getting what they did not ask.
Well, Embarcadero is awfully persistent in rendering itself in bad light.
-
If there are so many restrictions on the WinRT, I can foreseing the innevitable dead of Windows. It’s like shooting your feet, both at the same time.
-
In fact it’s not just MSVC that can do WinRT and be blessed into app store. JS code is allowed and of course .net. So Prism is good to go.
Personally I can’t see Emba getting anywhere with MS on this one. I’d expect it to need a government funded lawsuit to change things. And surely Apple is a more obvious target in the mobile space. MS not a monopoly there!!
-
Um, JS and .NET are what we called ‘managed’. This issue involves what we call UNmanaged.
I can’t believe I had to point that out.
-
I was just correcting the opening sentence of your blog post which is factually incorrect.
I think you know me well enough to know that I am well aware that .net is managed. So, not sure what your point is. Anyway, you now have an opportunity to correct an error.
-
Nit well and truly picked. Thanks.
-
-
-
-
You do look foolish.
… and you should stop posting you don’t cause it only increases that perspective.
It is nice to assume you know everything, but sometimes it may happen (although I’m certain its difficult) that the guys coding the thing know a bit more than you.
-
In this case the alleged “foolishness” stemmed from a claim that I had jumped the gun by blaming Embarcadero for not properly support WinRT. I never made any such complaint. I merely pointed out that the supposed and apparent level of WinRT support was not what was being
misrepresented in the World Tour content or other marketing materials.Namely, that a “Metropolis” app only looked like a WinRT app, but it wasn’t actually a WinRT app.
Which is confirmed very explicitly by Allen’s post. Explain to me where this makes me look foolish ?
-
‘Namely, that a “Metropolis” app only looked like a WinRT app, but it wasn’t actually a WinRT app.’
Funny thing is, EMBT could in principle still sell that in a completely sincere way – ‘turn your existing VCL applications into Metro-style apps that run on all popular versions of Windows’. Perhaps they actually will now, given the cat is out the bag…
-
Gah, just seen Allen Bauer’s reply below! Forget the previous comment…
-
-
-
-
I think you’re overstating the problem. It’s not so much that Delphi could not create WinRT apps, but that MicroSoft will not allow them on their store.
I don’t doubt that in addition, MS is using undocumented APIs for its own code. But that can be overcome.
-
Well then it’s not me that’s overstating the problem, but Allen:
Until we can get past that, targeting WinRT isn’t
actually possible from a deliverable product senseNot my words.
-
Allen Bauer stated it very clearly in his newsgroup post: “Yes. We are very keen on supporting WinRT with native Delphi & C++ code.”
-
And you were very careful, I am sure, to be deliberately unclear when you stated on more than one occasion that R&D “working on” that support.
Begin keen, and working on something is no good if the things standing in your way cannot be resolved by the application of enthusiasm, effort or expertise but depends on some other party who perhaps isn’t keen and isn’t working on solving the problem that needs to be solved.
That is the crucial information that you have withheld.
I understand why you withheld it, but that doesn’t mean I think you should have. As with much else about the way Embarcadero handles it’s communication with their customers, it speaks to a lack of trust and respect that ultimately only ever blows up in your face when the half-truths and deceptions are eventually uncovered.
-
Joylon says – “I understand why you withheld it”. Really? Really Really?
-
Yes, really. You treat your customers like the enemy, so I understand why you do the things you do: Out of fear and distrust.
You don’t trust us to understand that you have problems to deal with that are not always directly under your control, and you fear that if you tell us that we will run away to other tools.
The sad part being that when I talk to other Delphi developers, it isn’t what you deliver – or not – in Delphi (with some exceptions, obviously) that upsets us as much as the way that we feel we are treated. And it is that more than anything else that has us looking at alternatives.
-
-
“when the half-truths and deceptions are eventually uncovered” – half truths and deceptions? Really? I would really love to see you complete list going back to whenever you started with Delphi. That would be cool.
-
Well, since you seem curious, I started with Delphi with the Delphi 1 EEP.
See my response to Allen w.r.t the deceptions that I see in the handling of the XE3 launch. I’m not sure what asking for a lengthy history of any such things is supposed to achieve. I’m not sure that I implied that this was a characteristic of the entire history of Delphi. Far from it.
In fact, in recent years there were reasons to be cheerful.
We got a taste of a bright, diverse future with mobile platforms support in Delphi – only to have that yanked away and siphoned off into a new, separate product.
We even eventually got a roadmap back – but that has since fallen by the wayside, again, without even SOX to hide behind this time.
-
-
We are being deliberately clear about what we’re building and delivering now. What you can do with the product as being delivered is far more important that what you cannot do. Rather than parsing the words and looking for motives which are certainly not there, maybe look at the merits of what we’re delivering.
FTR, we *are* working on WinRT support. I’ve personally spent a large amount of time on it. How many people are working on it, and what state it is in is simply nobody’s business until we have more information to share.
I answered legitimate questions. The facts of the matter haven’t been held-back or buried by any stretch.
-
-
-
-
-
I’m confused. What did Embarcadero do wrong? The fact that we created tools that allow you to use the “Metro” ui style with VCL and Firemonkey apps? What is wrong with that? I don’t think we’ve ever tried to claim that these were “official” WinRT applications. Should we market our product by highlight what we cannot do rather than what we can? I would hope that most folks would rather hear about the former.
The fact of the matter is that even if we could target WinRT, it is likely that the timing between our releases and the Windows 8 release would not match-up very well.
From what I’ve seen, even MS is releasing desktop applications that use the “Metro” UI. The up and coming release of Office is a prime example. I don’t even thing MS is trying to equate the UI style with WinRT. That would be difficult anyway since one form of an official WinRT application is a DirectX based application where the application starts up and gets a DX context and can then do whatever. No XAML or WinRT “controls”.
I merely tried to point out that moving to WinRT will be on the “effort scale” is on par with moving to iOS, MacOS, or Android. It’s not just “translate a few new API headers and write a couple of new components” and bingo, next version. Just setting some expectations.
In the meantime, XE3 will allow you to build and port applications that will run on XP and up with a new, modern look and feel. Additionally, you can also take advantage of some of the new features of Windows 8, such as live-tiles. Why is that so bad for us to give to our customers?
-
There could be some problems, more for you than for us:
1) Windows 8 look an feel has been already delivered from DevEx and the like – so why buy XE3?
2) Companies like mine also use Visual Studio (but for GUI intensive apps), because C++ Builder can’t do yet what VC++ can do, i.e. drivers and 64 bit applications. Also many C/C++ libraries dropped support for C++Builder.
3) And because we also have VS for managed applications we use C# and not Prism.Thereby when faced with the need of building a WinRT applications such a company what would do? Use just a WinRT tile in Delphi, or decide to start that development *without* Delphi? Once we used to buy RAD studio. Then we kept Delphi only because it was still strong to build native client GUI applications, while the other tools looked too poor compared to VS, too many Windows executable types outside their reach.
Now for a while we won’t be able to target WinRT ones, and let’s see what happens if MS tablets gets momentum.
I understand the issues you’re facing – but I do not know how much useful could be a tool that does “less” albeit on many platforms. -
Allen, I think as others – not just I – have said, it’s not so much about what you have done as what you have said (or not said) and the way it has been said.
Above all else, your customers are developers! That means that – with a few exceptions
– we are not stupid, but more importantly it means that what we cannot do with our tools is just as important – if not more so – than what we can. You really should understand that by now.The “Modern UI” styling of the World Tour landing page and the references to Windows 8 support have raised eyebrows in some quarters, not least mine. Upon dissection of the information that initially trickled out, the apparent level of support seemed superficial. In particular the lack of WinRT support and the skirting around the issue when this was raised directly with David I, constantly raising what can be done (Win SDK) and saying that WinRT was being worked on.
That’s fine. But when the problem being worked on cannot be solved by any amount of enthusiasm or effort on your part, and relies on a change in policy or approach by some other party (Microsoft), then I think that is something that should have been mentioned from the outset.
Without that information the impression is very clearly given that it is just a question of time before R&D can deliver. But it is not just a question of time, as we now know.
Overall, the XE3 launch can be characterised in one word: “Deception”
That’s a strong word and it covers a wide gamut in this case, from the trivial and mostly inconsequential “deception” (“New HTML Builder” being a new name and an upgrade to “Rad PHP” [meh]) to the downright scandalous withdrawal of mobile platforms support from the Delphi product line (tho to be fair, the seeds of that deception were sown in the XE2 launch).
At first it seemed like the Windows 8 “deception” was just typical marketing, predictable and understandable “positive spin”, emphasising the capabilities “now” and intimating more in the future. Nothing surprising or unexpected there. The problem is that now the real problems are revealed, so is the true extent of the deception.
You talk about “setting expectations”, and you hit the crux of the problem right there.
Your problem was that your attempt to set expectations came too late and didn’t so much set expectations as crush those that had already been established.
-
I do take great umbrage at the notion of “deception.” That is tantamount to you accusing us of outright lying. While you’re entitled to your opinion, you’re not entitled to your own facts. In this case, the facts are that we’re focusing on what the product can *do*. No amount of parsing and twisting can change the fact that we’re working on selling a product that is soon to be released. I can guarantee that the next product won’t cure cancer, solve world hunger or make you popular with the ladies… so does that mean we’ve deceived our customers? Sure that’s a straw man, but no less that this attempt to ascribe some level of malice of forethought on our part.
-
I did not use the word “lie” because no, you have not lied to us, and as well as the other straw-men that you admit to using here, the accusation that I have accused you you of lying is the biggest one.
Yet another deception, although in this case it’s not entirely clear whether you are attempting to deceive others or just yourself.
-
Verbal virtuosity doesn’t cover the facts here. I took exception with the use of the term “deception”. Please tell me where I said you used the word “lie”? Just because you didn’t use the word “lie” doesn’t diminish the fact that you strongly inferred such. Calling us “deceptive” *is* saying that we’re lying. Its a difference without a distinction. Hiding behind that distinction makes it no less true that you did accuse us of outright deception. Words have meanings and they simply cannot be redefined on the fly by deflecting and twisting.
I thought I could help clarify our position, but clearly that’s not possible when one side is predisposed to assuming malice on the other side’s part.
-
You say on the one hand that didn’t say I said you had lied, then in the next sentence but one you flat out say exactly that:
Calling us “deceptive” *is* saying that we’re lying.
No equivocation, no context. A self-contained statement that contradicts yourself. Unbelievable.
No doubt you are having a hard time of it right now, so some slack has to be given. Too bad that some of that at least is a rod made for your own back. I don’t blame you for trying to deflect, but it is not a good look.
Instead of insulting my intelligence, you might instead like to apply the intelligence I credit you with and know – and I think really you do – that I was saying I never accused you of lying / having lied / told a lie / of being a liar / etc etc. The enquoted word “lie” was quite obviously – imho – a placeholder for all variations of accusation of your having lied. The sort of rebuttal argument that I am getting from you is what I might expect from a 4 year old caught with their hand in the cookie jar, not a “Chief Scientist”
“it’s not a jar it’s a TIN! HA!”. Sheesh.
It is simply undeniable that the statement: “We are working on WinRT support” whilst true in and of itself, fails to include an important fact. An omission that might be accidental on one occasion, but not on the multiple occasions on which it has occurred. David I’s repeated variations on the theme of: “We are keen to support” / “We are working to support” are all so sufficiently similar as to bear all the hallmarks of a carefully chosen form of words, chosen to be truthful just not complete.
At no time did he volunteer the fact that a significant problem you are experiencing is something over which you have no direct control – a crucial piece of information, as the reaction to it has I think demonstrated.
And WHEN that fact FINALLY comes out, as it now has, you cannot then claim purity and virtue and claim that there was never any deception.
For the record: I do not attribute this to malice. Just incompetence. Embarcadero still don’t know how to communicate with their customers.
-
-
-
-
-
@Allen Thanks for taking the time to communicate with us here. I, for one, really appreciate it.
-
-
The David I quotes are pretty bet hedging. I would not regard those as promises, but we’re into nit picking semantics here. As I’ve said, I agree with you that communication is poor and late. But, taking that as given for now, we can’t really cast final judgement until the product is out and the official announcements are made. Albeit in obscure forum posts!
As for the Torre quote, it sounds promising for Emba’s perspective. Reading Allen’s follow-ups in the forum thread, he opines that Win 8 was rushed out and that the devs probably had no time to consider 3rd party tools vendors. Quite plausible. Maybe when the dust settles MS will bless Emba’s runtime.
I think I’m out of touch with Apple. When they banned Flash from app store they restricted to specific languages, C, C++, Obj-C, IIRC. Reading around, that’s clearly been relaxed these days. I still think that Apple are evil though!
FWIW, my bet would be that WinRT remains closed for a long time and only available to MSVC, .net and MS Javascript. I just don’t think they’ll let anyone else have the ability to call VirtualProtect, VirtualAlloc, RtlUnwindEx etc. I predict it will need government lawsuit to change that. And I can’t see that happening. I alsi predict Windows tablets will fail and WinRT dies. I bet Win32 lives longer!
-
Lets be objective about this WinRT thing: You are using Objective-C for iOS/Mac development, right? If you have a commercial product and want to reach mobile market, then I think you will use some other language/compiler/tool to develop to Android, right? And then if Win8 on mobile get some market share, then you will have to use some other language/compiler/tool to develop for WinRT, right? Tell me frankly: In the last 20 years, how many commercial software have you known that are developed using 3 different languages AND compilers? I’m not saying C/C++ on 3 different compilers, but 3 different languages that simply can’t share code base?
Even if you have an Angry birds-type best seller app, how much money is needed to create and maintain an application in 3 different languages?
How many US$0.99 apps sold in Apple store will be rewritten using MS tools?-
Believe me, there are single applications that uses at least three different languages. One of ours uses Delphi, C++ and Python. another Delphi, C++ and C#. Look at Oracle… it uses at least C/C++, Java and Perl.
Anyway WinRT should become of Windows mobile products – if it succeed, you will have to code against it. Sure, you could use something between, but that strictly depends on what kind of application you’re coding.-
Hi Luigi,
Yes, I think there are some. We have one application using 2 different languages but it is not a app store kind of application. It was a requisite of one of our clients. I don’t see many commercial – and os – apps out there using so many different languages. If we have a mobile app for, say, iOS and one of our clients request the same for WinRT, sure we will have to make it, but our client will PAY for it. Thats not a US$0.99 app sold in app store… I don’t see how this kind of app can survive in long term with such high development/maintenance costs.
Best regards
-
-
-
Reading this comment I’m guessing Allen had a very good reason for not shouting this information from the rooftops, quite often it’s better to ask politely and quietly.
I suspect Allen will be even more selective about what he says in the future.
-
I hope not. For my part the issue I have is not with the information itself but the way it had to come out.
As Allen himself said in his original post, it is surprising this hasn’t been more widely discussed. It was a reasonable assumption – in the absence of any information to the contrary (for anyone that was aware of this issue [ftr: I wasn't]) – to think that whatever problems might beset compiler writers other than Microsoft, that Embarcadero were not one of those being held up by this. Especially given the previous publicly stated intention from Microsoft to help in this area. Embarcadero were getting this help, surely ?
(this isn’t what I was thinking – as I said, I wasn’t even aware of this issue, not being a compiler writer myself somehow it passed me by
just speculating as to what people who perhaps were aware might have been thinking)So when Embarcadero said “We’re working on WinRT support“, nobody would have thought: “Oh – of course this means they are rattling cages at Microsoft to try to get a way in to the walled garden that currently prevents them from delivering in this area. Let’s hope Microsoft play nice.“.
People that didn’t know about the problem would have no reason to think this, and people who did know would be thinking that Embarcadero were getting the help that they needed. Otherwise Embarcadero would be saying something, right ?
So I think it’s safe to assume that everyone thought “Well, OK. It’s just a matter of time. Those talented Embarcadero engineers just need a few weeks – worst case a few months – to cut the necessary code and it’ll be sweet.”
You might have thought that Embarcadero would have been more open about it, if only in order to avoid expectations settling at the wrong level. Then again, as is all too painfully obvious, Expectation Management is not a strong suit in Embarcadero’s hand.
Incompetence (in communication/customer relations). Not malice.
The solution to that is not to clam up even tighter, but appropriate communication right from the start.
imho.
-
First up I agree that Embarcadero could improve their overall customer communication.
I think it might be time for you to let this customer communication issue go though Jolyon. I can’t imagine there’s anything left to say that you haven’t said eloquently many times already. To be frank it’s getting a bit dull and I don’t think you’re achieving anything.
https://forums.embarcadero.com/message.jspa?messageID=484644#484644
If I substitute Embarcadero for the 800lb gorilla and you for the little guy Allen’s analogy works just as well for me.
-
Yep. I was just trying to explain how I see the communication issue in the light of this specific incident, as a [pre-emptive] counter to someone suggesting “Well, look at the flak Embarcadero are taking over this. Telling us about it sooner would just have meant taking the flak sooner“, and hence justify keeping things even more secretive and never telling us anything.
Which I don’t think is the case at all.
As for Allen’s analogy, looking at the date and the tone, it looks pretty obviously like a snark @ me and/or (dare I be accused of an inflated sense of self-importance) those making similar complaints. What I find interesting about that, that being the case, is that he sees Embarcadero as the 800lb gorilla who will just walk away.
That again tells me more about the mindset within Embarcadero and their attitude toward their customers than it does about how to complain effectively. They are bigger and tougher than us and don’t need to listen.
So you’re right – until they re-adjust their thinking, it is pointless being critical. Always was. Always will be. They just aren’t interested in listening.
Hence, sadly, there are going to have to be some changes around here very shortly.
-
Allen posted a response in good faith explaining a situation and it has almost been turned into a call for all Delphi developers to invade Microsoft HQ because they are treating our Delphi so badly. Maybe it’s just part of standard business that it takes time, the right people talking to the right people for cooperation to happen. It sounds to me like the R&D has continued while the business side is in discussions.
If you keep poking the 800lb gorilla and you aren’t getting any love in return, maybe you need to take your poking stick to a different zoo. You could always spend the money on Visual Studio instead and see how much love that gorilla gives you.
I think you are mistaking not listening for not doing what you want them to. They obviously listen or you wouldn’t get Malcolm, David I or Allen responding to your blog. Screaming doesn’t make them listen any more than speaking quietly does. Admittedly, it does remind of uni when the entire class was watching a movie and someone yelled from the back “Keep the noise down so I can listen!” and someone from the front yelled back “Listen louder!”.
If it has always been and always will be pointless being critical why do you keep being critical? That suggests you are wasting your time and effort on something you have decided is already pointless so maybe you need to rethink your strategy/approach/etc unless repeatedly doing something pointless is entertaining for you.
-
Allen’s post wasn’t the problem. As you know. It was the fact that this post came after what David I had said.
I’m done poking the gorilla on this one, but as I said – it wasn’t me that described Embarcadero as an 800 lb gorilla, a hardly flattering characterisation, but one that I have a horrible feeling is going to stick.
-
-
Gorillas aside, I don’t think being critical is pointless, I just think you have some unrealistic expectations about the amount of influence you can have over Embarcadero. Just because they don’t follow your advice doesn’t mean they aren’t listening.
I can tell you for a fact that over the years senior Embarcadero people spoken of you quite respectfully with phrases like “keeps us on our toes”. These last few months though I think you’ve just worn people out.
Don’t get me wrong, I’m not asking you to stop being the “critical friend” I just don’t think it all needs to be critical and particularly not the same repeated criticisms. I’m looking down at the tag cloud on your blog now and the topics that most interest me within it are all the ones with the smallest sized font which is a bit of a shame really.
Anyway take from this what you will. I for one hope your tag cloud continues to grow for along time to come.
-
It’s been a disappointing month, that’s for sure.
More positively, I am gradually ramping up to what I hope will be a welcome release of Smoketest, plus some other things that have been bubbling away for some time.
Keep your eye on that tag cloud.
-
-
I can’t imagine Allen thinks very much about you at all in fact. I’d take the comment at face value. The 800lb gorilla is MS. The little guy is Emba. No snark there.
-
Quite possibly, tho since no-one has suggested that Embarcadero have been or should be publicly eviscerating Microsoft on the issue it seemed to me highly likely he was making a snark at those that he sees as engaging in such eviscerations.
You see it different.
Only Allen knows for sure.
I couldn’t care less.
-
-
Back on gorillas
I agree with David Heffernan. Allen was definitely talking about Embarcadero and Microsoft, I’m the only one who said Jolyon was poking the Embarcadero gorilla (this is getting more ridiculous the more I write ).I expect if we really pushed Allen (let’s agree not to) he might agree with me that sometimes he feels like the gorilla.
Suddenly I feel like eating a banana or two
-
Suddenly I’m reminded of the (very) old joke:
– What do you call a gorilla with a banana in each ear ?
– Anything you like, he can’t hear you.
Badoom-tah! Tip your waitress.
-
-
Well who’d have thunk it.
Grumpy old Uncle Jolyon has a sense of humour
-
-
-
-
Lachlan, this is not a bisounours world, and this is a convicted monopolist’s policy we’re talking about. History repeatedly proved that nothing short of public outcry or a big enough legal hammer could affect their decisions.
As for being even more selective, are you suggesting that rather that taking this professionally they should just pout and throw tantrums instead? Informations already comes out in dribs and drabs, in low-visibility locations (JT’s blog, forum posts buried in deep threads, World Tour attendee’s reports, etc.) and is only made visible through the virtues of social networks. I honestly can’t see how they could communicate less or in worse fashions (and I’m not shooting the messengers here, let’s be clear, I’m shooting their communication policy, or lack of thereof)
That information should come out in press releases and announcements, f.i. they should have joined their voice to Mozilla, Google, Opera or Valve on WinRT limitations.
Embarcadero should be actively on the side of their customers, not fighting a pointless war of secrecy against them, with information coming out way too late, when they have their back to the wall, with customers left in thick fog of FUD.
-
For those who are curious about “a bisounours world” google leads me to believe it translates as “a Care Bears world”
Back to the big bad real world…
I’m saying if Embarcadero believe they can achieve a better result by asking politely then that’s what they should do. Why waste time and effort on a huge name and shame campaign if a few emails and phone calls to people you know will achieve the same result.
As for being more selective in the future, I didn’t call for Allen to be more selective I merely predicted it. You can’t deny that Allen must regret making those statements.
-
From my experience, I’m seeing more tantrums than professionalism. I’m not sure how JT’s blog can be deemed low-visibility when it’s on the the main Embarcadero blog and other blogs on the Embarcadero site have also mentioned or linked to it. That’s where I first saw it.
What’s the point of a press release stating that negotiations and communication is ongoing between Embarcadero and Microsoft to resolve the WinRT compiler issue. No amount of emails, tweets, carrier birds, smoke signals, etc are going to change that if I want to know about what is going on, I read the blogs and newsgroups or I trust that internally Embarcadero know how to conduct business when building developer tools.
What I also find frustrating is that when a comment is made as Allen did, there are so many people offering solutions from the outside as if the guys inside Embarcadero haven’t thought of that already.
At what point is suitable for such a message as from Allen deemed appropriate to be officially released – immediately R&D raise it internally or maybe it gets resolved the next day in which case people will start jumping up and down that they were told about something that was only an issue for a day. Maybe internally people have been working on solving the issue and I’m not particularly interested in a time line of what/when/who first identified, tried to solve, etc. the issue. I trust that as part of business, issues/road blocks/problems will come up and my supplier will face them and solve them.
What frustrates me is the assumption that the people at Embarcadero aren’t capable of problem solving, developing solutions, managing a product they build, etc by all those sitting on the outside. It’s easy to jump to conclusions, guess, fantasize, etc when we don’t have all the facts or information.
Embarcadero are in business so I as a customer don’t need to know every single little detail of how they are doing business internally. Just as when I go to a restaurant, I don’t expect a family tree of the chicken that is being cooked for my dinner along with the ingredients and recipe for the meal. I have to have a certain amount of trust and respect that all those involved in the process of making my meal are doing their best and have suitable skills, etc.
-
Nobody is assuming that Embarcadero can’t solve the problem. THe problem is that it’s not just down to Embarcadero’s determination and talents. No matter how determined and/or talented they are, if Microsoft choose not to play ball then it looks to me as if there isn’t even a ball game on this one.
-
I agree in which case I’d like to be told if we get to that nasty point where no solution is available that R&D had the compiler, etc ready to go but unfortunately due to Microsoft not playing ball, we will be unable to support WinRT. Until then, I’m happy to sit in my little uninformed seat.
-
But that is exactly where we are right now!
-
-
are we ?
DCC and RTL “as they are” are surely banned from the AppStore. But that is the only 100% fact.
We were told that it works okay on devel boxes with self-signed certificates. At least that mode they can provide, cannot they? For corporate environments where AppStore does not matter and self-signing would be okay for IT dept.
While it looks ugly tricks, it could be at least possible to show.Then there is VCL/FMX/WinForms/HTML+JS or some other GUI.
Compiler aside, is Delphi ready for RAD WinRT-compliant GUI design including Contracts and all that OO interop? I don’t know but expect it is not yet.Do you really believe that if MS give rtl17.bpl special mode tomorrow, then at XE3 release you’d be ready to make WinRT 1st-class applications ?
You’re are not.You put the line between “question of time” and “question of time and good will by MS”. But anyway it is still “question of time”. And that means R&D did not done everything they could yet.
Another question whether they should do anything before resolving RTL issue. But they clearly not yet “did all they should and could” to be on WinRT train.
-
I said it’s not just a question of time. Sure there may be some more polishing needed but there is no point putting the effort into that polishing if the App Store Validation issue is intractable. Arguably R&D should not be wasting their time if there is no reasonable expectation that the aspects of the problem that are beyond their control will not be addressed.
I am also not sure that deployment without the App Store is at all practical. Being able to install and run an app on one or a handful of devices for testing and debugging is one thing, being able to roll out an app across a fleet of enterprise devices, without using the app store, would be something else. I think.
-
-
i totally agree with the 1st point, but totally disagree with the 2nd one
however for us both that is just speculations
-
-
“I’m not sure how JT’s blog can be deemed low-visibility when it’s on the main Embarcadero blog and other blogs”
*Rolls eyes* That’s not high visibility, blogs are informal and don’t engage anyone but the reader.
How many people do you think that blog reaches? 1500 visitors? 2000 visitors? unless the Delphi users are several orders of magnitude less numerous than what Embarcadero claims, that kind of audience is nothing.
And JT’s post f;i. remains a technical post, obvioulsy quickly written, which outside of social networking links would have a searchability about nil (and will be almost nil in a few months when the social networks will have moved further along).
Allen’s post was buried deep in a thread with an unrelated title, that’s even lower visibility.
“as if the guys inside Embarcadero haven’t thought of that already.”
Oh that argument again? it’s a bit long in the tooth.
We got it for years: Borland knew better, Inprise knew better, Borland knew better (again), CodeGear knew better, Embarcadero knows better… yet each and *every* single time, it came they did NOT knew better.
What makes you think this time would be different? We only have undelivered functionality and an informal “promise” of a beta…
In the case of WinRT, thinking of it and being able to do something about it are two very different things. Even if there are nice, motivated and knowledgeable people at EMB talking to other nice people or even friends at MSFT, doesn’t mean they’ll be able to achieve more than sunday barbecue parties (good for them though).
It certainly didn’t help the product in the early Delphi days (when they were complaining about the bundling the VB & VC vs Delphi dlls), in the D.Net days (they were complaining about MS not having opened the CF.Net winforms designer outside of VS), and for WinRT, the initial start doesn’t look exactly promising at the moment.
>when I go to a restaurant, I don’t expect a family tree of the
>chicken that is being cooked for my dinner along [...]The exact recipe probably not, but you’re entitled to get a list of all ingredients if you ask (for allergies, etc.), and even if you don’t ask, you certainly expect the chicken was raised properly, not fed garbage, and prepared with good hygiene practices, that the kitchen is regularly cleaned, etc. and if it isn’t, then I don’t expect you take it lightly (ofttimes in more ways than one, if you get my meaning).
Case in point, maybe that’s because we do software that is used in the food industry here, so I’m aware of all the tracking requirements, but I expect any restaurant or industrial food processing facility to be able to provide all the above data on rather short notice, at least at their own level (when was the chicken bought? where? when wqs it cooked? who did the cooking? heck, who plucked its feathers is a question that can be asked) – and when they realise they can’t, it’s when they come buy our software
-
If a Delphi user isn’t visiting the Embarcadero blogs then that is not my problem. You managed to see the article just as I did so that visibility seems to be enough for those interested in being informed. People have to take responsibility for keeping themselves informed through the various options available and for me that includes blogs, newsgroups, etc.
I’m not disputing that errors have been made in the past but it seems easy for so many people to sit on the outside and be experts. If they are such experts, why aren’t they building compilers, IDEs, plugins for the IDE instead? It seems to me that a small but very loud bunch of “experts” exist that are always offering advice but haven’t actually backed it up with experience, expertise, etc. Just because most developers are intelligent doesn’t mean they are smart.
I’m sure as hell not going to give you advice on building software for the food industry as I have no experience or direct knowledge of the particular requirements in that industry. I’m sure in your job, you provide your users with details of every little internal process, challenge, defect, etc that you face every day through bulk emails, website notices and maybe blog articles and I’m sure they love receiving all that information.
-
You don’t need to be an expert in building IDE’s and compilers to be able to appreciate that the customer experience of different companies that ARE experts in these areas is very, very different, and to be able to decide which is the most effective and most enjoyable.
The mindset at Embarcadero is so closed and controlling that they simply don’t seem to be able to get their heads around the idea that anybody would dare compare them to someone else, let alone take a look around and take a critical look at themselves. They don’t take criticism from anybody, so it is little wonder that they can’t bring themselves to apply it to themselves.
-
-
-
-
-
-
Jolyon, I trust that you love the attention you are getting lately (:
(WinRT != Win8) => different OS, as a different OS, Embarcadero can choose to target it or not.
As for Microsoft and apple, IMHO, they should be allowed to lock down(legally) their OS, after all, it’s their IP, not mine, not yours, THEIRS!
-
I can’t say that I do. Apart from anything else, I’m watching my data traffic usage like a hawk as I’m running close to what my hosting plan allows and could end up having to pay over-charges.
80 MB (of 6 GB) has to last me the final 6 days of the month ! ! ! :S
-
You’d end with optimized blog, split to tiny static and dynamic files, heavily using json instead of page re-loading, etc
-
-
-
OK DavidI, I understand the problem with WinRT support.
But roll out your IOS and Android Support ASAP.
And you better do it right this time!
Clients don’t want to give expensive IPads and IPhones to the employees when cheap Android Tablets and Phones are everywhere in the market.
Same goes with WinRT Tablets as with IPads.Android support is very important!
-
+1
I Agree at 100%. Native support for Android is fundamental!
Best Regards
-
-
Do you know what is funny?
WINRT and Windows 8 support was never planned for XE3, and 60 days before the announcement they decide to create this Windows 8 support ( AKA fake Metro UI). Don’t blame Microsoft because of their momentary strategy to lock WINRT.
What’s happening in XE3 and past releases are basically because of the horrible management in Embarcadero, a lot things change since Borland, but Borland people remain here and some of them unfortunately came back.
-
That means Metropolies will have a lot bugs, as usual!?
I assume it was just added to create a bigger elephant poop.
#7 Eat like a bird, poop like an elephant.Hopefully they will change there strategy, and return to quality instead of poops.
-
-
The major reason they don’t inform customer about future, only update roadmap when you guys start complaining all over the place, it’s because they never know what will be delivered in advanced.
Comments are now closed.
Loading ...
DelphiFeeds
94 comments