dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) (11/20/88)
NOTE NOTE: OS1.3 C:RUN, not the 1.2 RUN
This is the problem. To avoid referencing "*" by Execute() itself,
I have to specify a nil: file handle for the second and third arguments of
Execute():
1> run <nil: >nil: program
Where "program" contains an Execute() like this:
Execute("some-command", NilFH, NilFH);
Unfortunetly, nothing can be a 'run', like this without crashing
the machine:
Execute("run list", NilFH, NilFH);
However, it CAN be a run if you do this:
Execute("run <nil: >nil: list", NilFH, NilFH);
or
Execute("run <nil: >nil: list >ram:x", NilFH, NilFH);
It appears that if pr_ConsoleTask is NULL, the ONLY valid way to
do a 'run' via Execute is if you use the above construction. Attempts to
replace pr_ConsoleTask with a port and simulate a dos device to handle the
supposed reference to "*" that run makes if you do otherwise have failed...
the port is never accessed.
Anybody who's a *real* DOS guru (i.e. C-A) no how I can do:
Execute("run Date", NULL, NULL);
Without crashing the machine? Note that here I do not specify the
nil: file handles. I have not confirmed this, but I think by NOT using
the nil: file handles the Execute() also attempts to access "*" for a
brief period, causing the machine to become unstable.
-Mattandy@cbmvax.UUCP (Andy Finkel) (11/24/88)
In article <8811200108.AA29768@postgres.Berkeley.EDU> dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) writes: > Anybody who's a *real* DOS guru (i.e. C-A) no how I can do: > > Execute("run Date", NULL, NULL); > > Without crashing the machine? Note that here I do not specify the >nil: file handles. I have not confirmed this, but I think by NOT using >the nil: file handles the Execute() also attempts to access "*" for a >brief period, causing the machine to become unstable. I know the problems you are having and plan to fix them up for 1.4. It's the use of the * as stderr that's biting us here, I suspect. However, the specific example Execute(run date",0L,0L); works fine on my 1.3 machine. (even if I run the program containing the Execute() statement) ie run testprog Possibly you are hitting a 16 bit/ 32bit defined constant problem ? (or your compiler is opening * for you in some other manner) The problem with the way the consoletask works with now is understood. Now all I have to figure out is a way to fix it properly. If it weren't for DeviceProc() I'd be home free :-) -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. "Possibly this is a new usage of the word 'compatible' with which I was previously unfamiliar" Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) (11/29/88)
>In article <8811200108.AA29768@postgres.Berkeley.EDU> dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) writes: >> Anybody who's a *real* DOS guru (i.e. C-A) no how I can do: >> >> Execute("run Date", NULL, NULL); >> >> Without crashing the machine? Note that here I do not specify the >>nil: file handles. I have not confirmed this, but I think by NOT using >>the nil: file handles the Execute() also attempts to access "*" for a >>brief period, causing the machine to become unstable. > >I know the problems you are having and plan to fix them up for 1.4. >It's the use of the * as stderr that's biting us here, I suspect. > >However, the specific example > >Execute(run date",0L,0L); works fine on my 1.3 machine. > >(even if I run the program containing the Execute() statement) Try doing it from a detached process, that was my point. RUN the program that contains the Execute("run date",0L,0L), but before the program does the Execute() close the console window: RUN >nil: <nil: charliex ENDCLI (charliex fclose(stderr) to remove "*" dependancy) (console goes away) (charliex sets pr_ConsoleTask = NULL or something else ... or leave it what it was if you want to gurarentee a crash. But even changing it guarentees a crash pretty much). (charliex now does an Execute("run Date",0L,0L))). >Possibly you are hitting a 16 bit/ 32bit defined constant problem ? >(or your compiler is opening * for you in some other manner) No. I use 32 bit ints all the way, and since the console window goes away, there are no file references. -Matt
nordmark@nada.kth.se (Arne Nordmark) (11/30/88)
In article <8811281929.AA18217@postgres.Berkeley.EDU> dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) writes: > Try doing it from a detached process, that was my point. RUN >the program that contains the Execute("run date",0L,0L), but before >the program does the Execute() close the console window: > > RUN >nil: <nil: charliex > ENDCLI > > (charliex fclose(stderr) to remove "*" dependancy) > (console goes away) > (charliex sets pr_ConsoleTask = NULL or something else ... or > leave it what it was if you want to gurarentee a crash. But > even changing it guarentees a crash pretty much). ^^^^^^^^^^^^^^^^^^ NO!!! If you set pr_ConsoleTask to a *valid* device-handler everything will work perfectly. (Hey, you said this yourself in your amigamail, remember?) That is what "null:" is all about. Just say pr_ConsoleTask=DeviceProc("null:"); and you won't crash anything, even though the console window is gone. If you do pr_ConsoleTask=NULL; or pr_ConsoleTask=DeviceProc("NIL:"); /* this yields NULL as well! */ you will crash the machine, but this will be fixed in 1.4 I hope. Before 1.4 is available you have no choice. You *must* set pr_ConsoleTask to a valid device-handler. The obvious fix for 1.4 is this: Whenever someone tries to do an Open("*",...), check the pr_ConsoleTask. (this is allready done in 1.2). *but* if it doesn't contain a valid device-handler (check the device-list) or if it is NULL, then do an Open("NIL:",...) instead. Otherwise send the "open"-packet to the apropriate device-handler, just as in 1.2. There you are, no more problems with gone-away console windows. -- Gunnar SNAIL: Gunnar Nordmark VOICE: (+46) 8 - 755 42 52 Nora strand 5 S-182 34 DANDERYD EMAIL: gno@stacken.kth.se SWEDEN gno@SESTAK.BITNET "Words, words, words." William Shakespeare
dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) (12/03/88)
nordmark@nada.kth.se (Arne Nordmark) Writes: >NO!!! If you set pr_ConsoleTask to a *valid* device-handler everything will >work perfectly. (Hey, you said this yourself in your amigamail, remember?) >That is what "null:" is all about. Just say > pr_ConsoleTask=DeviceProc("null:"); >and you won't crash anything, even though the console window is gone. Right. NULL: *does* work. But let me qualify your statement just a little. Not only does it have to be a *valid* device-handler, it must also accept Open("*", 1006) IN ALL CASES! That is, you cannot set pr_ConsoleDevice to a filesystem handler because Open("*",1006) will fail if "*" is already open! I have been testing NULL: at with my cron (setting pr_ConsoleDevice to DeviceProc("NULL:"), fclose(stderr), and EndCLI'ing the console window that started it and everything works fine! . o . o . // O -Matt\|/ * "The trajectory failed due to an ill-considered rounding of the floating point quantity by the compiler"