[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: