SDK evolution

Have a question about our Software Developer Kit? Ask them here.

Re: SDK evolution

Postby Thomas Frieden » Tue Jul 26, 2011 3:18 pm

JosDuchIt wrote:I rechecked now: -lauto is not mentioned but obviously works end is helpfull in the porting from OS3 to OS4.
It would be good that the gcc --help mentions it.

-lauto is not a command line obtion, actually... -l is, and that's documented. All -lauto does is to link with libauto.a

JosDuchIt wrote:So
a) "-lauto" can still be used as an option and calls for libauto
b) can also be called with -mcrt=libauto ? (tested different forms libauto.a auto, auto.a : all "invalid C runtime libraries)

-mcrt just selects the C library, and with that the paths it uses for searching for libraries and header files. -lauto is "just" another link library, nothing else.

JosDuchIt wrote:
- i am preparing to improve the Gui4CLi source again, which is using quite a lot of libraries.
Having had good but ill digested advice this source now compiles for OS4 (but for warnings) and i did not touch for more than 2 years.
My opening and closing of libraries certainly is a mess, but i always compiled using -lauto. The OS4 SDK's gcc never complained about this.

Then I suggest you keep linking with -lauto. There's no reason why this wouldn't work.

JosDuchIt wrote:
To get closer contact again with C-programming i am first trying to compile short examples and am struggling with -lauto __USE_INLINE__ , __USE_BASETYPE__, or just plain OS4 code

__USE_INLINE__ works nicely
__USE_BASETYPE__ is more obscure to me and gives me redefinition errors even in simple code. A good explanation of what it does would probably help.

__USE_BASETYPE__ is not really obscure. In the OS4 headers, we opted to define libraries as opaque, i.e. everything is simply a struct Library *, even libraries that were traditionally "typed". A good example is intuition.library. You used to refer to it as struct IntuitionBase *. While this still works, the default behavior is not to refer to it as struct Library *. This makes code more robust in the sense that it will catch access to the library base that is always prone to problems and should be avoided.

if you define __USE_BASETYPE__, the headers will revert back to OS3 style, i.e. if you include proto/intuition.h, it will define IntuitionBase as struct IntuitionBase * again instead of defining it as a struct Library *

JosDuchIt wrote:
I just now tried to compile Gui4Cli source without -lauto and i get a lot of undefined references.

Checking for their origin i see that i did open the corresponding libraries, i did define the interface pointers eg
struct GfxIFace *IGfx
but did not use a corresponding GetInterface() call.

For code that should remain backwards compatible, I would actually suggest to still use libauto...

JosDuchIt wrote:
So why is that not important anymore on AOS4 ?

It's not only a matter of choice. ixemul.library was, by all accounts, ugly. It messed directly with stack frames and did all sort of evil things to keep things like vfork working. For that reason, all attempts to port ixemul.library to OS4 have been abandoned.

Instead, work went into two other projects: newlib and clib2. newlib is shared and part of the system, and pretty efficient, but lacks some features. clib2 had some initial problems, but has a lot of features that ixemul had (minus vfork).

Actually, the whole ixemul/vfork usefulness was, IMHO, always overrated. In the end, there are very few instances where fork could be replaced with vfork, and you had to be very careful about using features not directly related to ixemul when using vfork. Most instances where fork could be replaced with vfork where the usual fork/execve pairs (i.e. you fork a new process and immediately replace it's process image by a new one). But these instances can be replaced by AmigaOS specific code easily, without the usual CF that is involved with vfork.

So yes, ixemul.library mostly allowed configure/make/make install ports, but with a bit of extra work, these can be done with clib2 or newlib, too.
User avatar
Thomas Frieden
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 147
Joined: Fri Dec 10, 2010 4:21 pm

Re: SDK evolution

Postby trixie » Wed Jul 27, 2011 11:36 am


trixie wrote:As there are apparently more people puzzled by the present situation, I'm going to write an article that will summarize the currently recommended practices related to the creation of ReAction GUIs under OS4.x. Stay tuned :-)

And here's the article, enjoy! ... rogramming
Smoke me a kipper, I'll be back for breakfast!

AmigaOne X5000 @ 2GHz / 4GB RAM / Radeon RX 560 / ESI Juli@ / AmigaOS 4.1 Final Edition
SAM440ep-flex @ 667MHz / 1GB RAM / Radeon 9250 / AmigaOS 4.1 Final Edition
User avatar
Posts: 395
Joined: Thu Jun 30, 2011 3:54 pm
Location: Czech Republic

Re: SDK evolution

Postby Hans-Joerg Frieden » Wed Jul 27, 2011 1:22 pm

trixie wrote:@JosDuchIt

trixie wrote:As there are apparently more people puzzled by the present situation, I'm going to write an article that will summarize the currently recommended practices related to the creation of ReAction GUIs under OS4.x. Stay tuned :-)

And here's the article, enjoy! ... rogramming

Very good article. Thanks for posting the link :)
NOTICE: If you want to contact me, use E-Mail. I cannot be contacted via the forum/private messages anymore
User avatar
Hans-Joerg Frieden
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 223
Joined: Wed Dec 08, 2010 4:52 pm

Re: SDK evolution

Postby JosDuchIt » Wed Jul 27, 2011 1:26 pm

Thanks @ all

I'm going to write an article that will summarize the currently recommended practices related to the creation of ReAction GUIs under OS4.x. Stay tuned

Looking forward for it

It is unclear whether absolute gadget size and dimensions can be specified at all for ReAction gadgets that are not in a layout. They are BOOPSI so theoretically that could be possible (the standard Intuition BOOPSI classes work without a layouting system). The thing is, why would you want to? Considering today's configurability of the OS4 appearance - the different fonts, themes, user-defined GUI element shape and size - how would you be able to ensure a usable GUI without an automatic layouting system?

I just want to add new gadget types to Gui4Cli, especially a listview with possibility for the user to change the visible part of fields (field sizes). I am looking more closely to GadTools, Boopsi classes or Reaction, but surely not to the point i can tell how this can be done.

Gui4Cli is conceaved to allow drag & drop of gadgets in the same window or between windows.
I don't use this feature very much, using my own gui4cli application in which i can define matrixes of gadgets and add them to the script(gui) i am working on. Thinking of it, i never checked if drag&drop still works under OS4. Making a gui with my gadget-matrix generator is a matter of seconds.
(Gui4CLI is the ideal bottom up, early prototyping language to me)
Gui4Cli also allows to add "absolute" simple graphics (lines, ellipse,..) to the window background (not working yet under OS4) which would marry les well i think with relatively positioned gadgets. Maybe not such a big problem.

Rewriting Gui4CLi such that it uses automatic layout change seems not impossible: instead of having the script defining absolute position eg
xBUTTON L T W H "title"
One could define its matrix position
xBUTTON Row Column "title"

That would probably be a major overhaul of the source. I am not sure if i could manage that.
Abyway there are other improvements that i want to implement first.
Cleaning up the code (includes, deprecated & obsolete's) first.
Posts: 291
Joined: Sun Jun 26, 2011 6:47 pm


Return to SDK Support

Who is online

Users browsing this forum: No registered users and 1 guest