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

[Gregory John Casamento]

Nicola,

--- Nicola Pero <address@hidden> wrote:

> 
> > > Btw, I think you both missed my point ;-)
> > > 
> > > .... if an application is built using "simple" / "standard" mechanisms
> > > (like: building a shared library, building a bundle, linking an object
> > > file to a shared library) then porting to new platforms will be easier,
> > > because once those "standard" mechanisms are implemented, your
> application
> > > will be automatically ported.  Linking a loadable bundle against an
> > > application is always going to be implemented *after* linking a loadable
> > > bundle against a library.  So if you depend on support for linking
> against
> > > a library (rather than on linking against an application), the stuff is
> > > more easily portable.
> > 
> > You are correct ... I did miss that point.

I didn't miss that point.  My counter point to this is that you shouldn't have
to create a library since it should work on windows just as it does on all of
the other operating systems currently supported by GNUstep.  Please keep
reading..
 
> > But I think that linking against the application is of the essence of a
> > bundle, so while it may be harder to port, it is necessary.
> 
> I agree with you that this might be nice and useful to have ... :-)

Yes it would be.

> > From the point of view of a developer using GNUstep (rather than someone
> > maintaining/writing the gnustep core) the correct behavior of bundles is
> > something that should just be assumed.  In other words, I don't think this
> > is an issue that Gregory should need to consider in his design, rather it's
> > an issue that we need to resolve in make/base so that he and others like
> > him can work productively.
> 
> ... but I still think that assuming advanced building features in "core"  
> components is not a good idea.  Gorm is a "core" component and it would be
> nice if it was very portable and worked almost automatically as soon as
> the very basic stuff is ported to a platform.

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.

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.

> GNUstep was ported to Windows years ago, yet it took ages for Gorm to work
> on Windows just because of this 'linking bundles to the application'
> issue.

Windows hasn't been priority until recently. :)  Also, the bundles don't "link
to the application" they merely require symbols from the application.  I would
expect to see a lot more of this as the number of applications for GNUstep
grows.   Do you propose that we put a FAQ in someplace telling people that they
can't use this feature, which is available on every ELF based system out there,
simply because Windows can't handle it?

> I'd definitely suggest choosing a building strategy which works out of the
> box using just the basic building blocks (libraries, apps, linking to
> libraries, loadable bundles).
> 
> 
> 
> > > Finally I don't understand why those palettes are loadable palettes at
> all
> > > (and are not just linked directly into Gorm) if they access Gorm
> internals
> > > directly so heavily ... why don't you link them directly into Gorm ?
> > > Then building Gorm on a platform would only depend on shared libraries
> and
> > > applications, and would be really easy to port ...
> > 
> > I don't know the current design ... but I can answer from a historical
> > perspective.
> > When I wrote the standard palettes, they used only the public API to access
> > Gorm and didn't depend on special access to the internals (I don't know if
> > that's still the case).  They were written as palettes precisely so that I
> > could test that palette loading worked and that the public API from Gorm
> > worked to let people write their own palettes.

Some of the palettes use editors which are available in the app.  This change
was done by Pierre a while back. 

> I'm not sure what the public API from Gorm is, if there is one, I think
> it's supposed to be GormLib, so palettes could just link against GormLib
> and access that public API, but when I mentioned that Gregory said the
> standard palettes need to access some more complicated Gorm internals
> directly and that GormLib is supposed to be a clone of some other Apple
> framework, so I don't know what public API Gorm has got or if it has got
> one ... if Gorm has got a public API I suppose that should go in public
> headers ...

Not just any "other apple framework" but the acknowledged public API of the
InterfaceBuilder.app.  The InterfaceBuilder framework was on OPENSTEP and is on
MOSX.   

I pulled all of the code which Richard is referring to into GormLib to be the
InterfaceBuilder library and also added missing methods and the classes which
were necessary to complete it.   The way it originally was, you couldn't really
add palettes which were external to the app since there was no "public" library
to link against.   Additionally those classes, such as IBPalette, IBInspector,
etc were in the app, so you had much the situation you have now.

If Gorm is reorganized, the internals (outside of what is defined by Apple to
be in the InterfaceBuilder framwowke) should be put into another library, not
GormLib.   

> ... and now IMO this is just the core of the issue ... if Gorm has got a
> public API with headers and symbols you access and need to link to, it
> should be turned into a library ... that's how you normally read headers
> and link to on most platforms.
> 
> If that means most of Gorm ends up in a library, I don't see what's wrong
> with that, you could have most of it in a library, and the Gorm.app
> application could just be a 'main' routine linked to the library and
> starting the code up.

I'm not sure I like this idea.  It seems wrong to put the entire app into a
library when linking like this should work in the first place.

> 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.

> I think I proposed enough variants so I'll drop off at this point ...  
> ;-)

And as I said before, your ideas will be considered. 
 
> Thanks

Regards, GJC

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