■■ Ｍ ａ ｃ で プ ロ グ ラ ミ ン グ ■■

Ｍacのｴﾐｭって、サイコー
http://teri.2ch.net/test/read.cgi?bbs=mac&key=999937246&ls=50

ここを見ていてMacの良さを感じたのですが、
68ｋ　Macでプログラミングはできないでしょうか?

６８ｋ　Ｍａｃｉｎｔｏｓｈで使えるプログラム
（Winｄoｗｓで言うEXEファイル）が作りたいのですが、
お金をかけずに作る方法はないのでしょうか？

また、Mac版のHSPは、６８ｋでつかえるのでしょうか？

ついでにMaｃのプログラミングの話題、募集中〜♪ﾐﾐ

エミュレーター上でちゃんと動くかは分かんないけど
Apple純正のMPWなら無料で使えるはず。当然６８K
用のアプリも作れる。MPWについては↓で見つかる
と思うよ。

http://developer.apple.com/ja/

でも、本格的なものを作るならやっぱCodeWarrior（有料）
じゃないかな。

あるいはエミュレータじゃなくて普通にOSXを使えば無料
ですごい開発環境がついてくるけどね。

REALbasicがある

>>2
たしか、Mac OS X は、UNIX ベースなんですよね。
UNIXベースのＯＳでは、Ｃ言語も扱うことができるらしいですし。

いっそのこと、６８ｋマックでＯＳ　Ｘが動けばいいのに。。(^^;

あれ？あと、６８ｋMacで使えるLinuxってありませんでしたっけ?

ヤメレ

SimpleIDE for MPWマンセー

>>5
何をヤメレばいいの？
詳細きぼーん

ちょうどいいスレが立ったので聞きたいのですが
Macでfreeのfortranのコンパイラってどこかにないですか？
宿題を(って言うか万が一教授になってもずっと)Macでやりたいです。

>>8
http://www.fortran.com/imagine1/
MPWと組み合わせて使う模様。

READMEとか見てみたら
互換性とかの問題があってファイル消したみたいな事が書いてあった。
スマソ

>>2
MPWが見つからないんですが・・・
どこにあるのでしょうか？詳細きぼーん

すいません、
MPWについて検索をかけたら答えが出てきそうです。
ご迷惑をおかけしました。

ただ、Macのプログラミングは、資料が少なすぎて
大変なんダヨなぁ。。。

あと、MPWで作ったプログラムって、Vectorとかに登録して、
自由に配布していいのかなぁ?

それが分からないので、知ってる人、教えてください。

>>12
MPWはフリーでも立派な「開発環境」なので配布はOKです。
ついでにシェアウェアも普通の製品もOKだと思います。

FutureBasicもある。
値段はREALの方が安いけどな。

その画像ならココ
http://www.f2.dion.ne.jp/~impact14/

>>15番は、変なサイトにつながるので、特に未成年者の方は
リンクを開かない方が良いでしょう。

ていうか、漏れもその末成年者に入るのだが。
びっくりしたのですぐに逃げた。

１分１００円もの金払ってみるもんじゃないね（ｗ

そういえば、ＭＰＷって、どのぐらい高度なプログラムが作れるんだろう？
あと、ＨｙｐｅｒＣａｒｄって、なぁに？

>>18
＞そういえば、ＭＰＷって、どのぐらい高度なプログラムが作れるんだろう？
作り方によってはCodeWarriorで作ったものと同じぐらいのものが作れる。

今からMacでプログラミングするなら、XでCocoaでやりなさい。
自分の時間をどう使おうが知ったことではないが、
役に立たなくなるもののために時間をさくのは勧めない。

>>20
僕は、68k Macで、感じTalk7,5,5を使ってるんですけど。。。(ToT)
それにCocoaって、68k Macで使えるものではありませんよね?

ところで、68k Macで動くLinuxってあるんでしょうか？

>>19
作り方を工夫すれば、MPWでMIDIシーケンサやワープロソフトを
作る事だってできちゃうんですか?
CodeWarror自体よくわからないので教えてください。。

>>21
腕を磨けばMIDIシーケンサもワープロソフトも作れますよ。

ついでに
http://www.google.co.jp/search?q=68k+Mac+Linux&btnG=Google+%8C%9F%8D%F5&hl=ja&lr=lang_ja

>21
http://www.micnet.ne.jp/miyu/ringo/linux/
ここ見よ

>>23
おっ　６８ｋ　Ｍａｃｉｎｔｏｓｈで使えるＬｉｎｕｘね。
サイコーじゃん!

ところで、　これってＭａｃのエミュでつかえるのかなぁ？
ＦＵＳＩＯＮとか、Ｂａｓｉｌｉｓｋ �U　など。
ｖMacでも動くと嬉しいよね。（ｗ

Macintoshのos9を買って、はじめてここにきました。
でもスレッド一覧に行くと全部、文字化けしてて読めないんです。
こんな初歩的な事ですが、どなたかアドバイスください。

>>25
アドレス欄が、*******.htmになってんだろ。
拡張子をhtmlにかえろ！

ほんとに初歩的。中学生の厨房に教えられんなよ。

>>26
本当に初歩的というよりは、２チャンネル独特のものでは?

あと、IE6で、圧縮された方に行くと、変な文字の羅列が
続きます。何故だろう・・・？
IE5では正常に表示できたのに。

あと、IE6で、EMBEDタグが使えなくなりました。
Win98を使ってからしばらくたってUpGradeしたからかなぁ?
そうすると、OSがおかしくなったりするようだし。

ちなみに現在は、Netscape 6 で書きこんでいます。

プログラミングと関係ないじゃん。

>>20
>今からMacでプログラミングするなら、XでCocoaでやりなさい。

言いたい事はわかるけど、なんか...そればっか。
Classicで初めても、基本的な事は無駄にはならんと思うけど。

>>27
お前も馬鹿だ。
HTMLが変わったの！
設定かえろヴォケ！

それに板違いだぞ！

>>30
オマエモナー

>>30
ばーか、ばーか！！！お前の方が馬鹿なくせに人のことを
言ってんじゃねーよ。この、厨房! (漏れはリアル中坊だが)

こう言うのを、
「目くそ　鼻くそを笑う」っていうんだ。覚えておくヨロシ。

>>32
板違いの事言っておいてバカはないだろ。

SNES9Xをビルド出来て悦に入っている工房より。

みんな若いのぉ...

ま、それはおいといて
>>29
無理にCocoaじゃなくてもプログラミングの基本的な部分は変わらんが、
単純にCocoa使った方がGUI部分とかはずっと簡単にできるから、その分
本質的な部分の勉強に集中できるメリットはある。それに自然とオブジェ
クト指向な考え方も身に付くだろうし。ただ、Objective-Cになれ切って
C++に移行すると窒息しそうな堅苦しさを感じるだろうけどね。

>>29
マジレスすると、Classicや、それの後継であるCarbonは
習得するのが大変です。今までのシガラミとかが、うんざり
するほどあるんで。今、Carbonやっている人はどっちかと
いうとClassicで慣れているから、その延長でって感じです。
Cocoaのほうが習得量が少ないし、OOPに対する考えも洗練
されている。まぁCodeWarriorでPowerPlantというのもある
けど、それでもCocoaプログラムより煩雑で、わけわからん
し、C++という皮下脂肪の塊みたいなものも習得しないと
いけないというわけで、これから始める人は圧倒的に
Cocoaのほうが有利です。とおいらは思うです。

CocoaってJavaでも書けるんだっけ？
今日ちょうどJavaの勉強始めたとこなんだが。

>>33
> お前も馬鹿だ。
> HTMLが変わったの！
> 設定かえろヴォケ！
この言葉遣いについていっただけデ〜ス♪
板違いのことに付いて「バカ」とは言ってません。。
いたち害の指摘は２ちゃんでは良いことでしょうから。

※ 粉らわしくてｽﾏｿ!

>>36
書けるよ。
分散オブジェクトとか、まだ使えないCocoaの機能も一部あるけど、それと引き換えにJavaの強力なライブラリが使えるので一長一短ってところか。

>>36
書けます。Cocoa+Javaという、そのものずばりの本も売っているよ。
ただ、あの本、あわてて書いた感じで、中身が薄いのが、ちょっとなー、ですが
雰囲気を知る程度なら参考になるかも。

68k Mac でCocoaが使えたらなぁ。。

あと、ジャンク屋さんに、Perfoma 575 の６８ｋ Macが
4500円で売ってたけど欲しいなぁ。。

68k Mac でCocoaが使えたらなぁ。。

あと、ジャンク屋さんに、Perfoma 575 の６８ｋ Macが
4500円で売ってたけど欲しいなぁ。。

あれ？何故>>40晩と>>41晩で、二重カキコ状態になってるんだ?!
どうもすみません。

＞40-41
そんなに欲しいなら買えばいいじゃん。
たったの4500円なんだし。

>>43

実は漏れ、お金を持ってないリアル厨房の1人で、
しかも、ネットに接続しまくってるせいでお小遣いが減らされています。

現在の持ち金: 1000円ぐらい

僕の誕生日が終わったってのに、なにもプレゼントはないし、、
欲しいのになぁ。。。あと、PC-9821も4500円で売ってました。
それも欲しい。。

>>44
お誕生日プレゼントにフレッツを貰いなさい。
君の中で何かが変わるよ。

>>45 さま、ご回答有難う御座います。
フレッツISDNですね？
常時接続しても5300円のやつ。
(BIGLOBE使いほーだいコース＋フレッツISDNでの接続料金)

そうしたいと思っています。
しかし、親父の行動力がないし、ネットのことを全く分からないといって
やってくれません。。どうしよう。。

ADSLの方がいいでしょ
第一もっと安いプロパにしなよ

Developer Tools の
プロジェクトの種類の詳細を教えてくれぇ〜
なんか聞き慣れない表現が多すぎぃ〜。

Cocoa + Javaのテキストエディタのアプリがきちんとうごかん。
ウィンドウが開かんし。
書いてある通りつくったのに、なぜ？

CarbonLib SDK（1.4）のインストール方法がわからん。
特にCarbonLibHeadersPreCompiledの中身って、
一体どこに入るんだ？ オッティモの小池さんのところにも書いてなかったぞ（汗）

ADSLの安いのだったら、携帯買ってもらうより
お金がかからなくて親も良いんじゃないの？
行動力もいらない、アナログなら電話し頼めば
ADSLのモデムを送ってくるだけ。

しかし、それらの機種じゃinternetはまず使えない
おれは物好きだから使っているけどね

> 1
　男は黙ってThink Pascal(謎)
　http://www.think-pascal.com/

>>50
precompiled headerというものを使ったことないでしょ、君。

>53

初心者でよくわからないので質問してます。

System/Library/Frameworks/Carbon.framework
かな？　よくわからんけど。

>>55
何が？

>55
開発環境はCodeWarrior6なのでそこではないと思います。

うーん、どうしたものか・・・。

>>57
CarbonLibHeadersPreCompiledの中身（正しくはCarbonHeaders.mcpをMake
した結果作成されるファイル）は、Sample CodeのサンプルをMakeするために
必要なのら。使い方は簡単。

1. Carbon Supportフォルダを丸ごとMetrowerks CodeWarriorフォルダにコピー
2. コピーしたCarbon Supportフォルダの中のCarbonLibHeadersPreCompiled
　フォルダに入っているCarbonHeaders.mcpをCodeWarrior 6で開く
3.Makeする

これでSample CodeがMakeできるようになるのら。
次からはCarbon SupportにあるREAD MEを読むこと。

うまくいったよ。ありがとう！

COCOAの Projectの雛形をそのままビルドすると。
warning -F: direectory name (省略) dose not exist
なる警告がでますが。
どういう意味でしょうか？気になります。

Cをある程度やっていたのですが
OS　XはCarbonでやるべきでしょうか？
それともCocoaですか？
ついでにいうとWindowsのプラグラミングもこれからやりたいのですが

その画像ならココ
http://www.h2.dion.ne.jp/~goldman/

>>62
>>その画像ならココ

ブラウザクラッシャー
クリックしないように

>>60
ディレクトリーがおかしいぞｺﾞﾙｧ!!

>>43, >>45
お蔭様で、Macを買うことが出来ました。
親父のお金が少し浮いたみたいで、5000円をくれたのです。
(夏目漱石が5人なんて言ってましたが)

33MHz で、今となってはとってもスペックの劣ったものでしょうが、
画像処理など、すいすいと動いてくれます。
同じぐらいのスペックのAT互換機に同じ事をやらせようとすると、
動作が鈍りますでしょうしね。

これがMacの長所なんですね。Macサイコー！！！
サウンドもかなりいけてますよ。

あと、今度、出来ればフレッツISDNにしようと思います。
有難う御座いました。m(_ _)m

>>60
プロジェクトフォルダーの中の"build"ってフォルダーに
"ProjectHeaders"ってフォルダがないぞゴルァ。
"ProjectHeaders"ってフォルダ作れば解決。
ほっといてもいいけど。

>>65
ジャンク屋ならPC-9821(Pentium2/233)がモニタ一式で3800円で売ってるよ。
もちろんWin95付でアプリ付でね。世間知らずにもほどがある。

かなーり昔に買った
CodeWarrior Discover Macが出てきた。
IDEは10か11くらい。
これってOS9.2.1でも動くのかな？
68k用にしかコンパイルできないし使う気はないけどね。
あ。このスレの目的ならこれでも大丈夫なのか。

>>67
うわーっ！漏れのマシンと同じぐらいのスペックの９８２１ではないか！
（漏れのマシン：NEC VALUESTAR NX VE23/35C 漏れのはNXシリーズだが)

でも、漏れのすんでる地域には、そんなに
ジャンク屋さんがあるわけでもないし。
（打ちの近くのジャンク屋：ハードオフ)

秋葉原にでも逝けば、山ほどそんなのがﾊﾟｿが売ってるだろうけど。

近くにそんなに安く売ってるお店があるわけじゃないし、
９８２１（Win95付き)の一体型が5000円で手に入るぐらいだから。

お金がたまったら買いたいなぁ。。

>>68
プログラミング関係のスレだし、そういったことを書きこむのに
問題なんてないんじゃない？

あと、６８ｋだったら、emuがあるから使ってみると(・∀・)ｲｲ!
ネット城を捜せば、ROMなんて、山ほどあるぞ!

>>68
ココ逝け!

Macのエミュレータ
http://teri.2ch.net/test/read.cgi?bbs=mac&key=999937246&ls=50

68k Macのエミュレータがある分、今後も68k Macが
流行ってくる可能性も考えられる。

漏れも最近、68k Macを買ってきたし。

ＰｏｗｅｒＰＣ搭載のMacでも、68kのエミュは動いてくれるし、
やってみてはイカガ？

>34
世界最初のWEBブラウザーはObjective-Cで書いたそうな
そのかわり、MacやWindowsに移植する時に、死ぬ程苦労したらしいけど

>>71
Objective-Cって、どんな感じの言語なの？
MacやWinに移植するときに、死ぬほど苦労するとは、よほど凄い
言語だったのでしょうね？


あ、そうだ！此方のメルマガはイカガ？
http://member.nifty.ne.jp/kyoryo/mactip/index.html
↑結構いいかもよ！お試しあれ。

>>72
CにSmartTalkの概念を追加したのがObjecive-C、ということらしいです。
C++に比べれば拡張要素はスッキリしているらしいですよ。
俺C++知らないんで詳しい事はわかんないんですが。

よく言われるのが、
●オブジェクトの動的結合
●多重継承できない
●#includeではなく#importを使う
　（一度参照したファイルは二度と読み込まない）
●クラスをオブジェクトとして扱う（クラスオブジェクト）
●[]を使ったメッセージ式
　（　[[[ Hoge ] alloc ] init];　←　クラスHogeのインスタンスを生成し、初期化）

こんな所でしょうか。Objective-Cの概念をCで再現しようと思ったら大変でしょうね。
…俺自身あんまり理解が深くないんで、もしかしたら的外れな事言ってるかも（w

この大ﾏｶ者めが！

>>73
ぜんぜんお話になりません。もっと精進したまえ。

プログラミングスレなんだからなんか作ろうよage

>>76さんの考えに禿げしく賛成！

とりあえず、こんなプログラムでも作ってみたまえ！

BASIC言語で、
10 print "Hello, World!"
20 end

↑此れがプログラミングの基礎的(?)な例だろう。

実は自分もプログラミングはやった事がないので、
詳しく分からずｽﾏｿ！

cocoa+javaの本どうりにやったら、ｱﾌﾟﾘできました。
うれちい

public class Hello{
public static void main(String[] arg){
System.out.println("Hello, World!");
}
}

#!usr/local/bin/perl

while(1)
{
print"Hello!World\n";
}

PERFORM UNTIL EOF
WRITE HELLO.REC AFTER 1
SET EOF TO TRUE
END-PERFORM

Hello Worldオリンピックみたいになってきたな（w
http://piza2.2ch.net/test/read.cgi?bbs=tech&key=1001185952&ls=50

ttp://wwwsoc.nacsis.ac.jp/jssst/planning/MacOSX-2001.html

msgbox "hello,world"

Dim the_I As Integer
Dim the_J As Integer
Dim Cnt As Integer

For the_I = 1 to 100
For the_J = 1 to 100
Cnt=Cnt+1
Next
Next

For the_I = 1 to 100
For the_J = 1 to 100
Cnt=Cnt-1
Next
Next

MsgBox "hello,world!!"

>>78
誤：どうり
正：どおり

#include <stdio.h>

int main( void )
{
printf( "Hello,world" );
return 0;
}
Cしか知らねえ..

<?php
echo "hello, world";
?>

<% out.println("Hello,world!"); %>

Hello, World! をいろんな言語でやってみまショー!

↓MS-DOS のバッチファイル
echo Hello, World!

↓JavaScript
<script language="JavaScript">
document.write{"Hello, World!"};
</script>
こうだったっけ？

↓Hot Soup Processor
　　　　　mes "Hello, World!"
　　　　　stop

↓Bash シェルによるシェルスクリプト
!#/bin/bash
print Hello, World!


間違てたら指摘きぼんぬ。
ナント言っても、漏れもプログラミング初心者名もんで。

あと、HSPのほうは，Macばんが出たときにでも役に立つ事でしょう。

すいません、間違ってました。。(多分)

Bashのシェルスクリプトのところで
誤×　print Hello, World!
正○　print "Hello, World!"　

>>61
Windowsでもプログラミングがやりたいのなら、HSPはどうよ？
Mac版も出るようだし、ＨＳＰ言語、覚えておくﾖﾛｼ。
※ これで68k Macがまた、普及してくるだろうな。

他に、Winで仕えるプログラミング言語といったら・・・
BASICぐらいまでは無料で出来るかなぁ?
(N88互換BASICを使えば出来るだろうし)

Ｍａｃ版のN88ごかんBASICが出てくれるともっと嬉しいのになぁ。。

FutureBasic^3じゃいけないの？<BASIC

MPWてのは？
たしか、Appleがただで配ってたはず。

ちょっとつかいにくいけど

bash も

echo Hello,world!

です。print文は BASIC

おや、iDiskでRealBASICのデモ版配ってんじゃん。

>>95
あれ？そうでしたっけ？printでも出来たような気がしたのですが。

あと、スペースの入る文章を表示するときは、
ダブルクォーテーションで囲まないと、正しく表示できません。(確か)

さらに・・・英文の決まり、コンマの後ろにはスペースを入れるのを忘れずに。

>>93
あ、FutureBASICでも、N88との互換性は取れてるんですよね。
でも、お金がかかる。

Macで、お金をかけずにBasic言語を扱えるプログラムってないものでしょうか？

>>97
bashに printは無いし
echo Hello, world.
でクォーテーションは必要なし。

>> FutureBASICでも、N88との互換性
使いものにならないらしい。

N88BASIC互換といっても、ちょっと慣れてくると
PC-98の key BIOS叩いたりしているから
実質的には互換性はないと思う。

互換性が欲しかったら Javaみたいに
ハードウェアを完全に隠蔽するライブラリをもった言語じゃないと。

自分で書いていてわかりにくかったから補足。

PC-98でよくできた N88BASICプログラムをみても、
機種依存命令がかなり入っていることが多いから、
互換をうたう処理系使っても実際には動かない。

よっぽどシンプルなのなら動くんだけど、
それじゃ全然意味がない。

>>98
>>Macで、お金をかけずにBasic

(要)英語読解能力

「Chipmunk Basic」
ttp://www.nicholson.com/rhn/basic/
「METAL」
ttp://www.iit.edu/~sarimar/GDS/metal.html
「Visual MacStandardBasic」
ttp://squirrelsw.com/vmsb.html

Visual MacStandardBasicはFREEじゃないかも…

>>103
うお
上の2つ懐かしいな。
昔それでしょーもないもん作ってた（ｗ

>>99
漏れが、クォーテーションを省いてやってみたら、
出来なかったような気がしたんですが気のせいでしょうか?
TurboLinux 3だったと思います。

解説書にもクォーテーションが書いてあったような気がしましたし。

>>100-102
へぇ、互換性がとれているといっても、本格的なものではないんですね?
ところで、機種依存命令って、どんな感じですか?
ＰＣ９８持ってませんし、分かりません。

機種依存命令の例(ｿｰｽなど)とその解説をしてくださる方がいたら詳細きぼーん。

>>103
お金をかけずにBASICが出来るなんて、ホント、嬉しいですわ。
唯、英語力が必要なのよね。
ｺﾝﾋﾟｭｰﾀを利用していく中で英語力が必要である事は、
こういったところからも分かりますね。

よし！じゃぁ、Hello, World!から始めて、
慣れてきたら数値を加減乗除するプログラムを作ろう!
それにも慣れてきたら、電卓プログラムってのもイイよね。

よーするに、>>103の「Chipmunk Basic」をダウンロードするには、
ftp://ftp.rahu1.net/pub/rhn/Chipmunk_Baic_3.5.7.hqx を
ダウンロードすればいいって事。お試しあれ。

>>105 "!" は行末の場合クオートする必要ないかもしれないけど、
基本的にはした方がいい。"" ではなく '' で囲む必要がある。
あとクオートしないと2文字以上の連続した空白が1文字になる。
echo 'Hello, World!'
とすればOK。

