bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) (07/25/87)
Today I had a reason to link with the "AStartup.obj" file from the Lattice C
disk. My program stopped working. The difficulty was traced to Astartup.obj,
and only showed up when using the Workbench. I dragged out the source (it's in
the examples directory) and gave it a quick scan. That was a waste of time,
so I looked a bit more carefully. I zeroed in on argc and argv as passed
to a program started from the Workbench. To my total amazement, the arguments
where passed in the wrong order.
The wrong order!? I swapped them and everything was fine. Now leery of the
quality of the code I examined it closer; several more "features" leaped into
view: if run from the CLI dos.library would never get closed, if a ToolWindow
was opened, it would never get closed, a function was called whos purpose
was to return a pointer in d0; the same pointer in fact that was already
in d0. As I was examining a potential bug in the string handling I realized
that this was hopeless.
The solution was to whip out the assembler, and cook up a version of my
my old startup routine that could to do what I wanted. I did, and
delivered the finished product to the happy customer on time. In addition
to working, my MyStartup.obj adds half the number of bytes to the
final result.
What's scary is that some software actually uses Astartup.obj. It's strange
that I have never heard anything about these bugs... and stranger yet that
a repaired version of Astartup.obj did not come with the gamma 1 developer's
kit. I'd send a bug report-> but this is too obvious to have been missed.
Is anyone else contemplating using, or actually using Astartup.obj with Lattice?
Did I miss an upgrade? Or did everyone switch to Aztec? :-)
-----------------------------
|\ /| . Ack! (NAK, EOT, SOH)
{o O} .
( " ) bryce@cogsci.berkeley.EDU -or- ucbvax!cogsci!bryce
U "Success leads to stagnation; stagnation leads to failure."scotty@l5comp.UUCP (Scott Turner) (07/28/87)
In article <8707251238.AA03602@cogsci.berkeley.edu> bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) writes: >Did I miss an upgrade? Or did everyone switch to Aztec? :-) How about option 3? Tossed the C compiler and went straight to assembly? :) As for the parameters being passed from workbench. How many programs have you ever seen that ran from the workbench and insisted on having piles of order dependent parameters fed to them? Scott Turner -- UUCP-stick: stride!l5comp!scotty | If you want to injure my goldfish just make UUCP-auto: scotty@l5comp.UUCP | sure I don't run up a vet bill. GEnie: JST | "The bombs drop in 5 minutes" R. Reagan "Pirated software? Just say *NO*!" S. Turner
bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) (07/29/87)
In article <> scotty@l5comp.UUCP (Scott Turner) typed: In article <> bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) writes: > >> [Astartup.obj is buggy] >> Did I miss an upgrade? Or did everyone switch to Aztec? :-) > > How about option 3? Tossed the C compiler and went straight to assembly? :) Of course you realize that this is what I do. I consider 68000 my primary working language. However, survey SAYS... most people switched to Aztec. > As for the parameters being passed from workbench. How many programs have you > ever seen that ran from the workbench and insisted on having piles of order > dependent parameters fed to them? You missed the point. By about three hundred kilobytes. Astartup.obj passes two things to _main, argc and argv. From the CLI argc is always at least 1, and counts the number of typed paramters. argv is a "vector" (pointer) to the array of pointers that contains the args. argv[0] is the program name, argv[1] is the first paramter, etc. When started from Workbench argc will be set to be 0, and argv will be the pointer to the Workbench message. The old Astartup.obj pushed those two on the stack in the WRONG order. Any C program that uses the Workbench message or wants to know if it was started from the CLI or Workbench needs a "pile" of those two parameters, preferrably in the proper order. TRIVA: The ReportMouse() function also screws up the order of it's own parameters. This was not fixed in V1.2 because people got it to work by switching the order of the parameters. Aztec went as far as doing this for you. For us 68000 programmers the boolean must be passed in A0, and the pointer in D0. (or just EOR the proper bit in one instruction, and forget ReportMouse().) BTW: I am told that there was an update to Astartup.obj posted the net. I never saw this, and could not find it at the j.cc.purdue.EDU archives. It matters little since I re-wrote it anyway... ----------------------------- |\ /| . Ack! (NAK, EOT, SOH) {o O} . ( " ) bryce@cogsci.berkeley.EDU -or- ucbvax!cogsci!bryce U "Be careful about reading health books. You may die of a miss-print" -Mark Twain