[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference hydra::amiga_v1

Title:AMIGA NOTES
Notice:Join us in the *NEW* conference - HYDRA::AMIGA_V2
Moderator:HYDRA::MOORE
Created:Sat Apr 26 1986
Last Modified:Wed Feb 05 1992
Last Successful Update:Fri Jun 06 1997
Number of topics:5378
Total number of notes:38326

62.0. "Short Sort 'O Stuff" by CYBORG::LAMBERT () Tue Jul 08 1986 18:16

    
    
    Note for shorts about the Amiga:
    
    	Short Ideas.
    	Short Tricks.
    	Short AmigaDOS commands
    	Short Programs
    	Short Problems.
    
    Brian
    
T.RTitleUserPersonal
Name
DateLines
62.1short 1CYBORG::LAMBERTTue Jul 08 1986 18:187
    
    
    In AmigaDOS I found a neat way to change the names I use for commands.
    Instead of having to type "EXECUTE" to execute a script file, I
    renamed EXECUTE in the C Directory to be EXE.  Same for DELETE to
    DEL, COPY to COP...
    
62.2Any Takers?CYBORG::LAMBERTThu Jul 10 1986 13:535
    
    Are there any hints for using the Amiga that anyone would care to
    share with the forum?
    
    brian
62.3Hang in there!NCCSB::JFISHERJohn B. Fisher @NCO (DTN 367-4259)Thu Jul 10 1986 22:287
    Sure !!  As soon as I have finished my relocation, and have a copy
    of c-kermit for the Amiga, I will copy some helpful start up files
    into this are, as well as other things I have done... Don't give
    up. Good ideas just take a while
    
    John
62.4GoodCYBORG::LAMBERTMon Jul 14 1986 14:395
    
    
    Good!  I thought no one wanted to insert any helpful stuff here!
    
    brian
62.5Couple of tipsVIKING::BANKSDawn BanksTue Jul 15 1986 14:1465
    Some short programming tips:
    
    The first one is a plea against something I've seen in lots of public
    domain software lately, that can only cause problems later on down the
    road.  That is, when creating a message port (either via CreatePort or
    by doing it manually), it's usually not necessary to supply a name for
    the port, and in fact doing so can cause additional overhead (albeit,
    very small), and can prevent the proper operation of your program if
    you're attempting to run multiple copies simultaneously.  The reason
    for this is that CreatePort will call AddPort to add the message port
    to the system's message port list if your call includes a port name.
    This is unnecessary if your program is not declaring itself as some
    sort of system wide server.  In fact, the only utility of AddPorting
    your port is if you want to make it public, so that any other task in
    the system can find it (via FindPort) and send it messages. If you're
    simply creating a message port to communicate with some device driver,
    that driver will by definition be able to find your message port,
    because you're sending it messages with that port address supplied as
    the reply port.  In fact, many programs I've seen will supply a
    port name to CreatePort (thus, implicitly making the port public),
    then assume all messages received from that port are from the device
    driver they're communicating with.  This is setting yourself up
    for disaster.  For instance, you want to talk to the serial device,
    and you create yourself a port with the name "serial.device", because
    that sounds like a good name for the port.  While this probably
    won't preclude you from talking to your desired recipient, it can
    cause trouble in multiple ways (in ascending order of painfulness):
    
    It takes additional memory to store this name string when it isn't
    necessary.
    
    Calls to FindPort take longer than they need to.
    
    Someone legitimately wanting to use this port name (or perhaps another
    copy of the same program) will have a hard time, because now there
    are multiple people with the same port name on the system list.
    
    Some other task may find your port on the system list, and decide
    it's a neat port to talk to (because, perhaps, you picked the same
    name as some legitimate system resource, or just because the other
    task thought it was an interesting looking port name).  That task
    would then start sending you messages, and if your code doesn't
    check the source of all the messages it receives on a port, things
    can go downhill pretty fast.  For instance, if the code just assumed
    that all messages received on that port were replies to something
    that code sent, it would not only act improperly on the data received
    (assuming contents that aren't there), but it would also fail to
    reply to the original sender, possibly resulting in lost memory,
    multiply allocated memory, etc.
    
    Moral:  Unless you're declaring your task as some sort of "public
    utility" to the rest of the system, don't give it a name and AddPort
    it (which CreatePort does for anything with a name).
    
    The second tip is just something of a warning:  A while back, I
    was playing with a beta copy of 1.2, and in particular, the interlaced
    workbench windows.  It was pretty nice to get a 50 line screen,
    so I recompiled a couple of programs to open CON:0/0/639/399/Foo
    to make full use of the screen.  That much worked ok, but a couple
    of weeks later, I'd forgotten about the whole thing, and tried to
    run those same programs under 1.1, which of course, doesn't support
    such a large workbench window.  The way it told me about it was
    a system hang.  Took me a lot of headscratching before I remembered
    what was going on.  Moral:  Openning CON: windows that are bigger
    than possible can fail in mysterious ways.