fischer-michael@YALE.ARPA.UUCP (04/08/87)
I have been using Konrad Hahn's GEMBOOT program (on a US version ST) for a few days now and its wonderful! The memory it ties up is a small price to pay for the ability to have a large number of directories on my hard disk. Also, it seems to have eliminated many "mysterious" system crashes that were apparently caused by GEMDOS creating duplicate entries in memory for the same folders. I was amazed by the results of Hahn's GEMDIR program, which showed up to 8 copies of some of the folders in C:\ immediately after my rather involved bootup sequence. I had placed a program in my A:\AUTO folder that read a file of command lines and invoked each of the programs in turn. Apparently each command that was invoked caused another copy of the folders in C:\ to be placed in memory, so GEMDOS had almost run out of memory even before I got off the ground. I did find the program a bit tricky to install, for I wanted the command shell and the .BAT startup files to reside on the hard disk rather than on the boot floppy. It was necessary to patch the code to do this, and that job was not particularly easy. Also, I might like to have it invoke my own shell rather than COMMAND.TOS without querying me first but have not figured out how to make that happen, for if there are no .BAT files, then the startup shell is not invoked at all. But these are minor quibbles that should not detract from the fact that Konrad has done a really nice job and provided us with an interim solution to a vexing problem. By the way, I would really like a copy of the source code for the programs in GEMSOFT, both to be able to customize them to my preferences and to learn more about what is going on in GEMDOS. Perhaps Konrad would be willing to post sources to the net, or at least send me a copy directly. --Michael Fischer Arpanet: fischer@yale.arpa Bitnet: fischer@yalecs -------
paone@topaz.UUCP (04/08/87)
I installed gemboot without a hitch. I have the SH204 with the autoboot installed. Also I have a 1040. But then again, I have had over 100 folders all along without any trouble. -- Phil Paone paone@topaz.rutgers.edu "Admiral...There be whales here"
XBR4D76H@DDATHD21.BITNET (04/27/87)
Received: from BR4.THD.DA.D.EUROPE by DDATHD21.BITNET
via GNET with RJE ; 25 Apr 87 01:36:52
Date: Sat, 25 Apr 87 01:35:57 +0200 (Central European Sommer Time)
From: XBR4D76H@DDATHD21.BITNET
Subject: Re: Gemboot
To: info-atari16@score.stanford.edu
X-VMS-To: X%"info-atari16@score.stanford.edu"
In digest #177
ubc-vision!alberta!sask!long@beaver.cs.washington.edu (Warren Long)
writes:
> ......
> Anyways, the bug is that Mark William's C has a neat new shell called
> MSH.PRG, which is not be able to find it's PROFILE when run with
> GEMSOFT present. This even applies when I try MSH from a floppy,
> with PROFILE sitting on the floppy with it.
>
> As soon as I remove GEMSOFT, everything is functional.
The effects with MWC seems to me (I can only guess, I don't have this
program) a result of GEMBOOT's initialization of the DESKTOP environment
string.
Initially the PATH variable is set to ";C:\" and can be set to your needs
with SETPATH.TTP.
BTW: I would like to know, if there is any interest in a multiple variable
support of the DESKTOP environment string ?
SETPATH does only modify the PATH variable.
Konrad A. Hahn
BITNET: XBR4D76H@DDATHD21K538915@CZHRZU1A.BITNET.UUCP (04/27/87)
Jos Vermaseren t68@nikhefh.uucp writes: >It is alarming to see that some people use the currently empty system >variables for different purposes than they have been intended too. >If GEMBOOT uses the variable _shell_p for its own purposes this is >going to upset the programs that use it properly. >This variable is intended for shell programs that submit child processes. >The shell program can put here the address of one of its subroutines. >The child process sees then that there is a shell and can have the already >resident shell execute commands. ....................................... Sorry Joe, but you are dreadfully wrong! As experiment shows shell_p is a pointer to a string (C-type) which contains the current search path. shell_p is used by a number of AES functions including rsrc_load. Any other usage of shell_p will probably crash a number of programs. Where did you get your info from? Simon K538915@CZHRZU1A.BITNET PS: It would be nice to have a system variable that does what you describe!
t68@nikhefh.UUCP (Jos Vermaseren) (05/04/87)
In article <8704272221.AA01484@ucbvax.Berkeley.EDU>, K538915@CZHRZU1A.BITNET writes: > Jos Vermaseren > t68@nikhefh.uucp > writes: > >This variable is intended for shell programs that submit child processes. > >The shell program can put here the address of one of its subroutines. > >The child process sees then that there is a shell and can have the already > >resident shell execute commands. ....................................... > Sorry Joe, but you are dreadfully wrong! As experiment shows shell_p is a > pointer to a string (C-type) which contains the current search path. shell_p > is used by a number of AES functions including rsrc_load. Any other usage > of shell_p will probably crash a number of programs. Where did you get > your info from? > PS: It would be nice to have a system variable that does what you describe! The info came only from Atari/Allan Pratt. So if I'am wrong about it its because .............. ( choose yourself ). If it would be nice to have such a variable I think that Atari should, as soon as possible, designate one of the variables in the $500 range for this purpose. It is really nice to have both an editor and a make operating with a full escape to shell. I hope this diminishes the confusion somewhat. Jos Vermaseren t68@nikhefh.uucp
apratt@atari.UUCP (05/13/87)
I have investigated the alleged use of _shell_p by the AES and the Mark Williams shell, and I can't see that either of them uses this variable. We have a logic analyzer here at Atari, and you can set it to stop when the 68000 reads from a certain memory location. I did this, triggering on 000004f6 (the address of _shell_p). Neither the AES (in looking for a resource) nor MSH (the Mark Williams shell) made any reference to this location, reading or writing. This includes starting programs which need resources, without that resource file present. Would somebody please enlighten me? I can't verify any of the claims made for the _shell_p variable by people in this newsgroup (Michael Fischer@yale and "Simon" at CZHRZU1A on BITNET), and I would like to. Can anybody please tell me exactly what steps I can take, with a GEM program and its resource, the Mark Williams shell, and/or GEMBOOT, to prove to myself that this stuff really works? Thanks in advance... /----------------------------------------------\ | Opinions expressed above do not necessarily | -- Allan Pratt, Atari Corp. | reflect those of Atari Corp. or anyone else. | ...lll-lcc!atari!apratt \----------------------------------------------/
fischer-michael@YALE.ARPA (Michael Fischer) (05/13/87)
Allan Pratt reports: > I have investigated the alleged use of _shell_p by the AES and > the Mark Williams shell, and I can't see that either of them uses this > variable. It's not surprising that none of these programs access location 0x4f6. However, they obviously do use the string that is pointed to by that location. There are probably other pointers to it floating around as well. I think the Mark Williams shell receives this string as its environment string when it is invoked, so it presumably accesses it through its basepage. To find out how the basepage gets set and why, you'll have to look at the DESKTOP and/or the code for Pexec. Perhaps the DESKTOP passes the value of _shell_p to Pexec when you double click on a .PRG file. Or perhaps the desktop supplies a 0 to Pexec, and Pexec simply passes on the DESKTOP's own environment string, which it in turn probably gets from GEMBOOT. Hope this helps. --Mike Fischer Arpanet: <fischer@yale.arpa> UUCP: <imagen!yale!fischer> Bitnet: <fischer@yalecs> -------
t68@nikhefh.UUCP (05/15/87)
To add a little bit to the confusion: I ran a complete disassembly of the ROMs and NOWHERE in the ROMs there exists the hard address 4F6 = _shell_p. This means that the ROMs don't dictate its use and any information about that use must come either from DRI ( the makers ) or Atari. The other possibility is that people start allocating the allegedly unused spot by themselves like Konrad Hahn has done apparently. Clearly this location was NOT meant for the way gemboot uses it as AES uses no variables in that range and it sits between a couple of GemDos variables. Therefore I believe that the use suggested by Allan Pratt is the correct use, and that gemboot should look for another location. Anyway I think that Atari should now tell us which address to use for the gemboot trick of passing resource directory information and which one for the communication between a shell program and its child processes. Jos Vermaseren t68@nikhefh.uucp