rs4u+@ANDREW.CMU.EDU (Richard Siegel) (08/19/87)
Just a comment -- Chuq (awesome dood :-) mentioned that LSC had problems under Juggler, uh, MultiFinder. This is an understatement. Lightspeed C *crashes* under Juggler, as does Lightspeed Pascal. An amusing side-note; I mentioned this to the twin geniuses who wrote Lightspeed Pascal (actually, just one of them was on the phone at the time), and he said "Well, we don't really intend to have Lightspeed Pascal run under Juggler." Then comes a shout from the background: "Yes we do! Yes we do!" Dissension? ;-) --Rich
olson@endor.harvard.edu (Eric Olson) (08/19/87)
In article <wV-DDAy00V4IzGo0fR@andrew.cmu.edu> rs4u+@ANDREW.CMU.EDU (Richard Siegel) writes: > >Just a comment -- Chuq (awesome dood :-) mentioned that LSC had problems >under Juggler, uh, MultiFinder. > > This is an understatement. Lightspeed C *crashes* under Juggler, as >does Lightspeed Pascal. An amusing side-note; I mentioned this to the twin >geniuses who wrote Lightspeed Pascal (actually, just one of them was on the >phone at the time), and he said "Well, we don't really intend to have >Lightspeed Pascal run under Juggler." Then comes a shout from the background: > Uh, let's not equate Juggler and Multifinder here. Practically everything crashes under Juggler (last time I tried), and it's not a real Apple product. Multifinder != Juggler. I suspect Think Technologies will come out with a fix for LSC and LSP to run under MultiFinder (if it doesn't already) soon after MultiFinder's release (a month or so from now, I hear). As soon as I get my grubby paws on MultiFinder, I'll let anyone who'll listen know whether LSC crashes under it, and if it will sub-launch (like running in another Switcher partition) or substitute-launch (what most applications do now), or not launch at all the Project Application. -Eric Eric K. Olson olson@endor.harvard.edu harvard!endor!olson
singer@endor.harvard.edu (Andrew Singer) (08/19/87)
In a previous posting, "rs4u+@ANDREW.CMU.EDU (Richard Siegel)" wrote: > Just a comment -- Chuq (awesome dood :-) mentioned that LSC had problems > under Juggler, uh, MultiFinder. > > This is an understatement. Lightspeed C *crashes* under Juggler... The following was posted this week on CompuServe. I post it here in its entirety to help clarify the above. Jon Hueras THINK Technologies, Inc. -------------------------------------------------------------------------- #: 55760 S3/Mac Programming 15-Aug-87 18:59:22 Sb: Multi-Finder bug Fm: Michael Kahl 75236,3146 To: All In attempting to determine why LightspeedC crashes under the newly christened Multi-Finder (aka J------), I believe I have found a bug in Apple's context-switching code. I can't say yet whether this is the only thing keeping LSC from working, but I thought I'd report what I've found in case it's of use to anyone else (and in hopes that Apple might fix it!). When LSC calls GetNextEvent (or ModalDialog, which in turn calls GetNextEvent), the Finder gets in to update its windows. A context switch is performed to establish a background execution environment. When the Finder completes this background processing, another context switch restores LSC's foreground execution environment. During this second context switch, *AFTER* the foreground task's dispatch table has been restored, but *BEFORE* other low-memory globals (notably "CurrentA5") have been restored, the context-switch code issues a call to _SetHandleSize. This means that if the foreground task has installed its own _SetHandleSize handler (using _SetTrapAddress), that handler now gets in, EVEN THOUGH THE CONTEXT SWITCH IS NOT YET COMPLETE! In particular, "CurrentA5" still points to the background task's A5 world. As fate would have it, LSC does indeed intercept _SetHandleSize. The handler wants access to LSC's globals, but since "CurrentA5" is wrong, mayhem inevitably ensues. Once it has restored the dispatch table, the context-switch code should assume that the foreground application can get in on any trap. Ideally no traps should be issued until the context switch is complete. At the very least, any traps should be called directly (via addresses previously obtained from _GetTrapAddress) rather than going through the dispatcher. I hope it is safe to assume that this bug report will reach Apple by virtue of being posted here. If someone from Apple could acknowledge this, it would save me the trouble of submitting this through more official channels. Michael Kahl 75236,3146 THINK Technologies, Inc.
jww@sdcsvax.UCSD.EDU (Joel West) (08/20/87)
In article <2708@husc6.UUCP>, singer@endor.harvard.edu (Andrew Singer) writes: > Once it has restored the dispatch table, the context-switch code should > assume that the foreground application can get in on any trap. Ideally > no traps should be issued until the context switch is complete. Although, as regular readers know, I'm very opposed to the 'blame Apple for everything' school of developers, I believe THINK is right in calling this a bug. MultiFinder is supposed to maintain separate trap patches for each application, and swap them as part of each context swap. Clearly you don't want to swap the patches in before you swap the corresponding value of CurrentA5.