There is great progress with DDL.

Tom S figured out, how to make it possible to load D classes transparently.
http://h3.team0xf.com/ddlDWT.7z

The problem of what to link against, is solved by having a loader application (Host.exe). This loades the DWT.lib and the application (also as a lib)

This is a proof of concept. It is not ready for practical use.

host.exe : 1.3  Mb
app.lib  : 0.16 Mb (Texteditor example)
dwt.lib  : 6.6  Mb

the host.exe can be either always the same and start the application passed as a commandline arg, or the host can be compiled with the application imported via import("app.lib").

I am looking forward to see this in a stable framework with integration into the D toolchain. Hopefully some day with linux support also.

Thank you Tom, for this nice demonstration

Frank

Perhaps a little background info might be useful. Frank had a few rather tricky requirements:

1. There is a large library which should be shared across applications
2. There are plugins to the library
3. Applications must be able to derive classes from the ones in plugins
4. Plugin implementations may be changed post-deployment. In other words, the app may not know the source or binary code of the plugins in advance.

1. itself is a tough issue on Windows, as DLLs are not D - friendly.
2, 3, and 4 mean that the application has classes whose code parts are not known until the plugins are loaded. While it might be solved with some fancy design patterns, it would be nice if the setup worked out of the box without any hacking around.

But how can we have an executable that derives from classes whose implementation is not known - it's in .di files? As far as I know, one can't have incomplete executables on Windows or Linux. (executables with unresolved symbols).

Here's where DDL steps in. There are perhaps more solutions, but we've employed a version where there's a 'host' executable that loads the application, the lib (and potentially the plugins) dynamically. The host links them all together using DDL and then starts the app. As a result, we only have one executable (and as Frank said, it can be shared across apps) and lots of libs that are loaded thru DDL. As libs may be incomplete, all problems are solved right away.


-- 
Tomasz Stachowiak
http://h3.team0xf.com/
h3/h3r3tic on #D freenode

Hello Tom,

> Perhaps a little background info might be useful. Frank had a few
> rather tricky requirements:
> 
> 1. There is a large library which should be shared across applications
> 2. There are plugins to the library
> 3. Applications must be able to derive classes from the ones in
> plugins
> 4. Plugin implementations may be changed post-deployment. In other
> words, the app may not know the source or binary code of the plugins
> in
> advance.
> 1. itself is a tough issue on Windows, as DLLs are not D - friendly.
> 2, 3, and 4 mean that the application has classes whose code parts are
> not known until the plugins are loaded. While it might be solved with
> some fancy design patterns, it would be nice if the setup worked out
> of
> the box without any hacking around.
> But how can we have an executable that derives from classes whose
> implementation is not known - it's in .di files? As far as I know, one
> can't have incomplete executables on Windows or Linux. (executables
> with unresolved symbols).
> 
> Here's where DDL steps in. There are perhaps more solutions, but we've
> employed a version where there's a 'host' executable that loads the
> application, the lib (and potentially the plugins) dynamically. The
> host links them all together using DDL and then starts the app. As a
> result, we only have one executable (and as Frank said, it can be
> shared across apps) and lots of libs that are loaded thru DDL. As libs
> may be incomplete, all problems are solved right away.
> 


This is great news!  Tom and Frank, thanks for experimenting with this.

I'm looking forward to seeing this option applied creatively to dwt projects (and other D projects).  I can see that this sort of plugin architecture could prove quite useful for larger dwt apps like poseidon or even application "systems" like eclipse (no D equivalent yet).  This may not necessarily be useful for small dwt apps, but I'm sure there are a host of opportunities for creative use.  Perhaps from OS kernels to high-level plugin systems.

Great work!

-JJR

The last time I did that was one year ago with DWT-Shawn and DDL was loading DWT terribly slow (like 10 seconds on a fast pc). So it was not usable at all. Is this still the case?

Frank Benoit Wrote:

> There is great progress with DDL.
> 
> Tom S figured out, how to make it possible to load D classes transparently. http://h3.team0xf.com/ddlDWT.7z
> 
> The problem of what to link against, is solved by having a loader application (Host.exe). This loades the DWT.lib and the application (also as a lib)
> 
> This is a proof of concept. It is not ready for practical use.
> 
> host.exe : 1.3  Mb
> app.lib  : 0.16 Mb (Texteditor example)
> dwt.lib  : 6.6  Mb
> 
> the host.exe can be either always the same and start the application passed as a commandline arg, or the host can be compiled with the application imported via import("app.lib").
> 
> I am looking forward to see this in a stable framework with integration into the D toolchain. Hopefully some day with linux support also.
> 
> Thank you Tom, for this nice demonstration
> 
> Frank

Hello bobef,

> The last time I did that was one year ago with DWT-Shawn and DDL was
> loading DWT terribly slow (like 10 seconds on a fast pc). So it was
> not usable at all. Is this still the case?
> 

Looks like this has been done a couple of times before, but not necessarily with DWT.  Kris submitted the first idea to use the host app about 2 years ago; the tool is in ddl svn.  I guess the method didn't catch on... perhaps because of load times as you mention, although it's a clever idea. :)

I haven't been able to test the example yet, so I don't know about load times. Frank? Tom?

-JJR

John Reimer wrote:
> Hello bobef,
> 
>> The last time I did that was one year ago with DWT-Shawn and DDL was
>> loading DWT terribly slow (like 10 seconds on a fast pc). So it was
>> not usable at all. Is this still the case?
>>
> 
> Looks like this has been done a couple of times before, but not necessarily with DWT.  Kris submitted the first idea to use the host app about 2 years ago; the tool is in ddl svn.  I guess the method didn't catch on... perhaps because of load times as you mention, although it's a clever idea. :)
> 
> I haven't been able to test the example yet, so I don't know about load times. Frank? Tom?

When first running the app, all deps are loaded, parsed and linked within about 3-4 sec on my laptop with centrino 1.7. When running it again and the libs are cached by the OS, it's about 1-2 seconds. This includes loading tango-base, tango-user, a dozen of winapi libs, the app and the dwt lib.
I'm planning to optimize the omf backend in ddl more, so these numbers can be expected to shrink :)


-- 
Tomasz Stachowiak
http://h3.team0xf.com/
h3/h3r3tic on #D freenode