August 18, 2012
On 2012-08-18 14:52, Michel Fortin wrote:

> Using a lookup table it could be done.
>
> But if you're going to patch the code as a dynamic linker does but after
> the dynamic linking stage, then you'll have to play around with
> no-execute flags as well as address layout randomization, and this is
> going to be ugly.

These are usually not pretty things :)

> Speaking of OS X, if your app is sandboxed I think it won't be able to
> do anything like that. Given that sandboxing is the beginning of a trend
> on many platforms, I'm not sure implementing all that would be
> worthwhile: all it'd accomplish is make processes that can't be
> sandboxed run a little faster.

Yeah, that could be a problem.

-- 
/Jacob Carlborg
August 18, 2012
On Saturday, 18 August 2012 at 12:45:19 UTC, Michel Fortin wrote:
> On 2012-08-18 05:29:18 +0000, "Paulo Pinto" <pjmlp@progtools.org> said:
>
>> Wouldn't DLL redirection with Toolhelp32 help here?
>
> No idea what toolhelp32 is.

It is a debugging library introduced in the Win16 days, the 32
suffix is the Win32 version.

I remember reading articles in DDJ about using it to modify DDLs
function entries.

--
Paulo
August 20, 2012
On Thursday, 16 August 2012 at 20:19:27 UTC, R Grocott wrote:
> That sounds clean in theory - but so does Pimpl, and I know from experience that Pimpl tends to make a horrible mess out of any codebase. It doesn't help that, as far as I know, COM is Windows-only, and D doesn't natively support the method-defaulting system you described.
>
> In practice, I think that proper interoperability w/r/t classes and inheritance will tend be cleaner than coding strictly against an interface. This can be demonstrated by choosing any base-class derived-class pair, from any OO codebase, and attempting to rewrite that parent-child relationship as a server-client one.

What you ask for sounds quite similar to COM composition with delegation.
If the problem is just fields and vtable shifts, D interfaces should work too. Though there's no easy way for composition and delegation with interfaces in D AFAIK. This already led to the null_t hack, but the problem wasn't really solved.
August 20, 2012
On Monday, 20 August 2012 at 15:26:48 UTC, Kagamin wrote:
> What you ask for sounds quite similar to COM composition with delegation.

Would anybody mind linking to resources which describe COM composition with delegation? It's been suggested twice in this thread as an alternative way to develop a non-fragile API, but anything related to COM is almost invisible to search engines (even moreso than D itself).
August 20, 2012
On 2012-08-16 17:54, Piotr Szturmaj wrote:
> Kagamin wrote:
>> You can also use C++ to develop COM components which have standardized
>> ABI.
>
> ...only on Windows.

What about XPCOM?

http://en.wikipedia.org/wiki/XPCOM

-- 
/Jacob Carlborg
August 21, 2012
On Monday, 20 August 2012 at 18:37:00 UTC, R Grocott wrote:
> On Monday, 20 August 2012 at 15:26:48 UTC, Kagamin wrote:
>> What you ask for sounds quite similar to COM composition with delegation.
>
> Would anybody mind linking to resources which describe COM composition with delegation? It's been suggested twice in this thread as an alternative way to develop a non-fragile API, but anything related to COM is almost invisible to search engines (even moreso than D itself).

You just need to know Windows development well, as this type of information requires MSDN navigation skills. :)

The best book about COM programming that I know is,
The Waite Group's COM/DCOM Primer Plus
http://www.amazon.com/DCOM-Primer-Plus-Waite-Group/dp/0672314924/ref=sr_1_cc_1?s=aps&ie=UTF8&qid=1345529642&sr=1-1-catcorr

Back to how composition works,
http://msdn.microsoft.com/en-us/library/ms678443%28v=vs.85%29
http://msdn.microsoft.com/en-us/library/ms686558%28v=vs.85%29

With ATL the code gets much more simple to get,
http://support.microsoft.com/kb/173823

Another example from CodeGuru,
http://www.codeguru.com/cpp/com-tech/atl/article.php/c3579/Containment-and-Aggregation.htm
--
Paulo
August 21, 2012
On Monday, 20 August 2012 at 18:37:00 UTC, R Grocott wrote:
> On Monday, 20 August 2012 at 15:26:48 UTC, Kagamin wrote:
>> What you ask for sounds quite similar to COM composition with delegation.
>
> Would anybody mind linking to resources which describe COM composition with delegation? It's been suggested twice in this thread as an alternative way to develop a non-fragile API, but anything related to COM is almost invisible to search engines (even moreso than D itself).

class MyButton: IButton
{
  IButton impl;
  void text(string t) @property // void IButton.text(string)
  {
    impl.text=t;
  }
  // ... other IButton methods
}

