■掲示板に戻る■ 全部 1- 101- 201- 301- 401- 501- 601- 701- 801- 901- 1001- 最新50



レス数が1000を超えています。残念ながら全部は表示しません。

MacOS Xはどうよ?

1 :名無しさん@お腹いっぱい。 :2001/03/09(金) 17:45
中身BSD。買いますか?

732 :名無しさん@Emacs :02/04/10 00:13
>>729
タネンバウムもえ〜

733 :名無しさん@お腹いっぱい。 :02/04/10 20:40
('' '' '' '')
%=~0!#"$%<>58+/

734 :名無しさん@お腹いっぱい。 :02/04/10 23:36
テバニやーん

735 :名無しさん@お腹いっぱい。 :02/04/12 01:27
つーかMacでHHKを使っているのだが,
コマンドキー(だっけ?ショートカットキー)が認識しない.
方法ありますかね?当方OS Xです.

736 :名無しさん@お腹いっぱい。 :02/04/12 01:36
あ?キーボードのスイッチで何とかなりそうな疑惑.

737 :名無しさん@お腹いっぱい。 :02/04/13 15:48
「Macのセキュリティは最悪!」タンと遊ぶスレ
http://pc.2ch.net/test/read.cgi/mac/1018520654/

本当に最悪なんでしょうか?

738 :名無しさん@お腹いっぱい。 :02/04/13 16:33
rootを盗るのは難しい。

739 :名無しさん@お腹いっぱい。 :02/04/13 18:01
>>725
遅レスだけど、locale自体が古臭い仕組だし、あってもそんなに
嬉しくないと思うんだが...?
wchar操作関数はもっとちゃんとサポートしてほしいと思うけど。


740 :名無しさん@お腹いっぱい。 :02/04/13 21:02
>>735
 HHKって初代?うちのはHHK2 USBだけどデフォルトのDIP SWで
ちゃんとメタキーがコマンドになってる。初代HHKにADB変換ケーブル
かませてポリタンG3だったらちょっと分からない。スマソ。

741 :名無しさん@お腹いっぱい。 :02/04/14 01:52
ロケールってどこもまだマトモじゃないねえ...
OSX自身も混乱してるし。

742 :名無しさん@お腹いっぱい。 :02/04/14 02:40
つか、Macにlocaleなんていらないじゃん。
X window みたいな国際化サポートのしくみがいまいちな
システムのためにlocale機構が必要なんだったら、
libcも自分で入れてしまえばいいんじゃないの?
Appleにそれを求めるのは変だよ。

743 :名無しさん@お腹いっぱい。 :02/04/14 12:41
>>742
はぁ?
国際化についてもうちょっとお勉強しましょう。

744 :名無しさん@お腹いっぱい。 :02/04/14 15:22
XFree86-4.2 + openmotif-2.2.0

で Ngraph コンパイルしたんですが、

Warning: Widget must be a VendorShell.
Error: attempt to add non-widget child "dsm" to parent "Ngraph" which supports only widgets

とメッセージが出ます。
これ自体は libXt の不具合だそうで ver 4.1のライブラリでごまかしましたが、
結局の所ウィンドウメニューのタグ類に文字が表示されず、日本語以前の問題で挫折しました。

XFree86-4.1 では日本語含めて使えていたのに…


745 :742 :02/04/14 17:23
>>743
ん?もしかして国際化ってlocaleしかないと思ってないか?
localeじゃないと困るところって具体的にどこよ?
おれは「localeを前提としたプログラムが使えない」こと
くらいしか思いつかないのだが。

746 :名無しさん@お腹いっぱい。 :02/04/14 18:14
Aqua とX Windowの日本語の扱いが同じになると非常に助かるんだが.......
先は長そうだ

744のコメントとはあまり関係ないかもですけど
確か、4.1と4.2では日本語の扱い変わってたよね
結局、4.2ではデフォルトでXLocaleが有効になってた

747 :名無しさん@Emacs :02/04/14 19:45
>>746
4.2ではUNICODEでいいかげんな実装されていて、それでOKになってしまって、
XLocaleがONしてある。
だめだめなのにね。。

なので、4.2の場合localeなしでコンパイルして、4.1の時ど同様にするっての
が吉だとおもう。

748 :教えて君 :02/04/16 05:02
15日に cvs で取得した XFree86 4.2 を -DX_LOCALE なしでコンパイルしました。

iBook 600MHz では、フルスクリーンは問題無いものの、ルートレスでは
X の部分だけ、モニターと同期がとれていないような感じ(縦、斜めに縞々が入る、色が変)になってしまいます。

同じような状況に陥った方いますか?
もしくは調整方法をご存知の方いますか?

749 :教えて君(748) :02/04/16 05:18

XDarwin.app の部分だけ (Xquartz.tgz) バイナリ落して来て入れ換えたら
改善されました。

でも何故...


750 :名無しさん@Emacs :02/04/16 07:18
>>749
純粋にその部分のCVS先端にバグがあっただけでは?

751 :名無しさん@お腹いっぱい。 :02/04/16 08:56
Localeの話題になってるけど、Citrus移植しようとしてる人とかいないのかな?

752 :名無しさん@お腹いっぱい。 :02/04/16 11:24
>>745
別人28号ですが、745はわかってないぞ。

> ん?もしかして国際化ってlocaleしかないと思ってないか?

Unixのlocaleって考え方は非常に重要だよ。
localeによって、そのプロセスがどの言語で動いているかを決めている。

> localeじゃないと困るところって具体的にどこよ?

localeで文字のソートなんかもはじめてきまる。
localeで現在のキャラクタセットが決まっているわけだからね。
例えば、en_US.utf8なんてlocaleがあると、
言語は米語、ソートはen_USソーティング、キャラクタセットはutf8て具合に決まる。
これは重要でしょう。

753 :名無しさん@お腹いっぱい。 :02/04/16 11:26
>>731
>ぢゃ、Amoeba使え〜

だからMachを受け継いだDarwinでもいいんじゃないかと。

754 :お役立ちサイトです。 :02/04/16 11:28
役立つサイトを満載したサイトです。
是非見にきてください。
http://home9.highway.ne.jp/cym10262/

755 :名無しさん@お腹いっぱい。 :02/04/16 11:30
>>742
やっぱり、UTF-16しかサポートしないってのは、だめだめですな。
UTF-16はsurrogateで、もう破綻しているからなあ。
OSはUTF-8ネイティブサポートでしょう。やっぱり。

756 :名無しさん@お腹いっぱい。 :02/04/16 11:51
>>754
単なる喫茶店の宣伝。
見に行く必要なし。

