Similar, but with IBM Websphere MQ.

Why a message queueing technology is branded under 'Websphere' I have nooo idea, but it turned out to be a nightmare of various configurations jammed together and not working well.

Tibco Enterprise Messaging (EMS) on the other hand is a dream to work with IME.

MQ was MQ series before the WebSphere rebrand. The rebranding happened because IBM is managed by silly people.

I dunno, if you look at the incredible hoops the iMessage exploit had to go through in order to work, then there must be a point where the effort involved in finding new exploits would far outweigh the benefits ... assuming Apple is actively finding and closing current exploits and not introducing new software that just increases the attack surface area.

Roughly speaking it worked by hijacking preinstalled apps (calendar, mail, etc) and privilege escalation, to create a new account.

The Apples preinstalled apps, and default behavior meant the attackers could rely on certain behavior once they were in.

Apples standardization is what got them.

My preference is never to use _com_ptr_t et al. (instead CComPtr for a nicer RAII) since they throw exceptions, and almost none of the developers I worked with expected that, so lots of unhandled exceptions at runtime was the result.

One of the best things about the COM (previously OLE) API was actually HRESULTS, so I always encouraged their use, and IErrorInfo wherever possible.

>The performance of COM is incredible. Agreed, the performance of COM is pretty good in-process, and can even be extended to allow other applications to script your objects (via the IDispatch interface). So it's a pretty versatile technology, but it seems to be yesterdays' news after .net came out.

To experience DCOM in your windows box now is pretty easy. Simply: Start -> Run -> 'mmc'

File -> Add Remove Snapin

Add 'component Services'

And enjoy the spinning COM+ balls to see running COM servers.

It's all still there.

And speaking of RPC and COM+ ...

Here's what I believe inspired a lot of what's in DCOM and COM+ (formally MTS)

https://developer.apple.com/documentation/foundation/nsdista...

It was an amazing technical achievement that they pulled off, but also a lot of work instantly destroyed with one patch.

Somebody's day got ruined when that was discovered.

And kudos to the Google project zero guys for an amazing writeup.

Nobody's day is ruined; they'd certainly have multiple zero-click zero-days in the backburner.

Exploited even whilst attempting to report an exploit.

Poetry indeed.

>Picking any language that embraces bounds checking enabled by default, and proper string/arrays, is already a major improvement.

Even bog standard C can be made safe, and include bounds checking if you create and consistently use an API that supports that mindset - see for e.g. Microsoft's string safe lib (not that I'm saying that is the epitome of such a thing).

However the will and the effort has to be there, C is an incredibly flexible and capable language and can be as safe as you want it to be.

The last Random ascii article I read, he found an easily exploitable buffer overflow in iOS simply by checking the code to see where it used memmove and worked out the exploit from there, guessing correctly that there was no bounds checking. So it seems that the usual culprits are fairly easy to spot, but somebody needs to replace the worst APIs with something safer (memmove, memcpy, memset, malloc, a = b).

Any "safe" string library for C that uses pointer and length as separate arguments is safe only in name.

Microsoft does it, because it comes along with SAL[0], which is kind of Microsoft's own Frama-C.

Also as long as WG14 doesn't care, everyone will keep passing char* around while hoping it is actually null terminated and points to the right place in memory.

Technically, ISO C could get safer types, or have something like SAL/FORTIFY, but as you say, without will it will never happen.

[0] - https://docs.microsoft.com/en-us/cpp/code-quality/using-sal-...

I always wondered the same thing.

For a while the 680x0 in Macs, Amiga and Atari was the most popular CPU, and I'm sure the first HPUX workstation I used in my Uni. had a 68040 so even in Unix and NeXT workstations.

But after the 68040 it never seemed to evolve into anything else, and probably got subsumed by the Power line of CPUs into oblivion.

And it has a fantastic assembly language to boot.

>I’m only aware of tea and silkworms..

And er... china. That stuff you make nice cups and saucers from.