=========================================================================
 
INFO-ATARI16 Digest         Thu,  1 Feb 90       Volume 90 : Issue  137
 
Today's Topics:
                            C-lab notator
                              EMULATORS
               Is there a (reliable) CHKDSK for the ST?
                           reserving memory
                   Strange (?) Problem, need help!
                      Terminal Program (2 msgs)
              wierd...problems and a benign? anti-virus
----------------------------------------------------------------------
 
Date: Wed, 31 Jan 90 22:23:00 EST
From: Greg Csullog <01659%AECLCR.bitnet@ugw.utcs.utoronto.ca>
Subject: C-lab notator
Message-ID: <90Jan31.222501est.58651@ugw.utcs.utoronto.ca>
 
Can someone on the net tell me where I can get this program?
 
------------------------------
 
Date: 31 Jan 90 13:29:20 GMT
From:
 pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!rpi!image.soe.clarkson.edu
 !sunybcs!uhura.cc.rochester.edu!rochester!rit!moscom!tmb@tut.cis.ohio-state.edu
  (Tom Bellucco)
Subject: EMULATORS
Message-ID: <1998@moscom.UUCP>
 
In article <900109.20085072.014763@CU.CP6>
 "FRAJKOR/ATARISTUFF"%CARLETON.CA@Forsythe.Stanford.EDU writes:
>
>  I am puzzled by those who suggest that there is no point to buying
>Mac / PC/ etc emulators because you can buy Messy-Dos machines sio
>cheaply today.
>
>   Personally, I would rather have a wife who is (a) sexy (b) intelligent
>and (c) a hard worker than three who are one of each.  Even if you can
>get the other two cheaply.
>    Personal taste, of course.
 
Let's compare apples to apples here...it makes sense to want 3 seperarte
items that perform their tasks perfectly than 1 item that performs 3 seperate
tasks half-ass.
 
Look at the list of software that wouldn't run on the Megas!  You bought a
piece of software for an ancient IBM PC, it worked on a PS/2.  period.
 
As for wives, the one you described is taken.  :-)
 
--
 Tom Bellucco - moscom!tmb@cs.rochester.edu  or  ?...?!rochester!moscom!tmb
                    -------------------------------------
   "Whatever I said, I didn't mean it...unless, of course, you liked it!"
   #include <std.disclaimer>
 
------------------------------
 
Date: 1 Feb 90 05:04:33 GMT
From: maytag!water!ljdickey@iuvax.cs.indiana.edu  (L.J.Dickey)
Subject: Is there a (reliable) CHKDSK for the ST?
Message-ID: <2947@water.waterloo.edu>
 
In article <1990Jan31.032956.28008@gpu.utcs.utoronto.ca>
 romwa@gpu.utcs.utoronto.ca (Royal Ontario Museum) writes:
>Sorry if this has come up before, but I am really in need of info
>regarding a reliable way to verify the integrity of the FAT.
>Hopefully, the program should also go ahead and fix lost clusters,
>etc. as automatically as possible.
 
There is something called  FSCK  that is available from panarthea.
You can get an index for panarthea by sending mail to
 
        archive-server%panarthea.ebay@sun.com
 
and include this line:
 
        index binaries
 
To get the file I think you want include this line:
 
        binaries/volume3 fsck
 
To get instructions, include this line:
 
        help
 
--
    L. J. Dickey, Faculty of Mathematics, University of Waterloo.
        ljdickey@water.UWaterloo.ca     ljdickey@water.BITNET
        ljdickey@water.UUCP             ..!uunet!watmath!water!ljdickey
        ljdickey@water.waterloo.edu
 
------------------------------
 
Date: 31 Jan 90 23:11:57 GMT
From: zephyr.ens.tek.com!orca.wv.tek.com!pogo!bluneski@beaver.cs.washington.edu
 (Bob Luneski)
Subject: reserving memory
Message-ID: <8473@pogo.WV.TEK.COM>
 
in <11830072@hpldola.HP.COM> you write:
 
>Let's say my application is loaded, wakes up and says, "I wonder how much
>memory I can use".  It goes out and does a Malloc(-1L) to find out how
>much available memory the OS has.  Then it says, "I want all but 50K".
 
Malloc(-1L) does not return the amount of free memory available to the system
only the size of the largest contiguous block. If your memory is fragmented it
will return less than the true available memory.
 
>1) malloc() (or Malloc()) all but 50K of the available memory and manage
>   that chunk of memory itself.  I just can't believe this is necessary,
>   shouldn't malloc() be able to do this (see #3 below)?
 
see #3
 
