[Prev][Next][Index][Thread]

command line options for Executor (you don't need to know this) + X Question



Dear Folks,

	Here are the few command line options you can specify to  
executor:

-delay [n]	Have GetNextEvent delay n ticks on a null event [this
		is a poor man's WaitNextEvent].  Min for n is 0, max
		is 60, default with just "-delay" is 2, default  
		without  -delay is 0.

-dogmeat [n]	Turn off the cache if n is 1.  Don't mess with the  
		cache if n is 0.  Default with just "-dogmeat" is to  
		turn off the cache.  Default without "-dogmeat" is to  
		not mess with things.

-flush [n]	A different cache flushing strategy.  The n is
		interpreted the same as -dogmeat, but the strategy is
		to flush the cache after every Mac A-Line trap.

-noclock [n]	Turn off the automatic updating of the Ticks
		variable.  This switch is confusing when you give a
		value for n because you get a double negative if you
		set n to 0 (i.e. don't turn off, leave it running).

-refresh [n]	Keep a shadow copy of the screen and affter every n
		ticks, resolve the differences between the two (i.e.
		use this switch when the program writes directly to
		screen memory).  N can be between 0 and 60.  The
		default for just "-refresh" is 10.  Without
		"-refresh" the default is 0.

Two other switches are recognized but don't help you on a NeXT.   
"syscall" is for machines whose unix implementation doesn't allow  
loadable kernel mods (and hence you have to add a new system call).   
"nbitsinaddr" is for machines where we can simulate 24 bit addressing  
better.  We may be able to support this in future versions of  
Executor on the NeXT.  Note:  all the options listed above can be set  
up in the configuration file so you don't have to worry about them.

If you come up with a configuration file that helps a program run,  
send a copy to me and I'll include it in our next distribution.

NeXTStep also has a chance to look at arguments so there's a chance  
you can set geometry that way but I don't really know what the  
options it looks at are or what they do.  Feel free to clue me in.

Remaining arguments are then checked to see if they specify files.   
If they do and the first one is an application (file type 'APPL')  
then Executor will try to execute that file, passing the remaining  
files into the application to run.  All the filenames should use UNIX  
paths (i.e. slashes instead of colons), but the files must exist  
within a volume that you've set up with dwrite, or in the default  
volume ExecutorVolume within the app-wrapper.

Here's my X question:  Would there be any demand for doing a merge  
with NeXTStep and X so that in addition to being able to run Executor  
under NeXTStep as is now the case you could alternatively run it  
under X, which means by setting your DISPLAY variable you'd be able  
to have your NeXT be a Mac server for all your X-stations?  We have  
the technology (we ran Executor under X when we got our first NeXT  
back in July for the first couple of weeks while I taught myself the  
bare fundamentals of programming the NeXT [I'll be attending  
developer's camp some day]) but don't know where to put the work for  
the merge on the priority list.

	--Cliff


Follow-Ups: