Closed
Bug 86550
Opened 23 years ago
Closed 23 years ago
Connect stdio calls to Mac OS X Console Application / Terminal
Categories
(SeaMonkey :: General, enhancement)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: beard, Assigned: beard)
References
Details
Attachments
(2 files)
21.43 KB,
application/octet-stream
|
Details | |
852 bytes,
patch
|
Details | Diff | Splinter Review |
The Carbon build uses the SIOUX libraries to implement a rather primitive console, which is inaccessible during debugging (can't scroll, respond to events). I've checked in a new file that when used instead of the SIOUX library, sends a stdio to the System Console application or to the current terminal, when debugging with gdb, or when launching from the command line. The new file is checked in as: mozilla/lib/mac/NSStdLib/src/MacOSX_Console.cpp To use it, you remove the SIOUX source files from the NSStdLibCarbonDebug.shlb target of NSStdLib.mcp. I will enclose the edited project file as an attachment.
Assignee | ||
Comment 1•23 years ago
|
||
Comment 2•23 years ago
|
||
Can we rig the carbon target to just do the right things on Mac OS 9 and X, i.e. to make a console window on 9, and go to the terminal on X?
Assignee | ||
Comment 3•23 years ago
|
||
Well, since our Carbon build is OS X only, I'm not sure this is worth the effort.
Comment 4•23 years ago
|
||
But it's not! Witness Conrads efforts to build the embedding sample for Carbon. We cannot assume that TARGET_CARBON==Mac OS X
Comment 5•23 years ago
|
||
I agree that assuming TARGET_CARBON==Mac OS X is bad. The Carbonized embedding sample is beside the point. It would be nice if we *could* run Carbon under 9 at some point. We certainly don't want to add more code which will make this less likely. Besides, how hard is it to call Gestalt?
Assignee | ||
Comment 6•23 years ago
|
||
Calling Gestalt isn't the issue, having to write two sets of console hooks in the same binary is a pain. We may have to change some SIOUX code to make this work. I guess I could put the SIOUX hooks in a separate shared library, and load those dynamically if need be. I agree that TARGET_CARBON doesn't imply Mac OS X, except for just right now. I'll ponder the right way to integrate this.
Comment 7•23 years ago
|
||
How about just having proc ptrs, initialized once depending on what system we're on? The calls have to come through the console_stubs.c routines, but just vector them from there.
Assignee | ||
Comment 8•23 years ago
|
||
I checked in a shared library version of SIOUX, that now gets dynamically loaded by InstallConsole() if the system version is < 0x00001000. The new project files are here: mozilla/lib/mac/NSStdLib/NSConsole.exp mozilla/lib/mac/NSStdLib/NSConsole.mcp Now we just need build system changes to build this library.
Comment 9•23 years ago
|
||
Awesome. The system console will be ideal under OS X. Since you did the good thing of having an external (I hope its external) shared lib, I (and anybody who wants) can just replace the dreaded SIOUX component with something better.
Assignee | ||
Comment 10•23 years ago
|
||
Yes I use CFM to open the library dynamically. The external library must have the fragment name "NSConsole" and it must have the following exports: InstallConsole RemoveConsole WriteCharsToConsole ReadCharsFromConsole SIOUXHandleOneEvent SIOUXIsAppWindow SIOUXSettings I had to add SIOUXIsAppWindow this morning, since it is being used by macstdlibextras.c in my most recent pull (this morning).
Comment 11•23 years ago
|
||
*** Bug 83539 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 12•23 years ago
|
||
I've found a way to distinguish between stderr and stdout, by taking over the I/O vectors called __read_console() & __write_console(). I've checked this into the latest version of MacOSX_Console.cpp. To use this, the file console_io.mac.c needs to be removed from the target NSStdLibCarbonDebug target of NSStdLib.mcp.
Assignee | ||
Comment 13•23 years ago
|
||
Assignee | ||
Comment 14•23 years ago
|
||
I need a reviewer and super reviewer to check these in on the trunk.
Comment 15•23 years ago
|
||
r=pink
Comment 16•23 years ago
|
||
sr=scc
Assignee | ||
Comment 17•23 years ago
|
||
Changes checked in on trunk.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 18•23 years ago
|
||
And by doing so you broke the mac build and then left it broken. Not nice. I tried to fix it by adding back the ContextualMenu library as it was before. I have no idea if that's right and whether you really wanted to remove it or just disable it in some targets.
Assignee | ||
Comment 19•23 years ago
|
||
For future reference, the correct way to fix linkage problems when dealing with Mac specific shared libraries, is to add them to the common stub library here: mozilla/lib/mac/InterfaceLib/Interface.mcp So, if I'd been called about the bustage, I would have put ContextualMenuLib in that library instead of readding it to NSStdLib.mcp. As it is, I will have to do this, because we shouldn't link the Carbon version of NSStdLib.shlb against ContextualMenuLib, because it isn't a Carbon library.
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•