#SAS C V6 Is Here!
9 messages in this thread
Kieth,
If you compile with cback.o and folow the userguide suggestion for so
dooing, then in SAS you can run a program fom Workbench (which is what I
was referrring to but probably neglected to say) and the initial CLI's
window used to start the program will never appear. This is primarily for
programs that either have no I/O requirement or do not need the startup
CLI's window for I/O.
wmc – via Autopilot!
Wayne,
Using cback.o is the incorrect way to do it — that's for programs that
you want to have detach. Cback.o has some downsides. If you forgotten
and left a printf() in, cback.o will cause the machine to crash. If your
program spawns other processes, with cback.o, it won't.
If what you want to do is get rid of the workbench window, regardless of
how the program is started, not have it crash on a printf(), and have
spawned processes work correctly, link with DEFINE __main=__tinymain.
-sja
Steve,
Thanks for the hint. (That message goes in the keeper pile). I had
looked for all refs to "window" and CLI that I could find – never thought
about looking under stdin/out..(duh).
wmc – via Autopilot!
Wayne,
The DEFINE __main=__tinymain works fine with the BLINK command and
does as advertized here (NOSTDIO in 6.0). I don't think any of this info
is in the manual.
Steve Krueger from SAS has added a second idea to all this. In the
source dir there is a program called "umain.c"; ("_main.c" for 6.0) that is
called by your main() function. It's in this code that the window is
opened. If you want the user to have a console interface when running from
an icon, but want a different size, like a full window, you can change the
size in this module and link it into your program.
-Tom
This is true. In 6.0 there are a couple of additional facts:
*) If you do keep the window, and you are running under
AmigaDOS 2.0, we add the /AUTO/CLOSE/WAIT flags to
the console spec, meaning the window won't actually
appear unless you *use* stdio.
*) You can change the device spec used to open the AmigaDOS
filehandle by declaring and initializing an external
variable. This means you can change the size of the window,
cause it to open NIL: instead of CON:, add a title,
whatever.
–Doug
I have been annoyed by the fact that one has to edit these files to change
the window spec for a while, but haven't broken down and done it
correctly.. i.e. get the window spec from the icon tooltypes on workbench
startups. I was thinking that maybe SAS6.0 would do this, although some
might be concerned by the added mess of those getdiskobject calls and icon
libraries. If I do bite the bullet, I'll U/L the new startup code…
unless someone beats me to it! There are a couple other standard tooltypes,
which might also be worth implementing… but they slip my mind at the
moment.
See Steve's reply… my point was that the fact that a program opens a
window when run from WBench is not indicitive of what compiler was used to
create it… as both compilers mentioned have ways to get around that.
– Keith
Keith,
The author of SID apparantly does not know that as he claimed the little
extra window you get in addition to SIDs main I/O window, was due to
limitations in Manx coimpiler. I don't have Manx, so I was dependent on
Timm Matrtin's experience with it. Then I ran nto another too that does
the samee thing and it mentioned in the docs that it was Manx'd. I took
that as proof of the correctness of Timm's claim.
I used (wrongly it appears) the cback.o to get rid of the window on a
little app that hung around waiting for printer access, then tried to
steal the printer driver's loaded segment. (I was trying to get at the
printer driver with the debugger without having to create my own
printer.device – was never able to "intercept" the printer driver segemt,
but did manage to get rid of that little window ;^} Anyway, I fixed my
probelm when I noticed an uninitilized variable in the graphics portion of
the driver. Added one line and it ended months of consternation. Its
amazing what one littel ol' uninited variable can do to you…
wmc – via Autopilot!
I'm not sure what Timm was claiming (or why/how SID ended up with that
window) but it's not something I ever ran into using Manx (for CLI launched
programs)… it's there by 'default' for both Manx and SAS compilers for
WBench launched programs and there are ways of getting rid of it in both.
And yes… uninitialized variables can be real fun (not!) <grin>
– Keith