86550 - Connect stdio calls to Mac OS X Console Application / Terminal

Status: RESOLVED FIXED

(SeaMonkey :: General, enhancement)

Description

[Patrick C. Beard]

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.

Comment 1

[Patrick C. Beard]

Attachment: Modified NSStdLib.mcp.

Comment 2

[Simon Fraser [no longer active]]

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

[Patrick C. Beard]

Well, since our Carbon build is OS X only, I'm not sure this is worth the 
effort.

Comment 4

[Simon Fraser [no longer active]]

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

[Conrad Carlen (not reading bugmail)]

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

[Patrick C. Beard]

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

[Conrad Carlen (not reading bugmail)]

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

[Patrick C. Beard]

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

[Conrad Carlen (not reading bugmail)]

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

[Patrick C. Beard]

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

[timeless]

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

Comment 12

[Patrick C. Beard]

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

[Patrick C. Beard]

Attachment: Build system changes to build NSConsole.mcp for external SIOUX console.

Comment 14

[Patrick C. Beard]

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

Comment 15

[Mike Pinkerton (not reading bugmail)]

r=pink

Comment 16

[Scott Collins]

sr=scc

Comment 17

[Patrick C. Beard]

Changes checked in on trunk.

Comment 18

[Peter Van der Beken [:peterv]]

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

[Patrick C. Beard]

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.