slightly similar to what emplace does
August 21, 2012
On Saturday, 18 August 2012 at 20:36:11 UTC, Ivan Trombley wrote:
> On Thursday, 16 August 2012 at 15:54:12 UTC, Piotr Szturmaj wrote:
>> Kagamin wrote:
>>> You can also use C++ to develop COM components which have standardized ABI.
>>
>> ...only on Windows.
>
> Code compiled with VC has a different vtable layout than code compiled with say GCC, so even on Windows there is no standard.

You're probably talking about C++ ABI in context of multiple and virtual inheritance. I doubt gcc can't into COM. Even dmd backend can.
August 21, 2012
On Monday, 20 August 2012 at 18:37:00 UTC, R Grocott wrote:
> On Monday, 20 August 2012 at 15:26:48 UTC, Kagamin wrote:
>> What you ask for sounds quite similar to COM composition with delegation.
>
> Would anybody mind linking to resources which describe COM composition with delegation? It's been suggested twice in this thread as an alternative way to develop a non-fragile API, but anything related to COM is almost invisible to search engines (even moreso than D itself).

There's nothing novel about COM except aggregation, and aggregation is just an implementation detail where a class pretends that it implements an interface but the calls to that interface go to another object, conceptually it's like "alias this" except that a dynamic cast (i.e. QueryInterface) is required to reach the second object:

http://msdn.microsoft.com/en-us/library/ms686558(v=vs.85)

For the most part COM sucks really bad: it is a very ordinary object-oriented ABI but without numerous features that we otherwise take for granted:

- In COM, you can't define static methods
- In COM, you can't overload functions
- In COM, constructors can't have arguments
- In COM, there are no fields, only properties
- In COM, class inheritance is not allowed (an interface IB can inherit from IA, but if you implement a class A that implements IA, you can't write a class B that derives from A and implements IB. In C++/ATL a template-based workaround is possible if A and B are in the same DLL.)

Moreover COM ABIs are fragile, in that there is almost zero support for adding or removing methods without either breaking everything or creating a new, independent, incompatible version (the only exception: you can safely add a method at the end of an interface, if you can be certain that no other interface inherits from it.)

Finally, it's Windows-only (although it has been reimplemented on Linux, e.g. for WINE) and modules must be registered in the Windows Registry.

I think the only reason we still use COM today is that, sadly, there is no other OO standard interoperable with all languages. C++ vtables are the closest competitor; I guess their fatal flaw is that there is no standard for memory management across C++ DLLs.
August 21, 2012
On Tuesday, 21 August 2012 at 15:15:02 UTC, David Piepgrass wrote:
> On Monday, 20 August 2012 at 18:37:00 UTC, R Grocott wrote:
>> On Monday, 20 August 2012 at 15:26:48 UTC, Kagamin wrote:
>>> What you ask for sounds quite similar to COM composition with delegation.
>>
>> Would anybody mind linking to resources which describe COM composition with delegation? It's been suggested twice in this thread as an alternative way to develop a non-fragile API, but anything related to COM is almost invisible to search engines (even moreso than D itself).
>
> There's nothing novel about COM except aggregation, and aggregation is just an implementation detail where a class pretends that it implements an interface but the calls to that interface go to another object, conceptually it's like "alias this" except that a dynamic cast (i.e. QueryInterface) is required to reach the second object:
>
> http://msdn.microsoft.com/en-us/library/ms686558(v=vs.85)
>
> For the most part COM sucks really bad: it is a very ordinary object-oriented ABI but without numerous features that we otherwise take for granted:
>
> - In COM, you can't define static methods
> - In COM, you can't overload functions
> - In COM, constructors can't have arguments
> - In COM, there are no fields, only properties
> - In COM, class inheritance is not allowed (an interface IB can inherit from IA, but if you implement a class A that implements IA, you can't write a class B that derives from A and implements IB. In C++/ATL a template-based workaround is possible if A and B are in the same DLL.)
>
> Moreover COM ABIs are fragile, in that there is almost zero support for adding or removing methods without either breaking everything or creating a new, independent, incompatible version (the only exception: you can safely add a method at the end of an interface, if you can be certain that no other interface inherits from it.)
>
> Finally, it's Windows-only (although it has been reimplemented on Linux, e.g. for WINE) and modules must be registered in the Windows Registry.
>
> I think the only reason we still use COM today is that, sadly, there is no other OO standard interoperable with all languages. C++ vtables are the closest competitor; I guess their fatal flaw is that there is no standard for memory management across C++ DLLs.

Even .NET with his goal of supporting multiple languages has the
CLS as the common set of datatypes and OO concepts to support across .NET
languages.

Given that OO has so many types of possible implementations, it is
hard to implement an ABI that works across multiple languages.

Lets see how the improved COM (WinRT) turns out to be.

--
Paulo