| Re: .0
There are several ways to get a lock on the current directory.
One way is to use CurrentDir:
METHOD ONE:
current_dir = CurrentDir(0);
CurrentDir(current_dir);
This makes use of the special lock zero. The lock zero is equivalent
to a lock on the hardware device DF0:. A lock of zero is a lock on
whatever volume is currently mounted in DF0: at any time the lock is
referenced. By the way, it is OK to unlock the zero lock. UnLock(0)
is a somewhat expensive No-op. Occasionally, you will find the
misinformed writing code like:
if (lock != 0) Unlock(lock);
The test is unnecessary. This information is in the AmigaDOS manual,
but is buried in the "Sending packets to device drivers section!"
Sigh!
METHOD TWO:
Get a lock on the null string. It is equivalent to getting a lock
on the current dir. (This will probably be the best method for a
program like yours, since you will probably have an optional
"directory" argument to your program. You can just initialize
your directory string to null and load it with the program argument
if specified.)
current_dir = Lock("");
METHOD THREE
Put the lock on the current directory from the process table for
your process
#include <libraries/dos.h>
#include <libraries/dosextens.h>
struct Process *process;
process = (struct Process *) FindTask(NULL);
current_dir = process->pr_CurrentDir;
(Off the top of my head, I think the above code is right.) FindTask is
an Exec, not DOS, routine. It is documented in the ROM Kernal manuals
(look in the Exec volume and the master alphabetical list of all functions
in the back of the Libraries and Devices volume.)
> 3 - Can someone tell me if there is a book which exmaines programming
> Amigados in a better fashion than the Bantam Amigados manual (which in
> my opinion is pretty dreadful on this front).
I recommend the book by Robert Peck. It has some name like "Programming
the Amiga," or "Amiga Programming," or "Amiga Programmer's Handbook."
Peck was a "technical" technical writer for the original Amiga group, and
oversaw the writing of the ROM Kernal Manuals. The AmigaDOS manual was
written by Tim King of Metacomco, so don't blame Bob for it. Peck's
new book is a sort of introduction (with lots of examples) to all of
the Amiga's operating system. In fact, it contains several examples
on writing a replacement "dir" program! (By the way, a technical
writer is someone who writes technical manuals by translating the
brain dumps of engineers into English. The technical writer is
not an expect on the subject, and rarely can cook up any examples
to illustrate the principles of what is going on. The technical
technical writer is someone who is very knowledgeable on the subject,
and can write examples that illustrate subtle points without help
of an engineer.)
In general, this book is very readable, and very informatative. A few
of the examples are marred by errors, but the book is a major net win.
(About half of the examples on Examine and ExNext have the FileInfoBlock
on the stack. Since AmigaDOS requires this data structure to be aligned
on a long word, this is playing with fire!)
> 4 - Can someone ensure that the current Amigados is replaced with one
> (perhaps ARP) thats written in C and not in the dreaded BCPL. All the
> these bloody BPTRs and stuff are just hateful.
I agree about the BPTR and alignment stuff. However, don't expect it
to go away soon. Even if Commodore stomps out all the BCPL code, they
will have to continue to support all those BPTR to keep existing
code working. About the best they can do is add all new system routines
that provide an APTR interface. So, in addition to Lock which returns
a BPTR to a struct Lock, they can provide a NewLock which returns a
struct Lock *.
Blame it all on Tim King of Metacomco. At least he is now busy working
for Atari on their transputer machine. (One wonder's if he was working
for Atari when he put BPTRs in the Amiga...)
By the way, ARP is not doing all the work needed to do away with the
BCPL sections of AmigaDOS. ARP is simply concentrating on rewriting
the CLI commands that depend on the BCPL environment so the Commodore
will have less to deal with when they decide to remove the BCPL
support from AmigaDOS.
A few programming tips:
If you obtain a lock on a object (using Lock, DupLock, ...), you must
unlock it before your program exits.
When your program exits, it should have the same CurrentDir lock active
as when it started. There are two reasons for this.
First, if your program is running under the CLI, your program is running
as part of the CLI. As such, any changes to the current dir made by your
program is being made to the process control block of the CLI. The CLI
expects a valid lock to be the current lock when your program exits. To
avoid confusion, your program should restore the current directory. No
one will be happy if after running your program they are not connected
to the directory of their choice, but instead the CLI is connected
to some funny temporary directory that your program uses.
Second, if your program is running under the Workbench, it will be started
with current directory lock of zero. If you stick some other lock in
current dir before exiting, the system will simply delete your process
without unlocking that lock, and you will now have a lock that can not be
unlocked until the system reboots.
Another sin is to Unlock the initial current directory sometime during
your program's execution. The first problem with that is that it makes
it hard to restore the exact lock to CurrentDir before exiting. A
second problem is that if you are using Lattice C, its standard startup
code saves the initial current directory and its exit code sticks the
initial lock back into the current directory. Since the CLI expects
the current dir to be valid lock, this quickly causes a Guru.
We manipulating the current directory, you should write code like this:
temp_lock = Lock("Fred");
old_lock = CurrentDir(temp_lock);
/* Now have lots of stuff that depends on being connected to Fred */
....
/* Restore the previous environment */
CurrentDir(old_lock);
Unlock(temp_lock);
Another source of locks you should leave alone is Workbench startup
messages. The standard exit code in the C library replies to this
message before the program terminates. When the Workbench gets this
message back as a reply, it then unlocks all of locks in the message.
If you have changed them or unlocked them yourself, expect a guru.
The rule is: "If you created a resource, you own it and are responsible
for disposing of it. If someone else has loaned you a resource, then
the resource is theirs, and you must return it to them intact. They will
dispose of it."
That is the Good Neighbor rule of Amiga programming.
|
| re .1...a great (but long ;-) exposition on dirs, locks, etc...this
should make clear for all of us...
re .0...One way I've learned a lot about the maig is to look at
others code...some good, some less so...two (in my opinion) good
examples are the dillon/drew shell and dave's vt100 (both sources
are on the net) since the shell has a section that does a dir,
with the kind of options list gives, except the the note, its probably
what you looking for...there have also been some replacement dirs
posted on usenet....browse around in mvcad3::user0:[amiga.usenet],
and .arc]
USER0:[AMIGA.ARC]SH207SRC.ARC;1 shell src code...
USER0:[AMIGA.ARC]VT10028.ARC;1 vt100 r2.8
scott
|
|
Hi,
Sorry for the delay in replying, been away from the Amiga for a while.
Thanks for the advice, just what I needed. My little utility now works
fine, using the empty string to get a hold of the current directory
lock works just fine. I also got hold of the source for Shell and they
are really good at showing how to use AmigaDOS (I was just about to put
a reply in asking how to get a files full path name but the Shell
source showed me how to do that).
Thanks a lot guys, I am now well on my way to becoming a real Amiga
hacker :-)
Colin.
|
|
Hi,
I'm back to programming the Amiga after a bit of a break. This time I'm
mucking about with a conversion for a fractal landscape program that's
been doing the rounds in some of the British computer mags. I have a
few questions on implementing the program on the Amiga that I hope
someone can help me with,
1) The algorithm I'm converting was intended for an IBM pc. It uses an
integer random number generator random (size) which returns an integer,
pseudo-random number between 0 and size-1. My problem is that my
compiler's (Lattice C V4.0) integer random number generator return's an
integer in the range 0 .. MAXINT. Can anyone point me at an algorithm /
code fragment that either implements a random number generator like the
one above or will convert the random number given by the function above
without resorting to floats ? Degree of randomness is not the problem,
just getting a number in the correct range.
2) I'm using the primitive graphic area filling routines. The
ROM-KERNAL manual says that these do not perform boundary checking and
so you should do it yourself or use the layers library. Now my question
is this, I am using these routines to draw in a borderless backdrop
window in a custom screen all of which have been created using
Intuition (p.s. using the window's RastPort). Does this mean that the
layers library will be used ? or do I have to do something else ?
3) I really want to save the resulting images as an IFF file. I have
mucked about with the stuff on the IFF developers disk and written a
few little programs that read and write IFF files, but the EA code is a
real pain to use. Does anyone know of some easier-to-use higher level
routines to read an write IFF files ?
Whew !!!
Thanks in advance for any help you can offer,
Colin.
p.s. thanks for the help with the AmigaDOS stuff I now have this little
utility that recursively displays all the files on a disk - I've wanted
to do that for a while.
|
| Re: .5
>It uses an integer random number generator random (size) which returns
>an integer, pseudo-random number between 0 and size-1. My problem is
>that my compiler's (Lattice C V4.0) integer random number generator
>return's an integer in the range 0 .. MAXINT. Can anyone point me at
>an algorithm / code fragment that either implements a random number
>generator like the one above or will convert the random number given
>by the function above without resorting to floats ?
Use the expression
(rand() >> 5) % N
to get a number in the range 0 to N-1. The shift is required, the number
5 is just a guess on my part. The "best" and most popular random number
generator does not produce a random result in the low order bits. The
low order bits must be thrown away before use. In fact random number
generators of this type cycle the low order bits: rand() % 3 would
just produce 0, 1, 2, 0, 1, 2 ....
>I am using these routines to draw in a borderless backdrop window in
>a custom screen all of which have been created using Intuition (p.s.
>using the window's RastPort). Does this mean that the layers library
>will be used ?
Yes, windows are clipped using the layers library automatically.
>I really want to save the resulting images as an IFF file.
A cheapie solution: Various public domain programs exist that will
save the top screen as an IFF file. I use the program ScreenSave on
Fish disk 55.
|
|
Hi,
Thanks a lot everyone for such a prompt response. This stuff is just
what I needed. I tried the straight rand () % (size - 1) and it worked
pretty well, but it certainly changed the look of the landscape, much
more jagged. I'll give screensave a go while I work on the IFF stuff.
Again, thanks,
Colin.
|