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

[Gregory John Casamento]

Alex,

--- Alex Perez <address@hidden> wrote:

> Gregory John Casamento wrote:
> > Nicola,
> > 
> > --- Nicola Pero <address@hidden> wrote:
<snip>
> > Support for weak symbols are hardly advanced, they have been a feature of
> ELF
> > since it's creation.  As I pointed out before, it's Window's use of the
> rather
> > ancient COFF standard which is the real problem.
> 
> Actually, Windows uses PE-COFF, which is still fraught with plenty of 
> COFFish limitations, but it's extended enough that weak link support 
> itself is actually supported by the spec. This is the support for which 
> Aaron LaWhatsHisName has recently implemented in GCC and binutils.

I couldn't remember which version of COFF it was, XCOFF or PE-COFF.  PE-COFF it
is.
 
> > I don't believe that we should be forced to change the architecture of
> GNUstep
> > or any of its core components to conform to the lowest common denominator.
> 
> Nor do I. It's also worth pointing out that very few modern OS' are 
> COFF-derived. Keep reading...

Yes, I know. :)

<snip>
> > 
> > Some of the palettes use editors which are available in the app.  This
> change
> > was done by Pierre a while back. 
> 
> Shouldn't those editors be in a separate library? It seems proper, at 
> least when examined superficially.

Good point.  I have considered doing this.

<snip> 
> Is that really necessary? What would be the benefit? 

I would consider it cleaner to put things which are Gorm-specific into another
library.

> I don't think 
> there's anything wrong with having non-appleornext stuff in GormLib...as 
> you said, this is already the case, anyways (or perhaps Apple changed this)

Already the case?  No, it's not.  You seem to have misunderstood me somewhere
along the line.  There is very little in GormLib which is Gorm-specific.
Although I'm not ruling out the possibility, I would prefer to keep it that way
rather than put things into it which really aren't part of the InterfaceBuilder
framework.  It should probably be called libInterfaceBuilder.so or
InterfaceBuilder.framework instead of GormLib. :)
 
<snip> 
> Heh, this conversation is even more apropos and relevant within the 
> context of the ultra-modularisation thread that we recently had on the 
> etoile-dev mailing list. I think extreme modularity is good, as long as 
> it's done properly. Anything feature of Gorm that could concievably be 
> used by another app should probably be in a library, if you adhere to 
> the mantra we had discussed.

I would tend to agree, but I wasn't part of that conversation. :)

> >>Then palettes could use the Gorm library headers and link against the Gorm
> >>library (including custom palettes, which could do the same); and once
> >>shared libraries (and loadabale bundles) work on a platform, everything
> >>would just build and work.
> >>
> >>Anyway, I appreciate all your points etc, I just think it's a shame it
> >>took so long to get Gorm working and it might have been so much easier if
> >>the building process had been more standard, so I'm trying to suggest
> >>possible ideas to make it more standard. :-)
> > 
> > 
> > The building process *was* standard for most UNIX systems.  As I have said
> > previously and I will say it again: Windows is the odd man out here.  It is
> > more difficult to build on Windows because of it's use of COFF and its
> > relatively primative support for shared libraries when compared to most ELF
> > based systems, which includes basically all modern versions of UNIX.
> 
> It's not as primitive as one might suspect; It's just that the GNU 
> toolchain never took proper advantage of PE-COFF's abilities until just now.

We'll see what can be done once the version which supports this is released. 
In the meantime I intend to look into how things can be improved, in general.

Later, GJC

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