OCTAGRAM

Microsoft were never supposed to work on this. Windows as we know it, is produced by division of labour. Intel defines binary object formats: first OMF, then PE. Microsoft writes kernel. Borland provides development tools, and now it's Embarcadero who is in charge for Windows development. Sometimes Microsoft managed to accelerate progress by kicking Borland. Microsoft made UTF-16 the only encoding in COM, and reference counting as the main memory management policy. Without that kick Borland was not...

AFAIK DCE had no reference counting. So Microsoft could possibly also maintain compatibility with something, this time DCE, and build trash that nobody likes after all, and nobody cares about DCE compatibility after all. I think, another more serious reason for ugly SOM without RC was C++ D2SOM. I was wondering why IBM didn't provide rich frameworks based on SOM. I install VisualAge for C++ 3.5.9 on Windows. D2SOM is not abandoned yet in this version (it will happen in 3.6). SOM is the way to go....

Simplicity is: Forgetting SOMEF ever existed Extending SOM.IR to contain explicit types, comments and passthru Wielding SOM compiler with extended IR emitter and pretending it was always united like this Rewriting other emitters to work with extended IR

I forgot one more thing. Why does it fail with SOMEF as is. Emitter receives just a single class definition. Even if you force SC to see all the forward definitions, emitter won't receive them. Won't be able to perform topological sort and other nontrivial actions like copy-pasting parent class methods into current bindings.

Indeed, they fail. But what do you propose instead? Imagine you have an empty SOM.IR database. It's the very first invocation of ir emitter, and some forward definition remains unsatisfied. I can gather a self-sufficient database and produce a good looking bindings. I mostly agree, but there are still some options to choose from. I can reject incomplete databases. I can map to SOMObject. I can map to SOMObject descendant without any additional methods, but that will make it incompatible with random...

Then how ir emitter is supposed to work? It does exactly this. Adds references to unknown classes. Then, hopefully, during some next ir emitter invocation reference will be resolved. This is not strong typed approach. I don't like it. Duty of the developer. In vanilla SOM.IR there were 2 or 3 class references remaining unresolved. I can consider it to be a bug, but to make things work I have mapped them to SOMObject. SOM revolves around DLL which cannot have circular loops. So those DLL shall have...

On my two ex-jobs and on my current job we use semi-COM to bridge Delphi. Different Delphi versions or independent RTLs. This semi-COM does not require registration. Semi-COM objects are obtained via DLL function. Developers just know that they must: Use WideString for all strings Use safecall for all methods Don't use closures Only reference to semi-COM and COM interfaces Either avoid changing interfaces or implement versioning Delphi safecall acts as exception firewall. It converts Result into...

Indeed, I would drop that CORBA trash. And memory management was a garbage. Not hopeless, but if we make something sensible, then old code won't fit. SOM is similar to Objective-C, but as you may see, Objective-C managed to polish its shortcomings. Objective-C did not have reference counting. It has got manual reference counting. Then some compilers implemented automatic reference counting. The same could be done to SOM, to some degree (not sure what to do with sequences and unions). It all can be...