Closed
Bug 2754
Opened 26 years ago
Closed 24 years ago
Need gestalt tests for system version etc.
Categories
(Core Graveyard :: Embedding: APIs, defect, P2)
Tracking
(Not tracked)
VERIFIED
WONTFIX
Future
People
(Reporter: sfraser_bugs, Assigned: adamlock)
References
Details
(Keywords: platform-parity)
The embedding app should be doing some gestalt tests for system version etc,
and put up informative dialogs when we can't run. Now that builds are going
public, this will prevent a lot of traffic on the newsgroup from people who
are trying to run under 8.1.
This will require some dialogs (probably native), of course.
Comment 2•26 years ago
|
||
per leger, assigning QA contacts to all open bugs without QA contacts according
to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser
Summary: Need gestalt tests for system version etc. → [PP]Need gestalt tests for system version etc.
Summary: [PP]Need gestalt tests for system version etc. → [PP] Need gestalt tests for system version etc.
Moving all Apprunner bugs past and present to Other component temporarily whilst
don and I set correct component. Apprunner component will be deleted/retired
shortly.
Comment 10•26 years ago
|
||
*** Bug 11541 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 11•26 years ago
|
||
Note that to fix one class of loading problem (i.e. missing shared libs), you
will have to weak link with the libraries, and test for them at runtime using
<some symbol in the lin> != kUnresolvedCFragSymbolAddress.
Comment 12•26 years ago
|
||
I would like to keep that a seperate issue from making sure we have a minimum
acceptable system checks for the beta. The above is a tougher problem since I
have no way of telling what libaries are required for a given component.
Reporter | ||
Comment 13•26 years ago
|
||
If an individual component requires a system library that is not present, then
the CFM will give back an error when we try to load that library with
GetDiskFragment (down in NSPR). It's highly unlikely that such an error will
survive the trip back out of the NSPR and the component manager. Do we have a
plan on how to deal with this?
Comment 14•26 years ago
|
||
I'm adding this comment as a reminder to myself to check the following
conditions when this bug has been fixed:
- Mac OS 8.1
- Mac OS 7.6.1 with ADD-IAD
- System 7.5.5
- Any System on 680x0 hardware
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
Comment 15•26 years ago
|
||
I checked in my fix. I left the 68K bug open becasue it is a bit harder to fix (
Maybe this should be done by the installer?). I could only do minimal testing
since my machine doesn't run OS's below 8
Comment 16•26 years ago
|
||
I should have this verified in about a week or so.
As far as the installer checking for the presence (absence) of a PowerPC
processor, that's fine, but there are situations in which it's still a good
thing for the app itself to check and see if it's running on PowerPC. Although
it's extremely unlikely this would actually happen, there are Macintosh
computers with PowerPC upgrade cards that can reboot into a 680x0 environment.
Universal System Folders used by some network admins also come to mind.
Comment 17•25 years ago
|
||
Marking this one as fixed. There are still minor open issues, but I don't think
that's a big deal. Here's what I found:
System 7.5.5 - App quits because it can't find the contextual menu something or
other
Mac OS 7.6.1 with ADD/IAD - App gracefully quits after warning that you need Mac
OS 8.5
Mac OS 8.1 - same as 7.6.1
In conclusion, it seems that if you have the contextual menu stuff provided by
the ADD/IAD installation for 7.6 and later, we do the right thing. If you don't
have that (ie no ADD/IAD or 7.5.5 or earlier), we don't, but it's no big deal.
I can't check 680x0 machines at the moment 'cuz my LC 475 is at home, but I'll
try to do that eventually.
Marking verified fixed.
Comment 18•25 years ago
|
||
Adding elig 'cuz he knows more about Macs than I do. elig, this is OK as it
stands, yes?
Comment 19•25 years ago
|
||
Marking fixed because it's good enough for me (and apparently elig too).
Comment 20•25 years ago
|
||
Oops. Never answered; not familiar enough with gestalt functions to have
meaningful opinion. If good enough for sfraser, good enough for me.
Reporter | ||
Updated•25 years ago
|
Status: VERIFIED → REOPENED
Target Milestone: M10
Reporter | ||
Updated•25 years ago
|
Resolution: FIXED → ---
Reporter | ||
Comment 21•25 years ago
|
||
Reopening. This appears not to be working correctly, judging by this post on the
newsgroup:
From: Patrick James Gibbs <Patrick@world-net.co.nz>
Newsgroups: netscape.public.mozilla.mac
Message-ID: <B472F9C9.E6%Patrick@world-net.co.nz>
Date: Tue, 07 Dec 1999 17:52:10 +0000
When an attempt is made to lauanch Mozilla the following appears
Error message shows
The application Mozilla could not be opened because
"InterfaceLib--PBXGetVolInfoSynch"
could not be found.
I am using a Performa 5400 PPC 48Mb ram running MacOS 8.1
Where can I obtain this Library?
Is MacOS 8.1 not supported?
Comment 22•25 years ago
|
||
I am guessing that my code is never getting called. I assume PBXGetVolInfoSynch
is some new call in 8.5?
Reporter | ||
Comment 23•25 years ago
|
||
Your code isn't getting called, because this CFM error happens before we run any
code.
I think the problem is that PBXGetVolInfoSynch is in InterfaceLib, and we're
linking with an InterfaceLib that contains 8.5 calls. We should weak link
somewhere, then test PBXGetVolInfoSynch before using it.
Comment 24•25 years ago
|
||
I am not going to have time to look at this. reassign back to don.
Comment 25•25 years ago
|
||
Guess we do this after beta 1 then ...
Updated•25 years ago
|
Summary: [PP] Need gestalt tests for system version etc. → Need gestalt tests for system version etc.
Updated•25 years ago
|
Target Milestone: M16 → M18
Comment 28•24 years ago
|
||
Since Don has left, Vishy is taking his bugs in bulk, pending reassignment.
thanks,
Vishy
Assignee: don → vishy
Comment 29•24 years ago
|
||
Giving to the closest embedding component we've got...
Assignee: vishy → adamlock
Component: Tracking → Embedding APIs
QA Contact: cpratt → mdunn
Assignee | ||
Comment 30•24 years ago
|
||
Isn't this a general Mozilla issue? Embedding apps have no such requirement to
put up a dialogs about the wrong OS because the host application would be
responsible for such checks.
Reporter | ||
Comment 31•24 years ago
|
||
Well, that's an interesting question. How does Gecko communicate to the embedder
that it is capable of running on this OS version? Should there be an API call (on
a DLL that has minimal OS requirements), or just documentation? If the latter,
then I agree that it's the embedder that needs to do the OS testing.
Assignee | ||
Comment 32•24 years ago
|
||
CC'ing Conrad for opinion on whether this is necessary for embedding on the Mac
or if it's a more general Mozilla problem.
Personally I think that any embedder should do their OS checks long before Gecko
is even instantiated in the host app. If necessary NS_InitEmbedding could return
an unsupported OS error but the embedder would still be responsible for testing
for it and displaying their own error message.
Updated•24 years ago
|
Target Milestone: --- → Future
Comment 33•24 years ago
|
||
Correction: Changing QA contact for the Embed API bugs to David Epstein.
QA Contact: mdunn → depstein
Assignee | ||
Comment 34•24 years ago
|
||
Is this bug still relevant or should we put the onus onto the embedder to
decide whether their app (including Gecko) is capable of running on a
particular OS?
Assignee | ||
Comment 35•24 years ago
|
||
I'm going to mark this WONTFIX.
Until such time as we ship a binary only version of Gecko for the Mac I don't
see how we can say which OS the embedders Gecko build will run on.
Status: NEW → RESOLVED
Closed: 26 years ago → 24 years ago
Resolution: --- → WONTFIX
Updated•6 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•