A newbie approach to C and AmigaOS 4.x: First encounters

12 posts / 0 new

Last post

Sat, 2011-02-12 20:54

cha05e90

Offline

Last seen: 4 years 5 months ago

Joined: 2011-02-07 20:22

A newbie approach to C and AmigaOS 4.x: First encounters

Hi everybody! THE PLAN After fiddling around with coloured tiny pictures the last year I thought it might be nice and new challenge to get the grips on coding with and for OS4. As I consider myself as a bloody newbie there are at least three big obstacles that I have to conquer on my way to ultimate fame: - learnig C (again)*, - knowing the Amiga API (more then now and more about 4.x)**, - understanding the SDK/IDE/GCC stuff.*** THE EQUIPMENT Residing on my hard disks are - the latest OS4 SDK, - Simon's Codebench, - Dietmar's Cubic IDE - already hacked to use the latest SDK (maybe I will some day do a full enviroment for the latest SDK like I did already for Modula-2), - the full Amiga_Developer_CD_v2.1 copied to hard disk for quick access, - some docs and tutorials from here and there. THE FIRST PROJECT I'm not good with learning something only from theory and/or RTFM - I need something I can bite into. So I decided to download Dave Norris' sources for "AISSView" (OS4Depot). It is a program that didn't work with my OS4.1 setup for some time now (I already know why ;-)), I would like to use it and I have some ideas how to improve it. Further I already found some bugs (or I should say "programming quirks") in the source, which I would like to fix/overhaul. Further it features: DOS operations, GUI stuff, user interactions, Tooltypes etc. and comes in nicely separated source and header files. THE FIRST STEP(S) My first aim is to make a clean compile of the source code - I would like to see how to build an executable. I am rather sure that Dave used an older SDK, so I would not be surprised, if something might *not* work. I will compare the original binary and it's functions to the new compile - and hope, they will work the same. So here's my first question: THE FIRST OBSTACLE The compile of Dave's source did *not* work. This is what the build process said:

SDK:gcc/bin/gcc -c main.c -o main.o  -lraauto -lauto
In file included from main.c:9:
viewer.h:71: error: 'select' redeclared as different kind of symbol
/SDK/newlib/include/sys/select.h:84: error: previous declaration of 'select' was here
make: *** [main.o] Error 1

Yes, "select" is declared as bool in viewer.h. But why is that obscure "select.h" from the newlib includes playing a role here? I suppose it must have been "sub included" by something else. If I *errm* manipulate the "sys/select.h" the source happily compiles to an executable - but this is of course no solution. What did I wrong? Compiler switches? Wrong includes? Where did I say to use newlib? Who did include that "select.h"? What did Dave what I didn't? I hope somebody might give me a clue how to solve this - and be prepared, it won't be my last question! ;-) Regards, Frank * I did my last sporadic C codes roughly 10-15 years ago - basically command line tools for Linux and some MS-DOS (really!) - never used this on Amiga (read: more than "HelloWorld"). ** I have *some* very, very basic knowledge about the Amiga API - so building up structures for windows, scanning through Autodocs hunting for the right Tags etc. is something I did in the past. But nothing a real Amiga coder would assume as sufficient. *** Yes, I used GCC already - in the stone age. So I don't know anything about the newer incarnations and especially nothing about any special switches for our enviroment.

Sat, 2011-02-12 22:34

Rigo

Offline

Last seen: 9 months 3 weeks ago

Joined: 2011-01-24 21:55

The clib code is linked into

The clib code is linked into the binary by specifying either -mcrt=clib2 or -mcrt=newlib for either clib2 (static) or newlib.library (dynamic) respectively. Your "interaction" with the newlib includes is because -mcrt=newlib is the default, and is enabled unless -nostdlib or -mcrt=clib2 is supplied as a linker switch. You will probably find that the program relies on some clib code being present, and my suggestion would be to simply rename the variable so it doesn't clash with the one defined in sys/select.h. Simon

Sun, 2011-02-13 12:11

