Thanks for the info.

Gary

"Walter" <walter@digitalmars.com> wrote in message news:b466p8$2hi9$1@digitaldaemon.com...
>
> "Patrick Down" <Patrick_member@pathlink.com> wrote in message news:b457to$1t6v$1@digitaldaemon.com...
> >
> > Actually gdi32.lib has little actual code in it.  It just provides symbolic linkage to the DLL.  Also you probably need to look a the space a simple hello world takes up, some people remark that the D runtime is a little large.  It's all a trade off.  Most runtimes don't have a GC in them.
>
> The gc adds some code (maybe 40k). A big chunk comes, however, from all
the
> unit tests in phobos.lib. Those should be removed from a release build, it is built now with all the debug checks and unit tests on.
>
>

Hi,

In article <b466p8$2hi9$1@digitaldaemon.com>, Walter says...
>The gc adds some code (maybe 40k). A big chunk comes, however, from all the unit tests in phobos.lib. Those should be removed from a release build, it is built now with all the debug checks and unit tests on.

If I try to make an optimized version of phobos.lib I get the message:

Error: don't know how to make 'gc2\dmgc.lib'

I have changed this two lines in the makefile from

CFLAGS=-g -mn -6 -r
DFLAGS=-unittest -g

to

CFLAGS=-mn -6 -o -r
DFLAGS=-release -inline -O

but I think that is not the problem ...

Gerd

I generally do not like the 'standard library as dll' approach because it leads inevitably to 'dll hell'. I prefer to make self contained executables that are not going to randomly crash because it got hooked up to some obsolete dll.

You need to go into phobos/gc2 to build dmgc.lib. -Walter

"Gerd Schmidt" <Gerd_member@pathlink.com> wrote in message news:b4772d$1d3$1@digitaldaemon.com...
> Hi,
>
> In article <b466p8$2hi9$1@digitaldaemon.com>, Walter says...
> >The gc adds some code (maybe 40k). A big chunk comes, however, from all
the
> >unit tests in phobos.lib. Those should be removed from a release build,
it
> >is built now with all the debug checks and unit tests on.
>
> If I try to make an optimized version of phobos.lib I get the message:
>
> Error: don't know how to make 'gc2\dmgc.lib'
>
> I have changed this two lines in the makefile from
>
> CFLAGS=-g -mn -6 -r
> DFLAGS=-unittest -g
>
> to
>
> CFLAGS=-mn -6 -o -r
> DFLAGS=-release -inline -O
>
> but I think that is not the problem ...
>
> Gerd
>
>

"Walter" <walter@digitalmars.com> wrote in message news:b49cc3$1ajv$1@digitaldaemon.com...
> I generally do not like the 'standard library as dll' approach because it leads inevitably to 'dll hell'. I prefer to make self contained
executables
> that are not going to randomly crash because it got hooked up to some obsolete dll.

it would be nice to have the option to chose static gc+phobos or dynamic.

while phobos, and D are developing then yes, std libs in a dll will be a nightmare, but once they are stable then as long as the dll name changes when API's change things are not too bad (MFC is fine as a dll now).

it would also be good to have a D dll (as opposed to a C dll) which allow D classes to be dynamically (in a dll not a Java sense) loaded. (perhaps a COM interface ICollect used to pass the GC to the dll on load via a D dll entry point, call LoadDLibrary, does LoadLibrary, then attaches the GC, then gets the class info's (should contain constuctors, static methods [static methods of dll loaded classes similar to delphi class virtual methods i.e. call via class info] as well as vtbl) )

choices that would be good.

app + gc(dll) + phobos(dll) + [ownlib( dll )]
app(gc) + phobos(dll)  + [ownlib( dll )]
app(phobos) + gc(dll) + [ownlib( dll )]
all statically linked.

when building a dll that contained a template, you would have to declare which instances it included.

I didn't mean "making it standard", but rather "making it posible".

Consider: someone wants to write a whole office suit in D. Take a look at some working office suit: OpenOffice for example. It is 70 Megs of object code, almost everything of it are DLLs which are simply all placed in the installation directory. This approach makes sense, because:
 - the suit of applications uses lots of common code -> distibution size is saved;
 - one can assume that often multiple applications are loaded simultanously -> memory is conserved;
 - the application loads features as soon as it needs them, making start-up times short.

If someone were out to write an OS in D, he would be even more grateful.

One could make it a standard feature to be able to compile sets of modules to DLLs. They could then be loaded statically *or* dynamically. I'm not exactly sure wether it's a bit slower since all access would be indirect (is it with static DLL binding? i don't know). The advantage is, that at application startup the library is represented with a set of uninitialised references. An acess to which would cause the library to load. Is this possible?

I assume it is with functions - simply the references need to be initialised to a loader function, written in assembly. I don't know whether there is a similar way for variables and constants. Possibly throught exception handling? If not, shared variables and constants can still be placed into the main application, and the library would have to "import" them from it at startup. Another solution is that the main application would wrap itself with checks, which IMO exception handling is intended to eliminate need for. Or this approach applied only to variables, and constants get always linked into the application?

Walter wrote:
> I generally do not like the 'standard library as dll' approach because it
> leads inevitably to 'dll hell'. I prefer to make self contained executables
> that are not going to randomly crash because it got hooked up to some
> obsolete dll.

I agree that there are times and places for DLLs. D can both become a DLL and call DLL's.