From: hyc@hanauma.jpl.nasa.gov (Howard Chu)
Subject: Re: MiNT, TCSH, CoNnect, Warp9...what they have in common?
Organization: SAR Systems Development & Processing, JPL
Date: Sat, 7 Nov 1992 23:42:10 GMT

In article <1dff3lINN3b5@aludra.usc.edu> baffoni@aludra.usc.edu (Juxtaposer) writes:
>In article <1992Nov6.173721.4625@elroy.jpl.nasa.gov> hyc@hanauma.jpl.nasa.gov (Howard Chu) writes:
>>In article <1dd85mINNlra@skat.usc.edu> mbaffoni@skat.usc.edu (Michael Baffoni) writes:
>>Mebbe you should get the Toswin 1.4 that Eric Smith recently put on a.a.
>
>	I will.  Is it moved out of the New directory yet?

I just moved it today, toswin11 has been deleted.

>>If you specify an INIT in your MINT.CNF file then it ordinarily will not
>>make it to the GEM desktop, so TOSwin is irrelevant then. The "leaving MiNT"
>>message means your INIT program exited, so MiNT shuts down. TOSwin is
>>absent from the resulting desktop because it only installs itself if MiNT
>>is active.
>
>	Right, but once it can't/isn't loading the program that is to be INITed
>shouldn't it reinstate MiNT and therefore TOSwin?  Besides, are there 
>limitations on what can and can't be INITed?  Like is it a bad idea to INIT a
>GEM program?  If not, then why is it not running say CoNnect from the INIT=
>when it works perfectly fine from the desktop?

The INIT program is much like /etc/init in Unix. Exiting init means you are
shutting down the system. When the INIT program exits, that means it's time
for MiNT to deinstall itself.

If you are running MiNT from your AUTO folder, then GEM hasn't been initialized
yet, so you can't run a GEM program from the INIT there. If you're starting
MiNT from the desktop or any time after the desktop has come up, then you can
put a GEM program in for INIT.
>
>	BTW, I placed the updates from 3.70->3.71->3.72->3.73 up on a.a. a
>couple of weeks ago so it should be available in the usual place (whereever
>that is).

I just moved them to the Utilities directory, thanks for the upload.
>>>and I have no problems whatsoever accessing the Warp9.acc.  In fact I can
>	I thought about that, but I turned the screensaver off (since I had
>access to it) and it didn't help.  BTW, why don't you just put "scrnsave.off"
>in your warp9.dat file and it will turn it off for the entire session, or
>configure your warp9.dat file so that it shuts the screensaver off whenever
>you run a program that has problems with it?

Forgot about that possibility... Gonna fix that Real Quick...
>
>>I also have problems with a lot of programs when BIOSBUFfering is active.
>>Uniterm exits with a bus error when it detects the CONNECT string after
>>auto-dialing a number. Big pain, haven't been able to track it.
>
>	You know something, I can 100% gurantee a lockup whenever I get a
>Connect message from the modem, regardless of whether I am in the dial
>menu or whether I am in the "direct" terminal.  In fact, I believe I remember
>ctl-alt-deling while connected, and it being frozen before I could do anything
>(which is unusual since it usually takes some action on my part before 
>something crashes).  I wonder if just being actively connected to the modem
>has anything to do with it....

That would be pretty unusual. Well, there *is* an interrupt vector for the
Carrier Detect signal, but that is initially disabled and I can't imagine any
program ever needing to enable it. Also, I can't understand why the interrupt
would cause a problem even if it was enabled...

In Uniterm the CONNECT message only makes Uniterm crash, and only if I used
the auto-dialer. You're saying you get a lockup even if you dial manually?
When you're in this state does Ctrl-Alt-F6 work (list active processes)?
-- 
  -- Howard Chu @ Jet Propulsion Laboratory, Pasadena, CA

All true wisdom is conveyed in one-line witticisms.
Newsgroups: comp.sys.atari.st.tech