Closed Bug 2754 Opened 26 years ago Closed 23 years ago

Need gestalt tests for system version etc.

Categories

(Core Graveyard :: Embedding: APIs, defect, P2)

PowerPC
Mac System 8.5
defect

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.
Setting all current Open/Normal to M4.
Status: NEW → ASSIGNED
per leger, assigning QA contacts to all open bugs without QA contacts according to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser
Component: Viewer App → Apprunner
Changed component to Apprunner.
QA Contact: 3853
Target Milestone: M4 → M5
Changed target milestone to M5.
Summary: Need gestalt tests for system version etc. → [PP]Need gestalt tests for system version etc.
Target Milestone: M5 → M7
Move off to m7
Target Milestone: M7 → M10
m10
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.
*** Bug 11542 has been marked as a duplicate of this bug. ***
*** Bug 11536 has been marked as a duplicate of this bug. ***
*** Bug 11541 has been marked as a duplicate of this bug. ***
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.
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.
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?
QA Contact: cpratt
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: 25 years ago
Resolution: --- → FIXED
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
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.
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.
Adding elig 'cuz he knows more about Macs than I do. elig, this is OK as it stands, yes?
Status: RESOLVED → VERIFIED
Marking fixed because it's good enough for me (and apparently elig too).
Oops. Never answered; not familiar enough with gestalt functions to have meaningful opinion. If good enough for sfraser, good enough for me.
Status: VERIFIED → REOPENED
Target Milestone: M10
Resolution: FIXED → ---
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?
I am guessing that my code is never getting called. I assume PBXGetVolInfoSynch is some new call in 8.5?
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.
Target Milestone: M13
Assignee: davidm → don
Status: REOPENED → NEW
I am not going to have time to look at this. reassign back to don.
Target Milestone: M13 → M15
Guess we do this after beta 1 then ...
Keywords: pp
Summary: [PP] Need gestalt tests for system version etc. → Need gestalt tests for system version etc.
Move to M16 for now ...
Target Milestone: M15 → M16
Target Milestone: M16 → M18
Move to M21 target milestone.
Target Milestone: M18 → M21
Since Don has left, Vishy is taking his bugs in bulk, pending reassignment. thanks, Vishy
Assignee: don → vishy
Giving to the closest embedding component we've got...
Assignee: vishy → adamlock
Component: Tracking → Embedding APIs
QA Contact: cpratt → mdunn
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.
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.
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.
Target Milestone: --- → Future
Correction: Changing QA contact for the Embed API bugs to David Epstein.
QA Contact: mdunn → depstein
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?
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: 25 years ago23 years ago
Resolution: --- → WONTFIX
.
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.