If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Connect stdio calls to Mac OS X Console Application / Terminal

RESOLVED FIXED

Status

SeaMonkey
General
--
enhancement
RESOLVED FIXED
17 years ago
13 years ago

People

(Reporter: Patrick C. Beard, Assigned: Patrick C. Beard)

Tracking

Trunk
PowerPC
Mac OS X

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Assignee)

Description

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

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

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

Comment 2

17 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

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

Comment 4

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

(Assignee)

Comment 6

17 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.
(Assignee)

Comment 8

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

17 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

17 years ago
*** Bug 83539 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 12

17 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

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

Comment 14

16 years ago
I need a reviewer and super reviewer to check these in on the trunk.
r=pink

Comment 16

16 years ago
sr=scc
(Assignee)

Comment 17

16 years ago
Changes checked in on trunk.
Status: NEW → RESOLVED
Last Resolved: 16 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.
(Assignee)

Comment 19

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