gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Alex Perez
Subject: Re: More Windows stuff ... Gorm works ... sort of
Date: Tue, 22 Mar 2005 16:22:29 -0800
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)

Gregory John Casamento wrote:
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.

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

[snip]

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.

Shouldn't those editors be in a separate library? It seems proper, at least when examined superficially.


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.

Is that really necessary? What would be the benefit? 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)



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

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.


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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]