757 :745 :02/04/16 16:40
>>752
だーかーらー、そういうのは UNIX locale の専売特許じゃないわけ。
その上で、 locale にどういう優位性があるか聞いているんだよ。
752もやっぱり locale しか知らないんだろ?

758 :名無しさん@お腹いっぱい。 :02/04/16 17:02
>>745
国際化のためには、他にどんな実装が有効だと思う?
locale 以外の実装例とか

759 :745 :02/04/16 19:18
>>758
Carbon/Cocoa/Toolbox(ScriptManager)

プロセス毎に1つの言語環境しか持たないlocaleシステムは
あくまでもi18nのための仕組みであって、m18nのための
仕組ではない。対して、MacはScriptManagerの時代から
ある程度m18nを実現できる環境を備えていた。

UNIXプログラマにそれらを使えと言うつもりはないが、既に
同等以上の環境を持っているAppleにとって、積極的に
localeサポートを行う意義は薄い。もしAppleがlocaleサポートを
行うならば、pthreadとNSThread/MPTaskのような統合を行う
行うべきだが、その労力を割くメリットがあるかどうか。逆に
まったく別の多言語環境としてlocaleシステムを実装するのは
混乱の元だ。そんなものいらない。
もし業界標準になりうるm18nスキームがあるならば、それに
乗っかる意義はあると思うし俺も賛成するけどね。

Free86かeXodusか知らないが、localeに依存したプログラムを
ユーザーの責任で入れるならば、localeもユーザーの責任で
環境構築すればいいだけの話。だれも禁止しちゃいない。
それにAppleがlocaleを実装したとして、またいろいろ不満が
出るんじゃないか?そのときは、Appleが直してくれるのを
のを指くわえて待ってるしかなくなるんだよ?

