mermelstein%tel.inrs.cdn@relay.ubc.ca (lois mermelstein) (11/28/88)
Help -- I'm having serious trouble opening the intuition.library (so I can
open windows onto Workbench, etc.)
I'm using code like:
struct IntuitionBase *IntuitionBase;
#define INTUITION_REV /*either 33, 0, 33L, or 0L */
main()
{
IntuitionBase = (struct IntuitionBase *)OpenLibrary("intuition.library",
INTUITION_REV);
if (IntuitionBase == NULL)
{ printf("Couldn't open lib.\n");
exit()
}
When the constant INUITION_REV is set to 33 or 0, I simply get "Couldn't open
lib." from the printf. When I set it to 33L or 0L, I get "software error --
task held", with a guru number of "#0000000A.00C [plus some other numbers].
I'm using Manx 3.6A with the default c.lib (16 bit ints) on a 2-floppy
B2000 that's completely vanilla (nothing else running, nothing bizarre
in the startup-sequence).
I've also tried variations on this code from books like Mortimore's
Amiga Programmer's Handbook and some examples I have from Rob Peck's book --
results are no better.
Any ideas? Any help would be mucho appreciated.
Lois Mermelstein
mermelstein@tel.inrs.cdndillon@POSTGRES.BERKELEY.EDU (Matt Dillon) (11/28/88)
mermelstein%tel.inrs.cdn@relay.ubc.ca (lois mermelstein) Writes: :IntuitionBase = (struct IntuitionBase *)OpenLibrary("intuition.library", : INTUITION_REV); :When the constant INUITION_REV is set to 33 or 0, I simply get "Couldn't open :lib." from the printf. When I set it to 33L or 0L, I get "software error -- :task held", with a guru number of "#0000000A.00C [plus some other numbers]. : :I'm using Manx 3.6A with the default c.lib (16 bit ints) on a 2-floppy :B2000 that's completely vanilla (nothing else running, nothing bizarre :in the startup-sequence). This is a standard mistake when using 16 bit integers. OpenLibrary() returns a pointer, what you have above is OpenLibrary() returning an integer and then casting it to a pointer ... which doesn't work well since pointers are 32 bits and integers are 16 bits. What you want to do is DECLARE OpenLibrary() as returning a pointer: extern char *OpenLibrary(); I.E, *ANY* kind of pointer. Doesn't make sense to declare it to return a struct IntuitionBase * since OpenLibrary() does other things, so you still need the cast as you have it but now, at least, it is converting a pointer to another pointer rather than an int to a pointer. :#define INTUITION_REV /*either 33, 0, 33L, or 0L */ Same problem .. I believe Aztec expects a long, so 33L or 0L. .. passing just an int (33, 0) would be incorrect. This is one of the many reasons I use +L (32 bit ints). Everybody says it makes for slower code and larger binaries. I have found that the code speed is more related to programmer experience rather than the size of ints, and although the binaries are larger for +L they aren't *that* much larger. Other people say that my reasons are silly because then I write incorrect code. I say they are silly because you can write incorrect code easily no matter what sized ints you use and my way saves me hours of worry... again, a matter relating to experience, NOT 16/32 bit ints. >Lois Mermelstein -Matt
bryce@cbmvax.UUCP (Bryce Nesbitt) (11/28/88)
In article <5679@louie.udel.EDU> (lois mermelstein) writes: > >IntuitionBase = (struct IntuitionBase *)OpenLibrary("intuition.library", > INTUITION_REV); > >I'm using Manx 3.6A with the default c.lib (16 bit ints) Whenever you use Manx in 16 bit, have a... #include "functions.h" ...line! Unless the function are declared as returning pointers, Manx treats them as returning ints (16 bits). For the OpenLibrary case, the required declaration would be: struct Library *OpenLibrary();
kkaempf@rmi.UUCP (Klaus Kaempf) (11/28/88)
In article <5679@louie.udel.EDU> mermelstein%tel.inrs.cdn@relay.ubc.ca (lois mermelstein) writes:
: Help -- I'm having serious trouble opening the intuition.library (so I can
: open windows onto Workbench, etc.)
:
: I'm using code like:
:
: struct IntuitionBase *IntuitionBase;
: #define INTUITION_REV /*either 33, 0, 33L, or 0L */
:
: main()
: {
: IntuitionBase = (struct IntuitionBase *)OpenLibrary("intuition.library",
: INTUITION_REV);
: if (IntuitionBase == NULL)
: { printf("Couldn't open lib.\n");
: exit()
: }
: I'm using Manx 3.6A with the default c.lib (16 bit ints) on a 2-floppy
^^^^^^^^^^ Aha !
Put something like 'void *OpenLibrary();' or '#include <functions.h>'
in your code, it really helps.
Without it, the 16bit manx thinks of OpenLibrary() as a function returning
a (16bit!) int. Casting that to a (struct IntuitionBase *) won't work !!!
Klaushiggin@cbmvax.UUCP (Paul Higginbottom MKT) (11/30/88)
In article <5679@louie.udel.EDU> mermelstein%tel.inrs.cdn@relay.ubc.ca (lois mermelstein) writes:
$Help -- I'm having serious trouble opening the intuition.library (so I can
$open windows onto Workbench, etc.)
$I'm using code like:
$
$struct IntuitionBase *IntuitionBase;
$#define INTUITION_REV /*either 33, 0, 33L, or 0L */
$
$main()
${
$IntuitionBase = (struct IntuitionBase *)OpenLibrary("intuition.library",
$ INTUITION_REV);
$if (IntuitionBase == NULL)
${ printf("Couldn't open lib.\n");
$ exit()
$}
$
$When the constant INUITION_REV is set to 33 or 0, I simply get "Couldn't open
$lib." from the printf. When I set it to 33L or 0L, I get "software error --
$task held", with a guru number of "#0000000A.00C [plus some other numbers].
$
$I'm using Manx 3.6A with the default c.lib (16 bit ints) on a 2-floppy
$B2000 that's completely vanilla (nothing else running, nothing bizarre
$in the startup-sequence).
$...
$Any ideas? Any help would be mucho appreciated.
$
$Lois Mermelstein
$mermelstein@tel.inrs.cdn
Are you declaring OpenLibrary as returning a pointer? If you don't, Manx
(and most compilers) will assume it returns an int, in this case, a 16 bit
int. When that is cast (as you declared it), it will be extended from
16 bits to 32 bits, which is trashing what was a perfectly good return value.
Long winded explanation, but here's the solution:
Add this to the top of your source file someplace:
extern void *OpenLibrary();
(or perhaps)
extern struct Library *OpenLibrary();
Regards,
Paul.mermelstein%tel.inrs.cdn@relay.ubc.ca (lois mermelstein) (12/01/88)
Thanks, everyone, for their answers on this one. When I get home I'll give myself fifteen lashes with a wet #include <functions.h> line, and hope this cures me of assuming that if something isn't documented in someplace obvious, I don't have to worry about it. Does anyone know if the RKMs are coming back into print, or if anyone has plans to update any of the better Amiga books for 1.3? Thanks, again. Lois Mermelstein mermelstein@tel.inrs.cdn
wbnsnsr@nmtsun.nmt.edu (William Norris) (12/02/88)
In article <5760@louie.udel.EDU> mermelstein%tel.inrs.cdn@relay.ubc.ca (lois mermelstein) writes: >Does anyone know if the RKMs are coming back into print, or if >anyone has plans to update any of the better Amiga books for 1.3? I just placed an order Tuesday for all four TRM's with MCS in Michigan. They CLAIM that these are the new 1.3 Edition. Guess I'll find out in a week, huh? -- wbnsnsr@nmtsun.nmt.edu | /// Seulement William B. Norris IV |\\ /// l'Amiga peut POB #2185 C/S | \\// vous l'offrir. Socorro, NM 87801 |=-=-=-=-=-=-=-=-=-=-=-=-=