dillon@CORY.BERKELEY.EDU (Matt Dillon) (04/06/86)
Well, I thank Robert Peck for his postings on processes, but if one cannot any executable, I don't much see the use. What I think we all need is the source to CLI. The CLI seems to handle executing programs and getting return values with no problem at all. So how 'bout it, Amiga ..... Why are you putting us through hell when the answer is lying there in front of you. -Matt
rmariani@watnot.UUCP (Rico Mariani) (04/08/86)
In article <8604061908.AA25887@cory> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > > Well, I thank Robert Peck for his postings on processes, but if one >cannot any executable, I don't much see the use. What I think we all need >is the source to CLI. The CLI seems to handle executing programs and getting >return values with no problem at all. > > So how 'bout it, Amiga ..... Why are you putting us through hell when >the answer is lying there in front of you. > > -Matt I think this would be a very good idea. There are quite a few things which the CLI seems to do without much effort that the world at large has trouble duplicating. However, since source hasn't already been provided I have this feeling that it's written in BCPL or something... In any case, Robert Peck's postings (say that 10 times fast :-) ) were quite informative. Thank you. -Rico {allegra|ihnp4|utzoo|decvax|linus}!watmath!watnot!rmariani
bruceb@amiga.UUCP (Bruce Barrett) (04/10/86)
In article <11701@watnot.UUCP> rmariani@watnot.UUCP (Rico Mariani) writes: >In article <8604061908.AA25887@cory> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: >> >> Well, I thank Robert Peck for his postings on processes, but if one >>cannot any executable, I don't much see the use. What I think we all need >>is the source to CLI. The CLI seems to handle executing programs and >>getting return values with no problem at all. >> So how 'bout it, Amiga ..... Why are you putting us through hell when >>the answer is lying there in front of you. >> -Matt >[...] However, since source hasn't already been >provided I have this feeling that it's written in BCPL or something... >[...] > -Rico The CLI gets the return value the same way Robs examples do. Likewise it will respond to return(value); and exit(value); just as Rob described in his examples. This is not a "CLI vs. the examples" difference, this is something to ba aware of with Lstartup.obj(.asm). NewCLI IS written in BCPL. We see no point in releasing the souce to that on top of the other examples Rob Peck provided. Matt-- Have IBM or Microsoft given you the source to COMMAND.COM ? Please, give us a break. --Bruce Barrett
robp@amiga.UUCP (Robert A. Peck) (04/11/86)
Responding further to Matt and Rico .... AmigaDOS has been flamed for
the way it does certain things and people have, along the way, either
found or been given the tools that are needed to perform various
operations in a more suitable ( Un*x-like?) manner. People who write
things like CLI's most probably will be building in various command
ability rather than asking the DOS to load the command such as type,
copy, and so on. I venture to say that there will be very (very very very???)
few applications released based purely on BCPL and developed with the
full background of knowing AmigaDOS-related TRIPOS process internals,
since the experts therein are very few and far between. So why not
concentrate on applications for and in the languages with which we are
all most familiar.
**** small flame-on *****
Why should it be necessary to spend the X-pages of code to set up the
BCPL process model and associated CLI data structures when, by a small
amount of code as I've already released, one can run most any program
without any of the CLI overhead. It is simply unnecessary for the
small amount of return one gets.
**** small flame-off ****
A second thing to note... only if a program ends by "exit(value)" rather
than "return(value)" can that value be sensed ..... EVEN BY THE CLI!
(See the Amiga C startup code: Astartup.asm .... little piece of it
here to show why this happens... so a program has to be intelligent
enough in the first place to be capable of "returning" a code). So
any program that uses the standard C startup has a choice of whether
it can or cannot return a code to the starting process or CLI.
domain:
jsr _main
; arrives here if return(value)
; from _main. Notice that the
; value is ignored.
moveq.l #0,d0 ; Successful return code
; See, return code = 0 no matter
; what value is return()'ed.
bra.s exit2
_exit:
move.l 4(SP),d0 ; extract return code from stack
; because the C code translated
; exit(value) as a function, that
; pushes value on the stack before
; calling the underlying function
; named _exit.
exit2:
move.l initialSP,SP ; restore stack pointer
move.l d0,-(SP) ; save return code
; ****** ( more stuff here ) **************
;------ this rts sends us back to DOS:
exitToDOS:
move.l (SP)+,d0
rts
Nuff said.
robp.
Disclaimer: The opinions expressed above are mine and do not necessarily
reflect the opinions of my employer. But so far C-A hasnt
released the source code of the CLI, so I suppose I shouldn't
do it either. page@ulowell.UUCP (Bob Page) (04/11/86)
dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > What I think we all need is the source to CLI. I thought that too, but in talking to the developer of AmigaDOS, it becomes apparent that it isn't true. The CLI, NEWCLI, RUN, Execute() are very closely tied together with the BCPL run environment. What we really need is to rewrite AmigaDOS in C :-). > The CLI seems to handle executing programs and getting >return values with no problem at all. True. From what I can get out of the documentation and from my talks with Metacomco (and months of crashing my machine), when CLI wants to run a task, it does a LoadSeg() and attaches the segment header to its (process->pr_CLI << 2)->cli_Module (questionable C, but you get the picture.) It then puts the command's name in cli_Command (I'm guessing, I don't have any docs or code in front of me), fiddles with the return address, mucks around with the stack and jumps to (long) (cli_Module << 2) + 4 (as described in one of RobP's recent postings on getting retvals). However, BCPL programs don't work that way! They have a library of code waiting for them when they start up, this saves about 10K per file, through the use of dynamic run libraries (the Global Vector). The BCPL programs (LIST, DELETE, etc) want an environment like what John T. recently described in his article on port handlers. Parameters, you ask? Well, the CLI (as near as I can figure) actually grabs the input file handle before the process starts up and shoves the arguments into it! Strange but true? I/O is another problem. Did you ever wonder why the CLI/Process structures have CIS, COS, CurrentOut, StandardOut, CurrentIn, and StandardIn? Like, who uses each one, and for what? I have wondered myself. And then there's pr_ConsoleTask, which is your message port to receive Read and Write packets. Make sure you set that up. If you're not doing your own console I/O (if you're using RAW: or CON:, for example), pr_ConsoleTask is the filehandle you get back when you open the device. Oh, you must make an entry in the task table showing your allocated task ID. Set that number into your own task ID slot in your proc structure. > So how 'bout it, Amiga ..... Why are you putting us through hell when > the answer is lying there in front of you. Those folks at Amiga may be hard pressed to even explain what's going on in the deep recesses of ADOS. They did not write it, and from what I've seen, do not enjoy dabbling in it. Besides, graphics is more fun! In article <11701@watnot.UUCP> rmariani@watnot.UUCP (Rico Mariani) writes: > ... However, since source hasn't already been >provided I have this feeling that it's written in BCPL or something... Exactly. Have you ever read BCPL? Besides, when I call West Chester, they give me (a registered developer who signed a non-disclosure agreement) the "it's Commodore's policy to never release source code" routine. Bah. Now where'd that debugger go? ..Bob I tried robp's suggestions about loadseg & runloadedcode. I/O doesn't work, and it seems to return twice! Like: Run(); printf("returned from routine, retval = %lx\n", retval); UnloadSeg(seg); printf("unloaded, leaving\n"); return(retval); Actaually prints 'returned from ...' and 'unloaded ...' twice (with the correct retval, BTW) and then "Software Failure - Task Held" requester time. Any hints? Resulting guru numbers are 3, 4 and B (seems to be random). I'm doing this from within my own environment (My own CLI, but my I/O could be messed up - see above). All the program that I LoadSeg does is: printf("hello world\n"); and exits w/o a return statement. Other than not being able to execute commands, my ZLI works fine :-) ..Bob -- UUCP: wanginst!ulowell!page Bob Page ARPA: page@ulowell.CSNET U of Lowell CS Dept VOX: +1 617 452 5000 x2233 Lowell MA 01854 USA
mykes@3comvax.UUCP (Mike Schwartz) (04/14/86)
In article <979@amiga.amiga.UUCP> robp@dudley.UUCP (Robert A. Peck) writes: >Responding further to Matt and Rico .... AmigaDOS has been flamed for >the way it does certain things and people have, along the way, either >found or been given the tools that are needed to perform various >operations in a more suitable ( Un*x-like?) manner. People who write >things like CLI's most probably will be building in various command >ability rather than asking the DOS to load the command such as type, >copy, and so on. I venture to say that there will be very (very very very???) >few applications released based purely on BCPL and developed with the >full background of knowing AmigaDOS-related TRIPOS process internals, >since the experts therein are very few and far between. So why not >concentrate on applications for and in the languages with which we are >all most familiar. I understand Rob's frustration due to the regular flaming of the CLI that seems to be happening here. However, I understand the frustration that led to all the flaming in the first place. To some of us, the CLI is the most important piece of software on the machine. To others, workbench is more important. I like to use both, and understand that the Amiga needs workbench applications as much as it does CLI applications. I am a developer, and use my Amiga to edit/compile/debug. Therefore, to me, the CLI interface is extremely important, and we all know the pros/cons about the current CLI. Rob, I think that there are several people working on CLI replacements because there is a tremendous need perceived by most people who use the current CLI - pure and simple. But CLI is only one of the real needs. Serious debugging and development tools all use AmigaDOS (as opposed to custom disk drivers using TrackDisk) so that data can be shared. It is nice to be able to write programs like gi, which takes an IFF file and generates c-source for images. When you consider that there are countless MS-DOS internals hackers and Unix internals hackers, you gotta realize that there must be a need to deal with the internals of an OS. Making the OS do tricks is not only a challenge to guys like Matt, but NECESSARY for the future success of the machine. If you look at the Shell that Matt did (or other shells I have seen), there is no doubt that a great deal of improvement has been made so early in the game (for the CLI). If you remember way back to one of Matt's earlier postings, he flamed the Amiga OS (and Rom kernel). Then he actually wrote a program (the Shell) and changed his tune quite a bit (he later wrote that there were only a few things wrong with the Amiga software). His only real gripe was that there weren't enough higher-level support packages to do the things he wanted to do. AmigaDos (TRIPOS) shows so much potential on the Amiga, yet it is near impossible for severl (vocal) developers to allow that potential to come through. And the CLI has all the problems that have been flamed about, especially if you have to use it all the time. For example, just a simple way to edit the last command typed would be greatly appreciated. Why shouldn't a CLI for the Amiga have it's own pull down menus, work in 640x400, talk, and do Unix kinds of things, if that is what the individual user wants? I use 640x400 for text whenever possible, because I can choose colors that hardly flicker and I like the extra 20+ lines I can read on the screen. I use 640x400 in my own terminal program that I use to talk to unix, and unix never looked better to me than it does with 48 lines on the screen. The frustrating thing for a developer is that you can tell that somewhere BURIED IN THE INTERNALS of AmigaDos, some routine calls OpenWindow() to open a raw: window or con: window if you open("raw:n/n/n/n/title...), and that ANY CLI COMMAND with stdout redirected to the resulting FileHandle will go to that window. I know for a fact that the console.device works wonderfully with a 640x400 screen, so there is no reason why any of the CLI commands would not work in 640x400. I wish that there were some way to open a window via open("raw:...), and somehow substitute a window of my choice (my own NewWindow structure instead of the default one) for the one that CLI uses (and thus any application run from that CLI). This is just one example of why developers might want to get into the bowels of TRIPOS, and to me the above capability would please me to no end. I am sure that there are many such examples of internal kinds of things that people want to do. Another example is I want to have a CLI window in front of my own Custom Screen. Sorry Charlie. I hope that this hasn't sounded too critical, because it wasn't meant to be. I understand what a mess TRIPOS really is, because I have studied all of the manuals (Tech Reference, Developer's Manual, User's guide) many times over (trying to figure out how to do some of the above). I realize that somewhere in the middle levels of the code, TRIPOS had to be hacked at to get it to work on top of the ROM Kernel stuff. And I don't want to see BCPL sources (I don't got no stinkin' BCPL compiler). The folks at C-A have been extremely helpful to all of us on the net, and have provided a tremendous amount of support, in terms of writing or giving sources to us, writing higher level support routines for things that we need to do a lot (CreateTask, CreatePort, etc.), documentation, and PERSONAL attention. Kudos to them for all the help. On the other hand, they shouldn't discourage people from trying to become TRIPOS internals experts unless they plan to switch over to a new OS or something.