>2) Malloc(50K) before any call to malloc() then Mfree() that 50K right
>   after the call the malloc() to keep 50K always free for the OS.
>   Yuck!, but could be workable on a single tasking OS.
 
Ugly hack that fragments allocated block structures!
 
>3) set some switches so that malloc will never take the last 50K of
>   memory from the OS.  This seems preferable, but I don't know what
>   the switches are for MWC (or any other compiler for that matter).
 
Not available with stock malloc fuctions. Malloc is a VERY unreliable
memory manager and it is best to use the OS call as infrequently as
possible.  The most elegant way to do it is to write your own malloc that
limit the total number of Malloc blocks to LESS than 16 and dynamically manage
those blocks as required.  Find the source to some public domain C comiler if
you need a prototype for these types of routines.
 
****************************************************************************
*  Bob Luneski :-)                               bluneski@pogo.WV.TEK.COM  *
*  (author: Diamond Back)                                                  *
*                                                                          *
*  The opinions expressed herein are my own and in no way reflect the      *
*  opinions of Tektronix, Inc.                                             *
****************************************************************************
 
------------------------------
 
Date: 31 Jan 90 19:33:23 GMT
From: sjsca4!greg@uunet.uu.net  (Greg Wageman)
Subject: Strange (?) Problem, need help!
Message-ID: <1990Jan31.193323.28036@sj.ate.slb.com>
 
Opinions expressed are the responsibility of the author.
 
In article <90029.124246O12@PSUVM.BITNET> O12@psuvm.psu.edu writes:
>Hello Everyone,
>
>I have a rather strange problem, I have written a GEM application
>which uses AES and LINE-A calls, and suffice it to say, it runs
>perfectly fine but has trouble exiting to the desktop
>properly and displays 3 bombs.
>
>The really wierd thing is the application runs and exits fine when
>launched from a shell other than the desktop, but then causes the
>SHELL to crash when you try exiting it to the desktop with 3 or 4
>bombs. Other programs can be launched from the shell before exiting it
>without error, the shell only crashes upon attempting to exit to the desktop.
 
Do you malloc() memory and change screens via Setscreen()?  If you do,
you must be careful to save the original values of Logbase() and
Physbase(), and return to using them via another Setscreen() before
you exit.  Otherwise, when your program exits, the memory you
malloc()'ed for your screen is freed, allowing it to be allocated by
other processes.  If the desktop writes on the screen at the addresses
you left active, it can scribble all over the free-memory pool,
resulting in spectacular crashes.
 
As a general rule, one of the first things I create in each GEM
program is an initialization routine and a termination routine.  These
share certain globals, such as the original values of Logbase() and
Physbase(), the initial palette, and so forth.  Then I religiously
call my termination routine anywhere the program exits (such as within
fatal error handlers).  This assures that things are put back the way
they were previously.
 
(Four bombs is an "illegal instruction" error.  This suggests that
code in RAM is getting clobbered somehow.  In my experience this
usually results from wild pointer references (storing through a
dereferenced, uninitialized pointer).  Any code that does a malloc()
or close relative is suspect in that case.)
 
Copyright 1990 Greg Wageman     DOMAIN: greg@sj.ate.slb.com
Schlumberger Technologies       UUCP:   ?uunet,decwrl,amdahl?!sjsca4!greg
San Jose, CA 95110-1397         BIX: gwage  CIS: 74016,352  GEnie: G.WAGEMAN
 Permission is granted for reproduction provided this notice is maintained.
 
------------------------------
 
Date: 1 Feb 90 04:58:35 GMT
From:
 mailrus!jarvis.csri.toronto.edu!neat.cs.toronto.edu!omicron.cs.fsu.edu!fsucs.cs
 .fsu.edu!boyd@tut.cis.ohio-state.edu  (Mickey Boyd)
Subject: Terminal Program
Message-ID: <9001312121.AA05873@fsucs.cs.fsu.edu>
 
In article <892@ztivax.UUCP>, mjk@ztivax.UUCP (Michael John Kaelbling) writes:
>Hi,
>
>does anybody know about terminal programs for the Atari ST handling Kermit
>protocols?  A program that does both terminal emulations, and the normal
>Kermit functions like send and receive would be even more appreciated.
 
