mwm%ucbopal@BERKELEY.EDU@caip.RUTGERS.EDU (02/16/86)
From: Mike (I'll be mellow when I'm dead) Meyer <mwm%ucbopal@BERKELEY.EDU> Having finally gotten all the docs, plus the latest C compiler (3.03B), I retreated from the large project to some easy stuff/general housekeeping. One of the easy things shows up some interesting behavior in the 3.03B compiler. The thing in question is a digital clock that only chews up one display line, (designed to hide out of the way in the screen title line). Run out of CLI, everything works fine, and I was real happy with it. However, when I copied over the default clock program, and ran it from the WorkBench, low and behold if it didn't create a window (besides the one it put the time in), that did nothing. Some poking reveals that the C compiler startup code creates the window by default when it's running from the WorkBench. There doesn't seem to be any documentation on turning it off. I tried recompiling _main.c with -DTINY and linking that in, but it crashes. I finally gave up, included stdio.h (thus growing my program by 4.5K) and fclosed stdin. There's gotta be a better way. Someone want to tell me how, and what piece of documentation I should have read? Thanx, <mike
daemon@caip.UUCP (02/18/86)
From: Louis A. Mamakos <louie@trantor.UMD.EDU> I noticed this too. I was recompiling my GfxMem program under the new lattice compiler, and noticed this very strange behavor. What I did is redefine my main(argc, argv) function as _main(args). This replaces the _main.c file that does the argc/argv hacking along with the bogus behavor of opening this additional window. Since I didn't need any of the arguments, this worked ok. You have to be careful in that the lattice unix compatable I/O routines for stdin/stdout/stderr probably won't work. Then again, you probably won't be using these in this type of application. Is there any interest in my reposting GfxMem.c to the mailing list? I put this hack in, as well as only displaying a single bar graph when there is no 'fast' memory in the system. Louis A. Mamakos WA3YMH Internet: louie@TRANTOR.UMD.EDU University of Maryland, Computer Science Center - Systems Programming
bruceb@amiga.UUCP (Bruce Barrett) (02/18/86)
In article <1281@caip.RUTGERS.EDU> mwm%ucbopal@BERKELEY.EDU@caip.RUTGERS.EDU writes: [...info about 1 one line clock...] >From: Mike (I'll be mellow when I'm dead) Meyer <mwm%ucbopal@BERKELEY.EDU> >I tried recompiling >_main.c with -DTINY and linking that in, but it crashes. >There's gotta be a better way. You are on the right track, the problem is a bug in _main.c. We just noticed and solved this one last week (I'd been meaning to post the problem/solution to the net but hadn't gotten around to it. Problem: Using -dTINY with _main.c and then running under workbench causes the program to crash. Solution: Edit _main.c, find the line: _ufbs[2].ufbfh = Open("*",MODE_OLDFILE); Replace it with the line: _ufbs[2].ufbfh = Output(); So now you know, please "Tell a friend". :-) (This fix brought to you by Bart, I meerly tested and recorded this info.)