Connect stdio calls to Mac OS X Console Application / Terminal



18 years ago
14 years ago


(Reporter: beard, Assigned: beard)


Mac OS X

Firefox Tracking Flags

(Not tracked)



(2 attachments)



18 years ago
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:


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.

Comment 1

18 years ago
Created attachment 39058 [details]
Modified NSStdLib.mcp.

Comment 2

18 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?

Comment 3

18 years ago
Well, since our Carbon build is OS X only, I'm not sure this is worth the 

Comment 4

18 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
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?


Comment 6

18 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.
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.

Comment 8

18 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:


Now we just need build system changes to build this library.
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.

Comment 10

18 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:


I had to add SIOUXIsAppWindow this morning, since it is being used by 
macstdlibextras.c in my most recent pull (this morning).

Comment 11

18 years ago
*** Bug 83539 has been marked as a duplicate of this bug. ***

Comment 12

18 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.

Comment 13

18 years ago
Created attachment 42711 [details] [diff] [review]
Build system changes to build NSConsole.mcp for external SIOUX console.

Comment 14

18 years ago
I need a reviewer and super reviewer to check these in on the trunk.

Comment 16

18 years ago

Comment 17

18 years ago
Changes checked in on trunk.
Last Resolved: 18 years ago
Resolution: --- → FIXED
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.

Comment 19

18 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:


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.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.