760 :名無しさん@Emacs :02/04/16 19:58
>>759
> Carbon/Cocoa/Toolbox(ScriptManager)
(w

761 :名無しさん@お腹いっぱい。 :02/04/16 21:49
すいません。長いです

>>759
UNIXの言語環境(正確にはX Window System)の言語環境は local に依存している。
そして、多くのプログラムはそれを利用することを前提に作られている。

MacOSXはNEXT由来の LibC 自体には国際化のための local 機構を載せずにもっと上位の
レイヤーで国際化を行なっている。
そのため、独自の思いきった開発が行え、他のUNIX環境にはない秀逸なFONT環境を手に
入れることができたと言える。もし、既存のUNIXとの整合性を図る向きで国際行おうとし
たら、もっと混沌とした状態になっただろう。それは、他の UNIX の状態をみていれば十分
に解ることだ。

Appleにとっては、いくら UNIX を土台としたMacOSXといえど、やはりMacOS。どれほど
UNUX の面を強調しようとも、MacOSとしての完成度を高めること以外には考えないだろう。
さらに、LibCに手を入れないことは、NEXTの資産を生かすための戦略的な意図もあるだろう。
両者の違いは、いわば、思想の違い。

>既に 同等以上の環境を持っているAppleにとって、積極的に
> localeサポートを行う意義は薄い。
とは、まさにそのとおりだが、 Darwin はオープンなのだから、 Apple にその開発をしろ、と
いう気もない。

762 :761 :02/04/16 21:53
続き

>>759
だが、Appleは新OSの基盤技術にUNIXを利用し、それを大々的に宣伝し、結果、多くのUNIX
ーザーを取り込んだ。さらには、潜在的UNIXユーザーを作り出した。そうなれば、MacOSXで
UINIXのWindow System を使いたいと思うのはごく当たり前の流れ。
しかし、実際には、Aqua とX Window では、同じ Derwin 上にあっても国際化の方法が違う。
そして、それが元で未だにまともな日本語環境を手に入れるのに苦労している。
それでも、MacOSXを使いたい"UNIX"ユーザーの多くは、まともな日本語環境が欲しいのだ。
そして、MacOSX といえど、他で利用されている local を無視することはできない。
それに、MacOSX の UNIX を強調したAppleには、そうして引き込んだUNIXユーザーにある程度
の責任はあるだろう。他のUNIXに劣らない言語環境を実現するための"道しるべ"を示すというのも
その一つ。

LibCに手を入れたくないなら、X Window と LibCとの間に、Aqua並の言語環境を実現する
ための橋渡し的なものが欲しい。
MacOSXの良い所は、Mac の文具的な使い勝手の良さと、UNIXの強力な処理能力をあわせもつ所。
だからこそ、必然と期待は高まる。

君の言いたいことは解るが、それではUNIXユーザーは幸せになれない。
非UNIXユーザーの見地からはそれでも良いだろう。
なにもかも、Appleに要求するつもりはない。
だって、UNIXはオープンなのだから。
Appleは基盤技術にUNIXを採用したことによってUNIX文化のいい刺激になったと思う。そして、
文句を言われながらもAppleは良くやっているとは思う。
でも、Apple には”自らの UNIX ”に対して責任があるのだ。

君は技術的なことには詳しいかもしれないが、色々な背景など全く考慮されていないとしか思えない。
現状で、X Windowを使う人のことなど考えてないのでは?

> Carbon/Cocoa/Toolbox(ScriptManager)
もし、これを使って、X Window から利用できる言語環境を構築するなら、どのようにする?

763 :名無しさん@お腹いっぱい。 :02/04/16 22:20
>>759
なんか、片岡さんの影響受けてる感じだな。

764 :名無しさん@お腹いっぱい。 :02/04/16 23:21
>>757
> その上で、 locale にどういう優位性があるか聞いているんだよ。

だから、もう一度繰り返しますが、
それは一言で言えば、
「プロセス単位で言語を設定できる」ってことだよ。シンプルで良いね。
これはメリットであってデメリットではない。

これは、WinとかMacOSXじゃあできない芸当だと思うぞ。
WinとかMacOSXだと通常はシステムの単一言語ベースだからね。
スレッドなんかにも言語を設定できるが、それはプログラムが設定できるのであって、
それぞれのユーザがコントロールできるのではない。
その点、UnixはLANGを設定すればすぐ言語が切りかえられる。
その簡潔さがすばらしい。

さらにen_US.UTF8なんかのlocaleを使えばUnicodeも使える。
UTF-16にしばられてるOSはやっぱりだめだよ。UTF-8のレンジはさらに広い。

765 :名無しさん@お腹いっぱい。 :02/04/16 23:32
>>761の話は、
じゃあ、Darwinはどうやったら有名になれるのか?
って話になる。
せっかくMachベースでBSDやLinuxとはまったく違った機構なのに。

OSXのCarbon/Cocoa/QuartzレイヤとDarwinのレイヤでは違う。
Carbon/Cocoa/Quartzレイヤで多言語化をしても、
Darwinのレベルで多言語化をしていないのであれば、だめだめでしょう。
やっぱりAppleがどういうふうにDarwinを多言語化していくのか
打ち出していかないとだめなんだよ。ちゃんとlibcまで含めて。

766 :名無しさん@お腹いっぱい。 :02/04/17 00:09
今のところAppleにとって優先順位は低いんだろうな。>国際化

767 :761 :02/04/17 00:34
> 765
> やっぱりAppleがどういうふうにDarwinを多言語化していくのか
> 打ち出していかないとだめなんだよ。ちゃんとlibcまで含めて。
だから、
>MacOSX の UNIX を強調したAppleには、そうして引き込んだUNIXユーザーにある程度
>の責任はあるだろう。他のUNIXに劣らない言語環境を実現するための"道しるべ"を示すと
>いうのもその一つ。
って書いたんよ

> せっかくMachベースでBSDやLinuxとはまったく違った機構なのに。
それが、魅力で以前はMKLnuxとかにも手を出してた(w

> OSXのCarbon/Cocoa/QuartzレイヤとDarwinのレイヤでは違う。
> Carbon/Cocoa/Quartzレイヤで多言語化をしても、
> Darwinのレベルで多言語化をしていないのであれば、だめだめでしょう。
DarwinレベルでAqua並の国際化機構が機能すれば、一番問題が無いというか素晴しい。
てか、Aquaだろうが XWindow だろうが同じように日本語使えたら凄いんだが。
というか、そうあるべきな気がする。
OSXのCarbon/Cocoa/Quartzレイヤでの実装が済んでる以上、今後どこまでやってくれるかは
疑問。
というか、せめて、Terminalで日本語通るようにしてくっれて感じ。
Apple には”自らの UNIX ”に対して責任があるのだ。
いや、ほんとに

768 :名無しさん@Emacs :02/04/17 07:02
>>767
>せめて、Terminalで日本語通るようにしてくっれて感じ。
このあたりはかなり難しい問題なきがする。。。
どうなん実際のところ?

769 :名無しさん@お腹いっぱい。 :02/04/17 08:24
>>759
> あくまでもi18nのための仕組みであって、m18nのための
1個多くねぇ?


770 :名無しさん@Emacs :02/04/17 10:32
>>768
難しいと思うぞ。
パスはUTF-8なのに、ファイルはShift-JISが標準のようだからね。


771 :761 :02/04/17 13:59
>>770
確かにむずかしいだろうね、実際。
ただ、技術的な問題を抜きでいうなら、Terminalって一応、Aqua上で
動いてるプログラムなのだから、その意味でもまともに日本語通って
然るべきなんだがなあ・・・
とぼやく今日この頃

772 :名無しさん@お腹いっぱい。 :02/04/17 14:02
>>770
パスとファイルのコードが違うってどういうことなんでしょう?
ソースもしくは、説明してくれるとうれしいです。

773 :745 :02/04/17 14:16
>>761
UNIXユーザーを引き込んだ責任...かぁ。
だいたい、Macとしてみてもまだ未完成なのに。

ただでさえ同一性障害を起こしてるようなOSにユーザーサイドで X Window
System を持ち込んで、こっちが de facto Standard だ、こっちをサポートすれ、
というのは、いかにもUNIX中華主義だよな。あるいは、行く先々にコロニーを
作りたがる帝国主義というべきか。
しかも、localeサポートなんて全然前向きじゃないし。

何度も書くけど、コロニーでも租界でも作るのは自由だよ。でも、なんでそれを
Appleに求める?
俺がUNIXを使いはじめたのはそんなに昔じゃない。けどつい最近までは、新しい
マシンを入れたらまずXをmakeして、sendmailやbindも入れ替えるというように、
自分で必要な環境は自分で構築するのが当たり前だったじゃないか?
それができるのがUNIXのいいところだろ?

XFree86のチームが「Appleのlibcがまともにならないと国際化対応できない」
とでも言っているのか?俺に届いた電波によると、やつらは鼻クソほじりながら
「兄弟、ニホンジンが何か言ってるぜ(藁」と言ってるぞ。

>> Carbon/Cocoa/Toolbox(ScriptManager)
>もし、これを使って、X Window から利用できる言語環境を構築するなら、どのようにする?
普通にframeworkをリンクして呼び出せばいいはずだが。ただのCの関数だし。
別にCarbonやCocoaのイベントモデルが強要されるわけじゃない。

774 :745 :02/04/17 14:17
>>764
やっぱりわかってないな。
ユーザー環境における言語というのは、メッセージやメニューなどに表示する
ために選択されるものだから、そう頻繁に変更する必要はない。
一方、データとして扱うテキストの言語は、ユーザーの環境がどうあろうとも
日本語なら日本語、タイ語ならタイ語と正しく扱える必要がある。
Mac OS X ではログインセッション毎の言語環境を自由に設定することが
できるし、それとは別にアプリケーションの優先言語を設定することもできる。
もちろん、アプリケーションが正しく国際化されていれば、そのどちらの環境
とも独立に、多言語を扱うことができる。

UTF-16に対する批判は尤もだと思う。
ただ、国際化プログラミングにおいては、内部コードはマルチバイト系よりも
ワイド文字系にした方が圧倒的に楽なのは明らか。UTF-16は純粋にワイド
文字と言えないところが痛いが。


775 :745 :02/04/17 14:18
>>770
「ファイルはShift-JISが標準」ってなんだよ(w
漢字Talk2.0のころの話か?

TerminalがUS-ASCII以外表示されないのは、表示部分の問題だろうね。
内部的にはそのまんまUnicodeが通るはず。
理由はふたつ考えられる。
ひとつはUnicodeの問題。例のEastAsianWidthをどう解釈するか。
もうひとつは、フォントの問題。このあたりの問題は、先駆者である
MuTermのドキュメントなどに解説されている。

日本人としては「日本語だけでいいからなんとかサポートしてほしい」と
思うだろうけど、Appleとしてはやりたくないだろう。

776 :名無しさん@お腹いっぱい。 :02/04/17 14:20
>>770
ん?基本的に全部 UTF-8使うのがお約束だぞ。
HFS+ の仕様書に書いてあるからよむべし。
なんか変なアプリつかって書き込んでないか?

>>768
UTF-8 ベースで「端末」を作り上げるのは、全体を再設計しないといけないから
放置されてるんだろう。たぶん。

>>767
Terminal は俺も日本語は出るようにするべきだと思うけど、それは
Terminal 固有の問題。UNIXうんぬんとは関係ないだろう。

つーか、なんか根本的に勘違いしてるやつが多いようだけど、Mac OS X の
基本的な国際化機能は Aqua のレイヤじゃないぞ? Carbon/Cocoa でも
ないし、ましてや Quartz でもない。

どこがやってるかっつーと、Core Foundation っていう、低レベルライブラリ。
Bundle サービスが地域別のリソース (C Locale のメッセージングに該当)を
提供していて、 String サービスが、エンコーディング周辺の機能を提供してる。
Carbon や Cocoa はこれをよびだしてる。

で、これは Darwin の一部であって、Mac OS X の専売特許じゃない。
コンソールアプリからでも Xアプリからでもリンクすりゃー普通に使える。
>>767 さんがお望みのものははじめからあるわけ。

まあ、C Locale に比べればポータビリティおちるけど、仕様としては
はるかにまともなブツ。Mac OS 9 版もある。GNUStep も持ってる。
(仕様古いし、まともに日本語は出ないと思うけど)
これがある以上、Apple は「国際化」の観点において「自らのUNIX」には
十分責任をはたしているといっていいだろうて。
世の中の他の UNIX が遅れすぎなだけ。

あえて問題にするのなら、それは「C標準をまじめにサポートしていない」と
いう点だろう。それをサポートする価値があるかどーかという点の判断は
俺はパス。まあ、Apple は価値無しと思ってると思う。

MS はなにげにサポートしてるんだけどね > C Locale

777 :名無しさん@お腹いっぱい。 :02/04/17 15:47
libxpg4なんてどう?
これってスマートで良いかなと。
選択的な使用もできるしね

778 :767 :02/04/17 16:08
>>776
>Core Foundation っていう、低レベルライブラリ。
>コンソールアプリからでも Xアプリからでもリンクすりゃー普通に使える。
そうなのか。
なら、確かに思い違い、スマソ
じゃあなぜ、これを利用しようとしないんだろう?
そういうプロジェクト聞いたことある?

> これがある以上、Apple は「国際化」の観点において「自らのUNIX」には
> 十分責任をはたしているといっていいだろうて。
そりゃそうだ

> MS はなにげにサポートしてるんだけどね > C Locale
これ、おもしろいね

779 :名無しさん@Emacs :02/04/17 20:45
>>776
すまん、日本語が下手だった。

パスのコードはUTF-8で、
ファイルの中身(テキストのコード)はShift-JISが標準

と言いたかった。

Terminalに限った話をすれば、デフォルトでUTF-8を表示できるようにして、
テキストファイルの中身を見たけりゃ、何かしらのフィルターを通すことに
なるんだろうね。きっと。


780 :名無しさん@お腹いっぱい。 :02/04/17 21:20
>>774
> 一方、データとして扱うテキストの言語は、ユーザーの環境がどうあろうとも
> 日本語なら日本語、タイ語ならタイ語と正しく扱える必要がある。

テキストの「デフォルト」の言語のことを言っているんだよね?
それともテキストのcharsetのことを言っている?
多国語テキストの場合、デフォルトの言語も大事だがcharsetも大事だよね。

> Mac OS X ではログインセッション毎の言語環境を自由に設定することが
> できるし、それとは別にアプリケーションの優先言語を設定することもできる。

それだけじゃ、アピールにならん。言語の扱いはUnixもMacもWinも対して変わらないな。
俺は逆にMacの方がGB18030やUTF-16サロゲートなんかの多国後対応が遅い感がある。
さらに、GB18030ネイティブキャラクタセットサポートってWinやMacじゃ無理だよね。

で、OSXの場合、それはネイティブのキャラクタセットを決めているのではないよね。
その場合はリブートしなくちゃならない。(だよね?)
Unixでのlocaleは現状、キャラクタセットもコントロールしているよね。
で、それがプロセス単位でできるわけです。
そっちのほうが柔軟だと思うよ。

> もちろん、アプリケーションが正しく国際化されていれば、そのどちらの環境
> とも独立に、多言語を扱うことができる。

それもMacだけの話じゃないな。

781 :780 :02/04/17 21:22
>>774
> ワイド文字系にした方が圧倒的に楽なのは明らか。UTF-16は純粋にワイド
> 文字と言えないところが痛いが。

なんでワイド文字系にした方が楽なんだ???
1文字という概念は、UTF-16であってもsizeof(WORD)が1文字ではないぞ。
ThaiとかArabicとかそんなのいくらでもある。
さらに、surrogateもある。surrogateはもう実際に使われているんだよ。
surrogateに含まれる文字もGB18030なんかで採用されたわけだからね。

782 :名無しさん@お腹いっぱい。 :02/04/17 21:33
>>778
> > MS はなにげにサポートしてるんだけどね > C Locale
> これ、おもしろいね

つーか、使い物になりましぇーんという感じが。。。
MSのRuntimeのlocaleまわりってバグバグなんだもん。

W関数呼んで変にネイティブに直して、
全部キャラクタがフォールバックして'?'になってたりとか。

783 :名無しさん@お腹いっぱい。 :02/04/17 21:49
>>778
ICU - http://oss.software.ibm.com/icu/
これ最強でしょう。


784 :名無しさん@Emacs :02/04/17 22:32
>>775
うん?
MacOSX標準のTextEditってRTFでShift-JISが初期設定。
ってか設定しないとほんんどのテキストエィタでShift-JISになってしまう。

内部的にも通るとは思えんのだが?
Unicodeに対応させるにはかなり大変だったりする。
TerminalがもしNeXTの物の移植なら、内部的にも対応してないと思う。

>>776
>Core Foundation っていう、低レベルライブラリ。
勉強になるけどあとで調べないとな(-∀-)

>ん?基本的に全部 UTF-8使うのがお約束だぞ。
これはfilenameとかの話だよね?
ファイル内容に関しては規定されてないきがするのは気のせい?
再調査しないと不明。

>>>777
まあいまの所いいのでは?

>>>783
Javaはここらへん結構整備されつつある。
まあいまのところ最強にちかくて、これとかつかって国際化されたデスクトッ
プ環境作成とかってできるらしいぞ。。





785 :名無しさん@お腹いっぱい。 :02/04/17 23:00
>>783
> Javaはここらへん結構整備されつつある。

いや、まだまだ。だから、Java版ICU4Jがある。

> まあいまのところ最強にちかくて、これとかつかって国際化されたデスクトッ
> プ環境作成とかってできるらしいぞ。。

まあ、Javaくらいなら、最近のWinからMac、Unixとかもできるよね。

786 :名無しさん@お腹いっぱい。 :02/04/17 23:04
>>776
> どこがやってるかっつーと、Core Foundation っていう、低レベルライブラリ。
> Bundle サービスが地域別のリソース (C Locale のメッセージングに該当)を
> 提供していて、 String サービスが、エンコーディング周辺の機能を提供してる。

うーん、ソース見てみるとわかるけど、
CoreFoundationって、結構ASCII(それかせいぜいLatin1)しか実装していないとか。
忘れちゃったけど、CFSTR()の中とか、そうじゃなかったっけ?
まだ完全じゃないよな。

787 :名無しさん@お腹いっぱい。 :02/04/17 23:38
>>784
> Javaはここらへん結構整備されつつある

その割には、Surrogateもサポートしてないじゃん。
JavaのサポートするUnicodeのバージョンってなんだ?

http://java.sun.com/j2se/1.3/docs/guide/imf/api-sample/IMFDemo.html
では、日本語Winだと日本語しか入れられん。。。

788 :745 :02/04/18 01:16
>>781
>ThaiとかArabicとかそんなのいくらでもある。
それはノーマライズか合成字母の問題だろう?Unicodeベースである以上、UTF-8でも
UTF-16でも同様に発生する問題だ。現実世界での文字とコード上の文字とが必ずしも
一対一に対応しないのは、ある意味避けられない。現実世界における「文字」の定義
自体が曖昧なのだから。
この問題とマルチバイト文字の解釈の問題はレイヤーが違う。マルチバイト文字の解釈と
文字の合成を1パスで行うのは非常に困難だし、アプリケーションの要求によっては
機械的に合成してはならない場合もある。

ワイド文字はその単位で扱う限りコードとしての正しさは保証できるし、サイズが
決まっているので、単一文字コード単位のプログラミングインターフェースを利用する
こともできる。ただそれだけだ。

>さらに、surrogateもある。surrogateはもう実際に使われているんだよ。
そう、それはUTF-16の問題だ。だからUTF-16は純粋なワイド文字コードとは言えない。
10.1から第2面の文字も一部追加されたようだが、まだunicharのインターフェースも
あるし、Appleはどうするつもりなんだろうか。

789 :745 :02/04/18 01:19
>>780

GB18030か、えらくでかい話を持ってきたな、オイ(w
たしかに Mac OS X はさまざまな点でUnicodeの制約を背負い込むことになった
わけだが、現状Unicodeに替わる国際キャラクタセットがない以上、十分
リーズナブルな選択だと思うぞ?
Unicodeにマッピングできる範囲でならば、必要ならばサポートすることも可能だろうし。
もちろん>>759で書いたように、それら全てを包含できるスキームができるのであれば、
それをMac OS X のベースに持ってくるのは歓迎なんだが。

>で、OSXの場合、それはネイティブのキャラクタセットを決めているのではないよね。
>その場合はリブートしなくちゃならない。(だよね?)
>Unixでのlocaleは現状、キャラクタセットもコントロールしているよね。
>で、それがプロセス単位でできるわけです。

>>774を読んだ上でこう書いたのだとしたら、意味が分からん。
各言語環境にはそれぞれ標準のキャラクタセットが規定されてはいるが、実際に
外部表現として何を使うかは、データに応じて、あるいはユーザーの指示によって
アプリケーションが決めればいい話だろう?
多言語環境ではひとつのプロセスが複数の言語/キャラクタセットを扱うことに
なるわけだから、それをプロセス単位でしか決められないんじゃまずいだろう。

>それもMacだけの話じゃないな。
もちろんそうだよ。だから、それが当たり前になってきているこの御時世に、
いまさらlocaleでもないだろうと言っているだけ。

Mac OS X が完璧だとか言ってるわけじゃないよ。坂村健とかに言わせりゃ、
やっぱり超漢字の敵じゃないってところだろう。良くも悪くもUnicode縛りだし。

790 :745 :02/04/18 01:22
>>784
だから、初期設定はあくまでも初期設定であって...

>内部的にも通るとは思えんのだが?
>Unicodeに対応させるにはかなり大変だったりする。
>TerminalがもしNeXTの物の移植なら、内部的にも対応してないと思う。

大変と思うか?外部エンコーディングの選択は既に実装されているし、
その場合の内部コードはUnicodeが自然だ。他にもキー入力や、文字コード
からグリフを特定する場合もUnicodeが基本になっている。
あえて内部コードを別のものにする理由がなければ、Unicodeのままが一番
自然なんだが。

NeXTのTerminal.appとはほとんど別もんなんじゃないかな。
NeXTにあったなんとかの機能が無いと騒いでたやつもいたし。

791 :776 :02/04/18 02:15
>>780
ああ、そこを勘違いしてるのか。リブート不要だよ。

心配しなくても Mac OS X はしっかり UNIX だから(笑)
各アプリケーションは、起動時に自分の locale を決定して、
それに応じてメニューやメッセージを組み上げるようになってるよ。

Mac OS X の 「System Preference/地域/言語」の指定は、
「全アプリケーション共通のデフォルトの言語優先順位」を変えてるだけ。
これを変えたあとに起動したアプリケーションは、その新しい言語で
起動する。動的に追随はしないんで既に起動してるものは影響をうけない。
っつーわけで、Finder のメニューを変更したければ、Finder を再起動
する必要があるわけね。で、解説には「ログアウトしろ」って書いてる。
別にログアウトせんでも、タスクマネージャから再立ち上げしてしまえば
さっくり変わる。

動的に起動時に locale を決定する方法はたぶんあるに違いないと
思ってるんだけど、あいにく俺は発見してない。まあ、Mac OS X では原則
同一アプリケーションは同時にひとつしかあげないから、アプリケーション
毎に言語指定したければ、defaults コマンド使ってアプリごとに言語指定
をアプリ別の Preference に追記しちゃえばいいんだけどね。
あいにくコマンドラインでしかないけど、GUIを作るのは難しい
ことじゃないだろう。テキストエディタで編集してもOK(笑)

Finder がそういったサポートしてくれたほうが俺はうれしいけど、
たぶん混乱するからそういったことはしとらんだけだと思う。

余談だけど、Windows も今は内部的にはプロセス毎のはずだよ。
ただ、これも起動のためのインターフェースが無い。
WinXP Pro の多言語版なら、ユーザ毎に言語インターフェースがまるごと
変更可能なので、別ユーザによる起動と併用したら任意に混在できると
思うけど実験したことはない。


792 :776 :02/04/18 02:26
>>779
 そりゃ Win も同じだ。心配すんな。
 作り方はポリシー次第だけど次のどっちかかな
 
  a. 端末を UTF-8 化
ls は垂れ流し
cat の表示はあきらめる

b. 端末を任意のエンコード
ls は国際化して、 UTF-8 -> 表示用エンコード の処理を入れる
cat の表示は指定してるエンコードならばっちぐー

Win は b. の方針やね。

>>784
ファイルの中身は別になんでもよかろーて。
EUC な Unix 環境で普通に SJIS のファイルとかつくるやろ(笑)
古典UNIX だと、パス名をロケールの文字列で処理しようとするから、
混在するととたんに不都合がでる。固定エンコードにして、
ファイル操作は専用API通すようにするほうが、基本的には
すっきりする。「ASCIIのみ使う」ってのはある意味そういう
ことなのねん

>>786
あれ、そうだっけ。ソースはみてないんや。すまん。
あとでなんかコーディングして確認してみる。
Apple のことやから、Darwin 側には反映してないっつーのもありそうだ。


793 :名無しさん@お腹いっぱい。 :02/04/18 12:25
>>788
> この問題とマルチバイト文字の解釈の問題はレイヤーが違う。マルチバイト文字の解釈と
> 文字の合成を1パスで行うのは非常に困難だし、アプリケーションの要求によっては
> 機械的に合成してはならない場合もある。

いや、俺もUnicodeを使うってのは賛成だよ。
でもワイド文字がUTF-16って意味で言っているのなら、それは俺と意見が違う。
君の言うとおりUTF-16もUTF-8もすでにポインタを進めるということは文字の境界と関係ないんだから。
(だからワイド?って聞いた。surrogateやcombining charの話をしたわけ。)
俺はUTF-8が良いと思う。Unixのシステムコールの実装にもあうし、endianの意識をさせる必要もないし。

794 :名無しさん@お腹いっぱい。 :02/04/18 12:44
>>789
> >>774を読んだ上でこう書いたのだとしたら、意味が分からん。

俺が考えてたのは、たぶん、WinやMacのNative CharsetとUnicode(UTF-16) Charsetの
世界を分けるのが、なんかぎこちなく感じたからだと思う。
MacやWinでもアプリケーションに対するデフォルトの言語、Charsetの考えがあるけど、
それだったら、Unixのlocaleのように、なんで、ja_JP.SJISとか、ja_JP.eucjpとか、ja_JP.UTF8とか
できなかったのかな。Unicode(UTF-8)もひとつのcharsetってことで、すっきりしてるじゃん。

あとUnixのLocale Functionですべてをしろってつもりで言ったんじゃないよ。
このスレでも出てたけど、ICUなんて、だから便利なものがある。
CoreFoundationのi18n String APIより、マルチプラットフォームの標準を狙ってるだけに、
俺としては好感度高いけどなあ。

>>791
リブートはWinだったね。スマソ。
Winでは、GetACP()の結果を変えるにはReginal Settingsの
System Localeを変えて、リブートしなくちゃならないんだよね。

795 :名無しさん@お腹いっぱい。 :02/04/18 12:53
>>786
Core Foundationのソース公開は一部だけなんだよ。
OS XのCore Foundationをブラックボックスだと考えて
適当にあれこれ関数呼び出ししてみると、
公開されているソース以上の処理をしているのが分かると思う。


796 :745 :02/04/18 20:20
>>793
>でもワイド文字がUTF-16って意味で言っているのなら、それは俺と意見が違う。
最初からもう一度言葉を拾ってみるよ。UTF-16は「ワイド文字系」のコードだが
「純粋なワイド文字とは言えない」というのが俺の認識だ。
まぁ、せこいまねをしてそのメリットを大幅に減じてくれたもんだとは思うが。

それから、endianの問題などと書いているが、俺が外部表現としてもUTF-8より
UTF-16の方が良いと主張していると思っていたんだったら、それは違うぞ。
外部表現はUTF-16でもUTF-8でも好きなものを使えばいい話だし、エンコーディング
としてUTF-8が優れているということは十分理解している。

>>794
>俺が考えてたのは、たぶん、WinやMacのNative CharsetとUnicode(UTF-16) Charsetの
>世界を分けるのが、なんかぎこちなく感じたからだと思う。
外部表現としてならば、Unicodeもone-of-themという認識は同じだ。
ただ、内部形式としてどのようなcharset/encodingを使うかといった場合、
複数のローカルなコードを扱うのと、Unicodeのようなひとつのグローバルな
コードを扱うのとでは大きく違うと思うんだが。

>このスレでも出てたけど、ICUなんて、だから便利なものがある。
>CoreFoundationのi18n String APIより、マルチプラットフォームの標準を狙ってるだけに、
>俺としては好感度高いけどなあ。

うん、最初にも書いた通り、こういった形で X Window System の国際化
環境との融合が図られるのであれば、俺も大賛成だ。

797 :名無しさん@お腹いっぱい。 :02/04/18 21:09
>>795
> Core Foundationのソース公開は一部だけなんだよ。

例えばどのAPIが公開されてない???
ちなみにCocoaのFoundationクラスのことを言っているんじゃないからね。w)

String.subproj, StringEncodings.subproj
をぱぱっと見たところ、String関係は、一通りそろってる感じがしたんだけどなあ。
あとで、試しにビルドしてみよう。

> OS XのCore Foundationをブラックボックスだと考えて

CoreFoundationは、OSXじゃなくてDarwinだよーっと。
これが本当ならIntel版Darwinも
このへんはソースからコンパイルできないってことか?

CFSTR()は今ソース見てみたけど、(CFString.cの__CFStringMakeConstantString()が実装)
将来的にUTF-8で扱おうって感じなんだけど、non-7 bitのStringは
すべてMacRomanのcharsetで扱ってる。あらら。

798 :794 :02/04/18 23:53
>>796
> ただ、内部形式としてどのようなcharset/encodingを使うかといった場合、
> 複数のローカルなコードを扱うのと、Unicodeのようなひとつのグローバルな
> コードを扱うのとでは大きく違うと思うんだが。

正しいと思うよ。
理想はUnixのtoolがすべてそれをやってくれたらいいんだけどね。
locale自体の存在は良いと思うんだよ。それはWinのUser localeであり、
Macのアプリケーションのデフォルトscriptと同じものとして使えばね。

OSXのTerminalの話だけど、これは>>792の人が言ってる選択肢があると思う。
俺は、Terminalは、別に無理せずに、
WinのDOS Promptのchcpでコードページを変えるのと同じで良いと思うなあ。
見えないものは見えない。見たいときにはlocale変えりゃあいい。

799 :794 :02/04/18 23:58
>>798
つーか、muleのようにするってことでいいのか。

800 :名無しさん@お腹いっぱい。 :02/04/19 17:03
>>797

> 例えばどのAPIが公開されてない???
APIじゃなくて、実装の日本語周りとか。

> ちなみにCocoaのFoundationクラスのことを言っているんじゃないからね。w)
Core FoundationがNeXTのFoundation KitをCに焼き直したもので、
CocoaのFoundation Kitはそれ自体がObjective-Cで完結していなくて
Core Foundationに被さっている部分が多いっての分かってる?

> CoreFoundationは、OSXじゃなくてDarwinだよーっと。
Darwinで公開されてるCore Foundationの実装は
日本語周りとかが欠けてるんだってば。
だ、か、ら、Core Foundationレベルでも完全に一致してないの。
OS XでCore Foundationに日本語処理させたらちゃんと処理するけど、
同じコードをDarwinで使ったら駄目駄目なの。

> これが本当ならIntel版Darwinも
> このへんはソースからコンパイルできないってことか?
日本語周りはできないよ。Intel版だけじゃなくてPPC版も。
だって入ってないんだもん。


801 :名無しさん@お腹いっぱい。 :02/04/19 18:41
ところでよ、MacPowerの5月号に風穴こうってやつがMacOSXは
マイクロカーネル使っているからUnix的ではないとほざいている。

でも、マイクロカーネルかモノリシックかっていうのはUnix的かどうか
ということに影響するのか?
確かにLinux的ではないということになろうが。。。。
賢者の意見希望。

802 :名無しさん@お腹いっぱい。 :02/04/19 19:05
マイクロカーネルもあれだがHFS+もどうかとおもう

803 :名無しさん@お腹いっぱい。 :02/04/19 19:16
>>801 当然

804 :名無しさん@お腹いっぱい。 :02/04/19 19:26
>>801
その記事は見て無いので前後の文章が分からないのだが、
Mac OS XのカーネルはMach 3.0ベースではあるが、
マイクロカーネルとOSサーバーに分割された構成をとっておらず、
厳密な意味でのマイクロカーネルではない。

よって、「Mac OS Xはマイクロカーネルだから〜」という意見は
見当違いだと思われ。

805 :名無しさん@お腹いっぱい。 :02/04/19 22:23
MacOS Xの実装を見てる訳じゃないから、どうかわからないけど、
性能が必要な部分を、意味的に完全に分離した状態でカーネル空間に
in kernel processとしていれているというのであれば、マイクロカーネル
構成でないと、いいきるのはどうだろう?

マイクロカーネル&モノリシックカーネルなんて意味分けは無意味だとおもうけどね。

ついでに、マイクロカーネル構成でもUNIX的なセマンティックスを提供して
いるのであれば、やはりUNIX的なんじゃないだろうか。
Machなんてそのもっともたるものだし。

806 :名無しさん@お腹いっぱい。 :02/04/20 00:16
ちなみに風穴氏は次のように述べている。
以下引用

MacOSXが「UNIX」ベースと表現されることがあるが、厳密にはそれは
間違いだ。確かにUNIXとしてのAPIをサポートするレイヤーが搭載され
てはいるのだが、OSとしての根本的な部分を担っているのはMachであり、それは決して「UNIX的」なものではない。

中略

Linuxは、伝統的なUNIXと同じくOS全体が「一枚岩」で構成されており、
マイクロカーネルに対してこれは「モリシックカーネル」と呼ばれている。


807 :名無しさん@お腹いっぱい。 :02/04/20 00:41
>>806
ありがとうー。

なるほどそういう文脈だったら、そんなにまちがいではないか。
でも、MachってBSDのバイナリ互換を目標としてたからなぁ。

808 :名無しさん@お腹いっぱい。 :02/04/20 00:54
>>807
Mach3以降はOSサーバ含んでないから他のUNIX系OSとの互換性なんて
それ単体では一切無関係なわけだが

809 :807 :02/04/20 01:11
>>808
質問!調べろとかいわれそうだけど(^^;
MacOS XのBSD層以外は、BSD層の上にのっかっているわけでは
なくて、直接Machにのっかってるの?

微妙にはなしがすりかわってるのは勘弁してくださいなのだが…。
BSD層にかなり依存してそうっていう主張をしてみたくなったので、
すこし切り口をかえてみた。

810 :名無しさん@お腹いっぱい。 :02/04/20 01:25
>>806
これだけ読むと
>>801
> マイクロカーネル使っているからUnix的ではないとほざいている。
なんてことは言ってないな。
MachはUnix的ではない、とは言ってるが。

811 :名無しさん@お腹いっぱい。 :02/04/20 01:38
>>809
調べろ

812 :名無しさん@お腹いっぱい。 :02/04/20 01:40
Unixみたいなユルいカテゴリーに「的」論は不毛と思われ

そんな話題を振るヤツは「煽ラー」とよばれることを覚悟されよ

813 :807,809 :02/04/20 01:48
>>811
わかった、あしたにでもdocumentよむよ。
酒呑んでるとどーもめんどくさくなっていかん。

>>812
すげー正論なので反論の余地なしなんだけど、
個人的にはこういうくだらんねたも、たのしくていい気がするよ。

814 :名無しさん@お腹いっぱい。 :02/04/20 09:20
MachはUnix的でない、と。。なのに
DEC UNIX(Unix95認定)はMach2ベース。。何故に?

815 :名無しさん@お腹いっぱい。 :02/04/20 09:38
BSD Magazine No.11によるとOS Xのカーネルはモノリシックらしいよ。
以下p.117より引用。
ご存じのように、Mac OS Xの中心部はDarwinと呼ばれるOSであり、そのカーネルxnu
はOSF/mk Machカーネルのソース、4.4BSD-Lite2のカーネルのソース、そしてNeXTで
開発されたソースなどを合体させ、そこにAppleがかなり手を加えたものになっている。
実は筆者は完全に誤解していたのだが、xnuはモノリシックなカーネルだそうだ。
そもそもMac OS Xはマルチサーバーになる必要がないため、ユーザーの視点から
見ればBSDサーバーがクラッシュするということはシステム全体がクラッシュすると
いうこととほぼ同じであり、マイクロカーネルにすることによってMachをBSDから
守ると言うことが特にアドバンテージにはならないそうだ。それよりもモノリシック
なカーネルにしてスピードアップをはかるほうが重要だというわけだ。

816 :名無しさん@お腹いっぱい。 :02/04/20 09:41
>>815
それはそれであまりに紋切り型な解釈だな…
筆者誰?

817 :797 :02/04/20 12:28
>>800
> Darwinで公開されてるCore Foundationの実装は
> 日本語周りとかが欠けてるんだってば。

Darwin単体での、ソースが公開してるCoreFoundationは
CF-liteと言って、OSXのCoreFoundationの一部のみというわけではなく、
まったく別物らしい。それ自体はコンパイルできるみたい。
READMEにこれはCF-liteですみたいなことが書いてあった。。。

> OS XでCore Foundationに日本語処理させたらちゃんと処理するけど、
> 同じコードをDarwinで使ったら駄目駄目なの。

よーくみたら、
日本語だけじゃなくて、Latin-1以外の実装はしてないみたい。だめだこりゃ。
libcだけじゃなくて、CF-liteもまるまる実装ぬけてるという。。。あーあ。

818 :名無しさん@お腹いっぱい。 :02/04/20 12:37
>>814
Mach2ベースってことは、まだBSDのコードが残ってたからね。
Mach3になって初めてMicrokernelになったんだよ。

>>815
> 見ればBSDサーバーがクラッシュするということはシステム全体がクラッシュすると
> いうこととほぼ同じであり、マイクロカーネルにすることによってMachをBSDから
> 守ると言うことが特にアドバンテージにはならないそうだ。それよりもモノリシック
> なカーネルにしてスピードアップをはかるほうが重要だというわけだ。

というか、CMU Mach3.0は、本当に4.3BSD(4.2BSDだっけ?)のバイナリエミュレーションが
可能だったんだよ。4.3BSDのプログラムならコンパイルなしで動いた。
それと同時にmdosサブシステムもあって、こちらも、DOSのバイナリエミュレーションで動いてた。
つまりサブシステムを追加すれば、それらが同時に動いてた。

で、OSXの場合、
PowerPCのFreeBSDのバイナリエミュレーションなんて、あまり喜ぶ人いないからなあ。
だからカーネルを入れちゃってもかまわなかったんじゃないの?

819 :名無しさん@お腹いっぱい。 :02/04/20 12:40
>>818
4.3BSDなOSサーバはMach3とはいちおう別モノなんではないかと

820 :名無しさん@お腹いっぱい。 :02/04/20 12:46
>>809
> 質問!調べろとかいわれそうだけど(^^;

しらべろぉー。

> MacOS XのBSD層以外は、BSD層の上にのっかっているわけでは
> なくて、直接Machにのっかってるの?

Machに乗ってるといえると思う。
BSDのプロセス管理は、そのままMachのTask/Thread管理にまかされてる。
仮想記憶なんかも、MachのVMを使って実装されてる。
プロセス間通信も、MachのPortを使って実装されてる。
Pthreadも実は中は、Machのcthreadを呼んでる。
あと、ファイルシステムはもともとMachにないからBSDのお仕事。

ちなみに、otoolなんかを使えばわかるけど、
Cocoaの分散オブジェクトの実装や、Quartzのウィンドウシステムなんかも、
MachのPortによるIPCを直に呼んでる。

821 :名無しさん@お腹いっぱい。 :02/04/20 13:23
>>820
質問と答えがびみょ〜にずれてるような…

CocoaやらCarbonやらがBSDレイヤーに依存してるかどうかを
知りたいものと思われ

822 :807,809 :02/04/20 13:53
うー、二日酔い。
>>820,821
それは、プロセス管理も、ポートも、cthreadもつかわなかったらMachを
ベースにする甲斐がないですとおもうっす(^^;;

だいたい820の意図のとおりなんだけど、
ufsはBSD layerなんだとおもうがHFS+の実装もBSD layerに入ってるのであれば
わりとBSDに依存してMacOS Xっていうシステムを作ってることになるよね。
同様にCoreFundation以上とかはどうなってるんだろうー?とおもったんだけど。

>>818
バイナリエミュレーションをするならカーネルに入れちゃった方がらくなのではないですかね。
Mach3の実装のほうがトリッキーにみえる。

823 :807,809 :02/04/20 16:52
ざーっと、document(SystemOverview)と、Darwinのソースをながめてみた。
基本的にファイルシステムはBSD subsystemのVFS上にすべてのっているのだね。
HFSもUFSも。あと、TCP/IPもBSD subsystemが担当してるのだね。

プロセス/スレッド管理&VMはMachが管理している以上、Mach IPCが多用されて
いるのは当然だろうけど、これだけBSD subsystemに依存しているのであれば、
十分BSD baseと言ってもよいきがするのですが。

824 :名無しさん@お腹いっぱい。 :02/04/20 22:17
Mutermって探してみたけど
どこにありますか?

825 :名無しさん@お腹いっぱい。 :02/04/20 22:57
>>824
MuTerminalのことだとしたら、ここから取れる。
ttp://www.bebits.com/app/980
本家はなくなったみたい。

826 :名無しさん@お腹いっぱい。 :02/04/21 00:53
>>821
> 質問と答えがびみょ〜にずれてるような…

しまった、よっぱらいながら書いてたので、間違った。スマソ。
>>809は、
> MacOS XのBSD層以外は、BSD層の上にのっかっているわけでは
> なくて、直接Machにのっかってるの?

だったのね。s/MacOS XのBSD層以外は/MacOS XのBSD層は/
と勘違いしてしまった。よっぱらいだ。

otoolを使って調べてくと、
CarbonとかCocoaも
vm_*(仮想記憶)とかmach_*(ポートIPC管理とか)とか
mig_*(RPC)とかのMachのシステムコールをいろいろ直に呼んでることがわかる。
つーか、BSDのシステムコールも同様に呼んでる。
Machのシステムコールがなかったら、BSDのシステムコールって感じなのかな。
いずれにせよ、OSXはMachベースのOSじゃないと移植はそう簡単にはいかなさそうだね。

827 :名無しさん@お腹いっぱい。 :02/04/21 01:05
>>826
今日も酔ってますか?わたしは酔ってます(おい)

OS XはMachベースじゃないと、移植は不可能でしょうな(^^;;
できても使える速度でうごかさなげ。

そういえば、OS Xってそうとう重いOSだとおもうけど、
どのあたりがいちばんのボトルネックなんだろう?

828 :名無しさん@お腹いっぱい。 :02/04/21 02:41
>>827
Aqua

829 :名無しさん@お腹いっぱい。 :02/04/21 02:45
>>828
やっぱ、Aquaなのかな?
でもBSD applicationとかでも明らかにおそくない?
コンパイルとか。disk IOあたりが結構よわかったりするのかなぁとか
おもったのだが。



830 :名無しさん@お腹いっぱい。 :02/04/21 09:26
>>829
DiskがIDEだから??

831 :名無しさん@お腹いっぱい。 :02/04/21 14:30
>>827
> 今日も酔ってますか?わたしは酔ってます(おい)

いえーい。酔ってまーす。
酒の肴にDarwinですかねー。

>>829
XFree86のFull Screen上でも遅い感じがする?


掲示板に戻る 全部 前100 次100 最新50

read.cgi ver5.26+ (01/10/21-)