GWindows/GView version compatibility?

[Russell Magee]

Hello,

At work we're developing a GWindows app using GView on a MVME162 box. The
target is a 68360-based system running OS-9 v3.0. On the target we're running
the newest version of GWindows (ed. 62 if I recall correctly), but on the
VME162 box we're compiling under GWindows ed. 54 (once again IIRC.)

It appears that if we try to run our app, compiled under the older
GView, on the target, which contains all the NEW Gwindows gadgets in ROM, it
simply refuses to run, giving an Error #000:221 (module not found).
GView itself also appears to refuse to run under the newest GWindows, giving
the same error.

We've called Gespac support about this, and they told us recently that we
did NOT need to upgrade GView along with GWindows. Is this the case? It almost
seems as if the GView application is trying to link to gadgets with specific
module edition numbers (and thus not seeing the newer gadgets).

Must one compile apps for the newest GWindows with a newer version of GView?
We have checked our module lists carefully and are pretty sure we're not
missing any critical modules.

Once again (sigh), Any help would be appreciated...
-Russ Magee

[Steve Adams]

In article <56snrb$e...@linux.cpsc.ucalgary.ca>, ma...@cpsc.ucalgary.ca
(Russell Magee) wrote:

> Hello,
>
> At work we're developing a GWindows app using GView on a MVME162 box. The
> target is a 68360-based system running OS-9 v3.0. On the target we're running
> the newest version of GWindows (ed. 62 if I recall correctly), but on the
> VME162 box we're compiling under GWindows ed. 54 (once again IIRC.)
>
> It appears that if we try to run our app, compiled under the older
> GView, on the target, which contains all the NEW Gwindows gadgets in ROM, it
> simply refuses to run, giving an Error #000:221 (module not found).
> GView itself also appears to refuse to run under the newest GWindows, giving
> the same error.

Russ,

You have found the one discontinuity in the development of G-Windows.
Except for this one problem that I had to work around, every change to
G-Windows has been fully backward compatible.

Unfortunately, you cannot mix versions of G-Windows and G-View if they
lie on opposite sides of the edition #62 boundary. You need to get an
update to compile programs on your target system.

Now an explanation of the cause of the discontinuity:

With V 1.2 of the OS9/68000 Ultra C compiler, Microware changed the
variable definitions in the cstart.r file. Variables like 'errno' are
defined in cstart.r, and previously were always in the same position in a
program's data space. This was important when using sub-routine modules,
because it gave them a way to access the 'errno' variable. When I
originally designed gadget subroutine modules, I followed example source
code from Microware that relied on the variable definitions in cstart.r.

The cstart.r file with OSK Ultra C (V1.2 and later) has the 'errno'
and other variables declared in a different order, so the errno variable
ended up in a different location in the variable space. When gadgets
thought they were writing to the 'errno' variable, they were really
writing to a stack checking variable. This made programs quit randomly
with a stack overflow error. There were probably other related problems
as well.

I couldn't very well ask Microware to take back all copies of their
Ultra C compiler and change back to the old format, so I had to change the
gadget structure so gadgets would not reference these variables. I did
put in a check so when incompatible programs and gadgets are used
together, they abort immediately rather than wait for a strange error
later on. I apologize for not using a more descriptive error code, but
there isn't one.

Best Regards,
Steve Adams

[Russell Magee]

Steve Adams (st...@polyware.com) wrote:
: Russ,

: You have found the one discontinuity in the development of G-Windows.
: Except for this one problem that I had to work around, every change to
: G-Windows has been fully backward compatible.

: Unfortunately, you cannot mix versions of G-Windows and G-View if they
: lie on opposite sides of the edition #62 boundary. You need to get an
: update to compile programs on your target system.

OK! thanks for the quick and definitive answer. You may want to tell Gespac
technical support about this, it seems THEY didn't know. 8-/

It sure would have been nice if wedit and/or our compiled app could have
some canned code compiled into it which would print out a more descriptive
string, such as "Obsolete modules -- contact Gespac".. (sounds simple, but
it's probably not, I realize).

Once again, thanks for the help.

-Russ Magee