Good ol Uniterm 2.0e will do this and more.  A very robust and powerful
program.  Also, for about $15, one can buy Flash.  It does NOT include
Kermit protocol, but there is a desktop accessory that gives it that
capability (which is either shareware or pd, I am not sure).  I use
flash myself (without Kermit) because it is much easier to understand
for a novice (which I recently was).  Also, it looks better on a color
monitor (IMHO).  With a mono, Uniterm is stunning, allowing super teeny
tiny text as an option (really nice with big listings).  Uniterm is free,
and probably the most capable and error free terminal program for the ST.
--
 
    -----------------------------------------------------------------------
    ---------------------------------+-------------------------------------
         Mickey Boyd                 |    "Nobody can be exactly like me.
                                     |      Even I have trouble doing it."
             FSU Comp Sci            |              - Tallulah Bankhead
    ---------------------------------+-------------------------------------
    -----------------------------------------------------------------------
 
------------------------------
 
Date: 1 Feb 90 01:11:38 GMT
From: eagle!ncastellano@ucbvax.Berkeley.EDU
Subject: Terminal Program
Message-ID: <6208@eagle.wesleyan.edu>
 
In article <892@ztivax.UUCP>, mjk@ztivax.UUCP (Michael John Kaelbling) writes:
> Hi,
>
> does anybody know about terminal programs for the Atari ST handling Kermit
> protocols?  A program that does both terminal emulations, and the normal
> Kermit functions like send and receive would be even more appreciated.
> Right now I'm working with a very primitive Kermit for the ST.  It's not
> [...]
 
Check out Uniterm in the comp.binaries.atari.st archives on
terminator.cc.umich.edu ...  Kermit support, full vt52, vt100, vt200, tek4010
emulation...great program.
 
                        Nick
 
--
_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_
Mathematics is the subject in which we never know what we are talking about,
nor whether what we are saying is true.  -Bertrand Russell
_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_
Nicholas Steven Castellano     | Box 4127 Wesleyan Station | Disclaimer: I am
ncastellano@eagle.wesleyan.edu | Middletown CT 06457       | irresponsible.
_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_
 
------------------------------
 
Date: 1 Feb 90 00:37:56 GMT
From: eagle!ncastellano@ucbvax.Berkeley.EDU
Subject: wierd...problems and a benign? anti-virus
Message-ID: <6207@eagle.wesleyan.edu>
 
In article <4072@jhunix.HCF.JHU.EDU>, ins_bac@jhunix.HCF.JHU.EDU (Ajay Choudhri)
 writes:
> I have seemed to have run into a problem or actually a wierd occurence.
> On my Flash disk I have Pinhead 1.4, MAccel2 and UIS3.
> When I boot up, I get 4 bombs but it proceeds to boot up and works fine.
> IS ther a memory problem here?? I was recently trying to get an EZRAMII to
> work and I am hoping I didn't mess up the MMU seating.
>
> Secondly, I have no clue where the damn thing came from but I seemed to have
> caught a virus..or anti-virus...
> I suspect I got it off a local bbs from a .MSA file of TeX
> when I boot-up, I get the message that this is an antivirus and it beeps and
 flashes when it encounters a disk with an executable boot sector.
> Well I have controlled the infection to only 3 disks but I would rather
> just have the AV gone.  Also if this AV has installed itself, I have noticed
> that when running Codehead's Coderam.prg(ramdisk) before it installs, the
> computer asks me to insert disk Z,then disk Y then disk X all the way to
> disk D which happens to be my ram drive.
> The bad thing is that it happens to be on my utility disk so anything
> I format or such gets the stupid AV.  It may be benign or harmless but I
> have no desire for it...anybody offer any clues..
>
> thanks from confounded in MD
> -Ajay CHoudhri
 
Before you completely wipe out the Anti-virus you may want to make a copy of
the a disk with the AV on it and send it to the authors of VIRUSKIL so they
could inspect it and add it to the list of virus programs that their program
can defeat.
 
There was a discussion of anti-viruses a while back on the security mailing
list (or perhaps it was VIRUS-L) about anti-viruses and the consensus was that
anti-viruses are just as much an invasion of data privacy as any other virus,
inless intentionally installed (on your own media).  Since these programs
exhibit all the same properties as other viruses (i.e. self-replication,
infection of disks that don't already contain the virus, etc.) they are just as
"bad" as any other virus (especially since it may really be a harmful virus
posing as an anti-virus, waiting for a certain signal to do some real damage.)
 
                          Nick
 
 
--
_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_
Mathematics is the subject in which we never know what we are talking about,
nor whether what we are saying is true.  -Bertrand Russell
_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_
Nicholas Steven Castellano     | Box 4127 Wesleyan Station | Disclaimer: I am
ncastellano@eagle.wesleyan.edu | Middletown CT 06457       | irresponsible.
_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_
 
------------------------------
 
End of INFO-ATARI16 Digest V90 Issue #137
*****************************************
