Re: More Windows stuff ... Gorm works ... sort of

[Gregory John Casamento]

Lars,

--- Lars Sonchocky-Helldorf <address@hidden> wrote:
> 
> Am Dienstag, 22.03.05 um 16:50 Uhr schrieb Nicola Pero:
> >
> > The other obvious reasons is that building the palettes depends on
> > building Gorm.app (to resolve the symbols), and building Gorm.app 
> > depends
> > on building the palettes (to copy them into the Gorm.app bundle), so 
> > you
> > get into a nasty building organization as you have now
> 
> This is called a circular dependency which you have to avoid in 
> software design. The Solution here is using the dependency inversion 
> principle: 
> http://www.google.com/search?hl=en&lr=&q=dependency+inversion+principle 
> . And it's always a good idea to have a read on software design 
> patterns.

This is not a matter of lower level objects depending on higher ones which
depend on the lower level objects again. :)   No such problem exists in Gorm's
code.

Basically, the problem is that the palettes include symbols which are defined
in the app.  The main Gorm application does not depend on any classes defined
in the palettes whatsoever.  On systems other than Windows (read any modern
UNIX implementation which uses ELF) this is perfectly acceptable and uses
something called "weak symbols". 

The idea of weak symbols is that some of the symbols in a bundle are resolved
at runtime rather than compile time.  Since Windows utilizes COFF, it has
rather primitive support for this which makes building apps which expect this
more difficult to build.

> regards, Lars

Nicola suggested some reorganization of Gorm sources and I am considering some
changes.  I believe, however, that, since weak symbols are not supported well
under Windows, that this will be a problem for other apps.

Later, GJC

Gregory John Casamento 
-- CEO/President Open Logic Corp. (A MD Corp.)
## Maintainer of Gorm (IB Equiv.) for GNUstep.