In my project I make use of a handful of external libraries in the
form of DLL's.

While the problem of binding to the functions contained in these DLL's
is more or less solved - apart from the need to sometimes go through
laborious trial-and-error in the creation of bindings due to mangled
function names and mixed C and PASCAL calling conventions... - there
remains the problem of external resources that the libraries create.
Usually this is in the form of an internal object in system memory
that is used to manipulate an image or a font, for example. Generally
it isn't possible to get complete control over these objects; usually
all you are allowed to manipulate is a handle.

When a program is compiled, one likes to be able to load things at
compile-time, before you even execute the app-starter word. However
two problems are created:

"roger.levy@gmail.com" gmail.com> writes Re: Here's an interesting design problem on the use of external libraries
[..]

[..]

Please explain, *why* do you want to do this? Is this process so very
time consuming? Modern Forths compile with blinding speed.

I can imagine. If the system makes it difficult to use previous
state, it probably doesn't want you to do that.

What's so awkward or slow about this? And why use a TURNKEY (the worst
of both worlds) at all?

It's a subtle problem. I'll try to clear some things up.

First I'm making games. Thought it was known by now because I have a
game library in alpha. Just to keep it in mind.

Because it takes less code.

Would you rather say: (and this is VERY psuedo-code)

: IMAGE ( z$ -- ) CREATE loadImage, does> @ ;

z" image.bmp" IMAGE myImage

or

0 VALUE myImage
...
: loadimage z$ loadImage TO myImage ... ;

It's a subtle problem. I'll try to clear some things up.

First I'm making games. Thought it was known by now because I have a
game library in alpha. Just to keep it in mind.

Because it takes less code.

Would you rather say: (and this is VERY psuedo-code)

: IMAGE ( z$ -- ) CREATE loadImage, does> @ ;

z" image.bmp" IMAGE myImage

or

0 VALUE myImage
...
: loadimage z$ loadImage TO myImage ... ;

"roger.levy@gmail.com" gmail.com> writes Re: Here's an interesting design problem on the use of external libraries
[..]

I also have problems I'd rather not talk about, but I don't post descriptions
of them at clf :-)

The sample is rather small to draw such a conclusion.

The fact that I ask questions you may perceive as rude does not mean
that I am criticizing you. I am honestly struggling to understand where
the problem is, and what the advantage of your startup-chain idea is.

-marcel

marcel: why are you trying to pick a fight with me?

oh, i guess you're better than me, my mistake.

ok, so you don't get it. not my problem. some people ask questions
and try to be constructive, others say inflamatory & immature things
like "why in the world would you..." or "don't take offense, but you
seem to be an idiot!"

guess it takes all kinds!

someone delete this thread ... what a waste.

On Mon, 11 Aug 2008 15:22:15 -0700 (PDT), "roger.levy@gmail.com"
gmail.com> wrote:

Try rephrasing the question. I, for one, did not reply because I
couldn't see the wood for trees. We've implemented C library
interfaces on several systems.

I rather suspect that you are confusing time frames - an easy
thing to do in Forth.

Stephen

Ok, one last shot.

Though I actually don't plan on replacing it. I think it's fine as it
is after all.

Here's the source code and comment:

{ =====================================================================
Externals

These words provide a general mechanism for restoring external state
at run time.
They are useful for restoring bitmaps, samples, display lists, etc
They work by registering "externals", or objects that require
creation handled by an external library.

The "output" for each external is a single value, usually a handle,
it depends on the library.

Each external is passed a single parameter, which it should use up.
It must return a value to compile into the structure.
At runtime, this is stored into the next cell.

One more thing!

I lump all kinds of external data structures, like display lists,
samples and fonts, all together. But only OpenGL stuff needs to be
restored on a video mode switch, not samples, fonts and others. So
I probably need to factor out my externals to support more than a
single list and only execute the OpenGL externals when I switch
modes. Otherwise memory fills up with duplicates.

Put simply, the point was to avoid the need to create pointers and
initialize them by hand in some kind of init routine. Or coming up
with a unique system for each library. EXTERNALS can handle them all.