on Fri 21-01-2000 12:25 John Kormylo wrote:

>> Why in heavens name should it need Geneva...?
>
>I needed a way to get the application name for the current process
>without doing a TRAP.  That info is available through the Geneva cookie.
>It might also be available from the MagiC cookie,

I am sure it is available, but not through the cookie itself.  I think
you need to make a series of MagiC kernel calls, first to find active pid,
and then to translate that pid into a name string.


>but I don't have MagiC documentation.

The full documentation for MagiC 6 is available in english translation.
I just checked the 'readme' that accompanied this archive, and the only
web address I can find is: "http://www.whalley.demon.co.uk/atari/", so I
assume that this is where I got it too (though I don't remember this now).
At any rate, it leads to the page of a guy involved in the project, so he
should be able to guide you to the MagiC docs (probably in his own pages).


>RAM_LEAK does not require Geneva.  It inserts magic numbers at the
>beginning and end of each RAM block, then tests them 4 times/sec to
>see if they have been overwritten.

I see. That would make it useful under most systems except MagiC I think,
since MagiC has block limit checking built-in for all RAM allocation.


>(Interestingly, one commercial program still sets it off.  I could never
>convince the author that he had a problem.)

Convincing a commercial programmer that already sold copies are faulty
can be very difficult.  (Economically motivated denial ?  :-)

However, it would be interesting to test the same software under MagiC 6,
because any program which overwrites RAM block limits under MagiC will
cause system error messages.  MagiC is too significant today for any of
the serious commercial programmers to ignore such reports, whereas they
probably find it easier to ignore reports from an unknown test program.

They know that if their product is branded as 'NOT MagiC-compatible' then
they will lose sales for that reason, and that should make them respond.


>I could MIME you a copy.

Please do.


>> Please doublecheck if you are still using a dialer from an older
>> STinG package with the newer kernel and modules.  That can't work.
>> The result of trying this would be bombs, which fits your problem.
>
>STinG v1.20 was the first version I installed.
>The DIALLER version is reported as 1.16.

That sounds ok to me, which makes the bombing even more mysterious...


>> I uploaded STinG kernel 1.22 on the 26th of October last year, and it has
>> been available for download there since then. You will find it as the 3rd
>> entry in the file list of my STinG\File submenu page.
>
>The only thing in that LZH is SERIAL.STX, which I have already
>installed.

That is the 2nd archive in the file list, named "ser_120.lzh".
I spoke of the 3rd archive, which is named "kern_122.lzh"


>If there is supposed to be a STING.PRG v1.22 inside, that
>might be the whole problem.

Immediately after reading this I logged on to my ISP, browsed my STinG page,
and downloaded KERN_122.LZH from its File section.  I then logged off again
and unpacked KERN_122.LZH.  The result was a folder named KERN_122\ which
contained the following three files:

TRANSPRT.H      Include file for C programmers of STinG clients/servers,
                with new definitions for TCP_info and UDP_info.

STING.PRG       Version 1.22 of the STinG kernel itself, adding UDP_info to
                the function links in the TPL structure.

KERN_UPD.TXT    History file giving very brief info on the main feature of
                almost every kernel update from the first creation of STinG.

There is no SERIAL.STX in this archive at all, and if you get such a file
in unpacking, then you did not get the correct file when downloading, or
somehow the unpacker chose the wrong archive to unpack.

Something is seriously wrong at your end, causing you to get or unpack
the wrong archive.


>>Detailed instructions are given for how to patch two different versions
>>of PD.PRG, and also for one version of the older TD.PRG.
>
>It SAYS that such information is available, but clicking the link does
>nothing.  At least in the English version it does nothing.

Well, as we now know that was just a misunderstanding of ST-Guide usage.
(I already have your mail about 'double-click VS single-click' on the link.)


>I suppose I could reset the interrupt vector after PD.PRG is loaded

You could do that, but it might be risky, depending on if PD.PRG handles
vectors dynamically or not.  I am not quite sure of this.


>(assuming everyone is using XBRA).

No dice I'm afraid.  PD.PRG totally ignores XBRA, as does all the PureC lib
functions that can modify system vectors.  That, by the way, means that any
vector bending to be performed by a real application must be done without
resorting to those lib functions, to comply with the XBRA standard.
(This means especially the PureC variant of the 'Signal' function.)


>What IF my test program wouldn't crash?  IOW, what if the
>problem is in DIALER?

Then it just serves as confirmation of this possibility, with all work of
searching for the bug itself still remaining for me to do.  That is one
of the reasons I adviced against investing too much work in a test prog.


I just thought of one more simple possibility for your problem.
(Grasping at straws here now...  ;-)

The dialer needs a DIAL.INF file to tell it where the DIAL.RSC and the
DIAL.SCR files reside.  It needs this file, in the same directory as the
program file itself, even if the path the file points to is also that same
path.  It may find the correct RSC anyway (depends on AES...) but it will
not use an SCR file found in that folder, unless the DIAL.INF is correct.

Now, in an earlier mail you wrote that you were TRYING to move from one
ISP to another, which suggests to me that you probably made a duplicate
folder for the dialer, so as to experiment with the new setup without
harming the old one.

If, through such copying and/or renaming of folders, the DIAL.INF file
ends up pointing to an incorrect folder, then unexpected errors may occur.
These are mainly of two kinds.

1:  DIAL.INF is not found, or points to an invalid path, or any path where
    there is no DIAL.SCR file at all.
=>  The dialer will then assume default values for all settings, regardless
    of values you may have edited into the DIAL.SCR file you wanted to use.
    These defaults may involve port choice and protocol choices that conflict
    with other system settings (even unrelated progs), thus causing errors.
    This could fit your problem, as it might cause bombs when attempting to
    activate the port, depending on what conflicts may exist.

2:  DIAL.INF points to the path of the older dialer setup.
=>  The dialer will then use the settings of the older setup, again without
    regard for any values you may have edited into the wanted DIAL.SCR.
    This does not fit your problem, as it should just lead to connection to
    your old ISP.

In any case, It is also possible that some bug in the dialer which I have
already worked on (and hopefully fixed) is involved in this.  To test this
I am now sending you a MIME attachement containing an LZH archive of the
latest beta version.  Note that this is still not intended for public
distribution, so don't post it elsewhere.

If that version gives no improvement, then it is probably a good idea for
you to send me copies of your two main config files, meaning DEFAULT.CFG
and DIAL.SCR, so I can check them for possible errors.

To avoid misunderstandings, please edit the PAP_PASSWORD value, and any
other passwords you may have in those files to the string "my_password"
before packing them to send them to me.

-- 
-------------------------------------------------------------------------
Regards:  Ronald Andersson                  mailto:dlanor@ettnet.se
http://dlanor.atari.org/    ICQ:38857203    http://www.ettnet.se/~dlanor/
-------------------------------------------------------------------------