(Reply to #2) #3

cha05e90

Offline

Last seen: 4 years 5 months ago

Joined: 2011-02-07 20:22

Thanks for that hint. I

Thanks for that hint. I *suppose* Dave linked against clib2 - so after introducing -mcrt=clib2 everything compiles just nice AND some really heavy errors/crashes doesn't occur anymore. Up to now my executable seems to work identically to the original binary. So I will go on with my inverstigations using clib2. Some day I should learn the differences between newlib and clib2 - there must be some heavy changes in whatever. There seems to be stuff in the AISSview source, that doesn't work with newlib...

X1000|II/G4|440ep|2000/060|2000/040|1000

Sun, 2011-03-06 20:13

cha05e90

Offline

Last seen: 4 years 5 months ago

Joined: 2011-02-07 20:22

Here we go again: While

Here we go again: While re-working some of the AISSview code tried to implement some string handling which converts upper/lower case mixtures to pure lower case strings. While scanning through possible functions I'll first used the standard C function tolower() [I had to #include ctype.h for this). Some time later I found that there's a utility.library function named ToLower(). What puzzle me as a newbie is my confusion about what to #include for this. After some research I found that:

#include <inline/utility.h>
...
for (icount = 0; buffer[icount]; icount++)
{
buffer[icount] = ToLower(buffer[icount]);
}

and this - using IUtility interface - works as well:

#include <utility/utility.h>
...
for (icount = 0; buffer[icount]; icount++)
{
buffer[icount] = IUtility->ToLower(buffer[icount]);
}

Using the SDK browser searching for "utility.h" shows some more hits (i.e. inline4/utility.h"). Very confusing. 1. Up to now I can't see a functional difference between the two shown examples and don't understand why there are two different includes necessary. 2. Is there a rule which include I have to use with certain [type of] function calls? I.e. "normal" vs. "IFace"?

X1000|II/G4|440ep|2000/060|2000/040|1000

Sun, 2011-03-13 10:30

cha05e90

Offline

Last seen: 4 years 5 months ago

Joined: 2011-02-07 20:22

*bump* Any idea where to

*bump* Any idea where to look for "which-include-when-to-use" information? (see question 2 ave) Still working with some kind of trial-and-error approach in this regards, which isn't that sophisticated... :-)

X1000|II/G4|440ep|2000/060|2000/040|1000

Fri, 2011-03-18 14:03

(Reply to #5) #6

djrikki

Offline

Last seen: 1 year 11 months ago

Joined: 2011-01-14 23:02

"Any idea where to look for

"Any idea where to look for "which-include-when-to-use" information?" Probably a question I'll be asking myself over the next few months when my SAM 460ex arrives next week.

AmigaOS.net - Discover Amiga, Discover AmigaOS.net Jack for AmigaOS Samba Idiot's Guide

Fri, 2011-03-18 21:07

kas1e

Offline

Last seen: 5 months 2 days ago

Joined: 2010-11-30 15:30

@cha05e90 Quote: 1. Up to

@cha05e90

1. Up to now I can't see a functional difference between the two shown examples and don't understand why there are two different includes necessary.

Its just same in end, you just do some "hard work" which will be done for you if you will use #include <proto/blalba.h> and __USE_INLINE__ (see next answer for details).

2. Is there a rule which include I have to use with certain [type of] function calls? I.e. "normal" vs. "IFace"?

If you want to use "normal" functions (without worring about IFace), then just follow to that 2 rulz for all the time: 1. always use __USE_INLINE__ I.e. it can be in source code itself: #define __USE_INLINE__ 1 or , in the command line strings (which is a bit better imho , because only makefile/compile line need to change): gcc balbalablabl -D__USE_INLINE__ blablalb 2. Use all the time where it possible #include <proto/blabla.h> No clib2/ anymore, nothing like this. Just all the time "proto", and if only you not have some defines or tags, then, include need it one (like for example for cybergraphics, or for some dos types). By this way, only one time when IFace still need it, it when you open library. I.e. you still do plain OpenLibrary call, but later, use GetInterface for IFaceBase stuff. And by this way, everything will be the same as you code on os3, just with new functions. All the ports from os3 code will works fine like this. New programms also will works fine which done in this way as well.

Sat, 2011-03-19 10:38

(Reply to #7) #8

cha05e90

Offline

Last seen: 4 years 5 months ago

Joined: 2011-02-07 20:22

@kas1e Ah - thanks for your

@kas1e Ah - thanks for your explanations. This shed some light into the dark corners of my head... ;-) Interesting thought about OS3.x "backwards compiling compability" - I haven't thought about this up to now. While it isn't really appropiate for the current project (AISSview) it might be handy to know about this concept for future activities. Or it seems to be the way to use already existing OS3.x sources for OS4.x migration/compilation.

X1000|II/G4|440ep|2000/060|2000/040|1000

Sun, 2011-03-27 13:12

(Reply to #8) #9

cha05e90

Offline

Last seen: 4 years 5 months ago

Joined: 2011-02-07 20:22

Another newbie question:

Another newbie question: http://utilitybase.com/forum/index.php?action=vthread&forum=2&topic=2237#msg18486

X1000|II/G4|440ep|2000/060|2000/040|1000

Wed, 2011-03-30 23:16

#10

Rigo

Offline

Last seen: 9 months 3 weeks ago

Joined: 2011-01-24 21:55

With the current crop of

With the current crop of malware disrupting utilitybase, you might be better off pasting the message here rather than linking to it. Simon

Thu, 2011-03-31 09:00

(Reply to #10) #11

cha05e90

Offline

Last seen: 4 years 5 months ago

Joined: 2011-02-07 20:22

Oops, I haven't noticed that

Oops, I haven't noticed that problem until I used my work place Windows PC... sometimes it seems to be an advantage to use malware-ignorant browsers like OWB or Netsurf...

X1000|II/G4|440ep|2000/060|2000/040|1000

Sun, 2011-04-17 00:26

(Reply to #11) #12

cha05e90

Offline

Last seen: 4 years 5 months ago

Joined: 2011-02-07 20:22

Ok, my first steps into

Ok, my first steps into programming with C in an AmigaOS environment are done - an updated version of Dave Norris' AISSview is in the upload queue of OS4Depot. I must admit, that it's not that easy for a newbie like me to get the grips with the AmigaOS4.1 API, especially the differences to the more or less comprehensive documented OS3.x. Nevertheless it's fun and there's still soooo much to learn - including basic C voodoo. There's a lot of ideas I'll like to test and implement into AISSview - all further dumb or not so dumb questions will come up here (or some other atm defunct place) as single problem posts. Thanks to all who helped/assisted/hinted so far!

X1000|II/G4|440ep|2000/060|2000/040|1000

Search form

User login