>>105
TL3 て2年前 漏れも使ってたよ。kernelが2.0から2.2になったときは感動したっけな(遠い目

>>108
まじレスさんくす。オライリーのbash第２版には
' 強いクォーティング
" 弱い 〃
とあるが自分じゃうまく説明できぬ。

echo '"A "B' だと
"A "B

echo "'"A " B'C"
'A B'C

echo ''"A " B'C'
A BC

謎だ

>105

PC-98の N88BASICを使っていた例ですが
PRINT文とか INKEY$なんかは大丈夫ですが
ゲームでも書いていて，INKEY$ではキー取得が遅すぎるから
INPを使ったり，描画なんかも高速化を図ると PSET使えないし。
VPEEK / VPOKEは MSXだっけ，なんかいろいろあります。

何年か前から高校の数学の教科書に BASICが入っているけど
あれを動かしたい程度なら互換環境は大丈夫です。
でも，N88BASICをガンガン使っていた人が

　懐かしいなぁ，いっちょ買うか

と入手しても，以前のコードはほとんど動かないと思います。

>>110
では、Win95のN88basicは、其れに比べて、どれほど互換性が
とれているのでしょう?

＃ただ単に「Basic」といっても、色々あるんですね。

>>108
へぇ、そうなんですか？始めて分かりました。

>>109
カーネルが２．０から２．２になったときは、
どのように感動されたのでしょうか?

むぉ、Ver.まで全角とわ。
>カーネルが２．０から２．２になったとき
はメモリアクセスが向上したため、見た目にも性能が上がるのを感じました。

>111

Win95の N88BASICは使ったことがありません。
というか聞いたのも初めてです。
すみません m(__)m

>＃ただ単に「Basic」といっても、色々あるんですね。

どんな条件を満たせばBASICを名乗れるのか不明です。
大ざっぱにわけても，行番号付きのと付かないのがあります。
N88は前者ですね。

そのあと QuickBasicなんかがでていますが
こいつには行番号はなかったと思います。
関数型言語になっていて，コンパイラです。

VisualBasicとか，REALbasicにいたっては RADで
オブジェクト指向になっています。

互換性の高い言語を作ろうと思ったら
言語仕様か標準ライブラリを強化して
よけいなルーチンを使わずに済むといいんでしょう。
方向性としては Javaですね。

一方，言語仕様がデブになると C++化するので
理想的には OpenGLのように互換性のあるライブラリを
もっと増やすのがいいのでしょうか。
方向性としては gtkかな。

>>103
Chipmunk Basicをダウソ口ーﾄﾞしてみました。

しかし、単体で実行可能なプログラムは作れなかったなぁ。
次の2つのは、単体で実行できるようなプログラムを作る事は
出来るのでしょうか?

Chipmunk Basic使ってみました。
結構いい感じですね。

これで、単体で実行可能なプログラムが作成できないのは本当なのでしょうか?
>>114の話とは違い、作成できそうなきもしたのですが。

やり方を知ってる人、教えてください。お願いします。。ｍ（＿　＿）ｍ

10.1のDeveloper Toolsに含まれてるIconComposerて、壊れてません？
Saveしようとするとエラーが出るんですけど・・。
修正版とか出てません？
米Appleのページを漁ったけどよく判らなかったもので・・。

なぜか、再インストールしたら正常に動くようになりました。
いったい何が悪かったのか、今となっては調べる由はありませんが・・。
とりあえず自己解決しました。（笑

http://www.zdnet.co.jp/macwire/0110/17/n_trolltechj.html

ToolBoxがチンプンカンプンage

>119

Toolboxはあの頃にしてはよくできていたと思う。
かすかにオブジェクト指向の香りがしないこともない設計だし
初期のWindowsの APIが似ていたというけど
１０年経ってもいい腺をいっていたのだと思う。

GUIを組むにはいいんだけど、たとえばゲームを書きたいとして
N88BASICよりずっと手間がかかったりするのはマイナス。
まずToolboxの初期化をしないといけないし、
イベントループやらウィンドウを出すやら
オフスクリーンを作ったり、PixMap固定・・・などやることが多い。
ちょっとやる気になっても下準備で力つきそう。

OS Xになって>118の通り Qtとか gtkとかでてきたし、
標準で ProjectBuilderがあるし、なんでも Cocoaは優れているらしいし
プログラミングをやるにはいいタイミングなのかもしれない。
昔の HyperCard並に気軽に作れて、いろんな人が楽しみを覚えるといいけど。

>>113
あ、Win95 向けの N88互換Basicは、Vector を探せば見つかりますよ。
N88互換BASIC for Windows95
あと、Win3.1向けのN88互換BASICもあります。

ちなみにそのプログラムは、ＶＢで書かれているようです。

そういえば、聞きたいことがあるのですが、HyperCaｒｄって、
どういうものなんでしょうか？

教えて、下さい。

>>122
なんか時代の移り変わりを実感する質問ですが...

HyperCardはオブジェクト指向言語HyperTalkのインタープリター
であり開発環境です。MacOSの描画APIであるQuickDrawを一人で書
いたと言われているビルアトキンソンが開発した。

イメージとしてはSmallTalkのような本格的なオブジェクト指向
言語にVisualBasicのようなグラウフィカルな開発環境がくっつい
た感じ。ペイントソフトでおえかきしてソフトの外観を作りながら
ボタンやフィールドといったオブジェクトにHyperTalkでイベント
ハンドラを記述するといった方法でプログラミングしていく。

ハイパーカードのプログラムは「スタック」と呼ばれて、スタッ
クはハイバーカード（またはハイパーカードプレーヤー）上で実行
される、すなはちスタンドアロンプログラムは作成できない。

簡単なアニメーションスタックとかはすぐに書けてしまう、敷き居
の低さが最大の魅力でしたね。先進的でありながら、初心者に広く
受け入れられたと言う意味で、最もマックらしいソフトだったと思
います。

>122

ボタンを置いて、ボタンにスクリプトを書くような開発環境です。
ボタン以外にもカードとか、オブジェクトにはスクリプトが書けます。

on mouseUp
　処理
end mouseUp

ならば、クリックしたとき（マウスのボタンを離したとき）に
処理を実行するというイメージです。
他にもカーソルが近付いたときとか、いろいろな条件で発動できます。

RADのはしり、と言えるかもしれません。
オブジェクト指向としては、C++みたいにメンバ関数よりも
こんな風にメッセージを飛ばす方が自然のような気もします。

ハイパーカードなら、今でも手にいるんじゃないの？
さわってみるのが一番手っ取り早いというか。
え？　手に入らない？

ハイパーカード、まだ売って末世。
たとえば秋葉原のLAOX Mac館で。


それよりもＦＢのバージョンアップ申し込まんと（ｗ
Ｖ３からはバージョンアップが一年ごとの契約制になったのが痛いかな.....

…全くの初心者で、
なんかやってみたいなぁ、という状況なら、
OSX買ってCoCoaでなにか参考書を探せば良いのでしょうか？？

>>127
http://www.big.or.jp/~crane/cocoa/

>128
ありがとうございます！
ん？でもCoCoaって情報が少ない？！
このスレをちゃんと読めてなかったでしょうか？？
とりあえずそこ、読みやすそうなので
これから勉強してみます。

>>128
そのページつまんねーよ。
バックグラウンドの色も目に悪いし。
死ね＞作者

>>128のページを見るときは部屋を明るくして離れてみた方が良いな。

誰かさ、iTunesのムービープレイヤー版みたいの作ってよ。
MPLAYみたいなやつ。

それか単純に、指定したフォルダ（階層もたどって）からランダムにムービーファイルを
クイックタイムで再生させるアップルスクリプトでもいいよ。

Xでそういうソフトってないよね？

これってムズいの？それとも需要がない？

http://www3.airnet.ne.jp/arozone/itadaki/arofm.html
これそれに近いんじゃない、ジングルがちょいうざい気がしなくもないけど

http://www.ksoft.net/cp_screen_shot_macos.htm
http://www.ksoft.net/cp_screen_shot_windows.htm
http://www.ksoft.net/cp_screen_shot_linux.htm

>>128,>>130-131
それは、>>128で紹介された所のページを作ってる人が、
256色の環境だからだと思われ。

背景色を薄くしすぎると、256色では、白く表示される事もあるし。

http://www.hi-ho.ne.jp/hideaki-i/n_on_mac/n-index.html

http://member.nifty.ne.jp/poseidon/images/jb5.jpg

は

フリーのＣコンパイラなんてないよね？

Ｆベーシックもリアルベーシックも
msxベーシックとの互換性は低いので
互換性問題は関係ないや。
一応n88dosベーシックで作ったものも
色々あったけど

>>139
MPWは無視？

>>139
Apple純正があります。

N-BASICとは違うの？

ぷろぐらみんぐしたいならOSXがよい

>141,>142
そんなのあったんですか？
ただで落とせます？
>144
う〜ん、それが一番なんですけど、実はOSXが市場で安定するまでｳｨｿに避難しようかと思ってるんです。
mac使いの風上にも置けない奴とは俺の事です、はい。

>145

C言語はほとんどの機能を外部ライブラリで提供しています。
だから、Cができるというより Carbonでプログラムが書ける、
といった表現の方が適切だったりします。
Windowsの MFCになれてから Carbonやっても
無駄にはならないけど、かなり苦労はするかと思います。

たとえて言うなら、日本語ができる人がいて
コンピュータのことなら何でも理解できるけど
法律関係になると何を言っているか分からないようなことになりますよ。

パソコンを始めて五か月の初心者ですが、
OS X 10.1バージョンアップを機にプログラミングを
勉強したいと考えました。
とりあえずJAVAの本を買って読んでいますが、
Project Builderの使い方がさっぱり分かりません。
今のところ、プログラミングとはどんなものか知りたいだけなので、
簡単なJAVA言語をコンパイル実行するにはどうすればいいのか
誰か教えて下さい。

>>147
Terminalで
javac xxxx.java
エラーがなければ
java xxxx
もちろんxxxxはファイル名ね

>>148
Terminalというものの存在は知ってましたが
下手にいじると恐いのでこれまで使ったことがありませんでした。
とりあえず、やってみます。

>147

1.　ファイルメニュー -> 新規プロジェクトを選ぶ
2.　PureJava -> Java AWT Applicationを選ぶ
3.　適当に名前を付ける
4.　ウィンドウがあらわれたら「林檎キー＋R」する

>>147
ぷろぐらみんぐなんてじかんをどぶにすてるようなもんだぞ
そんなことしてるひまがあったらそとにあそびにいきなさい

>>139
OSXは技術的には枯れきってると思うが...
NextSTEPの時代にはミッションクリティカルな分野（金融関係とか
NASA等の官公庁とか）で実績があるOSじゃん
ウインなんかよりずっと安定してるよ！

>151
そんなこと言ってるからユニクサーに
「マカーってOSX操作できるの？」って言われるんだよ。
知って害になる知識は無い。

No class DefFound Errorがでて実行できません。
エディターのせいかと思いエンコードを合わせたり、
BB Editというソフトをダウンロードして使ってみたりしましたが
いまだにうまくいきません。どうすればいい？

たびたびすみません。補足しておくと
JAVA Souce File を作るところまではできました。
Terminalでコンパイルすると？？？？？？？
というように表示されて、実行すると上記のエラーが表示されます。

Darwinについては十分に枯れていると思うが、
Carbonが駄目駄目でしょう。
CocoaもNeXT時代の蓄積があるとはいえ、
Mac OS Xでの変更時にバグが大量に入り込んでると思われ。

>>155
javaのエラーメッセージによるとクラスファイルが見つからない
ようですね。コンパイルがちゃんとできていないようです。javac
したときのエラーメッセージの内容が不明なので推測の域を出ま
せんが、コンパイラがソースファイルを見つけられないのでは?
コンパイルする前にカレントディレクトリをソースファイルのある
ディレクトリに移動するか、さもなくばjavacにフルパスでソース
ファイル名を渡すかすればうまくいくでしょう。
具体的には、ソースファイルのフルパスが
/Users/YOURNAME/Documents/Code.java
の場合ターミナルで
cd /Users/YOURNAME/Documents/
としてカレントディレクトリを現在の作業ディレクトリに移動し
java Code.java
とすると、同じディレクトリに
Code.class
ができるはずです。

またはターミナルにjavac と入力してからターミナルにソース
ファイルをドロップすればファイルのフルパスが入力できて
javac /Users/YOURNAME/Documents/Code.java
とでき、これでもコンパイルできるはずです。

実行は、カレントディレクトリをCode.classファイルのある
場所に移動して
java Code
でオッケーです。あ、もちろんCode.classファイルの中では
public static void main(String[] arg)
のメインメソッドを実装したクラスが定義されている必要があり
ます（じゃないと「メインメソッドがないずら」エラーがでます）

長々とすみませんでした、がんばってねー

レスありがとう。
結局、ファイルをhome/documentから
homeのすぐ下に移動したらコンパイルできました。

ずばりOSXを買えばプログラムができるから安い買い物なの？
今、プログラムを初めるんだったら買いですか？
まあ、うちのibookSE/366にはのせるのきびしそうですが…

開発環境タダで手に入る、もしくは最初から入ってる

無料の開発環境はいろいろなプラットフォームにあります。
Windowsの Borland C++とか Delphiなんかはかなりよくできていますが、
もっと上位の製品の導入バージョンって感じなのに対して、
ProjectBuilderはパワー１００％解放です。

>>159
>>159
iMac/350にOSXですがとりたてて遅いと感じることはないですよ。
（ただしメモリは512MB、ハードディスクは40GBに増強しました）
でもPBは最近使わなくなっちゃった...
エディターでソース書いてコマンドラインでコンパイルする方がなんか楽...

最近Cの勉強はじめたんですけど
PBでscanfつかうと何かおかしくなるんです。

　　　　int a;
printf("整数を入力:");
scanf("%d",&a);
printf("入力した数は%dです\n",a);

普通実行すると
整数を入力:20
入力した数は20です

となりますよね。俺のPBならないんです。
実行画面（でいいのかな）がまっしろで出てきて画面をクリック
するとカーソルが出てきて真っ白なんだけど入力できる、で、入力
すると

20整数を入力:入力した数は20です

と画面に出るんです。

おれだけなのかな？
何回かインストールしなおしたんだけどだめでした。
OSの再インストールからしたほうがいいのかな。

>>163
printfの後に fflush(stdout); と付けてみ。
多分、性能をあげる為に遅延評価を行っている為に、明示的にファイル出力を
するまで、画面に何も出力されないと思われ。

それから、PB使って Unix の Standard ツール作るだけでは寂しい。ぜひ、
Cocoa にも挑戦しなされ。

>>163

setbuf,setvbufとかの仕様も調べてみ。
バッファというものの存在を最近の人は知らないのかな。

>>164

きっちりでました。ありがとうございました。

>>165

知らないです。仕様の調べ方も（汗
できれば教えて下さい。
調べられるってことは仕様の変更もできるんだろうか。

>166

工場で製品を出荷する際に
１つできる度にトラックを走らせていては非効率なので
ある程度たまるまで待ってからまとめて運ぶみたいなことが
OSでも行われているわけです。

>>166
Terminalで
man setbuf
とか打ち込んでみるとか
（英語で説明でるけどな）
C言語の参考書とかにも載っているよ

>>167,168

どうもサンクスです。
んー勉強がたりませんでした。

Javaのことについて質問！
一度通したパスが、再起動やログアウトすると無効になるんだけど・・
どして？
いちいち設定しなおすのが面倒だYO!
あ、10.1での話ね。

さげてどうする・・・・age!

.tcshrcにでも書いておけばよろし

>>172
それってどうやってするの？
厨房質問でｽﾏｿ

自分のホームフォルダに ".tcshrc"ってテキストファイルを作って
setenv　PATH "$PATH:/Developer/Tools"
とか書いておけば/Developer/Toolsが追加されるよ。
コロンで区切れば複数指定できるし。

新しいターミナル開けば反映される。
今すぐ反映の場合はsource ~/.tcshrcとかやればよろしいかと。

ていうか10．1だったらjavaへのPATHは追加されてるのでは？
漏れは別に指定しなくても動いたが。
CLASSPATHだとしても同じ方法で指定できるけどさ。。。

>>172

servletとJSPがやってみたかったから、Tomcatを入れて、以下の様にservlet APIにパスを通してたんだけど、
setenv CLASSPATH /usr/bin/java/classes:/Library/Tomcat/lib/servlet.jar
ログインし直す度に↑を打ち込まないといけないから面倒だったんだYO!

で、↑を書いた .tcshrc を作ってみたけれど、全然ダメだったんだけど・・・
どこがいけなかったんだろ？

>>175
つーか、OS Xに、/usr/bin/java/classesなんてないじゃん。
/System/Library/Frameworks/JavaVM.framework/Classes/
だよ。

だめだった？ファイルが作れなかったとかじゃなくて?
もしそうならviとかpicoとかエディタがあるからそれとかで編集するがよろし。

違うなら俺もわからん。試してみたけど設定されましたよ〜〜

以前は動いてた(?)と思われるので
あえてつっこまなかったけど言われてみればそうだね

>>175
~/Library/init/tcsh　ってディレクトリを掘って、そこにrc.mineを作るよろし。

＃/usr/share/init/tcsh/rc　参照のこと

>>179
.tcshrc作るのと、変わらないじゃん。
ちなみに.tcshrcがあると、.cshrcは実行されないよ。

>>180
ちょっと前(OS Xのβかそこら)に.tcshrc試したらうまくいかなくて rc.mine でうまく行ったことがあったもので、、、
今10.1で試してみたら.tcshrcで問題ないっすね、、、
OS Xスタイルっつーことで勘弁して下さい。
鬱だ、、、(T_T)

>>176

/usr/bin/java/classes は無いのは知っているけど、

setenv CLASSPATH /usr/bin/java/classes:/Library/Tomcat/lib/servlet.jar

でちゃんと動くから不思議。もちろん。

setenv CLASSPATH /System/Library/Frameworks/JavaVM.framework/Classes:/Library/Tomcat/lib/servlet.jar

でもOKでした。

>>172

敗因は0S 9側で作ったのがいけなかったみたい。vi （初めて使った！）から作ればばっちりいきました。わざわざ夜中につき合っていただいてありがとうございました。

でも・・・・（続く）

上記の方法でパスを通した後、フツーのファイル（ハローワールド程度）を実行しようとすると、
Exception in thread "main" java.lang.NoClassDefFoundError のエラーが・・・・
もう何が何やら・・・・ハァ

cocoaと.NETどっちが簡単ですか?

>>183
ウィソでもLinuxでもそうだが、CLASSPATHは出来る限り設定しないほうが良いとされている（らしい）
設定していると暗黙に設定されているデフォルトのCLASSPATHが上書きされてしまうみたい。

カレントディレクトリをCLASSPATHに含めていないのも原因かも。

>>176

パスを通す代わりに、

javac -classpath /Library/Tomcat/lib/servlet.jar SampleJSP.java

ってすればコンパイル可能で、>>183のようなトラブルも起きなかったけど、
なるべくCLASSPATHは設定しない方がいいなら、どうやってパスの追加すればいいんだろ？

あと、暗黙に設定されているデフォルトのCLASSPATHはどうすれば分かるの？

age

普通tomcat入れてるならJAVA_HOMEは設定してるよね？
/System/Library/Frameworks/JavaVM.framework/Homeとか。

クラスパスはOSXだと
/System/Library/Frameworks/JavaVM.framework/Classesとかかな？
ここに本当はtomcat.jarを追加したいんだけど、
ユーザが設定しちゃあまりよくなさそうなので、
/Library/Java/Extensionsか/Library/Java/Home/lib/extに
入れればいいんじゃないかな？
そうすればCLASSPATHを設定しなくてもいいと思われ。

テストしたわけではないので確信は持てない、ｽﾏｿ

JAVAってめんどくせーな。
sage

OS X 10.1についてきたの、英語版だったんですけど、
日本語版のDeveloper Toolsってどこかでダウンロードできますか？

>>189
複雑な事をしようと思うと面倒なのよね。。

>>190
ていうか無いんじゃない？

/Library/Java/Home/lib/ext にservlet.jarを移動させたところ、
CLASSPATHを設定することなく、-classpathオプションも付けることなしでコンパイルできました。
実行も問題無し！

あと、JAVA_HOMEって設定する必要あるの？
Tomcatのインストールは↓にある.pkgを使っただけで、
JAVA_HOMEは設定はしてないんだけど。

ttp://homepage.mac.com/murraytodd/tomcat.html

>>190
そのままインストールしていいよ。
Project Builderなら日本語化されてるし。
Interface Builderは中途半端に日本語化。

http://www05.u-page.so-net.ne.jp/xd5/mkino/HMDT/
http://homepage.mac.com/mkino2/

>PB
ツールバーのボタンを「停止」とかローカライズしてる暇があったら、ヘルプの文字化けを何とかしてほしいんですが…

>>194

同意。あの文字化けには、インストール失敗したかとおもたよ。

>>192
そっか、よかったよかった。

パッケージでインストールすればいいのね、、（；´Д｀）
俺はPublicBetaの時にやった記憶なので。

>>172氏
数々の厨房質問に答えて頂きありがとうございました。
レスを頂いた、>>176氏、>>175氏にも感謝。

AppleもJavaの設定に関する資料をもっと公開してくれてもいいのに・・・

http://www.borland.com/jbuilder/mac/download/jbuilderformacos_preview_steps.html

JBuilderでてるね。
今ダウソ中。既出？

既出？
Q: Mac OS X 10.1でProject Builderを使うと、Javaコンパイラの
エラーメッセージが文字化けします。どうしてでしょうか?
http://developer.apple.com/ja/qa/qa2001/qa1092.html

こいっこ、Googleネタ
http://developer.apple.com/search/search.html

>>198
ありがーと
俺も落とし始めた

JBuilder使ってみた
結構いい感じじゃないですか
漏れは仕事ではWinでVisualCafe使って開発してるけど、
日本語版のJBuilderが出たら会社にMac持ち込んで開発しようかな

おい、113MBもあるじゃんーか（泣）
落とすのやめたらアンケートもう一回か？（鬱

>.203
ftp://ftpd.borland.com/download/jbuilder/mac/JBuilder5-Preview-MacOSX.cdr
アンケートに答えたなら、ここから落とせる
インストール時にはメールで送られてくる尻とパスが必要。なのでアンケートに答えないとインストールできないので注意
アンケートは>>198のリンク先参照

おぉ!!情報有り難うございます。
ProjectBuilderのJava開発環境があまり
使えなかったので腐ってました。
ただ今ダウソ中(^_^)。

Mac OS XのJava2が遅いのには凹みましたが
SUNのUltraBradeがそれ以上に遅かったのにはビビりました。
ForteのMac OS X版が欲しいなぁ。

Javaのバイトコードをネイティブに変換できればいいのに。
DevToolsに入っている MRJAppBuilderって何に使うのかな。

ただ今 97%(^^;)

>>206
JARファイルをMac OS Xアプリに変換するためのツールですね。
ttp://developer.apple.com/ja/qa/java/java29.html
ttp://developer.apple.com/ja/qa/qa2001/qa1003.html
この辺にヒントが...
Appとしてパッケージングするだけで Javaランタイムを使うことに
かわりありません。期待してるようなものじゃないです。
下のほうのリンクはSwingでAquaのルックスを実装する方法。

JBuilderでcom.apple.macosというクラスがインポートできれば
MRJのJDirectが使えそうな気がする。
そうすればある程度ネイティブに近くなるか？

あとはMRJの実装次第かなぁ？
WindowsだとGraphics2DはDirectXを呼び出すよう
になっているのでJavaアプリとは思えないほど高速。
だからMac OS X用のMRJがどの程度ネイティブ
に最適化されているかが肝だったり。

個人的にはJavaソースで扱う上位の部分は
あまり実行速度に響かないような感じです(起動が遅いのは仕方ない)
どうしても速くしたければ遅い箇所だけネイティブ
(CarbonまたはCocoa)で組んで JNIで実装したほうが
効率的かもね。

ttp://developer.apple.com/techpubs/macosx/Cocoa/Reference/ApplicationKit/Java/IntroAppKit.html
このへん見るとひょっとしてNSObjectも使えるのかとワクワクしてみたり

まぁJavaのソースからネイティブ叩き出せたら便利なんだけどね〜
そんな方法があったら俺も知りたいッス

javaで作ったcocoaアプリの実行速度って、
objective-Cで作ったものより落ちるんですか？

>>208
若干、落ちると聞いたような。

OSXのデベツールって任意のパーティションにインストールできますか？

最近できたゲ製作技術板より、

「Macでゲームを作るスレ」
http://game.2ch.net/test/read.cgi/gamedev/1005722214/l50

今月はCocoa本が２册同時に出るのでおいしいですねぇ。
ttp://www.zdnet.co.jp/macwire/0111/16/b_md_books.html

ただし、２冊揃えると１萬円近くなるのが厳しい…。

CUIでCを少しかじった事がある程度なのですが、
MacOSXの導入を機会に本格的にGUIプログラミングに取り組んでみたいと思います。
宜しければCarbonとCocoaにはどのような違いがあるか教えて頂けないでしょうか？
(使用する言語はCです)

CarbonではQuartsを使えない、Cocoaではドラッグ&ドロップに
対応していないといった話を聞いたので、
それぞれのAPIごとに出来る事と出来ない事を主に知りたく思います。

CarbonではQuartzを扱えない、というかMac OS 9でも動く
形式のCarbonではQuartzが使えない、というのが正しい。
Mac OS X上では使えるよ。CocoaでDrag & Dropできな
いというのは初耳、ていうかできてるし。

それぞれのAPIでできることとできないこと、というのは確
かに存在するが、両者の性質の違いを考えるとそんなことは
些細な事（事実上問題にならない）。これから始めるのなら、
色々な意味でCocoaをすすめる。CocoaからCarbon APIを
使う事は問題なくできるが、逆は不可能（Cocoaはフレーム
ワークなので）だしね。

>>214
成程、それでは実質Cocoaアプリだけが出来ないことは無い事になりますね。
勧めて頂いたように、Cocoaの方を学ぶ事にしました。
212のURLにある本を買って、今月から早速始めます。
ありがとうございました。

212で紹介されてる本は欲しいが
今一番知りたいのは
FoundationやAppKitの日本語での詳しい仕様書。

>207
だいぶ返事が遅れましたけど、
丁寧な解脱ありがとうございます。

Windowsの DirectX対応みたいにJavaのランタイム（というの？）が
もうすこし高速になってくれるといいですね。
Macでは DirectXみたいな高速描画の標準的手法がないみたいです。
GameSprocketも立ち消えになったみたいだし。

もっとも、DirectXは市場に存在するあらゆるビデオカードで
安定かつ高速を実現するのは結構難しいようで
それで悩んでいるプログラマは結構見かけます。

>212

荻原さんの ObjectiveCの本を買って
ちょっと読んでみましたが、題名通り ObjCの解脱が中心ですね。
とするとこれらの本にも期待。


>213

>214氏がおっしゃるように
Mach-Oバイナリでないと Quartzはだめなんです。
逆に言うと ProjectBuilderは Mach-Oしか作れないので
Quartzを使うことができるはずです。

　http://www.ottimo.co.jp/koike/MacOSX/

にQuartz 2Dを使うという記事がたくさんあります。

>>217
参考になります。
CocoaとCarbonの違いというよりはバイナリ形式の違いなのですね。
ということはCarbonを選んだ場合にも10.xに最適化すれば
9.x以前では使えなくなるということになりそうですね。
やはりCocoaを使う事にします。
ありがとうございました。

>218
大方の予想通りではありますが，Carbonと言っても
9.xと OSXの両方で単一のアプリが動くとは限りません。
まずGUIデザインが変っていますので
ボタンの幅なんかを調節しなければいけません。

あとは，たとえば CD-DAを演奏するとか
そういうことになると，IO-Kitを叩く（らしい）とか
そういうことになっていき，だんだん 9.xと互換性が消えます。

他にもCarbon.libのバグかなにか知りませんが，
9.xと OSXではバグの挙動が違うということもあるから，
今のOSを取得して対策を切り替えるとか，色々要ります。

色々な方がやっているように，Carbonでも 9.x用と OSX用の
２種類リリースするのが一番いいのではないでしょうか。

最後に，一部で Carbonは Cocoaまでのつなぎで，
そのうち消えるという話もありますが，どうも違いそうな雰囲気です。
Cocoaは最初は感激しますけど，使っているうちに UNIXの泥臭さも感じます。
たとえば，ファイルのアクセスに pathを使うとか。
Carbonだと FSSpecが使えます。

結局どちらも成熟しきっていないのでMac OS Xのソフトはまだ
作るなということ？

>>217
>ObjCの解脱
まじ！？スゲーな

>220
永遠にCocoaは泥臭い部分が残りそうな気もしますよ。
ジョブスが NeXTSTEPを愛しているんだし。

>221

???
未だに ObjectiveCのことがよくわからないんだけど，
あれ，どこまでが言語仕様で何処からがライブラリなのでしょう？
そもそも ObjCを使っているのは ProjectBuilderと gccの一部だけで
事実上 Cocoaプログラム専用言語なのでしょうか，あれ。

>>222
ごめん、ObjCのことは分からないんです。
"解脱"って、ネタなのかとおもってつい・・・
今は答えられないけど、わしも勉強しますです。

>>219 Cocoaは最初は感激しますけど，使っているうちに UNIXの泥臭さも感じます。
たとえば，ファイルのアクセスに pathを使うとか。

ってよく聞くけどファイルの扱いだけで他にあんまりないと思うんですが。
ファイルにしたってNSStringとかで隠蔽されてるのでは。
つーかオブジェクト指向嫌い？

>>222
どうもObjCの権利はAppleが持ってるらしいです。でもObjC自体は他にも使われてる模様。
プログラム板にObjCのスレッドがあったのでそちらを参照してみては。
んでObjCの仕様ですが基本的なクラスはjavaでいうjava.langパッケージのようにほぼ言語使用(gccのObject、CocoaのNSObject、他にNSAutoreleasePoolとか)ではないかと。

>>222
NSxxxってのは全部Apple（NeXT）がくっつけたものだろ。
categoryやprotocolはどうなんだろうな？

JavaのObjectは言語に含まれているけど、NSObjectは言語外だよ。

>>224
ファイルのアクセスにパス使うのが嫌な場合は、Carbon呼び出してFSSpecで
アクセスするクラスを書けば良い。Objective-CがCの拡張であるがゆえに
可能な技。Cocoaの標準のファイルダイアログがパス使った実装の為に、
パス長の制限が掛かるが、これも自分で作り直せない事は無い。

>>225
カテゴリは元々のObjCが持っていたのでは無かったかな。プロトコルは分散
オブジェクトを実装する為にNeXTが行った拡張だった筈。ちなみにOPENSTEP
になる前のNEXTSTEPでは一番のベースクラスの名前はNSObjectではなく、
Objectだった。

>223
げだつ・・・やられた。
前にアホな友人が辞書に学習させていったんです。
すみません，レポートに書いたこともあります（鬱

>224
pathってオブジェクト指向なんですか？
Cocoaってパス長が1024バイトを越えるものにアクセスすると
あえなくクラッシュしませんか？
Carbonで FSSpec使っていれば大丈夫なのに，
ちょっと退化しているような気がします。

クリエータでなく（10.1でサポートされたけど）拡張子使ったり
元が UNIXなんだから仕方がないとはいえ，
良く（安定したとか）も悪くもMacではなくなってしまった寂しさはあります。

>224,225
言語仕様なのかな，と思ったら違うのですね。

>226
旧MacOSもしばらくは生き残りそうですね，裏で。

>>226
>カテゴリは元々のObjCが持っていたのでは無かったかな。
どっちといいたいの？

>プロトコルは分散オブジェクトを実装する為に
分散オブジェクトって何のことを言っているの？
要はインタフェースの多重継承ってことだろ、プロトコルは。

>>227
>Cocoaってパス長が1024バイトを越えるものにアクセスすると
ずいぶんとマメですね。

>pathってオブジェクト指向なんですか？
パスっていうのは、/Volumes/Mac OS X/Applicationsというものだよ。
おっと、引用符でくくらないと大変なことになっちまう。

>>228
>>プロトコルは分散オブジェクトを実装する為に
>分散オブジェクトって何のことを言っているの？
>要はインタフェースの多重継承ってことだろ、プロトコルは。

>>228は、分散オブジェクトは、Cocoaで使ってる分散オブジェクトのことを
言っているんじゃないか？
>>228の言っていることは本当かどうかわからないけど、
CocoaではsetProtocolForProxy:で、@protocol使わなくちゃなくちゃ、
そのオブジェクトのインターフェースを実装しなくちゃ、
分散オブジェクトを実装できないよ。

あと、
http://www.cs.ruu.nl/wais/html/na-dir/Objective-C/answers.html
によると、
NEXTSTEP 3.0 is released in 1992. The compiler supports Objective-C++,
and the Objective-C language has been extended with `@protocol'.
In the same year, gcc 2.0 comes supplied with an Objective-C runtime
library.

In 1993, gcc supports protocols by version 2.4. NeXT stops the
production of hardware. With NEXTSTEP 3.1 they include support for
PC's. NeXT starts creating other products not bound to a particular
operating system, such as Portable Distributed Objects (PDO), which
comes with its own Objective-C compiler and debugger.
だから、>>228は、ありえなくもない。

頑張ってCocoa覚えようかなと思ったけど、プロでもiTunes2みたいな事を
やらかしてしまうと知り怖くなったので踏み出せない。。。

>>205
ForteのUnix版入れたら、とりあえずOS-X上でうごいてるよ。
ときどきエラー出るけど。

お前らMacOSXでシューティング作るとき、
画面への描画はどんな手法（どんなライブラリ？）を使ったら
いいのか教えてください。

>230
あれはねぇ・・・・ないよ，普通は。
安心してプログラム書いて大丈夫。

>232
基本はCopyBits()でしょう。

>>229
ﾌﾟﾌﾟﾌﾟﾌﾟ、
http://developer.apple.com/techpubs/macosx/Cocoa/ObjectiveC/4MoreObjC/Protocols.html
を読んでprotocolの基本を勉強しておいでよ。
228の言ってることがよくわかるよ。

CopyBits()？Cocoaですか？探してみます。

>>234
ﾌﾟﾌﾟﾌﾟﾌﾟ、
>>234のリンクはNeXTがprotocolを作った*動機*は書いてないよ。
http://developer.apple.com/techpubs/macosx/Cocoa/Reference/Foundation/ObjC_classic/Classes/NSConnection.html
あなたもこれを読んで、どのようにクライアントが
分散オブジェクトを実行するのか調べてみましょう。
簡単に言うと、クライアントはproxyオブジェクトをとってきて、
setProtocolForProxy:で、ptorocolをセットすることで、
そのリモートオブジェクトのInterfaceが使えるようになるってこと。

protocol自体の何かについて話しているんではなくて、
protocol実装した動機は何かってことを話してるんだろ。
もしかしたらNeXTは、分散オブジェクトを実装したくて、
そのためにはprotocolを必要だったかもねって、>>229は言っているだけのような気がする。
確かに、分散オブジェクトがなければ、EOFやWebObjectsも可能にならなかったんだからね。

>>225
>>カテゴリは元々のObjCが持っていたのでは無かったかな。
>どっちといいたいの？


曖昧な物言いで、混乱を招いてスンマソ。Objective-Cの最初の実装はStepStone社
ttp://www.stepstn.com
の物で、これにはカテゴリもプロトコルの概念もなかった。カテゴリくらいはあるかと
思っていたが、推測ではStepStone版のObjective-Cは、実行時バインドの他に
静的バインドも選択可能な仕様となっているため、実行時にメソッドの追加を行える
カテゴリの機能を敢えて実装していないものと思われる。

>>プロトコルは分散オブジェクトを実装する為に
>分散オブジェクトって何のことを言っているの？
>要はインタフェースの多重継承ってことだろ、プロトコルは。

分散オブジェクトは、C++で言うと、COMモデルとか、Javaで言うとHORBみたいな
物で、オブジェクトに対する呼び出しを、他のスレッドやプロセス、他のホスト上の
プロセスにあるオブジェクトに対しても行える様にする物で、この時、呼び出される
側の実装ではなく、インタフェースのみが規定できれば呼び出しが可能なモデルと
なっている。このインタフェースの規定の為に用意されたのがProtocolオブジェクト
であったが、今ではインタフェースの多重継承を意味する物として広く用いられている。

>>235
CocoaにCopyBits()は無いんじゃん。見たことない。
drawRectの中で描画命令書く以外に無いんじゃないかな？
OpenGLの命令使う手もあるか。

>235
CopyBits()はCarbonですよ。
Cocoaだと何を使うかは知らない。
どっちにしろ，オフスクリーンを使うのが普通でしょう。

１．オフスクリーンを作る
２．背景を CopyBits()する
３．自機や敵，玉などを CopyBits()で乗せていく
４．オフスクリーンをウィンドウに CopyBits()
５．２へ戻る

この繰り返しです。

http://www.ottimo.co.jp/koike/MacOSX/MacOSX_text_02/01_09_02.html

に Quartzについて載っています（他にも色々）が，
たぶん Cocoaでもこんな感じでしょう。
あと役に立ちそうなのは

　http://www.big.or.jp/~crane/cocoa/pixel1.html
　http://www.big.or.jp/~crane/cocoa/imgObj.html

なんかでしょうか。

>>236
ﾌﾟﾌﾟﾌﾟﾌﾟ、
もうちょっと柔軟な考え方したほうがいいよ。
きみはプログラミングしたことないでしょ？
ｱｯﾊｯﾊ!!

気になって調べてみた。
http://developer.apple.com/techpubs/macosx/Cocoa/Reference/ApplicationKit/ObjC_classic/Functions/AppKitFunctions.html
にNSCopyBits()があったよ。使い方は知らん。

あと、http://developer.apple.com/ja/technotes/tn2007.htmlにCGDirectDisplayとかいうやつの使い方がある。
/System/Library/Frameworks/ApplicationServices.framework/Frameworks/CoreGraphics.framework/Headers/にヘッダがある。

全然詳しくないのだが、NSView#drawRectとかじゃ遅いのかな?

>>236-237
ふむふむ、
>>229を見ても、protocolの実装時期と、分散オブジェクトの実装時期が
同じってのは、なんかかかわりがあるんだろうね。

>>228=>>234=>>241か？
> ｱｯﾊｯﾊ!!

って、ちみちみ、
こら、ごまかすなー。

しょうがなけどもう一度いうね。何度もいうのは鬱陶しくて嫌なんだが、
>>236はまるで分かっていません。
http://developer.apple.com/techpubs/macosx/Cocoa/ObjectiveC/4MoreObjC/Protocols.html
を読んでprotocolの基本を勉強しておいで。
実際にプログラミングしない人に何度言っても無駄かもしんないけどな。
ﾌﾟﾌﾟﾌﾟﾌﾟ

>>244
どーでもいーことだが、荻原氏のObjCの本にはprotocolは元は分散オブジェクト間の通信規約を抽象化したもので、現在はさらに広い概念で使われている(つまり多重継承の代用)。んでJavaのinterfaceはこれを取り入れたものと書いてある。
さらに分散オブジェクトのprotocolの設定に関して、あらかじめsetProtocolForProxy:を行うことでメッセージ送信の度にメソッドの引数の型チェックをしなくていいので通信の効率を向上できると書いてある。

たぶんObjCは型チェックがゆるいので、もともとprotocolのようなものは必要ないと考えられてたのだと思われ。それが分散オブジェクトにより、メソッドの引数を送信する必要が発生したのにあわせて導入されたのではないかと。

みなさんPowerPlantどうやって習得しました？

C++は理解しているので、Windows MFCは結構すんなり
いけたのですが、PowerPlantがあまりにも資料が少なく
抵抗があります。

みなさんどうやって習得されました？
よいサイトなどがあれば教えてください

>>246
「もっと進め！コードウォリア」
というのが定番だけど、これ最近、絶版になったんだよね。

>>242
Cocoaの標準的なAPIだけ使ってるとどーしても描画は遅いです。
ttp://www.zero-flux.com/
ここにあるシューティングゲームを動かしてみると良く分かる。

あとdrawRect:は単にViewに再描画の要求がかかった時に呼ばれるメソッドでしかなく、
CopyBitsとはちょっと性質が違います。

えー、レスをくれた方、大変参考になりました。ありがとうございます。
CocoaOnlyでいくつもりでしたが、まだプログラミング
はじめたばかりだし、Carbonについても少し学んでいこうかと
思います。ありがとうございました。

来月号のCﾏｶﾞにCodeWarrior7(forMac)のレビューが。

赤松氏の「cocoa for java」よりもうちょっと突っ込んだ本ってありますか？

>>244は
君が何かむしゃくしゃしているいうのはわかった。
せっかくの良スレをこわさないでくれ。そのリンクはもういいよ。
でも>>236とか>>245の意見にくらべて、君の今の説明はprotocolの説明のリンクだけ。
そのリンクにはこう書いてあって、だからそうじゃないだろってのが聞きたい。
引用して説明が長くなってもいいからさ。そういう話ができないのなら、もうやめとけ。
悪口はいらないよ。つまらないから。

それにしても
>>225=>>228=>>234=>>241=>>244
って行くたびに性格が変わっていってるのはなぜ。。。
最初は良かったのに。。。

Carbonﾑｽﾞｲよー（´Д｀；）
リソースの定義法がｻﾊﾟｰﾘです。どこかないですか？

>>252

何度も聞きたいようだね。何度もいうのは鬱陶しくて嫌なんだが、
>>236はまるで分かっていません。
http://developer.apple.com/techpubs/macosx/Cocoa/ObjectiveC/4MoreObjC/Protocols.html
を読んでprotocolの基本を勉強しておいで。
実際にプログラミングしない人に何度言っても無駄かもしんないけどな。
ﾌﾟﾌﾟﾌﾟﾌﾟ

う、ごめん。
252は英語がまるで読めない消防だったんだね。
プログラミングするには英語も読めないとだめなんだよ、ﾎﾞｸちゃん。

>>253
.rファイルの書き方ってことかよ？

>246
K仲川氏の本で覚えましたが、
PowerPlantも思想がわかればあとは自力で出来ます。
あの本だけでは絶対的に内容が不足していますが、
それでも一応作れるようになったのは考え方が理解できたからです。
MFCができれば楽かも知れません。

>248
たまたま
　http://devworld.apple.com/qa/qa2001/qa1068.html
を見つけました。
前からDrawSprocketの一部は残ると聞いていたのですが、
ひょっとすると使えるかも知れません。
OSXになってからハードウェアの直接アクセスとか
ややこしくなっているらしいので救世主かも。

それより、InputSprocketはどうしてくれよう・・・？
ジョイスティック無しってのも困る。

>253
いまさらだけど、ResEditを使うのが良いでしょう。
Appleのサイトを探せばでてきます。

>>256 Yes .
>>253
Classicのままですかね？
Classic環境起動遅いんだよな…鬱だ…

>>258
まずね、
ftp://ftp.apple.com/developer/Tool_Chest/Core_Mac_OS_Tools/MPW_etc./Documentation/MPW_Reference/Building_Progs_In_MPW.sit.hqx
をﾀﾞｳｿﾛｰﾄﾞ。
こいつのAppendix C（PDFの585ページ）を見れ。基本はこれだ。

>>257
>それより、InputSprocketはどうしてくれよう・・・？
>ジョイスティック無しってのも困る。

とりあえず君の出発地点はここだ。
http://developer.apple.com/techpubs/macosx/Darwin/HID/index.html

リンクばっかだと252のﾎﾞｸちゃんにまた怒られるな。

protocolってJavaでいうInterfaceだろ？
簡単に言えば。

てか
>>245
に詳しく書いてあるね、、逝ってきます、、

なんだなんだ、ひさびさに来てみればすごいことになってるなあ。

>>254の内容は、>>226の反論にはならないよ。
第一、>>254（>>260か）は、>>254リンクを彼が本当に読んでれば、
「要はインタフェースの多重継承ってことだろ、プロトコルは。」
なんて言い方はしないはずだよ。そのページではそんな風な言い方で結論していない。
protocolはそういう側面もあるけどね。それは単に「側面」だ。
>>254は単にgoogleだかdeveloper.apple.comで検索してリンクしてるだけっぽいな。
>>254は、>>254のリンクしたその次のページ読んでないじゃん。
http://developer.apple.com/techpubs/macosx/Cocoa/ObjectiveC/4MoreObjC/Remote_Messaging.html

>>263
そう。
protocolはとはなんですか？という質問にRemote Messagingという単語を
使わないと答えられない君は人間失格ってこと。

ＣＧＩ(Perl言語)で…

#!/usr/local/bin/

print<<END

Content-Type: text/html

<html>
<head><title>Hello, World!</title></head>
<body>
Hello, World!
</body></html>
END


↑あれ？こうだったっけ？半分覚えた状態だったので・・・

>>265
OS Xの場合はDev Tools入れたデフォルトの状態だと、
#!/usr/bin/perl
ですね。

ある開発案件をWin用とMac用同時に発注する場合、やはり
Mac用の開発予算のほうが高くつくものですか？
MacOS X対応ともなれば、さらに高くなりますか？

開発屋によって、差はあると思うので、同じ開発屋に
Win用とMac用を一緒に発注するものと仮定して、教えてください。

>267
あんま関係ないと思います。
ステップ数、あるいは時間に応じてお金がかかるとしたら
MFCをつかう Windowsより InterfaceBuilderが使えるOSXの方が
安く済むかも知れませんし、プログラマが多い Windowsの方が
さっさと終わって安く済むかも知れません。

>>267
一般的にMacプログラマの工数割高です。競争相手が少ないので最初の見積も
りで強気の金額を出してくるはずです。で、「高い！」と言われて調整しな
がら徐々にプライスダウンしていくということで。それでも通常Winより高め
になるのが普通です。
知っている限り開発費をステップ数でカウントする会社はあまりないと思い
ます、時間というか何人の人間で何ヶ月で作るか「人月の工数」で算出する
ところがほとんどです。

対応OSによる開発費は
「OS Xのみ」若しくは「OS 9以前のみ」対応ならそこそこの金額。
CarbonアプリでOS XとOS 8.5〜OS 9の両方に対応となると実装の手間も
若干増えますけどそれ以上にテストの工数が一気に増えて工数が1.2〜2.0倍
くらいになります（ウチの場合）。
OS 8〜OS Xまで対応となるとCarbon版と別に従来版と・・・（以下略）。
最後のような要求例は現実的にはほとんど無いと思いますけど。

＞同じ開発屋にWin用とMac用を一緒に発注するものと仮定して

その場合、社内の連中にWin用をやらせ、Mac用は外注に、ってオチで
高くなる可能性はあるかもね。どっちにしても同じ業者に発注という
のは本当にそれでいいのか慎重に考えようね

ごめん。両方とも外注に出す、ってオチもありうるかも。
その場合も、別々の外注に出す、っておおいにありうる

>>266
ほうほう。はじめて知りました。
(自分は、OS X は、持ってないんですけどね。)

そういえば、自分はBIGLOBEのプロバイダを使っているのですが、
BIGLOBE では、Web サーバーで、Perl パスが #!/usr/local/bin/perl
になってたんです。

(あれ？そういえば、BIGLOBE の Web サーバーって、
HP-UX が使われているんでしたっけ?)

（´＿ゝ｀）＜　話題変わりまーす

Cocoaからプログラミングをはじめたいと思っているのですが、
ObjCとJava、どっちが将来他の環境に移る時に
すんなり以降でき、どっちが入りやすいでしょうか。
ちなみに、シェルスクリプトとPerlとEmacsLispと、あとC言語が
少しだけ経験があります。マジ質問です。よろしくお願いします。

すいません。訂正します。
C++的なオブジェクト指向のJavaと、
SmallTalk的な(MVC?)オブジェクト指向のObjC、
どちらが入りやすい,又使いやすいか皆様の
意見を聞かせてください。

> C++的なオブジェクト指向のJava

こういうこと書くと怒りだすJavaプログラマいるよ。
漏れは怒らないが（というかJava興味ないので）

習得度で言えば、Objective-Cのほうが楽だし、
OOPとしての勉強はSmalltalkの影響受けてるだけあって
正統って感じがするね（生Smalltalkをかじるとなおよし）

>>273
そこまで経験があるならどちらがいいか判断付くと思うのだが、、

>>275
　　＞怒りだすJavaプログラマ
　　以後気をつけます。
　　＞Objective-Cの方が楽
　　＞生SmallTalkをかじるとなおよし
　　参考にします。ありがとうございます。

>>276
　　＞そこまで〜判断付く
　　世の中をまだ知らない為、判断付けるのが
　　恐いのです。すいません。

>275
とはいえ，JavaってC++を意識して作っているのは間違いないと思う。

>>273
CocoaするならObjective-Cだと思うんですけどねぇ。
わっざわざJavaでやんなきゃいけない理由がわからないねぇ。
ま、どっちにしても将来他の環境に移ることを前提としてんなら
Cocoaは選択肢に入らないだろ、ふつう。

>279
>どっちにしても将来他の環境に移ることを前提としてんなら
>Cocoaは選択肢に入らないだろ、ふつう。

色んな環境，言語に触れておくってのは大事なことだと思いますよ。
たとえばLISPの関数閉包を知っていると，STLが分かりやすいとか。
知らなくても使えるけど。

>>279
　　Cocoaってクローズド過ぎですか？もしかして
　　Apple社さん、がんばってくだされ…

>>280
　　ですよね！でも、あまりに特殊すぎて抜け出せないってのは
　　ないでしょうか？それが恐いです。

MacOS Xってライブラリの拡張子が.dylibとかついてるんだけど
これってFreeBSDの.soとは違うの？

なんかGNU物のコンパイルは通るらしいから通常の.soとかも
使えると思うんだけど詳しい人情報キボン

＞わっざわざJavaでやんなきゃいけない理由がわからないねぇ。

結局のところ、Javaわかる人のほうがObjective-Cわかる人より
多いとか、そういう政治的な理由でしょう。Javaのほうが面倒
だと漏れは思うんだけど、なかなか信じない同業者が多いあるよ。

＞あまりに特殊すぎて抜け出せないってのは

逆だよ。「ふつー」ばっかりにとらわれてコケている同業者多いよ
いつまでたってもCOBOLしかできないとか、FORTRANから抜けられない
とか、そういう偏食してたらダメよ。

＞JavaってC++を意識して

かもしれないけど、宇多田と倉木みたいなもんで
表面的に似通っているけど、中身が別人になってる。
たとえば、C++ではdeclarationとdefinitionが別々に記述して
面倒なのが、Javaだったら一本化できて楽だとか、
Javaだったらオブジェクトの参照だけに対し、
C++だったらポインタか参照か、そのものかの３パターンが
あって、それぞれで対応が変わるから面倒だとか。

（・∀・）＜　決心できました。偏食しないで
　　　　　　　バクバク食っていきます。

>>285
私見だが、JavaはObjectPascalにC++のフレーバーをかぶせた物と思われ。
マクロもヘッダもなくて、中間言語にコンパイルして実行とかね。何よりも
'.'だけ書いていれば解決する世界はとてもPascalっぽい。

>>273
Live long, and prosper!

ぅぅっ、ageてしまった……。
まぁ、ageついでに言うと、'_'を余り使わないコーディング慣習も
Pascalっぽい。Pascal≒Smalltalk≒Javaだよなぁ。基本的に単一
継承だし。Javaはきっと、C++に洗脳されてしまったプログラマに
Smalltalkの福音を与える為の使徒なのだと思われ。

>>287
（´＿ゝ｀）＜　ｱﾘｶﾞﾄﾝ｡しぶとく行きますよ。
　　　　　　　　ところで、今度Cocoaはヤッパリ！の本が出るそうですが、
　　　　　　　　俗にいう「萩原本」とどちらがいいですかね？買うとしたら。
　　　　　　　　さすがにリアル厨なので英語だらけはキツくなってきたのです。

萩原本は、純粋ObjC本なので、補完する物としてCocoa本としてのヤッパリも必要と思われ。
赤松本がいまいちだったので。

>>290
純粋ObjC本というよりはFoundation本だろうね。立ち読みしただけだが。
もうひとつはAppKitなんだろうね。どっちかっていうと。

どっちにしてもこの手の本はあまり期待しないほうがいいと思いますよ。
リファレンスがあんな薄っぺらになるわけないんだから。

>281
むしろ，一つの言語しか知らないほうが危険ですよ。
たとえばC++しか知らなくて「オブジェクトは構造体だ」とか
そういう認識にはまって（はまらないか・・・）しまうと
まともなオブジェクト指向言語をみたとき意味不明になるかも。

>285
悪い部分は改善しようという意思は見えますね。
でも，ぜんぶぶっ壊して構造改革したって感じもしません。

>>289
両方を買うべし。扱っている焦点が違うから。

>>292
「クラスは構造体です」みたいな認識に
はまっているやついるよ、けっこう
もちろんC++しか知らないひと

> リファレンスがあんな薄っぺらになるわけないんだから

まともに書いてたら３年ぐらいかかるし、
その頃には内容が陳腐化しているし、
おまけにブ厚い本は苦労するわりには売れないし、

で薄くなるわけです

Macソフト発注の件、、
>>269 etc..
なるほど参考になりました

ただ、極めてアルゴリズムが同じソフトを同じ会社に発注したほうが
共通（アルゴリズム的に）部分が多いので、その分割安になるのでは？
という考えは間違っていますか？
（当方もプログラマーなので、開発プロセスはわかってるつもりです。
なら、自分でやれば？という返答は勘弁ください（笑）

>296
共通に使えるコードは有効活用したほうがいいですよね。
けど，AppleScriptをサポートしようと考えたりすると
表層のGUIだけを置き換えるような単純なものではなくなります，たぶん。

マックではソフトを構築できないと聞いたのですが本当ですか？

>>298
スレを読んでから発言しましょう。

＞＞296

同じ要員がやった場合はそうかもしれないけど
別人がやる場合はどうでしょうね。
それとWinとMacを両方わかってないと共通できるかどうか
なんて誰も判断できませんしねー。
ソフトの再利用という深いテーマにかかわるけど
理屈と実践はべつものですから。

>>298
ネタはよそのスレでやってください。

私見ですけど，Macはガイドラインというか
なんとも説明しづらいものを重視する人が多いですから
Windowsのベタな移植だと受けが悪いでしょう。

移植というより同じことができる別のソフトを開発することになるかと。

Winにもガイドラインはありますよ。
守っている人は少ないけど（爆）

そういえば、ＨＳＰのＭａｃ版、できたよね。
http://www.onionsoft.net/

唯、これは68kでは使えないみたい。。
68kで使えてもいいはずなのにねぇ。

あと、これは、今後、Cocoaがどうとか？
今後、Macでプログラミングをはじめるのにはいいかもね?

>302
Windowsっていろいろ個性を主張する方が多いですね。
そのせいで使いにくくなることがしばしばあるのが残念です。

でもその結果，新しいインターフェイスが生まれることもあるし
必ずしもマイナスではないのですが。

>303
プログラミングは全員がやる必要はないのですが，
最近の普及率はちょっと低すぎると思います。
１０年くらい前（もっとかな）は標準で BASICやHyperCardがついていて，
ちょっと興味がある人はやってみたものです。

けど，最近では開発環境は別売りだったり
プログラミングそのものが難しくなっていました。
そこに Cocoaが来たわけですから面白くなりそう。

Windowsも VisualBasicの一番下のモデルを
標準で付ける・・・とまた独占禁止法とかうるさいんでしょうが
やったほうがいいと思います。

今月控えていた仕事がぽしゃってしまいました。しかも年末年始なので
動いても無駄におわりそう。
Macソフトの開発案件があれば、すぐ着手できます。
（まじねた、なんならコンタクト用メールアドレス用意します）

ちなみにWindowsでも全然OKです。
たぶん、このスレに（まともなことを）書き込む人って
実は、お互い会社・実績ソフト名か、名前くらいは知ってたりするのも
めずらしくない世界ですよね。よいきっかけになればいいですが。

>>306
あなたの発言はプログラミングのことではありません。
スレのタイトルを100回読んでみてください。音読可。

従来のFinderに近い（そして若干のアドバンテージがある）
デスクトップメタファーのシェルというかファイラーを
>305さんのようなプロの方が作ってくれないかなと期待してしまいます。
報酬は払えませんが，シェアウェアならばレジストします。

>>308
よくそれ言う人いるんだけど、9のFinderみたいにできがいいのは
Apple内部の人間もしくは内通者がいないと無理だよ。
そのうちAppleもXのFinderに金かけだすんじゃないかな。

>>309
漏れもそう思う
動きの機敏なFinderを作ろうと思ったら多分CocoaとかCarbonより
下のレベルのAPI使わないと出来ないと思う
これって一般には公開されてないから普通の人じゃ無理だよね

Windowsのエクスプローラがいい例

そうかな？
http://www.bekkoame.ne.jp/~iimori/sw/Coela.html
とかはオーソドックスな作り方をしていると思うけど

>>305,306
激しくスレ違い。

>>303
今さら68Kをサポートしても旨みがないです。
漏れも68Kサポートはとっくに切りました。

>>311
それとかあともう一つあるのは知ってるよ。
そういうのがいつまで続くか内心楽しみではある。

>>313 SNAX?いいと思うよ。

>>314
あ、そうそうそれ。
どっちが先にやめるんだろうね、そんときのいいわけも楽しみなんだけどね。
どっちしてもある程度は作らせないとつまらないので、シンプルで使いやすい
ですとか、これでXのFinderには用がなくなりましたって感じの励ましを
うそでもいいからたくさん送ってあげてね。

決してこの手のソフトを否定しているわけじゃないのでそこんとこよろしく。

>314
Coelaの作者，iimoriさんはプログラマとしてはスゴイ人だと思いますんで
完成させる実力はあると思います。

彼（ですよね？）は何をしている方なんだろう？
フリーではなさそうだし，メールのヘッダには所属は書いていないし。

>>これって一般には公開されてないから普通の人じゃ無理だよね

技術的に難しいところはないと思う。公開されているAPIで十分作れる。
問題は規模と完成度で、例えば9のFinderと同じ感触で７割くらいのよ
く使われる機能だけを持ったアプリケーションならがんばれば個人で作
れるだろう。お手本があるというか真似するだけだからね。

問題は残りの３割の機能で、これを個人でカバーするのはすごく大変。
NetInfoやiDiskのサポートとかCD-Rのburningとか、もっと身近な
とこだとアイコンビューの管理とか（リストだけなら簡単）。とまあ手
間と時間がかかる。CoelaとかSNAXもそんなに細かいとこまで作り込
まれることは決してないと思うけど、そこそこ便利なFinderの補助ユー
ティリティ（置き換えは無理）として存在価値はあるんじゃないかな。

>>313
MacShellはどこいっちゃったんですかね...
個人的にはあれが好き。何よりフリーだしプレビューもあるし

いや確かに出来る事は出来ると思うよ
「機敏な」と書いた意味がちょっと伝わらなかったようだ

シェルとして使うアプリなら結局ディスクとのI/Oがどうしても必要に
なるし余計なAPIレイヤーを通さない方がこういう処理は速いでしょ？
さらにCocoaというかMach-OのFrameWork自体がダイナミックリンク
しまくりのフォーマットだからやっぱりこういう処理は遅そうだなと思ったわけ

たとえばsgiのIRIXなんかにはファイルシステムを通さないダイレクトディスク
アクセスのAPIなんかがあってディスクI/Oがめちゃくちゃ速い
HDTVのリアルタイム処理なんかにはディスクRAIDとあわせてONIXのバスの
スループットを最大限に生かせる
その代わりセクタなんかは自分で把握しておかないと駄目なんだけど
まあこれは極端な例だけど「機敏」と言う意味の一例として

今思い出したけどDarwinのソースは公開されてるからシステムコール
直接叩けばいーんじゃん・・・ｲｯﾃｸﾙ

>319
>アクセスのAPIなんかがあってディスクI/Oがめちゃくちゃ速い

テストしていないけど，CocoaとかCarbonの
IOってそんなに遅いんですか？
古い情報だけど

　http://www.bekkoame.ne.jp/~iimori/progtips/fasterdiskio.html

叩き方によっては大分違うのは有名ですが
上手くやってもCocoaじゃダメなのかな。

>>318
ttp://members.tripod.co.jp/bitworks/

＞ Coelaの作者，iimoriさんはプログラマとしてはスゴイ人

同感。なにものだと思うぐらい、とんでもなく高度なこと
知ってますよね。最近ではマウスを高速化するドライバを
発表してたけど、純粋アプリ屋の漏れには真似できない。

だって、あれはDarwinの一部として公開されてるApple製のUSB Mouse Driverのソースの定数値（マウスの解像度）を変えてビルドしただけだよ。もちろん一緒に修正したソースも公開してるけど、変更したのはほんとに１行だけ。

>>319
> シェルとして使うアプリなら結局ディスクとのI/Oがどうしても必要に
> なるし余計なAPIレイヤーを通さない方がこういう処理は速いでしょ？
たぶんOSXが遅いから最適化が必要といってるんだろうけど、
OSX（or Finder）の遅さってのはFileI/Oではないと思う。
やっぱりWindowServerが遅いんだよ。G4でも描画は遅い。
それに比べてWinNTなんかだとPentium266MHzでもきびきび動くよね。

> さらにCocoaというかMach-OのFrameWork自体がダイナミックリンク
> しまくりのフォーマットだからやっぱりこういう処理は遅そうだなと思ったわけ
Frameworkはdylib(MH_DYLIB)を使ってるよね。
dylibはアプリケーションの立ち上げ時にSymbolを決定しようとするから、
そのときに遅くはなるけど、一度決定されれば、他ではそれほどかわらないよ。

> たとえばsgiのIRIXなんかにはファイルシステムを通さないダイレクトディスク
> アクセスのAPIなんかがあってディスクI/Oがめちゃくちゃ速い
これはRDBみたいな独自データストレージに対してきいてくる。
一般的なファイルシステムに対してそういったダイレクトアクセスAPIは
あまり効果ないと思う。だって、結局はファイルシステムにアクセスするんだから。

> 今思い出したけどDarwinのソースは公開されてるからシステムコール
> 直接叩けばいーんじゃん・・・ｲｯﾃｸﾙ
これって実際にはなんなのかな？
少なくともopen/write/readなんかのSystemCallはDarwinではガワだよね。
だってそれらのAPIはUnicodeじゃないから。
いがいとCarbonのFile Manager APIでも別にスピードのロスってのは、
ないのかもって気がしてきた。

>>319
>「機敏な」と書いた意味がちょっと伝わらなかったようだ

じゃあ、FinderなんかはBSD+Machレベルでは何のSysCallを呼んでるのかなと
調べようとしたんだけど、あらら、OSXでは、ktraceって動かないんだね。

error: ktrace() system call not supported in the running kernel
re-compile kernel with 'options KTRACE'

だって。カーネルコンパイルしなおしかー。
なんでAppleはktraceをdisableしてあるんだろ。

9のような機敏なFinderはWindowServerが遅いから、
iimoriっていう聞くところによると凄い人がどんなに頑張っても
無理無理よ〜んってことでいいですか？

WindowServer自体はこれ以上最適化しようが無いのですかね？
もしWindowServerが速くなればほとんど全てのアプリが恩恵を受けられるというのに。。。

ahora.c : line 319-320
致命的エラー : システムコールは叩けません。

>>325
% nm /mach

nm で。
/System/Library/CoreServices/Finder.app/Contents/MacOS/Finder

軽いFinderを作るのはAquaがある以上無理だと思います。
Appleがチューンするか，高速なマシンに乗り換えるしかない。
けど，「>console」でログインするとか
classicの動作速度を見るかぎりOSが腐っているわけじゃないのはわかります。

ボタンなんかのアニメーションをどうにかする（究極的には自分で作る）か
遅いことに関しては無視しちゃうかですが，
私は挙動を何とかしてくれれば遅いのはある程度我慢します。

漢字Talk７のファインダもMac OS 8のファインダも
発表当時の機種では決して速くなかったと思うが‥。

ShadowKillerを使うと速くなるYO。
http://www.unsanity.com/products.php
でも、さびしい（涙

インターフェースのカスタマイズはＯＳ８の頃からやるやる言ってやってない事の一つだからなぁ
いいかげん、カレイドスコープで『できることとできないこと』の見極めがついたんだから
そろそろ、カスタマイズ可にせれ。　・・・ＯＳ７．６風の白黒にするガナー

kernelのコールなんてアプリから直接叩けるわけねーだろ、
このｳﾞｫｹが！！

MacOS Xのスクリーンセーバーってなにげなく見てるとわかんない
かもしれないけど、実は全画面で拡大縮小、合成してるね。
G4の遅いマシンでもかなり滑らか（そのままムービーを再生する以上に
滑らかに感じるけど）
これもクオークの恩恵ですかね？

>>333
テーマは昔からあるんだが、何か？
凶のﾃﾞｽｸﾄｰﾊﾟを見れ、て優香キミCopland派？（ｗ

涸井戸であれこれいうのはnssでも笑われそうだじょ。
http://www2.odn.ne.jp/qwer/index_nss.html

>335

http://pc.2ch.net/test/read.cgi?bbs=mac&key=1005820692&ls=50

の11にも書いてあるけど誰もコメントをつけない。
スクリーンセーバーって不思議。

CodeWarriorでClassic用のプログラミングをしようとしているんですけど，
CodeWarriorってコーディングする際に
VBやRealBasicみたいにTABキーで命令や関数を補完したり，
関数の候補一覧を表示することすることはできないのでしょうか．

Toolboxを一文字間違える度にコンパイルを失敗するのは面倒臭い．

それともC++のコーディングってこういうものなのかな．

>>328
nmだとシンボルしかしらべられないよ。そうじゃなくてktraceしたいわけです。
DarwinだけでUnicodeファイルシステムをアクセスするには
どうすればいいのかなってふと思った。xnu見てみる。

>>334
> kernelのコールなんてアプリから直接叩けるわけねーだろ、

彼の言いたかったのは、FrameworkのAPI呼ぶよりBSD+Machのシステムコールが呼べるんだったら
BSD+Machのほうがパフォーマンスだせるんじゃないかって言ってたんじゃないのかな？
VMのアクセスだったら、FrameworkのAPI呼ぶよりMachのvm_*()とか呼ぶとか。
NSPortとか呼ぶよりmach_port_*()とか呼ぶとか。（うーん、動くのか？）
けっこう、BSDのシステムコールをMachのやつに置き換えても速くなるんじゃないかな。
例えば、pthread使うより、Machのcthread使ったほうが効率的っぽい。
あと、BSDのPipe使うんだったら、MachのPort使ったほうが速そう。

でもこういうことすると、わけわからんバグになやまされたり、
何倍もしっぺ返しがきたりするから、たいへんそうだなあ。

>>337
あのスクリーンセーバーは2Dイメージの拡大・縮小にOpenGLのハードウェア
アクセラレーションを利用しています。だから、漏れのLombardなんかぢゃ、
殆ど動かない。AGPバスﾏﾝｾｰ！

>>339
そーゆーことか。それならDarwinってあんまり関係ねーんじゃねーの？

BSDやMach層では大丈夫かもしれんが、そこで起こしたことをCarbonやCocoaの
層で整合性をとるのは難しいと思うぞ。その辺は公開されてないしね。

>340
Windows使うやつとグラフィックボードの話をしていたんだけど
そしたら，Direct3Dには対応するけど OpenGLには対応しないとか
そんなことを話していた。

もちろん高価なのは OpenGLドライバがあるらしいんだけど
Macでも OpenGLを前提として開発して大丈夫でしょうか。
ユーザー様がどんなビデオカードを使っているかわからないんだし。
Appleがやっているんだからいいのかもしれないけど。

>>341
> BSDやMach層では大丈夫かもしれんが、そこで起こしたことをCarbonやCocoaの
> 層で整合性をとるのは難しいと思うぞ。その辺は公開されてないしね。

UIは確かにそうだよね。
でも、xnuのコード見てたら、
CarbonのバックエンドのFileI/OやThreadのAPIとかのコードだったら使えるかも。
Darwinのシステムコール呼ぶ方が速くなるかもって気がしてきた。
CocoaはあまりMachとかのThreadコールとかとまぜちゃだめみたいだけどね。

>>319がしてた話に戻るけど、
FinderのFileのリストを表示する部分なんかは
CarbonのFile Manager使わないで、通常のUnixfileI/Oのシステムコールが使える。
Darwinの場合、FileI/Oは、BSDのものよりさらに改良してあって、
HFSからUFSまでサポートしてるし、creator/typeなんかもアクセスできるようになってるし、
キャラクタセットはUTF-8ベース。すげー。

>>319の
> 今思い出したけどDarwinのソースは公開されてるからシステムコール
> 直接叩けばいーんじゃん・・・ｲｯﾃｸﾙ
も、バックエンドなら、ある程度期待できるよ。

なんか最近、Macの部分よりもMach+BSDの部分の方がおもしろくなってきたっす。

>>343
> CarbonのバックエンドのFileI/OやThreadのAPIとかのコードだったら使えるかも。
> Darwinのシステムコール呼ぶ方が速くなるかもって気がしてきた。

じゃないや。

CarbonのバックエンドのFileI/OやThreadのAPIとかのコードだったら、
それをDarwinのシステムコールに書き換えて、
Darwinのシステムコール呼ぶ方が速くなるかもって気がしてきた。

ってことっす。

うわ詳しい人が出てきたね
正直ほとんど憶測と勢いで書いたただのDarwin厨房です
（UNIXでの開発経験はあります）

漏れの言いたかった事はその通りです
例えばMacだとファイル容量を常に表示するようなオプションがあるけど
ああいうのはAppFrameWorkからじゃなくてDarwinのシステムコールを
直接使ったほうが速いんじゃないかと

dylibは確かに起動時にはシンボルのバインドが終わるけどFinderみたいに
ユーザからは通常終了できないアプリじゃない場合は起動と終了を繰り返す
事になるよね
そうすると起動時間が結構気になるんじゃないかと思う
一度立ち上げたら終了しなければいいんだろうけどそういう使い方をユーザに
強いるのはよくないと思うわけ

>>345
> 一度立ち上げたら終了しなければいいんだろうけどそういう使い方をユーザに
> 強いるのはよくないと思うわけ

うーむ、メモリが512MB、HDが20GBが普通の時代に、仮想記憶以外選択できない
OS Xにあっては、終了しないと言うのが正しい使い方であると思われ。

終了しても二度めの起動は速くなると言うのは、なぜ?

>346
だけと立ち上がりまくっているアプリを
全部（でなくてもいいけど）終了させると軽くなった気がします。
もっと高速なマシンを使っている人には不要なのかもしれないけど。

>>345
つーより、Frameworkのロード自体が高価ってのは間違いだよー。
Frameworkみたいな共有ライブラリのおかげで、
複数のアプリケーション間でそのライブラリを共有して
使用メモリも節約できるし、何度も同じコードをハードディスクから読み込まなくてもいい。
Unix, Windowsなど他のOSでもみんなやってることだよ。

それとも、FrameworkはやめてKernelに全部入れたらと思ってますか？
Kernel内に入れると、そこがクラッシュした場合、OS自体をリブートしなくちゃならない。
Kernel内にはシンプルで本当に必要なものだけを入れた方が良い。
で、さらにその考えを発展させたのが、Microkernelだよね。

>>346
> 終了しても二度めの起動は速くなると言うのは、なぜ?

dyldがキャッシュしてライブラリを覚えていて、
再度サーチする必要がないから。

>>345
> dylibは確かに起動時にはシンボルのバインドが終わるけどFinderみたいに

そうそう、これは、OSXでのdylibは、ちょっと違う。
初めてその関数が呼ばれたときに、その関数のシンボルのバインドがされる。
いわゆるlazy bindingってやつですね。
setenv DYLD_BIND_AT_LAUNCH 1
しとけば、起動時にバインドされるように変えられるけどね。
man dyldしてみるとこの辺が書いてある。

定説。
マックユーザーはプログラム出来ないのがあたりまえ。

ちょっと言葉が良くなかったようです
FrameWorkのロードが高価だって言ってるんじゃないです
だってそれはMach-O dylibじゃなくてELFのsoでも同じだから（ｗ

言いたかったのは>>349で書いてくれてますがシンボルのバインドの事です
つまりELFのsoはシンボルのアドレスがリンク時に決定されるからアドレス
変換がいらないよね
でもMach-Oのdylibの場合はアドレス変換が起動時(または関数コール時)
にされるからどうしても反応速度という意味では遅くなると思う

まあディスク-メモリ-CPUの速度が速いなら体感的にはどうでもいいレベル
なのかな

で、結局のところ9のように軽快なFinderは作れるのかね？

>352
どうなんだろう？
OSXのFinderの不備か，OSXの不備かしらないけど，
アイコンの位置を覚えてくれないとか
困った問題はどっちに起因するかによるでしょう。

はやくAppleに本腰入れてもらいたいのら。XのFinder。

お金があるうちに優秀なプログラマ動員して
OSXを魅力的なものにすればAppleの未来は明るいかもしれない。

クライアントとしてのUNIXとしては最強だと思うのは
やっぱ信者だからかな。

>>351
> 言いたかったのは>>349で書いてくれてますがシンボルのバインドの事です
> つまりELFのsoはシンボルのアドレスがリンク時に決定されるからアドレス
> 変換がいらないよね

違うよぉ。
ELFだって、そんなのリンク時に決められない。
じゃあなんで、コンパイル時にfPICわざわざしてるのか考えてみそ。
このへんはld.soとかのmanを見てみれば良いのかな。

>>356
え？いらないでしょ？ジャンプテーブルにバインドされるじゃん
少なくともアドレスの計算は必要ないはず

>>357
> 少なくともアドレスの計算は必要ないはず

じゃあ、テーブルを見てみましょう。
例えば、Linux上で、
nm libghttp.so.1 | grep strlen
なんて打ち込んでみます。
すると、
U strlen@GLIB_2.0
なんて出てくる。これはlibghttp.so.1が別のライブラリ(libc)のstrlenを呼んでるから。
このUっていうのはアドレスが解決されていないってこと、未定義ってことです。
ね、リンク時にはきまらないのだ。というかわからない。

www.linux.or.jp/JF/JFdocs/GCC-HOWTO-6.html
あたりを見れば書いてあるよ。

>>357
http://www.linuxjournal.com/article.php?sid=1060
に、LinuxのELFの場合について詳しく書いてある。
この例では、printf()を呼ぶだけのプログラム（hello）が
printfを実装してるshared library(libc)に対して
どのような情報を持っているかを説明してる。
で、問題のjump tableは、helloプログラムの.pltセクションに書いてある。

This contains the jump table that is used when we call functions
in the shared library. By default the .plt entries are all initialized
by the linker not to point to the correct target functions,
but instead to point to the dynamic loader itself.
Thus, the first time you call any given function,
the dynamic loader looks up the function
and fixes the target of the .plt so that the next time this .plt slot
is used we call the correct function. After making this change,
the dynamic loader calls the function itself.
This feature is known as lazy symbol binding.

ってことで、最初はdynamic loader(これってld-linux.so.*のことだよね)をポイントさせといて、
その関数が最初に呼ばれた時に、dynamic loaderが実際のライブラリの関数を見つけて
書きかえるらしい。

結局LinuxでもOSXでも同じで、関数が最初に参照されたときにbindしてる(lazy binding)ってことみたいだね。

ちなみにWindowsのDLLも実行時にアドレスが解決される。
LoadLibrary関数でDLLをロードし、
GetProcAddressで関数へのポインタを取得する。

で、俺のプログラミング的な経験から言うと、
ディスクアクセスはCPUの動作に比べて圧倒的に遅いので
プログラム側でファイル操作の部分を高速化しても大した効果は得られない。
どちらかというと、OSのキャッシング性能が効果を発揮する。
それとディスクドライバがPIOかDMAかでも相当に違う。

肝心なのはファイル読み込み待ちの時間を
他の処理に割り振れるかどうかで
MacOS 9.xだとこの辺の処理は最高にお粗末。
ファイルコピー中にタスクを切り替えると
あからさまに動作が遅くなったりするからだ。
Mac OS Xではどうなんだろ？使ってないから分からない。

個人的にはMac OS Xの画面処理がネックになってると思う。
どうも描画処理が終わるまで他のタスクが待たされているような感じだ
(少なくとも人間が視認するのは待たされる)。
もしMac OS X内部で描画処理中にCPUが待たされるのなら
改善しなければいけないと思う。
場合によっては機能を削ってまでも高速化を実現するような
判断を迫られる時もあると思うのよ。

俺はMac OS Xがキビキビ動けばすぐにでも移行するよ。
そしてProjectBuilderでプログラムを作るのさ!!
Carbonだけどね。

>>360
> ちなみにWindowsのDLLも実行時にアドレスが解決される。
> LoadLibrary関数でDLLをロードし、
> GetProcAddressで関数へのポインタを取得する。

このLoadLibrary()とGetProcAddress()を使うDynamic Linkingは、MS用語で言うと、
Run-time Dynamic Linkingだよね。今まで話していたのとちょっと内容が違うかも。

話していたのは、OS Xのdylibについてで、MS用語でLoad-time Dynamic Linking、
つまり、WinのImport Libraryを使ってDynamic Linkingするのに相当するやつ。
そのときどのように解決されていないシンボルをアドレスに変換するかを話してたんだけど、
>>359 のようにやっているらしい。WinはこのへんMSDNで公開されていたっけ？

あと、Winはどちらも.dll、Linuxとかはどちらも.soっていうけど
Darwinでは、.dylib(MH_DYLIB)っていうShared Libraryと、
.so(もしくは.bundle)(MH_BUNDLE)っていうLoadable Moduleっていう２種類がある。
この違いは、
fink.sourceforge.net/doc/porting/shared.php#lib-and-mod
にちょこっと書いてある。
それとDarwin(他のUnixも)もdlopen(),dlsym()で、WinのLoadLibrary()とGetProcAddressと同じことができるね。

>>361
ワリ。話がズレててスマソ。

>>360
> ディスクアクセスはCPUの動作に比べて圧倒的に遅いので
> プログラム側でファイル操作の部分を高速化しても大した効果は得られない。
これはよくわからないなあ。
ディスクアクセスはCPUの動作に比べて圧倒的に遅いから、
プログラム側でファイル操作の部分を高速化すると効果は得られる
っていうのならわかるけど。
例えば、open/close/read/writeなんていうDarwinへのシステムコールは
バッファリングしていないよね。
で、stdio.hのfopen/fclose/fread/fwriteはシステムコールじゃないけど
バッファリングしている。詳しく言えば、libc.dylibで、カーネルの外、
ユーザ空間（プログラムから呼ばれたdll）でバッファリングしている。

> 個人的にはMac OS Xの画面処理がネックになってると思う。
そうだよねー。

> どうも描画処理が終わるまで他のタスクが待たされているような感じだ
これは単にWindow Serverに負荷がかかってるからだと思う。
Terminalでtopして、そのTerminalのウィンドウをドラッグして激しく動かすだけで、
俺のiBookだと"Window Man"（これってWindowServerかな？）80%位行くときがあった。。。

> 俺はMac OS Xがキビキビ動けばすぐにでも移行するよ。
XFree86を別画面で動かせば、OSX結構使えるよ。;-)
俺はプログラム系のことしか興味ないからiBookでも使ってられるのかな。。。

いまだに68kは、エミュが使われているのに・・・
ＨＳＰも、できれば68kにも対応してくれたらなぁ・・・

あるいは、PowerPC対応のエミュレータが出たらうれしいんだよなぁ。
いつになったらPPCのエミュが出来上がるだろうか。
これは、アポーVSエミュといったところだろうか。

PPCのMacエミュができたら、感じTalk7.5.5を入れて使うだろうから。（ｗ

HyperCatd with ObjC
誰か作ってくんねー？

http://www.iit.edu/~sarimar/GDS/metal.html
なんてだめですか？

>>357
> え？いらないでしょ？ジャンプテーブルにバインドされるじゃん
> 少なくともアドレスの計算は必要ないはず

これは、ELFじゃなくて、その昔のa.outフォーマットのころの話ですね。
a.outではリンク時にアドレスがbindされてたけど、
ELFの.soとかMach-Oの.dylibの場合、プログラム実行時にアドレスがbindされる。
ELFやMach-Oのおかげで、簡単に効率良くlibraryが使えるようになったってことですね。

PowerPlant面倒くさい...
かといって Toolbox直叩きも嫌だとすると
大人しく Cocoaを使えということでしょうか。

TCL(Think Class Library)からPowerPlantにうつった時はずいぶんすっきりした
ように感じたものだったが、Cocoaにうつったら、PowerPlantが無茶苦茶複雑なものに
思えてきた．．．もう後戻りできん。これはこれでちょと不安なので、一緒にCocoa漬
けにならぬか？ (w

>369
Cocoaもやりたいけど，OSXでしか動かないのが気になりますね〜
あとまだ言語的に不可解なところがあるし，
ProjectBuilder, InterfaceBuilderは素晴らしいけど，
gccを使っているところに不満もあります。

どっちかというと CodeWarriorに追いついて欲しい。

お前ら難しい話はいいからiTteyoshi改良してくださいよ。

>>Mac OS XのJava 1.4対応は2002年5月にプレビューで8月に正式版
この記事をみると、J#とかの動向しだいな面もあるけど
MacでもJavaが徐々にメイン開発環境になっていくんやね。


>言語的に不可解なところがあるし
言語「的」以外はOKやね。もちろん言語って「日本語」なりね。
>CodeWarriorに追いついて欲しい。
値段が？PowerPlant嫌いがCW使う意味無いなり。

>CodeWarriorに追いついて欲しい。

無理っしょー。ヴァージョンアップするたびに
前のプロジェクトのソースをいちいち書き換えないとエラーになる
ような開発ソフトにそういうのを期待するのは。

コンパイラとしてはCodeWarrior好きなんだけどな〜
あとエディタか。

OS Xでは、Mach+BSDなのでMach thread(cthread)とpthreadが使えるはずです。
で、久しぶりにAppleのTechNotes見てみました。
マルチスレッディングの話が出ているんですけど、
http://developer.apple.com/technotes/tn/tn2028.html
なかなかおもしろいです、このnoteは。
CMU Machでは、pthreadはUserレベルのスレッド、Mach threadはカーネルレベルのスレッド
ってのが普通ですが、OSXでは、pthreadはMach threadを元に書かれていて、
カーネルレベルのスレッドになっちゃったんですね。
あと、pthreadは、CarbonやCocoaなんかでも使えるとか書いてあるし。

で、ちょっと疑問に感じたので教えてください。
OS Xでのguidelineとして以下のことが触れられています：

User-space processes should not create Mach threads directly.

OSXだとcthreadが使えるじゃんと思ってたんですが、ここを読むとそうするべきじゃないようです。
なんで直接Mach thread(cthread)のシステムコールを呼ぶべきじゃないんでしょうか。
これってどういう理由なんでしょうかね。

憶測だがCocoaとかQuarzで使うからスレッドを勝手に
増やさないで欲しいんじゃないだろうか？

そうするとcthreadとpthreadは違うレベルで動いてるのか？

おっと319は俺じゃないよ上の書き込みの名前は間違い

Developer Tools 10.1(5H16) が出たらしい、
http://www.versiontracker.com/moreinfo.fcgi?id=11117&db=macosx
が、ADCに置いてなくてみんな混乱。どこにあるんだろ・・・

>>376
CocoaとかCarbonとかQuarzは、Unix流に言えば、OS側のコードではないですよね。
CocoaとかCarbonというのは、GUIアプリケーションにリンクするための
単なるダイナミックライブラリで、
Quarzってのは、AquaのWindowサーバと、Windowクライアントとして、
GUIアプリケーションにリンクされるダイナミックライブラリですよね。
どちらも単なるユーザエリアのプログラムもしくはその一部ということです。
OSX上には、ほかにもいろんなユーザエリアプログラムがあるので、
それらユーザエリアプログラムのためにスレッドを勝手に増やさないでというのは
理に合わないような気が。。。
あと、Machのセマンティクスにもそれではあってないのでは？

> そうするとcthreadとpthreadは違うレベルで動いてるのか？

Libcのソースを見るとわかると思います。
pthreadはcthreadで実装されてます。中をみると、
単にcthreadのインターフェースをpthreadに変えている程度のコードです。
pthreadは単なるライブラリAPI、cthreadはシステムコールです。
システムコールを使うべきでないってのはどういう理由なんでしょうね。
ちなみに、pthreadは実装が抽象的で、細かいことができないので、あまり好きでないです。
まあ標準だからOSにdependしないように作ってあるから、そうなるんでしょうけどね。

>>375
単に一般的な指針として、できるだけ高レベルのものを使え、てこと
じゃないすかね。

>>380
やっぱりそうなんですかねー。

ってADC探したら、Darwinのドキュメントにも同じようなことが。
http://developer.apple.com/techpubs/macosx/Essentials/SystemOverview/InverEnvironissues/Threading_Packages.html

You should use POSIX threads when you want maximum source code compatibility
with other operating systems. For example, a good deal of BSD code uses POSIX threads,
which should be compatible with the implementation in Mac OS X.

With rare exceptions (such as debuggers), your projects should avoid
creating and managing Mach threads. These threads lack much of
the infrastructure provided by POSIX threads. Moreover,
use of Mach threads is likely to lead to compatibility problems later.

結局Unixとして、pthreadが一般的だから推奨してるだけってことなんですかね。
その意味で言えば、Machのシステムコールはすべて使うべきではないと言えるの
かもしれませんね。

そんなこと言ってるわりには、
http://www.opensource.apple.com/bugs/X/Libraries/2686231.html
で、pthreadのAPIかなり実装さぼってんじゃねーかよ、みたいな。。。

＞直接Mach thread(cthread)のシステムコールを呼ぶべきじゃないんでしょうか。

一般的な定石としては、上層部がどういう下層部の使い方をしているか
わかっていないのに、うっかり下層部を「こんな使い方してほしくない」
という使い方をされないようにと釘をさす意味で警告することはあるわな。
なぜダメかは、実際の実装を見ないことにはわからないけど、それは
企業機密で隠されているので、われわれは推測するしかないと思うけど。

>>382
> 企業機密で隠されているので、われわれは推測するしかないと思うけど。

cthreadもpthreadもDarwinのコードだから隠されてないです。
特ににpthreadはUnixのthreadプログラムをしたことが
あるなら知ってるファンクションだと思います。

さらに、OSX上なら、
CarbonなんかのCoreServicesのレイヤだって、
その気になれば実際に何をやっているか調べるのだって可能です。
UnixでELFとか、いじったことがある人なら。 ;-p

>cthreadもpthreadもDarwinのコードだから隠されてないです。

あーあ、よく読めよ
「上層部がどういう下層部の使い方をしているか」
だろ？下層がどういう実装しているかの話じゃない。

＞CarbonなんかのCoreServicesのレイヤだって、
＞その気になれば実際に何をやっているか調べるのだって可能です。

ドキュメントに正式に書かれていない情報、
いわゆるundocumentedなものは次回のヴァージョンアップ
でこけるという定石はごぞんじ？

＞UnixでELFとか、いじったことがある人なら。

なんだ。自分がいかに賢いかを自慢したいだけの厨房だったのか。

>>386
> なんだ。自分がいかに賢いかを自慢したいだけの厨房だったのか。

でも俺はそんなこと思ってないです。
そう思ったんだったら、謝る。ごめんね。

>>384
>「上層部がどういう下層部の使い方をしているか」
> だろ？下層がどういう実装しているかの話じゃない。

それって、CarbonとかCocoaのthreadルーチンから
cthreadまでに行き着くまでってことでしょ？
http://developer.apple.com/technotes/tn/tn2028.html
をヒントにして、あとは実際に調べていけば良いってことです。

不思議だったのは、なぜ、pthreadは良くて、pthreadが呼んでいる
cthreadは"should not"なのかってことです。"must not"や"don't"じゃないですよね。
実際にpthreadの実装はシンプルでその中でcthreadを呼んでいます。
それを見るとなんでcthreadは"should not"なのか不思議になったわけです。

>>385
> いわゆるundocumentedなものは次回のヴァージョンアップ
> でこけるという定石はごぞんじ？

知らないです。それはOSXでも定石なんですか？

ただし、cthreadってのは、Machの由緒あるシステムコールです。
サブシステムなんかを構築するときに使われてきました。
User-space processes should not create Mach threads directly.
ってあるので、kernel-modeでは使って良いというようにも思えるんですよね。

>知らないです。それはOSXでも定石なんですか？

今までClassic Mac OSとかWindowsとかで仕事をしたことないんでしょ？
隠しているところは、怠慢で隠しているわけじゃないのよね。
Open Sourceな世界とは違って。

＃Layer Managerの悪夢とか言ってもわかんないだろうな。

Cocoa関連の本はわりとでてますが、Carbon関連の本はありますか？
もちろん日本語で。

>>390
Learning Carbonをおライリーが和訳するとかしないとか。
Cocoaの方は鋭意作業中らしいけど。

>390
Carbonって Toolbox（というのかな，昔からのAPI）をベースにしているけど
その Toolboxの本すら消えつつあるから，
最初から入る場合は Cocoaの方が楽になっていますね。

Toolboxでプログラム書ければ，とりあえず書いて
googleあたりでコンパイルエラーになる関数と "Carbon"で検索するか，
Universal Headerでも調べればかなりいけますが。

>>392
ADCのリファレンスも充実してきました。でもCarbonっていつ
仕様変更があるか分からないから手を出しづらくないですか？
ttp://developer.apple.com/techpubs/macosx/Carbon/carbon.html

みなさん、ありがとうございます。
393さんのリンクみましたが、日本語のドキュメントってないのでしょうか？
とりあえずAPI関数名と引数などのリファレンスみたいなものだけでも日本語であれば…

>>394
URLは失念しましたが、どなたかが自分がよく使うToolBoxについて
まとめた「My ToolBox」という文書を公開なさっていたのを覚えて
います。

×ToolBox
○Toolbox

細かいところで失礼。

>393
確かにしょっちゅう変わって，コンパイル通らなくなるのは嫌だけど
そんなに大々的に変わるわけじゃないから対応可能です。
ヘッダを grep検索すればコメント載っているし。

>395
これですか？

　http://www02.so-net.ne.jp/~shin-n/toolbox_ref/toolbox_index.html

>396
REALbasicを RealBasicと書くと文句を言われたりするのがありますけど
細かいスペルはどーでもいいことだと思います。

ところで今Office v.Xのマクロの仕様みてたら、REALbasicを
呼び出すようになってるんですね。
何かREAL SoftwareがMSに買収されるような予感がしないでも
なくなってきました。

おお！
398さんのリンク先って、すばらしい！
教えてくださってありがとうございます！！

どうしてアップルジャパンはこういう物を公開しないのでしょう。
技術資料の翻訳料なんてたいした額じゃないのに。

>> 389
> 今までClassic Mac OSとかWindowsとかで仕事をしたことないんでしょ？

いや、仕事で開発してますよ。いわゆるレガシー製品ってやつですがね。
Win,MacからAIX,Solaris,Linuxとかまでのマルチプラットフォームで。
だからこそ、pthreadなんかが使えるとうれしいのはあります。
で、OSXの場合、pthreadは一部しか実装されていない。
じゃあ変わりに何を使えば良いか、そういうところはcthreadしかないわけです。
そうすれば自分で、cthreadを使ってpthreadを実現できる。

> 隠しているところは、怠慢で隠しているわけじゃないのよね。

別にCのソースが見れないってことは、俺は何も言ってないですけど。
隠しているっていうけど、CarbonやCocoaの部分は、
システムコールじゃなくって、たんなるライブラリのAPIですよね。隠しているというなら調べれば良い。
どう調べるかは、OSXの場合、ktraceとかMach-Oとかいろいろ方法があります。

>>379の繰り返しになっちゃうけど、CocoaやCarbonは単なるdylib（ダイナミックライブラリ）です。
ってことはアプリケーションプログラムの一部として動くものですよね。
QuartzってのもWindowサーバの部分（これもアプリケーション）と、
そのクライアントライブラリ（これもアプリケーションの一部）です。
（この辺のスミワケってAppleは何でちゃんと説明しないんだろう）
ってことなので、「システムコール」の使用を「単なるアプリケーションに連結されるライブラリ」
（ユーザレベルのプログラム）が制限するって言う説はちょっと説得力がない気がします。

そもそも、AppleのDarwinに関してのDocumentでは
Darwinの部分でもcthreadの使用を"should not"、pthread使ってねってなってます。
Darwinは別のプロジェクトなので、CarbonとかCocoaとかQuartzのために
何かを制限しようってのはでないはずです。

>399
VB for Applicationではなくて？

>400
是非翻訳して欲しいけど，労力は結構かかると思います
というのも単に英語ができるだけでは翻訳できない（のけ反るような訳になる）
んでエンジニアにある程度の時間を割いてやらせないといけないわけです。

398のサイトも使っていますが
Toolboxを実際プログラムにどうやって組み込めばいいのか
よく分からない自分は逝ったほうがいですか？
「すすめコードウォーリア」を買ったのですが、
あそこに書かれていないことをしようとすると、とたんに撃沈。
英語できないから、参考にできるプログラムが少ない。
みんなどうやって勉強してるんだぁ〜

＞「すすめコードウォーリア」を買ったのですが、

その資料は古いよ。

っていうかアップルがコロコロ仕様を変えるせいだけどもね。

＞システムコールじゃなくって、たんなるライブラリのAPIですよね。

はぁ？なにを言っているんでしょう。あれはフレームワーク。

結局cthreadはOS開発側が使うものだから仕様が変わる事もあって
ユーザは規格化されたAPIのPthreadを使うべきだってことでしょ
だからshould notなんでしょ

KS3GZkVUが詳しいのは認めるけど自分の知識をひけらかしたい
その性格はどうにかしたほうが良いと思うよ

詳しいついでに聞くけどさDarwinってどこまでソース公開されてるの？

>403
別に逝かなくていいです。

少し慣れてしまえば古い本のコード打ってみて，
コンパイルエラーがでてもめげずに進められるんだけど
そうじゃないと結構辛いと思います。

プログラムなんて好きに書けばいいんだけど，一例として
通常の Toolboxプログラムは Toolboxの初期化を最初にして
必要なら AppleEventの登録（これは必須じゃないけど）します。
あとはイベントループに突入するわけです。

Boolean exitFlagでも立てておいて，while( exitFlag != true )で
ぐるぐる回して，その中でWaitNextEvent()でイベントを読み出して
それに応じて動作させる，ってのがありがちなパターンです。

XのIconComposerで作った128×128アイコンをCodeWarriorの
Carbonアプリに組み込む方法ありますか？
教えてください

多分>>401さんが開発されているような製品は、OSのバージョン
アップと共にどんどんバージョンアップを重ねて行くような性格
のものなんでしょうね。
私のような素人プログラマとしては仕様変更の度に振り回される
のはごめんなので、公開された部分だけを利用する方が賢いよう
に思います。
>>402
私もVBAの誤植かと思ったのですが、
ttp://www.zdnet.co.jp/macwire/0112/05/n_md_news_1_2.html
の後半を読むとやはりREALbasicのようです。

>>405
> ＞システムコールじゃなくって、たんなるライブラリのAPIですよね。
>
> はぁ？なにを言っているんでしょう。あれはフレームワーク。

>>401であってるんでないかい？フレームワークって言葉は使ってないけど。

フレームワークはADCのドキュメントをチェックすればわかるけど、
フレームワークって言うのは、ダイナミックライブラリ+リソースをパッケージにしたものだよ。
例えば、CarbonのフレームワークはCoreServicesに入ってて、
/System/Library/Frameworks/CoreServices.framework
だよね。で、これをフレームワークって言う。
で、下のFrameworksってフォルダには、複数のフレームワークがまた入ってる。
/System/Library/Frameworks/CoreServices.framework/Framesworks/CarbonCore.framework
にCarbonのフレームワークがある。
その下のCarbonCore（これはaliasだけど）がダイナミックライブラリだよ。
ためしに、"nm CarbonCore"ってTerminalでやると、NewThread()とか
CarbonのThread ManagerのAPIが入ってるってのがわかる。
で、続いて"otool -h CarbonCore"ってやると、このfileypeが6、（つまり、MH_DYLIB）
って表示される。これはCarbonCoreってファイルがダイナミックライブラリってこと。
実際にotoolを使って調べると、他にもいろいろなことがわかる。 man otoolは読んでおくといい。
NewThread()の実装はこのCarbonCoreにあるって言って良いと思う。

俺もこの件に対して調べてたんだけど、
結局CarbonやCocoaやQuartzはダイナミックライブラリとして実装されてるってのは
正しいと思うよ。つまりそれらはアプリケーションプログラムがロードされたときに
それらのライブラリはロードされて、アプリケーションの一部として動作してる。
だから、CarbonやCocoaはデバッガやotoolで逆アセンブルとかしたりすれば、
最後はシステムコールを呼んでるところまで、解析できる。

>>406
どうしてpthreadなのかはわからんけど、
cthreadは変わらないと思うよMachのシステムコールだからね。
CMUのMachでの、いろんなサブシステムなんかはユーザプログラムと言えると思うけど、
それらは、cthreadやvm関数を使ってたからねー。

システムコールはOS側じゃなくても使うよ。
例えばopen,read,write,closeなんかはファイルなどをアクセスする
Unixでよく使われるシステムコールだけど、
これらは普通のアプリケーションプログラムなどでも良く使うよね。

> KS3GZkVUが詳しいのは認めるけど自分の知識をひけらかしたい

たしかに。
でも、KS3GZkVUは、だいたい正しいような気がするけどね。
って、俺にも、おめーむかつくんだよーって、からんでこないでね。

> 詳しいついでに聞くけどさDarwinってどこまでソース公開されてるの？

これは彼が答えればいいのかもしれないが、これだけ入ってる。
http://www.opensource.apple.com/projects/darwin/1.4/projects.html
基本的にカーネルとドライバ類、その他ライブラリ類かな。
Darwinのソースチェックするとだいたい全体像がわかりやすいよ。

OSXと、RedHatのパッケージとを比較した場合、
DarwinはLinuxに相当するもので、
MacOSXはRedHatパッケージ全体に相当するものって言うのであってると思う。
QuartzはXFree86ってとこかな。XlibやXtがCarbonやCocoaかな？（適当だから、つっこみなしね）

>KS3GZkVUが詳しいのは認めるけど自分の知識をひけらかしたい
>その性格はどうにかしたほうが良いと思うよ

たぶん彼は若い人なんだと思うよ。
漏れも昔はあんな感じで気がついたら友達がひとりもいなくなって
正月に年賀状が１枚も来なくてへこんだこともあったよ。
まぁそうならないようにね。

>>410
からみはしないけどデバッガで追跡しろ、は、ちょい鼻につくな。
みんなヒマ人じゃないんだから、そこまでやってられね、っつの。

Javaを勉強し始めたところなんですが、プログラム板を見るとJavaってもうダメ
みたいな話ばかりです。一方この板ではそんな話全然出てませんね。
実際のところどうなんでしょう？

言語としてのJavaは当分OKだと思いますけど。
VartualMachineとして、環境としてのJavaは有名無実になりつつありますが、ではなにがとって変わるかといえばまだみえないし。
とにかく勉強して損になることはないでしょう。

当方バイオ屋なんですが将来情報系との共同作業が必要になりそうなので
プログラミングの概念を理解しておきたかったのです。
そういう目的ならJavaでよさそうですね。
即レスありがとうございました。

>414
Javaはプログラミングの練習にはいい環境だと思います。
批判が多いのは理想に現実が追いついていないからではないでしょうか。

書き忘れ
>416
バイオ屋ってVAIOかと思ったけど，研究者の方かな。
某医化研で遺伝子解析やっているのはスーパーコンピュータで
ソフトはたしかＣ言語かなんかで書かれていたと思うけど
操作はJavaで作ったソフトでやっているっぽいです。
計算は速度を要求するけど，操作はほどほどに速ければいいみたいで。

>408
私も知りたいです。

>409
本当ですね。
新居雅行氏が書いているし，評価版がうんぬんということで
誤情報ではなさそうですね。

分子生物学です。将来自分で大規模なソフト開発をばりばりするようなことは
多分ない（＆できない）と思うんで、とりあえず勉強しやすさで選んで
Javaにしときます。

>>411
なんか889UOZ8PはKS3GZkVUっぽいがまあいいだろうｗ

システムコールを使うなって言ってるんじゃないよ
実質的にはどっちを使ってもいいと思う
でもどちらかと言えばユーザコードならPOSIX規格の
APIの方が好ましいっていうのは分かるかな

あとリンクさんきゅー
結構いろいろ入ってるんだね

誰も指摘しないみたいだけど、将来のOS XはPOSIX API層は保証するけどその下にMachが
あるとは限らない、てことなんじゃないかな。もちろん"Mac" OS XのKernelが変更される
理由は特にないわけだけど、別のハードもサポートする計画があるとしたら！？

お前らAppleScript Studio出てるぞ！
わしは使わないが話題性あるからｶｷｺ。

>>421
> なんか889UOZ8PはKS3GZkVUっぽいがまあいいだろうｗ

なんか、ばんばん言われている本人です。ちなみに、889UOZ8Pは違います。

そんなにむかつかれるとは思わなかったので、ショックって感じです。
ごめんって謝ったあとでも、年賀状の話までされて、それはひどいと思ったです。
っていうかそっちのほうが盛り上がってるし。。。

で、やっぱり生意気って感じられた人もいるでしょうけど、
たぶん、俺は、その人の答えが間違ってると思うと、それは俺もちょっとじれったく感じたのは事実です。
で、その俺の答えにまたむかむかしててなるみたいな。
むかむかした人は、ごめんね。

>>424
書いてる人はむかむかしてる訳じゃないと思うよ
単に直したほうがいいよと言ってるだけじゃない？

詳しいのは認めてるんだから

>>423
え？もうでたの？どこどこ？

>>426
ttp://connect.apple.com/
の下の方だがね。

>>427
ｻﾝｸｽ｡IDとPASSあやふや…鬱だ…

>>422
うーん、それだったらDarwinがなんか他のLinuxとかBSDとかと同じになってがっかりだよー。
Darwinの魅力はMachのシステムコールが使えるってことのような気がするんだよね。
もともとMachってのは、分散OSの代表格だよね。分散OSっていうと、Unixの次にくるべきものって
ことで開発されたわけで、既存のUnixにはない魅力的な機能がつまってる。
それらの拡張された機能を元に戻すってのはなあ。
MachがあってNeXTやIBMやOmronなんかのOSが作られたわけだし。
Darwinに惹かれる人って、Machに思い入れや期待があって、
あの有名なMachが使えるのかって来るんだろうなと思うんだよね。
そうじゃなきゃ、LinuxやBSDでいいんだし。

あと、Darwin自体はMachベースだからintelもサポートしてるよ。
Linuxと違って、Machの部分は機種依存の所はわけてあるので
他のプラットフォームにも移行しやすいと思う。

ちなみにOSXのpthreadはOSX10.1でやっと使えるようになったんだよ。
かたや、cthreadはMach15年の歴史があって、変わらずに使われてきた。
pthreadはPOSIX標準だからOSに依存しないAPIだよね。ってことは、
LinuxやBSD、Windowsでさえもコードを変更せずに使えるって反面、
Machの強力なthreadスケジューリングとかThread同士のコントロールとか十分にできない
ってのがあると思う。

>>429
と、酔っぱらってsageないで、くだらないっこと書き過ぎちゃいました。
またまた生意気言ってすみません。

>Darwinに惹かれる人って、Machに思い入れや期待があって、あの有名なMachが使えるのかって来るんだろうなと思うんだよね。

このスレでDarwin語ってる人は単にOS-Xがらみで使ってるんだと思うけど。
自分を含めてね。
OS-XがDarwinじゃなかったら使っていないよ。
詳しくないんだけど「Machの強力なthreadスケジューリングとかThread同士のコントロール」ってたとえばNTカーネルなんかと比べてどう違うの？

>>431
> このスレでDarwin語ってる人は単にOS-Xがらみで使ってるんだと思うけど。

俺はMachだからOSX使ってるって感じです。OSXは簡単分散OSですね。

> 詳しくないんだけど「Machの強力なthreadスケジューリングとかThread同士のコントロール」って
> たとえばNTカーネルなんかと比べてどう違うの？

うーん一言では言えませんが、
Machはユーザプログラムだけでなく、KernelもPreemptiveです。
（Linuxはkernelの中はNon-preemptiveですね。）
複数のCPUのキューのなかで効率良くスケジュールされています。
Thread同士のコントロールってのは、cthreadを使えば、
簡単に相互排除もできるし、Portを使えばThread/task間通信も
簡単にできるという手軽さプラス便利さってとこでしょうか。
NTの俺の印象は、セマフォとかMutexとかがやっぱり使いづらい。
う、ぜんぜん比較になってないし、説明になってない。
他にもメモリオブジェクト、外部ページャ、OSエミュレーション、いろいろウリがあります。
あー、よっぱらいなので、わけわかめモードです。

MachはTanenbaumの本読むといろいろ書いてあります。
あと、大学生の方はOS論みたいなのを取ると分散OSの章あたりでMachが出きます。
論文なんかもいーーっぱいCMUには置いてあります。

ええと、モノリシックカーネルとマイクロカーネルの違いはわかるんだけど（linux VS Mach,NT）。
マイクロカーネルでMachとNTで根本的になんか違うのかな、と。

darwin か OSX で GPIB や RS232C をつなげている人いてはりますか？
いろいろさがしてみたんすけど，ぜんぜん情報ないのです．別スレッドにそういうところありますか？

IconComposerで保存したicnsファイルって、ResEditで開いても
データフォークになりますね。icnsリソースとして認識する方法って
ありますか？教えてください

>435
http://homepage2.nifty.com/ayaki/chap0013.html
をご覧下さい。

ありがとうございます
>>436

ただ、ここでも
サムネイルアイコン・ファイル *.icns を ResEdit や Resorcerer で
開くと、"icns" リソースの０番にアイコン・リソースが登録されています。

となっていますが、なぜか、ファイルを開いてもデータフォークのみなんですよ。

>437
仕様変更になったのかな・・・
あと，ないと思いますが UFS使っていませんよね？
リソースフォークは HFS(+)じゃないと持てないそうです。

>>435
データフォークのものをリソースフォークとして認識させる
ってのは無理だにょ。
フォーマット自体は一緒なので、データフォークの中身全部を
ResEditとかでicnsリソースをnewして、そこにペーストすれば
いいと思うにょ。

>>439
なるほどありがとうございます。

なんかMachフェチうざ、って思うの漏れだけだろうか？
嬉々としてTerminalの隠れコマンドをうれしそうに話すヲタ
なみに気色悪いものを感じるんだろうけどね。
現実世界で友達がいない、というか、友達をなくす原因となった
行動をネットワークでもやらんでもいいのにと思う。

>>441 なんか最近嫌なことでもあったの？友達なくしたとか

それはないけど、Mac OS XをUnixみたいに使うのが通だ
と勘違いしているUnixヲタが鼻につく今日このごろです。
友達はなくしてないけど、変なストーカーみたいなのに悩まされてます（笑）。

>>441
厨房はひがみっぽいね

>>441
Mac OS X上の開発にある程度以上のUNIXの知識が不可欠というのは
この間のiTunesインストーラの件で分かったと思うが…。
かくいう俺も勉強し直し中なんだけど。 参考になる部分は多いので
そこまで言うことはないと思うよ。

＞厨房はひがみっぽいね

いや厨房というのは職場で嬉々として話して同僚から
うざがられるから、ネットワークで嬉々として以下省略

>443
そっかな，NeXTからじゃなくて System 6, 7, 8, 9から
OSXに来たクチだけど，結構UNIXな面は楽しんでいるよ。
けど，同時に寂しいけどね。
外見はなんとなく似ていないことはないけど，
GUIの挙動は大分違うし，よく見るとUNIXなんだもの。
堅牢さとかいい面はあるけど，Macの優れていた部分が付け焼き刃みたいな実装だとか。
ファイルの識別をするのに，クリエータが弱くて拡張子が強いとかね。

>>441
> 嬉々としてTerminalの隠れコマンドをうれしそうに話すヲタ

隠れコマンドだって。ぷぷ。そんなもんないっつーの。

> 現実世界で友達がいない、というか、友達をなくす原因となった
> 行動をネットワークでもやらんでもいいのにと思う。

つーか、あんたもなって感じですな。
君にとっては親友かもしれないが、向こうはどう思ってるのかね。
こういう人ってけっこう普段からいろんなことにケッって思ってんのかな。

>>446
やっぱりひがんでんじゃん。

>>448
言ってることが違うって
Macは基本的にシステムのことは関係なくても使えるから
いわゆるアプリケーションユーザがたくさん居るけど
そういう人たちにUNIXがどうとかMachがどうとかいちいち語る
奴がウザイっていってんじゃん

俺自身は開発側の人間だけど441の気持ちは分かるよ

>>449
だったらそう書けばいいだけ。
それにアプリユーザの話は違うと思うんだが。
AppleのDevToolだってUnixのツールを使ってんだから
Unixの話はそれなりにメリットはあると思う。

確かに知ったか君ってのはまずいが、
俺は>>441がいつまでもしつこいのは粘着だと思うよ。
実は、>>441は、彼に適当な突っ込みを入れたけど、
反論されたってのが悔しいってのが本音だろ。

>AppleのDevToolだってUnixのツールを使ってんだから
> Unixの話はそれなりにメリットはあると思う。

ツールとOSの中身は別問題だぜ、ってつっこまれると思う。

448もひがみ根性全開だな。441の書いた文章から
よくそこまで想像を膨らませられるんだって思うぜ。

＞ 441がいつまでもしつこいのは

ていうか、こいつが登場したのは今日の午前だろ？

不毛な争いはやめようよ。
せっかくOSXが面白いのに。
MachでUNIXでMac（謎）で，魅力的な開発環境が無料なOSなんて
他に類を見ない。

MachでUNIXでMac（謎）ならMkLinuxがあったけどね。

で、プログラミングの話しに戻っていい？

>>455
荒れている人はほっといて、ずずっとやってください。

Unixな部分を隠すためにNSTaskとかを活用しよう。
とか、そういう話題を盛り上げましょう。

でもネットプログラム書くとなると生socketになっちゃうと思うんだけど。
NSSocketedPort（名前あやふや）はドキュメントないし。

>>458
OpenTransportというオチだったら激しくイヤ（笑）。

AUDIOやMIDI関連ってどう？
サンプルの数十行のプログラムでSMFプレイヤー（QT音源）がつくれたのにはびっくりしたけど。
外部MIDIっていつになったらまともに動くの？

>>459
それはないよ。

>460
というか，Appleの標準的なMIDIドライバはどうなったんだろう？
昔はMIDI Managerとかいうそのままの名前のがあって，
あとでOpcode社のOMSを採用したまでは知っている。

ひょっとするとQuickTimeで外部MIDIが扱えるんじゃ，と期待しているけど。
QuickTimeミュージックの中に「QuickTimeミュージックシンセ」しか書いていないけど
MIDI機器を繋ぐと他にも出てくるのかな。

Opcode社の社員を引き抜いてOS-Xの標準MIDIドライバ書かせてるらしいけど。
devツールのサンプルコードにも外部MIDIあるけど、コンパイルしても動かなかった。
まだOS側に実装されてないんでしょう。
YAMAHAのmLANももりこまれるとか…

>>461
>それはないよ。
それは安心した。あんな使いにくいもの勘弁だから。

XTIはマイナーだからね。
日本語の本は一応出ているけど。

だからsocketなのよ。

>>439
>フォーマット自体は一緒なので、データフォークの中身全部を
>ResEditとかでicnsリソースをnewして、そこにペーストすれば
>いいと思うにょ。

話題さかのぼってすいませんが、ResEditでデータフォークをそのまま
コピーして、任意のリソースにペーストする方法ってありますか？
あるいはほかの方法があれば教えてください。

>>467
ResEditではデータフォークは開けましぇん。
他のソフトでクリップボードにコピーししないとね。
Resorcererもってればこれだけですむのだけど。

OS9.2.2ですが、ResEditでメニューリソースの編集をしているとすぐフリーズします。
初期設定すてたり、メモリーを３MBに増やしたりしましたが解決しません。なんとかなりませんか？

>469
昔からそうです。
9.2.2に限りません。

対策はこまめにセーブすることでしょうか。
そのうち何をすると凍るか感覚でわかってきます。

報告です。
icnsをデータフォークからそのまま icnsリソースとして
コピペしたらちゃんとアイコンはつきました。
そんだけ。

>>470
そうですか。どうもです。
いい加減バージョンアップしてくれよ。

商品だけどResourcerer（スペル自信なし）
ってのはどうですか？ >>472

>472
前にResEdit 3.0ってのがあったけど，途中で消えました。
誰かリソースマップ（というのかな）に詳しい人が
Carbon版作ってくれないかな，というのは他力本願ですね。

>>469
Super ResEditはどうですか？

OpenFirmware上で動作するアプリってどうやって作るんですか？
ってか、NetBSDとかって開発環境何ですか？

>>473 私にはもったいないです。
>>474 検索したら出てきました。使っても平気なんでしょうか。

>>476
OpenFirmware上のアプリってそれOSってじゃないっすか？

> ってか、NetBSDとかって開発環境何ですか？

そんなことここで話すとまた
「なんかBSDフェチうざ、って思うの漏れだけだろうか？」
って言われちゃうぞ。こわいこわい。

>>477
昔、AppleのサイトにForkSwitcherっていう、Data forkとResource Forkのデータを入れ替える
ツールがあったんだけど、なくなっちゃったみたい。macnnにあったけどこれ同じやつかな。
http://www.macnn.com/news.php?id=6045

>>478
>それOSってじゃないっすか？
意味不明なんだが。

>>479
っていうか、もとの質問が意味不明って感じです。
>>476が聞きたいこと理解可能だったら、教えてあげなよ。

>>480
君の日本語について問うておるのだよ。
>それOSってじゃないっすか？
っつーのはどーゆー意味なのかね？

>>481
http://www.openfirmware.com/
の場合、
Open Firmware is the name given to the IEEE-1275 Standard for Boot (Initialization Configuration) Firmware
っていうことですね。なので「OpenFirmware上で動作するアプリ」っていうがよくわかりません。
あえて、Open Firmwareに近いアプリケーションといえばOSって言いたいのかな？
って意味だよ。
でも「日本語について問うておる」ということだから
別のことを質問しているのかな？

で、>>476
は、どーゆー意味なのか君はわかったのかね？

FutureBasicって簡単？　Basic知ってれば大丈夫かな。

http://page3.auctions.yahoo.co.jp/jp/auction/c13808899

＞ 478

どことは書かないけど召還呪文は書かないほうが。
せっかくマッタリしかけているのに

>>483
cより簡単だけど、FB2は68kアプリしか作れないぞ。
それに紙のマニュアルが付属しないのはいただけない。
FB2はあの分厚いマニュアルが付属することに意味があるんだよ。

あ〜、荒らしちゃってすいません。
OpenFirmwareの「コンソール上」で動かすって意味です。
OpenBSDは画面黒くなるけど、NetBSDは
OpenFirmwareのコンソール上でcursesを動かしているような
インターフェイスなんです。

開発環境がついてるんでプログラム勉強しようと思い
どうせならCocoaを勉強しようと思ったのですが、
CocoaはObjective-CとJAVAが使えるそうなので
どっちを勉強したらいいか迷ってます。
例えばjavaだと出来ないことがあるとかあるのでしょうか？
Objective-Cはあまりメジャーじゃないらしいので、どうせならJAVA覚えた方が後々応用が利くと思ったので、どうでしょう？
何か初心者なんで、支離滅裂ですけど＾＾；
おしえてください。

Windows覚えろ．

>>488

そうね、メジャーをめざすならWindowsでC++だね。
諸刃の剣だけどな。誰か吉牛ｺﾋﾟﾍﾟ作れば？

>>488
いや、だから、マックでって＾＾；
メジャーっていう面ではそうだろうけど、Cocoaではどうなの？
どっち覚えても一緒？
難しさは？教えて下さい

>>491
CocoaやるならObjective-Cにしといたほうが無難。
実のところ、JavaでCocoaアプリ作ってるｱﾌｫいんのかよ？

>>487
Objective-C。

>>487
どっちも覚えた方がいいよ。
CocoaではObj-CとJAVAを混在できるから、
例えば開発するソフトのネットワーク関連の部分は
JAVAで書いて、他をObj-Cで書くなんてことも可能。

>>494

そりゃ、理屈はそうだが。
Objective - CとJavaをシームレスにつなぐような機構が
少ない、あるいは使いづらいと思わないか？

両者を調節する苦労を考えたら、どっちか一方で作った方が
いいように思う。

>495
そうかな〜。
オブジェクト単位で使い分ける場合は問題ないと思うけど。
ネットワークアプリなんかだと、ネットワークとのアクセス部分を
Javaでクラス作ってブラックボックス化してしまうと、
全部Obj-Cで書くよりずいぶん楽だけどな〜。

>>496

「初心者」っていってるから、まずはそんな難しいことがやりたいんじゃ
なくて、とりあえずはプログラミングの楽しさを味わいたいってことなんじゃないかな？
だったらcocoaで一番「標準」といった雰囲気のObjective-Cだと思うんだが。

>>487
Javaももちろん標準ではあるけど、Objective-Cを勉強して絶対にソンはないと思う。
初心者ならまずはCを勉強しつつObjective-C。というのがいいのでは？

ある程度勉強したあと、やっぱしJavaがヨサゲというならそうすればよし。
無駄にはならんよ。

>>496
結局は使い方次第ってことか。
おれの設計がまずいだけかもしれんし。

>>487
とりあえず、何か書いてみれば？
どーせ、どっちも明日はどーなってるか分からん言語だ。

個人的にはCocoaはObjective - Cで楽しんで、将来のために
JavaならCocoaというObjective - C向けのフレームワークより
先に標準APIをマスターした方がいいと思う。

>>496
OSXのJAVAって単に文法としてJAVAが使えるだけでしょ？
一般的なJAVAのクラスライブラリってネイティブ環境のものは
無かったと思うけど

ネイティブなアプリケーションだったらどっちの言語でも
Cocoa FrameWork使わないと駄目なんじゃないの？

VMの上で動作するアプリならJAVAの方が楽かもしれないけど

500だ！！
OS-XでもJDK1.3.1入ってるし、pure JAVAアプリつくれし動かせるよ。

CocoaでもJavaのライブラリ使えるんじゃなかったっけ？
必要あるかどうかは知らないけど。

>>501
もちろん、使える。
実際にいくつかのクラスはJavaの標準APIを使うように変更されている。
NSString, NSThread, NSTaskとか。

それでも被ってるのが多いんで、削ってほしいけど、そうすると
遅くなりそうだな(藁

>>502
JAVAのクラスライブラリがVM用じゃなくてネイティブコードで
実装されてるって事？

>>503
クラスライブラリってCocoaフレームワークのこと？

たとえば、com.apple.cocoa.foundation.NSDictionaryなら

　public native Object objectForKey(Object obj);

ソースではこうなってる。
詳しいことは知らないんだけど、Objective - CをJavaでラップしてるみたい。

Java Bridgeっていう技術(?)らしい。
CではなくObjective - Cてのがミソ。Objective - Cのコードで
Javaのクラスをインスタンス化できるのもこいつのおかげ。

ま、あまり知らんから、細かいことは突っ込まんでくれ(w

>>504
違うよJAVAで規定されてるクラスのことだよ

> Objective - CをJavaでラップしてるみたい。

・・・ってCocoa FrameWorkをラップのまちがいだろ？
それだと中身はCocoaそのものじゃん（ｗ
やっぱり文法にJAVA文法が使えるだけで出来ることとやらなきゃ
ならん事はCocoaと変わらんってこった

Swingを除いたJAVAのライブラリが「ネイティブで」動くのかと
思ったよ

>やっぱり文法にJAVA文法が使えるだけ

Javaの文法だけってことは，throw - catchが使えるとかそういうこと？
よー知らないけど，たとえばJava Socketが好きな人は
ウィンドウ作るのはCocoaにやらせて，ネットワークはJavaってことが
できると聞いているんだけど，勘違いなの？

>ウィンドウ作るのはCocoaにやらせて，ネットワークはJavaってことが
できると聞いているんだけど，勘違いなの？

できるよ。実際にそういうことやってるアプリもある。

だ・か・ら
JAVAのライブラリは「ネイティブで」動くんだって！
ADCのjavaのHPみてごらん。

>>506
それは出来ると思うよ
ただしJAVAのコードはVM上で動くんじゃないかな

>>508
みてみたけどやっぱりJNIライブラリ以外はVMの上で動くんじゃない？
Cocoaオブジェクトとメッセージのやり取りは出来るみたいだけど

>>505

>・・・ってCocoa FrameWorkをラップのまちがいだろ？
　鬱だ・・・。ｽﾏｿ
　中身がCocoaそのもの、ってのは同意。
　でも、JavaのAPIはそのまま使えるよ。
　だから、>>496が例に挙げてるような使い方もできる。

>Swingを除いたJAVAのライブラリが「ネイティブで」動くのかと
>思ったよ

　それやると、Sunを味方にできねーんだろ(藁
　Javaの思想について議論する気はさらさらないけど。

>>508
　じゃあ、何でクラスファイルが必要なんだ？
　JITのことじゃないの？

>>510
そうねVMの上でメッセージがやり取りできるって事はjava.*の
ライブラリが使えるって事だからな
これはこれで面白いな
OSXはVMが標準装備だからVMが必要なアプリでもOSX上なら
どこに持ってっても動くし

>>508は無知って事でｗ

OSXのVMは意外に軽いって意味だろ>>508

>509
>ただしJAVAのコードはVM上で動くんじゃないかな

コード自体はVMがバイトコードを逐一解釈して実行するんでしょうね。
JITだっけ，ダイナミックリコンパイルするのもあるそうだけど。

でも，ライブラリがバイトコードで記述されているってのは
素人目にもかなりタコなんで，こっちはネイティブだと信じたいものです。

>>513
今のJAVA VMってほとんどJITコンパイルするでしょ

ライブラリがネイティブってCocoaのこと？
Cocoaはネイティブバイナリだけどjava.*は基本的に
バイトコードだと思うけど

>ライブラリがネイティブってCocoaのこと？

言葉の定義が要りそうですね。
私のいう「ネイティブ」ってのはCPUが直接解釈できるコード
という意味ですので、現行のMacの場合はPowerPCのコードです。

たとえば、Javaで直線を描くときにアルゴリズムを
プレゼンハムを使うのか何を使うのかは知りませんが、
その実装がバイトコードではなく、PowerPCコードだといいなぁ、と。

もちろん、Javaが一度書いたらどこでも動く思想のために
中間言語（バイトコード）を採用しているのは知っていますが、
ライブラリまでバイトコードで書かないで欲しいなぁ、というのが
率直な意見です。

>>515
全部バイトコードです。

×プレゼンハム
○ブレンゼンハム
です。

December 2001 Mac OS X 10.1 Developer Tools
一般ダウンロード開始仕上げ！

>516
>○ブレンゼンハム

お恥ずかしい。
けど

　http://www.google.com/search?q=%83v%83%8C%83%5B%83%93%83n%83%80&hl=ja&lr=

　http://www.google.com/search?hl=ja&q=%83u%83%8C%83%93%83%5B%83%93%83n%83%80&btnG=Google+%8C%9F%8D%F5&lr=

間違っている方が多いって事？

>>518
英語表記は"Bresenham's Line Algorithm"
もしかしてこれも知らなかったの？
晒しsage

>>519
それをどうやれば ブレ「ン」ゼンハム と読めるのか教えてほしい。

えらそうにいって自分も間違ってるって恥ずかしいね。>519

http://www.google.com/search?hl=ja&q=%83u%83%8C%83%5B%83%93%83n%83%80&lr=

>518とあわせて３種類目（これが正解らしい）。
早い話が間違って覚えている人が多いってことみたい。

あの〜ProjectBilderでWebの巡回ソフトを作ろうと思うトルです

最近のWebページはクッキーとかで認証しますよねぇ。
その認証が突破できなくてコマっとるです。
クッキーの受け渡しってHTTPのプロトコルで行われるんでしょうか？
暗号化とかURLエンコードとかしないのでしょうか？

それと使うクラスですが、NSURLを使おうとおもうとるです。

よさげな参考文献orURLがあればおせえてくだされ

>>523
クッキーはHTTPのヘッダを使ってやりとりします。確かNetscapeの
サイトにあったような気がする。

で、NSURLではクッキーの受け渡しとかは絶望的だと思っていいです。
渡すのはできますけど、サーバのヘッダを確認できないので（多分）。
NSFileHandleを使った送受信なら
http://homepage.mac.com/k_suka/
にサンプルがあります。
iTteyoshiのHTTPConnectというクラスもこれを一部パクってます。

Apple Script Studioって略すとASSなの？

そんな事より１よ、ちょいと聞いてくれよ。スレとあんま関係ないけどさ。
昨日、近所のADCアクセスしたんです。ADC。
そしたらなんか人がめちゃくちゃいっぱいで接続できないんです。
で、よく見たらなんかAppleScriptStudio公開とか書いてあるんです。
もうね、アホかと。馬鹿かと。
お前らな、AppleScriptStudio如きで普段来てないADCに来てんじゃねーよ、ボケが。
AppleScriptStudioだよ、AppleScriptStudio。
なんか親子連れとかもいるし。一家４人でADCか。おめでてーな。
よーしパパPremier会員になっちゃうぞー、とか言ってるの。もう見てらんない。
お前らな、質問のインシデントやるから帯域空けろと。
ADCってのはな、もっと殺伐としてるべきなんだよ。
Omnigroupの開発者MLに参加している奴といつ喧嘩が始まってもおかしくない、
刺すか刺されるか、そんな雰囲気がいいんじゃねーか。女子供は、すっこんでろ。
で、やっと接続できたかと思ったら、隣の奴が、Javaで、とか言ってるんです。
そこでまたぶち切れですよ。
あのな、Javaなんてきょうび流行んねーんだよ。ボケが。
得意げな顔して何が、Java、だ。
お前は本当にJavaで開発したいのかと問いたい。問い詰めたい。小１時間問い詰めたい。
お前、Javaって言いたいだけちゃうんかと。
ADC通の俺から言わせてもらえば今、ADC通の間での最新流行はやっぱり、
Objective-C、これだね。
WebObjects5、Objective-C、CyberFramework。これが通の頼み方。
Objective-CってのはJavaと違ってネイティブコードが多めに入ってる。そん代わりメモリ管理が少なめ。これ。
で、それにWebObjects5とCyberFramework。これ最強。
しかしこれを頼むと次からアップルにマークされるという危険も伴う、諸刃の剣。
素人にはお薦め出来ない。
まあお前らド素人は、HyperCardでも使っていなさいってこった。

>>526
イマイチ普通で面白くないな

>>524
センキュウです！そのサンプルのページはチェック済みです（￣ー￣）ニヤリ
まずはHTTPでのデータ受け渡しのヘッダのログ出力からはじめた方がよさげですね

吉野家とプログラミングは両立しないもの。

winのオープンソースなアプリに「ソースについてはGNUにしたがえ」てゆうのを良く見るんですけど、これってMacにも適用されるのでしょうか？
あと、GNUの日本語訳を読んだけど、長過ぎて要点が分かりませんでした。
GNUって簡単にいうと、なんなんですか？

簡単に言うと、「GNU's Not Unix」

知りたいであろうことはむしろ
GNU GPL (GNU General Public License)一般公衆使用許諾契約書
または
GNU LGPL (GNU Lesser General Public License) : GNU 劣等一般公衆使用許諾契約書
を読めば良いのでは？

簡単に言ったら、
ソース使わせてやるからおまえもソースを公開しろ、
というようなもの。

GPLって確かソースを使わせてもらって何か作ったら
それもGPLにしなきゃいけないんじゃなかったっけ。
とすると、GPLのことを知らずに安易に発表すると何が起こるか分からないよね。

ソースクローズにしとけばばれないからOK.

>>534

のんきでいいね

>>526さんのお勧めもあるので、
http://www.apple.co.jp/ftp-info/reference/hypercard2.2litej.html
ここからHyperCard 2.2Lite-Jを落とす。

落として解凍してからHyperCardをダブルクリックしてから
ゴーメニューから最後のカードを選ぶ。
それからゴーメニューからメッセージを選んで、
“magic”とカキコしてreturn。そうすると隠れていたレベルが
うpしてレベル５(無制限)が選べるようになる。

>>534
前にINTERWAREがそれやってばれたよ。

GNU GPLについて分かりました。ありがとうございました。

MacでC言語やるならOSXが不可欠ですか？
それとも、OSXでもコンパイラって買うしかないんですか？
OSXは開発環境としても優れてるって聞いたんですが…

OSXを買えば開発環境はついてきます
プリインストールのマシンを買った場合はついてこないかもしれませんが
Appleのサイトからダウンロードできます（要登録、無料）

開発環境として「優れている」と言われるのはObjectiv-Cというやつで
これはNeXT SETPから引き継いだ開発環境です
Objectiv-Cについての詳しい説明や資料は
http://www.big.or.jp/~crane/cocoa/
がいいでしょう

基幹部分はUNIX系なので、Cの勉強にもうってつけでしょう

OSXを使うならコンパイラにお金を払う必要は無いです

>540
レスありがとうございました。
やはりOSXに移行することにします。
(現在OS8.5。UpDaterで8.6)

無論、G4買うつもりです。
(G5って出るんですかね？噂が先攻してる感じなんですが…)

G5は出るとは思うけど、そんなに夢のようなCPUではないと思います。
前にG3が出たときはインテルがPentiumIIで、
性能的に優位に立っていたこと、それまでのPowerPCに比べて
かなり速かったこと、というわけでＧという文字にはいいイメージがありますが
G4は並だったし、たぶん次のCPUにG5と名付けて
単なる新型にとどまりそうな気配です。

Software Design読んでる人いる？

>>544
昔読んでたよ！
今も実家にバックナンバー置いてあるかも…。

ttp://www.oreilly.co.jp/BOOK/lcarbon/
ｶﾎﾞｰﾝ派の皆さんにオライリーから素敵なX'mas プレゼントです。

ｶﾎﾞｰﾝﾎﾞﾝ読んでたら
Objectiv-Cがすごく楽に見えて来たよ。（,,´д｀）

Cocoa本の方も同時に出して欲しかったな
順序としては正しいが

今出てるCocoa本はどれも文字とか余計な図が多すぎで
情報量が少ない上にレイアウトも無駄が多い

間違えた
「文字が大きくて余計な・・・」だった（撃

とりあえずｱﾌﾟﾙｼﾞｬﾊﾟﾝには
「Cocoa Developer Documentation」の全てを
早急に翻訳してほしいです。
求人の条件には必ず英語の読み書き能力が必須とあるんだから
まさか翻訳出来ないとは言わないだろうし。

>>548
Learning Cocoaも情報量は少ないよ

>>548,551
あれって確か、Discovering OPENSTEP.pdfを
Cocoa対応にしただけじゃなかったっけ？

＞求人の条件には必ず英語の読み書き能力が必須とあるんだから
＞まさか翻訳出来ないとは言わないだろうし。

英文科しか出てないのに技術翻訳やらせると
その「まさか」が起きるから恐いよ。

>>550
技術書類くらいの英語がﾁﾝﾌﾟﾝｶﾝﾌﾟﾝでCocoaに挑戦かよ。
小学生にはまだ難しいと思うんだけどねぇ。（藁

>554
若い芽を摘むジジイだな。

>>554
バーカ

>>550
まぁ、Cocoaのリファレンス、結構読むの簡単だったんで、
せっかくだから挑戦してみたらどうですか？
>>554はバカだけど。

550ではいろんなｻｲﾄで
「日本に開発ユーザーを広げるためにも翻訳してほしい」
みたいなことがよく言われるので
ｱﾌﾟﾙｼﾞｬﾊﾟﾝに対する軽い皮肉のつもりで書いたんだけどね。
一言も英語が判らないとは書いてないのだが
>554のような読解力0の煽りがあると大藁いですな。
まあ>554のような厨房には難しい日本語だと思うんだけどねぇ。(藁藁

煽りあってる時点で同レベルじゃないか。

日本語ドキュメントが出て、おまえらのようななんちゃってプログラマの
書くゴミプログラムがネットに出回ると考えるとｿﾞｯとするな。

モンキー発見！

まあ、どうでも良いけど、
このスレって、煽りあいがなんでこんなに多いんだ？
それがまたしつこかったりするんだよね。

いいじゃんごみでもなんでも、気軽にプログラム
作ってみようって環境がととのうのが、なんで
いやなの？

いやネタだと思われる。ほっとけ。

まさか本気で煽り合いしてるんじゃないよなヽ(´ー｀)ノ冬休みか…

ただの選民意識だろ

ヽ(´ー｀)ノ厨房工房は冬休み

ｻﾉﾚﾍﾞｼﾞ

あれ？きみらコマンド打つの苦手じゃなかったの?

しかし、本気で冬厨が来てるな（苦笑
頭の体操になるから軽くプログラムでもやったら？

>>550
聞くところによるとAppleの資料はスラングが多用されて居るので
読みにくく、IBMは格調高い典雅な英語なので読みやすいと聞いたのですが、それが本当ならTOEICとかトフルとか、あるいは英文科レベルではスラングなんて分からんから、
その為に日本語資料は遅々として進まないか出てこないのでは無いかなぁと思うのですが、
本当のところはどうなんでしょうか?

>>570
英語わかんねーのがばればれだぞ、お前。

無理やり読んでもなんとかなるけどなぁ。Cocoa回りの資料なら。
俺？英語下手。多分中学生程度。
なぜか音大出て、英語じゃなくて無意味な独語学ばせられたし。
辞書片手に技術系の単語で詰まる事もあれど、なんとかなってる。
ま、最初は日本語で解説されてるモン読んで概念解ってからだけど。

コマンド打つの？苦手だよ。Win触るとどうしてもdirじゃなくてdeltree打ちそうになる（藁

めちゃめちゃ簡単な英語で書いてあるぞ？
技術書読んだことないのか？
論文なんかより、ずっと簡単

うーん、たぶん普通の人は英語の文章なんて必要ないから見たこともないのではないかと。

正直、文法は平易で中学レベルです。＞大抵の技術文章（つうか、そうでないと誤解される可能性があるし。）
書いてある内容も、技術文章を読む程度その分野に対する知識があれば問題ないでしょう。
要するに野球のルールブックを読むのにボールって何？って状態であれば、それが
日本語であろうと英語であろうと面倒だろうし、逆に野球のルールブックを読解できれば
バスケットボールのルール読むのも楽だろう。みたいなもんです。
冬休みの人向けの解説ね。

同じことが出来るプログラムを何人かで作ってみると、
ソースが違ってたりする。
それと同じで翻訳も人によって変ります。
他の人が見ても納得できるソース＝理解できる文章というのがちと難しい。

Macに詳しくて英語がそこそこの人と、
Macはいまいちだけど英語が得意な人とでは、
どちらが「読める」文章を書けるでしょうか？
（プロは知らないジャンルでも下調べをしっかりします）

翻訳するにはある程度の責任が出てきます。
いくら英語が読めたって、
きれいなソースを書けたって、
わかりやすい日本語を表現できなければ駄目。
むしろ翻訳なんかしない方がまだマシ。
翻訳しないｱﾌﾟﾙｼﾞｬﾊﾟﾝが一番悪いけど、
まず自分で読んで見ましょうsage。

Appleの技術書類の英語自体は難しくないので、プログラミングやMac OSの
知識がある程度あれば読めるよ。ただ、いくらプログラミングの知識があっても
英語の構文解析能力が足りないと間違って読んじゃうだろうね。

とりあえず読んでみればスラング多用かどうかはわかります。
私は気合いと辞書があれば中学生でも読めると思います。

　http://developer.apple.com/ja/index.html

　http://developer.apple.com/techpubs/macos8/mac8.html
　http://developer.apple.com/techpubs/macosx/macosx.html

>>571
そのとおりだが何か?

でも他の人も言う通り、自分で使うだけなら辞書片手に何となく読んでいます。ただ、辞書に無い語が多くて(技術用語等)辛いのは確か。
の?hぁに逝くべきか..........

>>578
わかんない技術用語かいてみるってどーよ？分かる人が教えてくれるかもよ。
前後関係もあったほうが教えてくれる人もわかりやすいでしょう。
基本的にMacプログラミングのスレだからAppleのドキュメント限定でさ。

でも、Appleの文章は丁寧すぎて意味を取りにくい。
もっと簡潔に書けないもんかなぁ
つーか、リファレンス欲しい。

ファンクション名
　機能
引数・・・A　型　意味
　　・・・B　型　意味
戻り値・・・型　意味

見たいに箇条書きでいいのよ。

いきなり質問ですが
CodeWarriorでMach-Oプロジェクト（C++）組んでるときに、
例えば、test.rのリソースを、設定で
「リソースを個別のフラット化ファイルとして出力」
したいとき、どうしたらいいのですか？

単にチェックを付けて、test.rsrc　としても、書き出されないですよね？

教えてください

辞書に載ってない単語＝スラング
と勘違いしているに１０２４アフガニー

>>582
この場合スラングじゃなくてジャーゴンだな。正しくは。
ジャーゴンが理解できないのはプログラミングの基礎知識がないからだ。
日本語文献さがしてもカタカナになってるだけだから理解しにくいのは
変わらないぞ。

日本語で読んでも理解できないものは英語でも理解できないからね。

>>580
同感！
それでも AppKit/Foundation は Toolbox の頃に比べれば
断然よくなりましたね。Classic/Carbon の pdf は
Manager 毎にバラバラだから読むの辛かった。pdf 沢山開いて
Acrobat Readerが反応しなくなったりして。>OS9の頃

日本語版マニュアルを出してほしいと言ったら「そんなの必要ない」なんて
強がりつつ狼狽してる人ってどんなプログラム作ってるの？
くだらないシェアウェアが淘汰（フリーウェア化）されるなら
意味があると思うよ。小銭稼ぎたい気持ちは分かるけど。

>>585

> 日本語版マニュアルを出してほしいと言ったら「そんなの必要ない」なんて
> 強がりつつ狼狽してる人
void風に言うと 「ということにしたい」んだろ。
自分が読めないからってぐちゃぐちゃいうなタコ

> くだらないシェアウェアが淘汰（フリーウェア化）されるなら
> 意味があると思うよ。小銭稼ぎたい気持ちは分かるけど。
やれやれ…

>580
リファレンス、ありませんか？
たとえば Quartz(Carbon)だと

　http://developer.apple.com/techpubs/macosx/CoreTechnologies/graphics/Quartz2D/Quartz_2D_Ref/index.html

なんかはリファレンスです。

アップルジャパンはmac売るだけの組織じゃないの？
開発とかやってないでしょ。
よくわからんけど。

ドキュメントがオリジナルだとか日本語訳だとかみたいな
開発の問題なんて、知ったことじゃないって雰囲気感じるよ。
webページだって日本独自の要素ってないでしょ？

何も考えずに（本社に）言われたことをやってるだけっぽい。
だから、要望はやっぱり本社に出した方がいいんだろうなあ。

>>587
おー、すばらしいぃぃ
うん。この書式でCocoa のが欲しいですー

プログラム板でWinMXのクローンを作っている人たちがいるのですが、
Macで作ってしまうことはできないでしょうか？
ここで聞く質問ではないのかもしれないですが、お考えを伺わせていただけたら幸いです。
http://pc.2ch.net/test/read.cgi/tech/1005757407/

>>580
リファレンスだったらヘッダーファイルとクラスブラウザと
http://developer.apple.com/techpubs/macosx/Cocoa/CocoaTopics.html
で十分なような。

つーかCocoaは引数とか戻り値とか構造体はあんまり使わないでObjectで渡すでしょ。
意味とか機能はクラスとメソッドごとに独立してるから結局クラスの解説みたいな
ドキュメントが一番いいのでは？

>>590
ざっと読んだけど、クローンを作ってるのではなくWinMXを操作するプログラムを
つくってるみたいだけど。
WinMXはたしかOpenNapと独自のプロトコル(仕様は非公開)なんで、
クローン作るのは難しいでしょう。

>>591
現状は、HTMLドキュメント中のそれっぽいメソッドを見つけて、ヘッダーファイルで検索してそれっぽい値を試しに渡してみて・・・を繰り返してます。

つーことで、クラスブラウザって何？
Object-Cのソースでも動くの？

先日MacOS10.1.2を買ったのを機にCの勉強を始めたのですが、
基本的な所でつまづいてしまいました。
諸先輩型にアドバイスをいただければ幸いですm(_ _)m

名前が連番になっているファイル群を作成するプログラムを書こうと思い、
forループの制御変数をファイル名にしようと考えました。
そこでまずループ内で、

#define LAST 10
for(i=0; i<LAST; i++) {
if((fp = fopen(name, "w"))==NULL) {
printf("ファイルを開く際にエラーが発生しました。\n");
exit(1);
}
(以下略)

↑このようにchar型の配列「name」をファイル名に指定したのですが、
「name」に型キャストした「i」の値を代入しようとすると失敗します。
また、出来れば出力されるファイル名は「0001」のように四桁に統一したいと
考えているのですが、どういったアルゴリズムなら実現出来るのか思い付きません。

教えて君ではありますが、ヒントだけでもお願い致しますm(_ _)m

>>593 文字列配列に代入、とか言わないで、
atoi、strcpy、sprintfってな関数をヒントにして欲しい。

>>594
こんなに早くヒントをいただけるとは、感動です！
教わったsprintfを使って、作成に成功しました。
sprintfは私の参考書に載っていなかったのですが、
お陰さまでこれからも使えそうです。
本当にありがとうございました(^-^)

Project BuilderでCarbonアプリサポートされたのって、
いつ頃（バージョン）からですかぁ？
最近ですかね？

＞ sprintfは私の参考書に載っていなかったのですが

そんな本、捨てておしまい

>>592
クラスブラウザはProjectBuilderにある"クラス"タブのことっす。
辞書のアイコンをクリックすればクラスのドキュメントが表示されるよ。
名前をクリックすればヘッダを表示。

あとコード補完ができたような気がするんだけど、誰かしりません？
できなかったっけ？

自己レス。コード補完じゃなかった。
ソースコード中の文字列をoptionキー+ダブルクリックでメソッドとかの検索が簡単にできる模様。これはこれで便利。

を、それ便利ね。

>アップルジャパンはmac売るだけの組織じゃないの？
>開発とかやってないでしょ。

やってるよ。昔はマーケティング＆販売の会社と、ローカライズ＆開発の
会社は別々だったけど、今は一緒になってる。

あけましておめでとうございます

>>596
あれ？project builderでcarbonアプリって作れるの？？
それってOS9上で動くソフトが開発可能って事？？
むむー。

OS9ではPEFというフォーマットにコードが入っています。
OSXではMach-Oというフォーマットにコードが入っています。
project builderで作ったCarbonアプ（アプリって響きがﾀﾞｯｻｰ）は
後者なので、Xでしか動かないの。簡単に言うとそーゆーこと。

XではPEFもMach-Oも実行できるけど、9だとPEFMach-Oは実行できないの。

>9だとPEFMach-Oは実行できないの。
9だとMach-Oは実行できないの。

の間違いなの。

>>604
あー、なんとなくわかりました。
サンクス。

Cocoaアプリを作成するため、Objective-Cを勉強し始めた者です。
(以前はCだけ)
ProjectBuilderで作ると、オブジェクト指向の部分は自動的にObjective-Cの
コードが追加されますが、それ以外の部分はCの文法のみで開発出来るのでしょうか？
Cocoaには"NSMovie"というフレームワークが用意されていますが、
CarbonのようにCだけで書けるものならCだけで書く方法を勉強したいと思います。

>>608
stringとか基本的なサービスはCoreFoundationにあると思うが、
AppKitのかわりになるようなのはCarbonしかないのでは？
それ以上は知らない。

しかしイベント処理とかAppKitでやった方が圧倒的に楽なのでは？
スピードもObjCであればあまり問題ないと思うが。
もしよければ、Cだけで書きたい理由を教えてくれ。

>>609
成程、逆にCarbonでなければ扱えない部分があるわけですね。
ありがとうございます。
Cだけで書きたいのは、Winで書く機会が多いのでObjective-Cの文法に依存したくないだけです。
(でもここ数日の間にObjective-Cが好きになりつつあるのですが)

>>609
CarbonをCで書いてもWinじゃつかえないよ。こういうのは大抵OS依存。

やりたいことは何となく分かる。
とりあえずのデータ構造とかロジックをCで独立したファイルに書いて
Objective-Cでラップクラスを書くのが一般的じゃないかな。

ログはさらっと読みしかしてない厨房ですが、
今後のマックはＣｏｃｏａが主流になるとの理解でいいですか?
ＯＳが８のころのコードウオリア買ってまったく使いこなせなかった
くらいの馬鹿ですからどうしようもないんですけどＣＷは
バージョンアップする価値なしですか？おとなしくＸについてくる
開発環境使った方がよし？現在Ｗｉｎユーザです。

コンパイラとかリンカーの性能はCodeWarriorの方が高そうです。
CWがCocoaをサポートすると言う話もあるし、
このままPBに負けっぱなしで終わらなければ買う価値はあります。

Cocoaが主流になるかどうかは正直分かりません。
あれはNeXTからきたやつなので、魅力的なところは多いけど
Macっぽくない部分もたくさんあります。
CarbonとCocoaで切磋琢磨して欲しいところです。

PBでブレークポイント設定して、デバッグ開始しても
実行されるだけでポイントでとまってくれません。
何か原因があるのでしょうかね
教えてください

>>614
ちゃんとデバッグになってんの？
main()でちゃんととまるなら単にそこ通ってないだけなんじゃ？

>>615
main入った直後においても駄目・・・
ちゃんと「実行可能ファイルをデバッグ」してますよ

>>616
Clean、Build and Debugもやってみてよ。
それでダメなら全インストールするか首吊れ。

>>617
できないものはできない
てか、そもそも教え方が悪い

>614
Cocoaですか？

>>619
そんなの関係ねーだろ、ｳﾞｫｹ!!

>>613
CocoaはNeXt出自ではないっすよ。
ニュートンに載せるなんて計画もあったApple純正です。

>>618
教え方が悪いとか言うんだったらまずﾃﾒｰがどんなことしてみたのか
書けよ。

>>622
Macプログラミングしってるのはわかったし、教えてくれようとする
姿勢はみえたけど、首つれとか　Macプログラマー（いやマカー）や
このスレの品質を下げるような発言はやめようや。

単なる荒らしなら、こんなことはいわない。改善の余地があると見たから
言う。
ほんとはまともな人なんでしょ？目の前ではそんなクチのききかたしないでしょ？

>>621
それって別のCocoaじゃ…。

発見。今はこれだね。
ttp://www.stagecast.com/

>620
バカ？

>>588
いまさらですが・・・

会社概要
http://www.apple.co.jp/employment/overview.html
アップルコンピュータ株式会社 （Apple Japan, Inc.）
　業務内容： 米国アップルコンピュータ社のコンピュータ・周辺機器、
　　ならびに関連ソフトウェアの輸入販売・研究開発

　研究所と合併する前は輸入販売のみ。ガカーリしたものでした。

今度プログラマーoffあるらしいけど、誰か行くかたいます？

>>623
それもそうだな・・・
ちょっと言い過ぎたよ、ワルカッタ

>>626
なんで？Cocoaが関係あるわけねーだろ。ｳﾞｫｹ!!

>>629
偽者は首吊れ。

>630
関係ない理由を言ってみろよ、ｳﾞｫｹ!!

>>631
あ、俺の勘違いだった
スマソ

>>632
だから偽者は首吊れって。

>>631
わからないならプログラミング一生やるんじゃねーよ。バ〜カ。

いい加減にしてくれ。

<<624
そもそも、Obcective-C だってApple純正というか、長年Apple内部で開発
されていたもの。開発者はラリー・テスラー氏。彼は元XEROXのパロ・アルト
の研究員で、アラン・ケイの同僚。ジョブスがパロアルトの研究所を訪問し
た時のガイド役でもあった。その後、アップルに移って長年先端開発部門の
マネージャでもあり、アメリオの時代には副社長。この経緯からObjecrive-C
とCocoaはセットなの。ジョブス復帰直後に退社して、確かステージキャスト
という会社を作ってCocoaベースの教育ソフトを作っていた。ジョブスとテスラー
は子弟関係みたいな感じかな。Appleのオブジェクト指向関連はテスラー氏の息
がかり。だから、師匠の業績をOS-Xで受け継いだとみているんだけどね。

ちあみに、カット＆ペーストのユーザインタフェースはAltoでテスラー氏考案し
実装したといわれている。MPWベースのObjective-Cというのもあったと思うけど。

JBuilder6 Personal for MacOS X (無料のやつ)出たよ。それも他のと同時に!
http://www.borland.com/jbuilder/personal/

Swingで開発すると見た目Cocoaアプリみたいでマンセー
LinuxやWindowsからするとその速さと美しさが羨ましいよ

iBook買ったけど家専用だし・・・

ｊｏｂｓが有能な開発者を追い出した、そのうちの一人か

>633
プログラミングの「プ」の字も知らない奴に言われたかないね。

>634
すみません、バカ煽るのはこれで最後にします。

Cocoaて名前のソフト（プロジェクト？）のことじゃないの？
（MacOSXのフレームワークとは全然別物）
625が言ってる奴がその成果品

あれはDylan（Appleが開発した言語）でかかれていたハズ
Newtonに乗ってる奴はDylanのマクロをベースにしたNSBasicて言語

Objective-Cを作ったのはCoxって人だったと思う

2ch恐るべし
Dylanスレ
ttp://pc.2ch.net/test/read.cgi/tech/1004242854/l50

まぁ、漏れは一介の講釈師に過ぎないから見てきたような嘘も
つくが、その変は許されよ。

かつてのアメリオ時代の最後に、アメリオに紹介されてジョブスが
一般の面前でスピーチした際に「オブジェクト指向、それは、そこ
にいるラリー・テスラー氏ならよくご存じのことだと・・・」なん
て語っていたことがあるんです。オブジェクト指向について、テスラー
氏はジョブスのベン・ケノビであったと。思えるわけ。

誰が言語を開発したか。という場合、その誰を誰と特定するのは難し
いですよね。特に会社というレベルで開発している場合。ただ、テスラー
氏はスカリーの時代からアメリオの時代まで一貫して先端技術開発の
マネージャをしていたわけで、実際のコーディングをしたかどうかは
別として、その管理監督者の立場にいた。ということはいえる。この
意味で彼が開発者と書いたわけ。

いずれにしても、今のAppleでジョブスが一番上位の「オブジェクト指向」
の理解者であることは確かだから（実装技術を持っているかという面で
はないけど）、テスラー氏も気楽に退職できたのでは？

彼に関する昔話は、以下のブルース・ホーンの文章に若干載ってます。
ttp://www.xent.com/FoRK-archive/spring96/0331.html
ブルース・ホーンはFinderの開発者として知られていて、日本にも来た
ことがあります。あぽーが開いた最初の開発者会議（横浜パシフィコ）
で身近で見た（だけだけど）ことがある。93年か94年のこと。

あと、テスラー氏個人のサイトはこちら
ttp://www.nomodes.com/
ドメイン名に要注意。昔はmodeless.comだったんだけど、移転。モードレス
オペレーションというキーワードは昔のユーザインタフェース・ガイドライン
に載っているキーワードでもあるんです。BYTE Mag. Aug.80に彼のAltoに関す
る記事にはその辺のこだわりがごっちゃり書いてあったりするんですけど。

>>638
知恵おくれさん、版をお間違えになっていますよ。

Cocoa環境でプログラミングをはじめるんだけど、
入りやすさ、後の効果という観点で見た時、
JavaとObjectiveCどっちではじめた方がいいですかね？
手前CとScheme経験のみ、いろいろな意見が飛び交っている
のでどっちがいいかわからない状態です。
誰かナイスな理由付きでスパッと斬ってくださいな。

>642
知恵おくれさん、字をお間違えになっていますよ。

>>644
あはは、ナイスつっこみ

だけど、なんか全体低レベル化してきている・・・

>>645
だって初心者しかここ見てないんでしょ。

デバッガの動作にCocoaが関係あるって思ってるﾊﾞｶがいるようだしね。

Windows Media PlayerのCOMコンポーネントってどう使うの？

>>614
ブレークポイントの矢印がグレーになってないですか？
デバッグ情報を生成してますか？
コンソールから直接ブレークポイントを設定しても止まりませんか？

>>643
JavaだとSwing使えばややこしいこと抜きに作れるよ。
書籍も大量に出てるし。

とりあえず窓出したければ
import javax.swing.*;
class HogeHoge {
public static void main(String[] args) {
Frame f = new Frame();
f.setVisible(true);
}
}
こんだけ。

↑インデント消えてしもたスマソ

>>614
ターゲットの実行可能ファイルのデバッガの設定が
Java Debuggerとかになってたりして

>>649
FrameはAWTで、SwingはJFrameでは？

デバッグ＆ブレークポイント不具合の件
>>651
いや、Gdbになっています。（OSAも試しました）
PBのバージョンは1.1.1です

そもそも
ヘルプの「デバッグする」のなかにかかれている
「ファイル名の右側に表示されているグレイの虫アイコンをクリックして
黒い色のアイコンに変えます」
とありますが、
ファイル名しか表示されておらず、そういう項目はないんですよね。
これは前からひっかかっていました

デバッグ開始後にgdbはちゃんと起動してんの？

てきとうにあたらしいプロジェクト作ってデバッグできるか
試してみろよ。

>>653
やりました。テンプレートから作成してmain直後にいくつか
ブレークポイント立てても駄目。

ところでgdbの起動ってなにか手動が必要なのですか？

で、デバッグを開始した後にgdbはちゃんと起動してるの？

PBはgdbと通信してるので、Terminalからgdbで目的のアプリケーション
をデバッグしてみてよ。それができれば、PBがgdbを利用するための何かが
足りないということになる。そこからは知らないので、自分だったら
インストールし直すと思う。

どうやらCocoa、Carbon Application(nib based)などでは
問題なくブレークポイントは機能しますが、「Carbon Application」
のみ、ブレークポイントが機能しないことが判明しました。

どなたか解決方法わかるかた教えてください

だれかおしえてけろー
OS 8 and 9で、Appearance Manager 使って壁紙の設定をしようとしてます。
んで、GetTheme で取得した Collection の中身を見ると、kDesktopPictureName は存在しなくて、 kDesktopPictureAlias があるのですが、その値は0なんです。

なにか、事前の手続きなど必要なのでしょうか？
それとも、Collectionの値のとり方に間違いがあるのでしょうか？

上記２点、サンプルもドキュメントも見つからず、なんとなーくでやっているので自信ありません。

壁紙の設定をしているときも、していないときも現象は同様です。
CodeWarrior に付いていたライブラリ使っているのですが、Appleの配付しているSDKの方を使った方が良い物なのでしょうか？

教えて偉い人ぉ

>> 657
僕ならアピアランスにアップルイベントを投げるね。

＞＞ Appleの配付しているSDKの方を使った方が良い物なのでしょうか？

最新版を使った方が良いよ。
入れたらプリコンパイルヘッダーを作り直さないとメイクできなくなるよ。

ちなみに僕は偉くないよ。

>>658
ありがとうございます。
最初はAppleEvent使ってとりあえず動いたのですが、「アピアランス」っていつもこの名前であるんだろうか？？ってところで悩んでしまい、直に行けそうな今回の方法を取ろうとしました。
つでに、FSSpecメンドイ・・
ぜんぜんMacの事知らないのでもしかしたらアホな考えかもしれませんが。
ウェブ上ではAppleで配付しているSDKは２年ぐらい前のVersion 1.0が最新です。ftp.apple.comだと別の物を配付していたりするのでしょうか？今度探してみます。

>>659
名前からじゃなくてクリエーターからターゲットを決めれば良いよ。
そういうAPIがあったはず。

>>ウェブ上ではAppleで配付しているSDKは２年ぐらい前のVersion 1.0（略）
Univarsal Interface3.4がありますね。こいつに新しいヘッダとライブラリが入ってます。

>>657
亀レスで申し訳ないが．．．
少なくとも9.2.2ではkThemeDesktopPictureAliasTagの取得と変更はできるよ。
変更時はAppleEvent投げるよりずっと少ないコードですむんだけどな。

Collection collection = ::NewCollection();
err = ::AddCollectionItemHdl(collection, kThemeDesktopPictureAliasTag, 0, aliasH);
if (err == noErr) err = ::SetTheme(collection);

collectionのNULLチェック、aliasHの初期化は必要だけど。

うぞーん。
試しに9.2.2（Classic藁）でやってみましたが状況は変わりませんでした。

col = NewCollection();
err = GetTheme(col);
for (num = 1; num <= CountTaggedCollectionItems(col, kThemeDesktopPictureAliasTag); num++)
{
long size;
AliasHandle* alias;

err = GetTaggedCollectionItem(col, kThemeDesktopPictureAliasTag, num, &size, 0);
alias = (AliasHandle*)NewPtr(size);
err = GetTaggedCollectionItem(col, kThemeDesktopPictureAliasTag, num, 0, alias);
DisposePtr((char*)alias);
}

sizeが１３９とかになるのも謎

>>662
GetTaggedCollectionItem()に渡すsizeはGetTaggedCollectionItemInfo()で
初期化が必要なのさ。そのコードだと不定値をGetTaggedCollectionItem()に
渡してることになるね。

>>662
っていうか
alias = (AliasHandle*)NewPtr(size);
んなことしてる奴は死刑！！

あ、ちがうか、見間違えた。ｽﾏｿ。

ほへぇ？？
http://developer.apple.com/techpubs/mac/GXEnvironment/GXEnvironment-201.html
ここに書いてあるコードをちょっぱって来ただけなんすけど・・・
確かにsizeは不定値を渡しているけど、ヤバいのかな。
でも、この値は貰える物と踏んでいたのですが。
試しにやってみるっす。

解決しました。
お手間をとらせたみなさんありがとうございました。

結局、ここに書いたコードで、データの取得はできてました。
ただ、指定したポインタに入れてくれていた値がAliasHandleではなくて、AliasRecordだっただけでした。

Fxxk!! Apple!!!

ハンドルだったら、サイズは４のはずだもんなぁ・・・なんで５日も気付かなかったんだろう。
でも
kThemeDesktopPictureAliasTag = FOUR_CHAR_CODE('dpal'), /* <alias handle>*/
って書いてあったら普通AliasHandleだよね？ね？ね？

>>667
礼はいいからもうクソ質問は２度とやめてくれ

>>668
クソ質問もできないお前はｹﾞﾛ！

>>668
Bakka Macker !

>>668
んじゃ、糞じゃ無い質問をやってみてくれ。
もしくは、僕の書いたくそ質問に答えてくれ！！

Cocoaはさっぱり！
http://pc.2ch.net/test/read.cgi/mac/1007632025/

質問はこっちのスレがいいのでは？

>>672
そっちはCocoaだけじゃん。ば〜か。

ｵﾗｵﾗもうレス切れか？

その人本人とは思わんけど、マックのDev系メーリングリスト
にはさ、一言多いベテランさんがいるんだよね。有名な人
なんだけど、質問者が期待してない方向の解答を、わざと
（知的レベルから言って、あれは意図的だろう。
かえしてくるんだよね。
意地の悪い解答してくるぐらいなら、最初からレスすんな
よな。嫌われるのが好きなのかもね。

v

＞＞６７５
誰それ、どこのメーリングリスト？
気をつけたいので教えてください
伏字でいいです。名前も。

>>675
その手の人は昔からいますな。
意地悪いレスにはいちいち反応しないのが吉。

OSXでCをコンパイルしようとしたんですが、
どうしてもできません。
Deverloper Toolsをインストールしてるんですが、
ccがインストールされていないみたいです。
だれか対処法を教えてください。

>>679
Terminalでman ccしてみた？

>>680
man ccってなんですか？
いちおやってみました。

>>678
だれぇ？教えてよー。
せめてMLの名前だけでも．．．。もしかしてCW ML？

>>681
やってみたらどうだったのさ？

>>679
which cc　して見つからなくても、
find / -name cc　で見つかるかも

>679
何でインストールされてないって思ったんだよ．

which cc したらccは見つかりました。
ですが、色々ためしてみたけど未だにコンパイルできません。
成功すると別にファイルができるんですよね？

ccがうまくいくと、同じディレクトリにa.outができるハズ。

>a.out
で、じっこー

いちおー本をみながらやっているんですが、
TextEditで以下の文を打ち込んで
main()
{
printf("hello, world\n");
}
（￥のとこはバックスラッシュにしてます）
これを、hello.cで保存してターミナルで
cc hello.c のコマンドでコンパイルを試みようとしてます。
なにか間違ってるとこあります？

./a.outだろ，たぶん．

>682
macosx-dev-jpの常連で、言わなきゃいいのにって発言をする方がいます。
し○○○氏なんかは発言数が多いから有益なのもあるんだけど、
的外れな（厨房な？）質問をした人に対してとか、
議論が白熱すると要らないことを書くことが多い気がします。

有名なＫ仲川氏は自分のＭＬではかなり紛糾しているようですが、
CW-MLとかmacosx-dev-jpでは問題ないようです。

コンパイルできました。
ファイルの保存のしかたが悪かったみたいです。
みなさん色々ありがとーございます。

>その人本人とは思わんけど、マックのDev系メーリングリスト
>にはさ、一言多いベテランさんがいるんだよね。有名な人
>なんだけど、質問者が期待してない方向の解答を、わざと
>（知的レベルから言って、あれは意図的だろう。

macosx-jp mlのしろやまじゃないの？

ようするに、やられたのね・・・

あわれ

>>692
ＲＯＭってるだけだって。

>自分のＭＬではかなり紛糾しているようですが

もう、ないって。MLじたいが。それにあれはたんなるギャグつうかネタだろ。

し＊＊まは天然だな。ま、無視、無視。
リアル社会で友達ができないので、あそこで誰かにかまってほしい
哀れな人だと思えば腹もたたねえよ

MLの危険人物云々はやめよーよ。
これが出てくると毎回スレが荒れる。
マ板へ逝ってくれよ。

ここはもうちょっとﾏﾀｰﾘで‥‥。

age

　ちょっとPBの動作環境のことで聞いてみたいんだけど、G3での
開発って（速度的に）実用に耐えれるもの？　近い内にPowerBook G3
が手に入る予定なので、それでいろいろいじってみようと思うんだ
けど。
　なんとなく新しいiMacも使えそうな感じなんだけどね。

>>697
なんとなくでマックのプログラミングやるのは、無理っぽくないですか？
決意とかやる気が感じられない。
ほかの時間に割り当てることをお勧めします

やっとCがわかってきたのですが、
次は何をやればいいですか？

まず首をつれ

じゃがいもの皮をむきやがれ。

>>697
俺は時々仕事を家に持って帰ってPismo400/512MBでやってるけど、
なんとか使えてるよ。iBook300/64でProjectBuilder走らせたときは
死ぬかと思ったけど。

>>698
( ﾟдﾟ)ﾎﾟｶｰﾝ

なんか殺伐としてる？
俺はG3 300MHzでやってるよ。遅いけどそれほど問題ない。

わたしゃG3/400HzのPowerBookですが
不自由は感じてませんが。
開発で使うツールが高速でなければならないという決まりもありません。
むしろ遅いほうが遅いマシンのユーザの立場に立てて
効率のいいプログラムを作ろうと努力するので、
かえっていいという意見すらあります

おれのアホ！！
400MHzだ。いくらなんでも400Hzはないな。

>>704
共感！
早いマシンだと、工夫しなくてもそれなりに動いちまうからね。

>>703-706
G3 300より64MBに注目しる！

>>704
> むしろ遅いほうが遅いマシンのユーザの立場に立てて
> 効率のいいプログラムを作ろうと努力するので、
> かえっていいという意見すらあります

つーか、適当にだれかに言いくるめられているんじゃないの？w

実際のプロダクトを作るって場合は、
１ファイル変更しただけで、リンクするまで20分とかかかるとかあるし、
そんなプロダクトの場合、やっぱり速いマシンはほしいよなあ。

開発のメインハードはG3 MT266。
仕事でOS 8.0以上対応のアプリまで作ることがあるから。
これにOS 8.0〜9.2.2までパーティション切って入れてる。
そんなに速いハードでなくてもCode Warriorって快適だけど。
確かにビルドの時間はどうにもならんが・・・

＞＞７０９
慎重だなー

>>699
縺薙ｌ縺ｰ縺九ｊ縺ｯ螳悟?ｨ縺ｫ逶ｮ逧?谺｡隨ｬ縺�縺ｨ諤昴＞縺ｾ縺吶′縲?
"ANSI standard C"繧剃ｸ�騾壹ｊ逅?隗｣蜃ｺ譚･縺溘ｉ
"Objective-C"繧貞級蠑ｷ縺励※Cocoa縺ｧGUI繝励Ο繧ｰ繝ｩ繝溘Φ繧ｰ
縺ｨ縺?縺?縺ｮ縺ｯ縺?縺九′縺ｧ縺励ｇ縺?縺具ｼ?

>>709
すげー。さすが日本男児だ。我慢強い。
それでCabonizeまで、やっちゃうの？

俺ならもうマネージャに言って、
新しいマシン注文してください。そうじゃなくちゃ、この機能Win32のみです
って、おどす。

Appearance Managerの動きが8.0/8..1（Appearance1.0）は8.5以（Appearance
1.1以降）と随分違うし、Power ManagerやIcon Managerとかも・・・
OS 8.5以上だけ対応っていうのなら随分楽になるんだけど。営業サイド
とかからOS 8.0での動作もサポートしてくれという要求があるので。OS 8.0
が動くハードでないと・・・
さすがにOS X版（Carbon版）実装のときはG4 733を使うけど。

8.1サポートってもう辛いよね。
OSとしては現役なのにな。開発サイドからすると。

>１ファイル変更しただけで、リンクするまで20分

Macじゃないけど、昔、リンクが終わるのに半日かかる大物をやっていたことがあって
結局、オーバーレイ単位で分割することにしたことがある。
さすがにリンクに時間がかかるようなら別モジュールにするとか
別アプリにするとか別ライブラリにするとか、そういう次元で検討した
ほうがいいと思うよ。

みなさん、どうもです。PBG3でしばらくいってみることにします。
それで我慢できなくなったら、Ｇ４を買うということで。

>>715
> 別アプリにするとか別ライブラリにするとか、そういう次元で検討した
> ほうがいいと思うよ。

もうそういうレベルは超えたと思うよ。
規模も大きくて、１０年もののいわゆるレガシー製品なので、あっぷあっぷなんですな。

＞＞７１７
はげ同

>>717
なんというソフトなのよ？

保存

おまえらもうネタ切れなのですか？

macでdelphiが動けば最高なのになー。

OS XでPHP使いたいんですが、どうすればいいのでしょうか？。

既出かもしれんがPlotIconIDってﾊﾞｸﾞってるね。
Screen外の描画がされない。
自作のアプリでもCodewarrior IDEでも同様の症状になた。

>>724
スクリーンの外に描画されないなんてどーやって確認するん？
言ってる意味がわからん。

マックでＪＡＶＡの勉強はどうですか？

>>725
window内にicl/sアイコンを描画するようなアプリ。
windowの内容が隠れるような位置にwindowをDragする。
で、Finderからそのアプリを隠す／表示をした後、
windowの内容が見れるように位置を変える。

Arenaでも同じだった。

あ、724&727はCarbon(OS X)での話ね。
cicnは描画されるんだけどなあ...

なんか場違いな質問でした。WEBプログラム板に逝ってきます。

アプリケーションを立ち上げると四角い細い枠がじわじわって大きくなりますが、
あれと同じ枠をプログラムで任意に出したいのですがどうすれば良いですか？
コードウォーリアでC言語でおながいします。

>>730
ZoomRectsか？
TransitionWindowつーのもある。

使い方は自分で調べてね。

>>731
私が使いたいのはZoomRectsの方だと思います。
ありがとうございました。

>>730

MacOS 8.5 以降なら
TransitionWindow
(StubLibraries の AppearanceLib が必要)

MacOS 8.5 以前なら
ZoomRects または ZoomRegion
(StubLibraries の DragLib が必要)

AppearanceLib 使う時はプロジェクトインスペクタで
弱くリンクして Appearance のバージョンチェックして
見つからない場合のエラー処理もした方が良い

>>733
詳しい説明ありがとうございます。

>>723
MacOSXServerならPHP使えたはず
WebObjects使っとけ

>>723
Xでも普通に使えます。
ちゃんと検索したのかな？

>>723
MacOS XでPHP+MySQLコンテンツの開発をしていますが、何か？

FutureBasic^3 リリース６　ついにカーボン対応！！！

http://www.stazsoftware.com/

ageます

Mac（Classic)のフォント描画で縦書き対応にする機能って
ありましたっけ？
「〜」とか「ー」を縦にしたり。
どなたか教えてください

ないと思います。
QuickDraw GXではできたみたいだけど。

ATSUI使うよろし

>>742
>>743
Wordは古くから縦書き対応していますが、独自のルーチンですかね？

CodeWarrior8どうすかね。

>744
前に聞いた話だけど、PageMakerで縦書きが横書きより表示が遅いのは
１つ１つ DrawText()しているからって説明していたよ。

>>746
下に下っていく
座標計算に関しては縦書き用の機能はFontManagerはもってなさそうだから
そうせざるを得ないということですね。

「〜」とか「ー」を縦にしたかったら描いた後に回転させなきゃいけないってこと？

>748
それだと「、」とか「。」が変にならない？

>>749
ですね、Wordなんかは特定の記号に関しては、回転も交えて
特殊な処理をしているのかもしれない

フォントの中には縦書き文字も入っているはずです。
全てのフォントで使えるか知らないけど、ことえり等の文字パレットから探せます。
プログラムでは変換テーブルでも書くのが良いかと。

ATSUIを使えば楽に済むのかもしれないけど、最近の事情はわかりません。

システム7.5以降添付のまともなフォントには縦書用のグリフ変換テーブルや
メトリクスが含まれている。QuickDraw GXやATSUIで縦書を指示すれば
これらが正しく使われる。
それ以外の方法で描画する場合は自分でフォントデータを解釈したり
独自処理が必要
MacOSXは全面的にATSUIを使っているから将来性を考えるならATSUIを使うべき

CodeWarrior 7.2Jでたよ〜

http://www.metrowerks.co.jp/Support/TechInfo/Professional/Info_pro72_mac.htm

REALbasicじゃ物足りない、CodeWarriorは高価すぎる、MPWは難しい、Objective-Cもまだまだ・・・
やっぱりマカーは黙ってFutureBasic。
直販なら20000円なのでREALbasicとほぼ同じ値段です。
おすすめ。

CodeWarrior 、昔学割で15,000円を4,000引きで買ってきたんだけど最近は高いよね。

OS Xで初めてスキルアップの為にプログラミングに挑戦しようと
思っています
Cocoaはやっぱり等を読むとある程度
C言語の知識が必要だと書いてありますが
いきなりObjective-Cを覚えるのは難しいのでしょうか？
それとも知っていれば覚えやすい程度のものなのでしょうか？

全く何も知らない初心者がCocoaでのプログラミングをマスターするには
まず何から手をつけたほうがいいでしょうか？
みなさんの意見をお聞かせください。よろしくお願いします。

最終的に（時間はかかるのは十分承知してますが）簡単なアプリを
作れるようになりたいと思っています。

>>756
まずはプログラミングの基本をperlなりCなりで覚えるのが吉かと。
繰り返しとか条件分岐とかのコツをある程度押さえておいて...っていうのが
いいんじゃないかな？
GUIはそれから覚えても遅くないと思います。

>>757

やはり基本的な事からやっていくべきなんですね
とりあえずCからやってみます
ありがとうございました

すいませんお邪魔します。
この板でCocoaドキュメントの日本語化が勧められていることをご存知でしょうか？
こちらのスレをご一読いただき、興味を抱いていただけたらご協力いただきたく。

日本人なら「ココア」でしょ？
http://pc.2ch.net/test/read.cgi/mac/1016716727/l50

Cocoaでゲームプログラミングってできるんですか？

>>760
Omniが色々移植してるよね。

実は「perlでcgiを書く」が一番おすすめ。
すぐに結果が出るし、単なるテキストよりは見た目面白い。

うーん、perlって、初めてプログラミング勉強する人用というより、
やっぱりshスクリプトを書いてきた人のための言語と思うんだけどなあ。
CGIで使われているってのもあるけど。
初めてやるなら、awkやpythonのほうがよっぽど良いと思うなあ。

でも、OSXで、一般的なプログラミングの勉強というなら、
Terminal立ち上げて、Unix流C言語で良いのでは？

>CodeWarrior8

うーん。どうだろう。CWでのプログラムは面倒くさい、と思うようになったのでもうおなかいっぱい。

＞いきなりObjective-Cを覚えるのは難しいのでしょうか？

難しいとは思わないな。C言語からおぼえるのも手だけど、
Objective-Cならではの表現がC言語より簡単だったりするから
いきなりObjective-Cでもいいような。
たとえば配列なんてC言語では固定だけど、
NSArray使うと可変配列だし、好きなところを挿入、削除しやすいから
あれおぼえると固定配列には戻りたくなくなるね

>>764

>たとえば配列なんてC言語では固定だけど、
嘘つかないように。

>CWでのプログラムは面倒くさい、と思うようになったのでもうおなかいっぱい。
理解できない人はポインタを勉強してから発言しましょう。

>>764
NSArrayがObjective-C言語の一部だと思っちゃうなんてｵﾓｼﾚｰﾔ。
ま、2chだから許しといてやるよ。

>>765

ポインタと配列の区別のつかないヴァカですか？
ひょっとしてmallocとかreallocを使えば可変配列できますってか？

＞NSArrayがObjective-C言語の一部だと思っちゃう

どこにそんなことが書いているの？
キミの脳のなか？

>765

>>たとえば配列なんてC言語では固定だけど、
>嘘つかないように。
嘘つかないように。

>>CWでのプログラムは面倒くさい、と思うようになったのでもうおなかいっぱい。
>理解できない人はポインタを勉強してから発言しましょう。
意味がわからないなら、日本語を勉強してから発言しましょう。

>>768
配列とNSArrayを同等に書いてあるじゃん。
気付かせてもらって感謝くらいしろよ。嘘つき君。

可変配列はNSMutableArrayかと思われ。
つーかrealloc()とかの操作をクラスでカプセル化してるから楽ってことじゃないの？

Cocoaではポインタは主にJavaの様に参照として使ってるので、初心者はいきなりObjective-C&Cocoaでもいいんじゃないかと。
[NSData getBytes:]とかは違うが。

何も作れず、知識だけで頭でかくしてヤツよりはマシ
といったところか？

>>772
どっちもどっち

いきなりでも別にいいけど、どうせ、Cは必要だよ。

つーか、いいかげんやめてほしいよね。相手を攻撃するの。
なんでこのスレすぐ荒れるのかね。
生意気だと思っても、チクってしないで、
冷静にそれは違うよって言えばいいだけじゃんね。

殺伐としてて面白い。ってことで。

そんなあなたにFinderでGo!

ttp://www.macospeak.org/Lab_2/

777じゃん

FutureBasicでどうですか？

sage

>>780
sageてどうする!!

>>783
ｼﾈ！

>>782
CodeWarrior8が手に入ったので、死ぬのは先になりそうです。

バージョンあがってもどうってことないね
普段の開発に貢献なし

>>783
Ｘ上でクラシックアプリのデバッグできるようになりましたか？

そもそもなぜ７でできないんだろうな

ぼうやだからさ

何だか厨が多くて、
1000行って倉庫行きになった物ばかりでなくて、
人知れず糞スレ嵐でいくつか沈んだおかげで、
いつの間にかこのスレが上位60位以内に長寿になってるなんて
悲しい。

>>787
言いたいことは何となく分かるが日本語的にかなり難しいな。

>>787-788
何だか厨が多くて、良スレッドまでもが犠牲になったおかげで
いつの間にかこのスレが上位60位以内に長寿になってるなんて
悲しい。

質問です。
THINK Cはハコにsystem6.0.4対応と書いてありますが、
System7以上では使えますか？

起動すれば何とかなるんじゃない？
デバッガのたぐいは知らないけど。

問題は、最近のAPIが使えるかどうかってこと。
たとえば AppleEventなんか全滅だろうし。

ムム・・・そうなんですか。
軽いＣコンパイラとして使おうとしてたんですけど、考えようによっちゃ
コンパイラなんてムチャクチャOS依存ですよね。
起動すらできない気がしてきました。
よもや使っている人は...居ません、か。

>>790
24bitモードなら動くと思う（その前に、バージョンがいくつなのか書くべきだったな）。
このスレ、最初からざっと見たけど、３流以下の奴のくだらない書き込みで役に立たない。

そいえば、System 6って24ビットアドレスなんだっけ。
IIcxに16MBメモリをなけなしの金をはたいて買ってきたら
8MBしか認識しなくて悲しかったっけ。

けど、あんまりダーティなコーディングをしなければ
最近のOSでも昔のコンパイラで作ったソフトは起動するよ。
コンパイラが動くかどうかはわからないけど、
純粋なコンパイラの機能はソースをマシン語に直すだけだから動くかも知れない。

THINK CがLC520ではうごきました。
しかし、あの頃のプログラミング言語は小さかったな。

ANSI Cの練習…というのならTHINK Cでも十分かと思います。
ただし、ソフトを公開するという場合はやめておいたほうがよいでしょう。

>>795の目的でいいなら、MacMiNT+gccという手もあるかな。
つーか、7.5以上ならMPWでいいような。そんなに重い?

> Undefined entry, name: "qd"
> Reference to unresolved symbol "qd"
ひさしぶりに覗いてみたけど、やはりこれはFAQだったのね。

>>790-796
て優香、68k,PPCとかは大丈夫なのか？
68kOnlyなら問題ないが。
PPCで動かすとなると、PPCコードが吐けるコンパイラがいるぞ。
68kえみゅが走ってるのって、OS8.1までだっけ？

68kえむはROM封入。
OS9.2でも68kアプリはびゅんびゅん!!

最後までOSから68Kコードが消える事がなかったから
エミュレータがなくなるとOSが起動しなくなる。
なんかすっごい荒技。

800gochisosama

>798-799 thanx

＞最後までOSから68Kコードが消える事がなかったから
つーことはMacOS9.99.0ぐらいで68kコードが消えるのかな？（ｗ

オープンソース化して欲しいね。＜MacOS
それが無理なら、ソースコード入りストレージをサザビーに出品とか。
OSXの開発資金が出来て、ジョブズ君も助かるだろうし。
多分ゲイツ君が落札しちゃうだろうけど。

こんなん来たよ。

■Version 8(英語版)製品紹介
Version 8(英語版)では、Objective CとCocoaフレームワークのサポート、
Interface Builderとの統合やWindows XP対応をはじめ、様々な新機能の提供と
バージョンアップを行いました。

詳細の製品情報は、こちらをご覧ください。
http://red.tricorn.net/mwj/jump.phtml?v=D011&u=49816

>>801
MacOSに限らないけど、もう手を入れるつもりのない製品は
情報を公開して欲しいと思うよ、ほんと。
MacOSはしばらくはてこ入れがあるんだろうけど、
多くの他の製品は切り捨てたっきり放置されている。
PC98とか、X68とかね。

winのVisualCみたいな楽なビルドアプリが欲しい。

>803
同意。
OS9しか入れてないんで、PowerBuilderの使い勝手が知りたい。
見た目、GUIツールが標準で付いてるぽいけど、VCやDelPみたいに
2-wayコーディング可能？

>>802
X68はSHARPとHudsonが有志の求めに応じて、公開されたはずだけど。
PC98は望み薄だね。
…Newtonどうにかしてくれんかなあ。

>>802
げげ、Pro6からのアップグレードパスはないのか？それとも単なる
先行キャンペーンか？
7はいまいちだったんで見送ったけど、8はいいなぁ。

7にアップデートしてから8にしても、新規に購入するよりは
安いけど...。それならいっそDepotで買った方がいいか。

>>806
先行キャンペーンだから、もうちょっと待てば
日本語版のアップグレード案内が来ると思う。

それに、CodeWarriorってずっと放置していても
ちゃんとアップグレードパスあると思うよ。

７は最初はいまいちだけど、アップデータを使ったら
デバッガも軽くなったしいい感じ。

>>804
とりあえず、PowerBuilderじゃなくてProject Builder。

実は2-wayコーディングの意味がよくわかっていないで返事するが、
ウィンドウやボタンなどを作るソースコードを代わりに書いてくれる、
ヴィジュアルなツールがあるか、という質問なら、
Mac OS XのGUIビルダ(Interface Builder)は
そういうことはできない、と答えてみる。

ソースにいっさい手を触れないで保存と読み込みができない
メモ帳が作れるか、という質問なら、作れると言える。
さらに文字や画像のコピー&ペースト、
フォントや文字の色の切り替え、行の右揃え、
といった簡易ワープロみたいなこともできる。
保存もPDFの形式ならできる。
なんもやっていないのに凄いことをした気分にはなれる。

ビジュアルCなら、素人でも５分でタブブラウザくらいできちゃうらしいねぇ。

>>809
できないよ

>>808
俺はWinで自前のタブブラウザ使ってるけど
VC++で素人が５分で作るのは難しいと思われ
一枚のタブ作ってそこにIEコントロールをドラッグ
するだけなら5分で十分だが(もちろん正常に動作するが)
複数のタブのIEコントロールを操作するには多少の熟練は必要

>>811
ちなみに、Cocoaでは
ブラウザのviewは用意されていない。
簡単なHTMLやRTFの読み書きができる程度。
まあ、アポーがそんなものを用意できてたら
とっくに自社ブラウザ出しているんだろうな。

2-wayできるかどうかというのはフレームワークの思想の問題だと
思うけどな。
2-wayコーディングってHyperCardみたいにGUI部品とコードが一体に
なったイメージなので素人さん的には作りやすいかもしれないけど、
MVCが完全に分離できない作り方になりがちでない？
つまり再利用性やメンテナンス性が悪くなるような。

CocoaはMVCをかなり意識した作りになっているようだよ。
。。と、必死こいてCocoaを推してみる。
いや、他のフレームワークをよく知らないから、あれなんだけどさ。

ただ、GUI部品を継承してコーディングすることはそんなにないよ。
特殊なGUI部品を使いたいときだけだね。
http://www.geocities.co.jp/SiliconValley-SanJose/9760/develop2.html
の最後の方にある、"今から始めるCocoaプログラミング：最初のアプリケーション"
の3から5が分かりやすく説明してあるかな。まだβ版だった頃の記事。
Java的には違和感あるが。

>>811
HTML表示ライブラリはあるよ。
CarbonならHTMLRenderingLib
CocoaならHTMLDisplay.framework
前者はHelp Viewer.app、後者はMail.appやProject Builder.app
なんかで使われている。

ただ、これを使ってブラウザを作ろうと思っても、遅すぎて
使い物にならないけどね。

＃純正ブラウザって、CyberDogになかったｹ？

815は812に言っている気がするので返事。
まだPrivateのようだけど、
HTMLDisplay.frameworkなんてのがあるんだね。
ある程度HTMLを処理できるのは知ってたけど、
ブラウザとして使えるようにするまで手を加えるつもりなのかな。
ブラウザとして使えるようになる前に、きっと自社製ブラウザ出すぞ。
。。と思う。

あと、CyberDogは忘れてた。
というか、CyberDogをみたことがない世代だったりする。

AppleはWebブラウザまで持っていく気はないと思う。
Help Viewer止まりじゃないかな？
XMLパーサーは、また別にあったような気がする。

漏れ的にはCocoazillaに期待しているんだが…
(NSViewを継承したNSBrowserViewを作ろうというプロジェクト。Mozzila Projectの一環らしい）

>>817
CoreFoundationにXML関係あり。