【WinFX】次世代Windows Longhornを語るスレ

2005〜2006年頃に登場する次世代Windows（コードネームLonghorn)は、
Win95以来の大変革になる模様。

関連リンク

WinFX――Longhornが提供する「革新」の核心
http://www.zdnet.co.jp/news/0310/29/nj00_winfx.html

Longhornスレ 〜Long Long Way Horn〜
http://pc2.2ch.net/test/read.cgi/win/1063619983/


Win32APIは姿を消し、新たなAPI「WinFX」が登場。(Win32が使えないわけではない)
WinFXは、完全なクラス構造になっている。
http://www.zdnet.co.jp/news/0310/30/l_winfx.jpg

開発環境はどうなるのか？.Netの扱いはいかに？
VB房は死滅しちゃうの？などなど、大いに語ろう。

おぢ達が、新しいからって言って何も考えずに買って、
2000用のノートンとかMacDrive とか超速とかわけわからんもの入れようとして
「何でインストールできないんだ」とか文句たれるんだろうなきっと

お、立てたのか。Win32APIスレで雑談してたけどここに移行しよ。

ちなみにこっちの方がわかりやすいかも。
http://itpro.nikkeibp.co.jp/free/NBY/NEWS/20031028/2/

>>4
その記事、タイトルおかしくない？

> Win32と.NET Framework，およびWinFXの三つのAPIから選択しなければならない

と書いておきながら、次世代.NETの名称はWinFXとか。
WinFX=.NETなら選択肢は二つってことじゃん。

Win32、現.NET、FXの３つってことじゃないの？

>>5
うん、Win32APIスレでも同じ話が出た。
たぶんその記事が言いたいのは、
「選択肢はWin32API、従来の.NET Framework（この二つは主に互換のため）、そして新しいAvalonなどを追加した.NET（＝WinFX）」
ということかなと。
あくまでもAvalonやWinFSなどを使わない従来のアプリも作れますよってことが言いたいだけじゃないかな。

しっかし用語を省略せずに正確に書かないと話が噛みあわなくて一気に論争に突入しそうだな。

Indigoで分散アプリ作り放題！System.Net.PeerToPeerハッケソ

あと関連記事はこれくらいかな？
各記事ごとに図の写真が違うから補完用に。
http://www.zdnet.co.jp/news/0310/30/nj00_longap.html
http://pcweb.mycom.co.jp/news/2003/10/29/11.html

あと本家
http://msdn.microsoft.com/longhorn/

WinFXのリファレンスはLonghornSDKで
http://longhorn.msdn.microsoft.com/

でかそうな風呂敷だけど、何かをする上でのやり方が変わっただけで
何が出来るのかは大して変わってない気がするのは気のせいですか？＜WinFX
IndigoでWebサービスが爆発的に普及するようなシナリオになればいいけど。

>>11
まぁAvalonやWinFSも見た目や操作性や機能的にもどれほどのもんか具体的にわからんからなんとも言いようがないな。

Webのしょぼい、にぶいものじゃなくて早くこうなってほしいよ。
2chブラウザ使ってる人には分かるのでは。

http://pdc.xbetas.com/xbetaspdc/content/4050/avalon_amazon.jpg

amazonのデモの動画ってどっかありますかね？

今のところ個人でもいいからLonghorn（WinFX）の日本語情報サイトってある？

>>11
Webサービス(HTML)じゃなくて、Avalonサービス(XAML)に移るわけです

見た目も変わって利用者にアピールできるし、開発効率も格段によい。
いままでちまちまPOSTを解析してたのが、いきなりメソッドたたいてくれる。

>>16
UIとWebサービスは直接は関係ないじゃん。
Webアプリケーションの一部がXAMLを利用する形になるだけだろ。

Microsoft Professional Developers Conference 2003 レポート
Longhornはどんな構造になっている?
http://pc.watch.impress.co.jp/docs/2003/1030/pdc02.htm

ん？Avalonサービスって何？
WebサービスをサポートするのがIndigoで、UIをサポートするのがAvalon（XAML）で、
WebサービスがUI（Avalon）に移るって表現おかしくない？

AmazonのデモはWebサービスとAvalonを組み合わせたものだし。

>>18
さんくー。
今日で一通りPDC関連記事は終わりかな。後は各社総括記事まで数日かかるのかな。

>>19
IndigoはWebサービスに限ったものじゃないよ。
メッセージング全体のインフラと見た方がいいと思われ。
従来のRemotingからEnterpriseServiceも含めて。

>>21
うん、Webサービスをサポートしてると書いただけで、それしかないという意味ではないよ。

>>19サーバーとのデータのやりとりが、HTMLからXAMLに変わるのだね。さらに、HTTP Protocolに変わるものとしてIndigoのMessageが用意されているわけだねこうなってくるともはや Webサービスの範疇に収まらなくなってきてるじゃーん、と思ったわけです。失礼いたしました

>>22
失礼しますた。

>>23
いや、あくまでもデータのやりとりは基本的にXML（SOAP）だと思うが・・・
今のHTMLもAvalonのXAMLも、やりとりしたデータを表示するUIであって・・・

16はとんでもないDQNな予感・・・

JavaやってればOSバージョンアップしてもUIプログラミング
変わらないのにな。


もっともUIが進化しないし、現実はAWT→Swing→SWTと変わっているんだがｗ

> WinFSは、ファイルに対する変更に対してイベントハンドラを呼び出すように設定できる。
> アンチウィルスソフトをイベントハンドラとして登録すれば、ファイルが変更される前に内容をチェックできるようになる。

つまり、アンチウィルスソフトの後にウィルスがイベントハンドラを登録すれば、変更されたすべてのファイルに自動的に悪意のあるコードを仕込めるってこと？

>>26
まぁまぁ

http://itpro.nikkeibp.co.jp/free/NBY/NEWS/20031028/2/

> WinFxはLonghornのメインAPIになる。これまでの.NET Frameworkに，
> （1）画面描画機構「Avalon（開発コード名）」，
> （2）データベースを使ったファイル・システム「WinFS（同）」，
> （3）そしてWebサービス用の非同期通信機能「Indigo（同）」を
> 新機能として追加する。

別に.NETは.NETのままなんだね。

>>28
どこの引用？

>>28
つまり証明書だよりッてことかな

【PDC 2003】次世代Webサービス環境「Indigo」の詳細が明らかに，信頼性と簡便性を同居
http://itpro.nikkeibp.co.jp/free/NBY/NEWS/20031030/1/

>>31
横からだけど >>18 の画像の説明。

>　Longhornのプレビュー版には、x86版とIA-64版、AMD64版が含まれる他、SDK、Tablet PC SDK
>、Driver Kit、Windows Mobile SDKなどが含まれる。推奨環境は、1.6GHz以上のCPU、1GBメモリ
>、DirectX 7 GPU+32MBビデオメモリで、望ましい構成はDirectX 9 GPU+64MBビデオメモリとなっ
>ている。また、「(プレビュー版は)まだ性能はよくない。だから、ハイエンドマシンにだけ搭載
>する方がいいだろう」とAllchin氏は指摘する。

素晴らしいな。PCハード業界の需要を引き出すマイクロソフト。流石です。
ついでにia32も捨ててIA64やAMD64にさっさと重心移動して欲しい。

>>32
俺のマシンの軽く4倍でつね・・・

Pre-Release Version Of .Net Framework Available For Itanium 2
ttp://www.crn.com/sections/BreakingNews/breakingnews.asp?ArticleID=45574

>>34
ウェー、俺が今年買ったばかりのノート(PentiumM 1.3GHz)じゃ駄目じゃん。
恐るべし。

つーか、メモリ1GってOSだけで400-500M消費するんだろうか

これだけ高いスペック要求すれば.NETが遅いなんて声も封じ込められるんだろうな・・・

Microsoft 開発ツール ロードマップ 2004-2005
http://www.microsoft.com/japan/msdn/vstudio/productinfo/roadmap.asp

MSDN TV: Lap Around Longhorn
http://msdn.microsoft.com/msdntv/episode.aspx?xml=episodes/en/20031028LHORNDB/manifest.xml

英語分かんなくても見てみるといいよ。

.NETが遅いんじゃなくて他が速いんだ。

>>34
そのスペックならJavaもさくさく動きそうだが・・・

金ないやつには中古マシン+Lindowsでも使わせておいて、
MSはガンガンマシンスペックを要求するような機能を実装
していって欲しいな。Windows2000みたいに軽いのじゃダメだ。
2000のおかげでPCの値段は下がり、PC業界が不況に。。。
激しく重たいOSキボンヌ。そしてマシンの平均単価を20万まで
引き上げてくれ。

スペックに関しては数年後にそれだけ必要だってことで、数年後には大して高いとも思われないんだろうな

>>18 によると今の.NETより速くなるみたいだけど。

それまでに庶民の購買力が向上してるといいなぁ

PDCで注目を集めるMicrosoftのWinFS
http://www.zdnet.co.jp/enterprise/0310/30/epic02.html

http://msbetas.net/Longhorn-4051-PDC.xBetas.rar.torrent
Longhornベータ版。bittreent使用。

アバロンってトヨタのアバロンとかぶらんのか？

>>49
ジャンルが違えば大丈夫よ

なるほど
じゃあカローラFXともかぶらんな

コードネームだしな

おい！
じゃあサンテFXも大丈夫なんだな！！

@ITも記事出したよ。
http://www.atmarkit.co.jp/fwin2k/insiderseye/20031030pdc03-01/pdc03-01.html

米Microsoft，次世代OSと開発ツールの姿を明らかに
http://itpro.nikkeibp.co.jp/free/NSW/NEWS/20031030/136033/

【PDC 2003】MS ResearchがLonghornの「先」を披露
http://itpro.nikkeibp.co.jp/free/NBY/NEWS/20031030/2/

結局Longhornが手に入るまでは試せないので祭りは一時的なものですぐに無人になる悪寒・・・

俺はLonghornが手に入っても動くスペックのマシンが無いよ・・・

>>56
広く出回ってるし。

>>57
俺も。インストールにすげぇ時間かかりそうで。

WinFX API って用語はどこにも出てきてないよね？クラスじゃなくて関数を連想させるからかな？
Longhorn SDK でも「WinFX managed classes」なんだよね。
それともクラスとは別にWinFX API関数ってのも用意するんだろうか。

クラスじゃないよ。名前空間だよ。
で、その中にAPIがいっぱい詰まっている。

.NET Frameworkでやってると移行しやすいってことですか?

ラシッド教授ってまだMSRにいたんだ。。。

>>60
その中のAPIの話をしてると思うんだが

>>61
クラス図見てると、.NetFrameworkそのまんまだしね。
でも、WinFXってネイティブなアプリケーションから呼べるの？
そうなると.Netの立場はどうなるんだ。

>>64
Win FX ⊃ .NET Framework

.NET Frameworkの存在意義はW2k、XPでも
同じバイナリが動くくらいじゃない？

>>64
今まで.NETがネイティブ呼んでたのが逆になったような感じ。

ランタイムは常に名前空間をサポートしてる？

.NET は WinFX のパブリックプレビューだったって事かな？
先行公開した .NET をデベロッパーの荒波にもませて洗練させた後それを WinFX に集約。

>>28
今のところ（System.Storage, Version=6.0.4050.0）、
SetChangedEventType Enumには Added と Removed しか定義されてないね。
まあいずれは Changed とかも定義されるんだろうけど（と願いたい）。

とてもパフォーマンスが悪いそうだが本当に改善されるのかよ。

>>64
LonghornではWinFXがネイティブになるんだよ。

>>71
そうなん？
WinXPベースで新しい.NET Frameworkが動くだけのような気がするんだけど。

>>72
http://pc.watch.impress.co.jp/docs/2003/1030/pdc02.htm

まぁ、実際のところはまだなんとも言えないようだけど。完全に実装されてるわけじゃないし。

>>68
あながち邪推とも言えなくない。
.NET 1.0がベータの頃からObjectSpaceもAvalonも原型があったわけだし。

Win16→Win32→WinFX
の流れで、今の.NETはどこ？ってなると、Win32とWinFXの間でWinFXのパブリックプレビューと言えなくもないか

WinFXをWin32に変換するのか、
Win32をWinFXに変換するのか、
両方そのまま処理できるようにするのかまだわからないというわけか。

>>76
そうみたい。
でもWinFXがメインAPIになるということには変わりないから、Longhornの「ネイティブ」はWinFX。

Longhorn評価用に新マシンが欲しいけど、正式版の頃には使い物にならない予感･･･。

バリバリの3Dゲーマーなプログラマじゃないとあんなもん動かせないんじゃないのか

WinFXが普及するのはまだま先になりそうだね。

>>69
System.Storage.Watcher.WatcherEventTypeにModifiedがあるわけだが。

パブリックベータをかなり前から大々的にやるのでは。

SDK共有神募集中

>>83
禿同

日本語版MSDN Magazineが死滅したのが今となって惜しまれますね･･･。

ネイティブアプリ作る言語は何がメインになるの？

MSDN Magazine日本語版はなんで無くなったの？
出版社が悪かったのか？
そこそこ売れると思うんだけど。

>>87
翻訳版権の元が取れずに破綻という噂

やっぱオリハルコンFXだな。

Whidbey評価版試した人いる？

不参加組はLonghornとYukonしかまだ入手できてないはず。

>>88
そうなんだ、あんまり売れてなかったのか。
というか、置いてる本屋が少なすぎたな。

画面表示がGDIからD3Dに変わる事により
CPUが直接の描画処理から開放されて
そこそこのマシンならすこぶる速くなるわけだが
特に16ビットコードに弱いP4系統ならさらに向上する

単なる開発途上版だけ見て重そうだとか言ってるのはただのアホ
デバッグコードなんかもバリバリ入ってるしな

>>92
「手元においておくと、半年後ぐらいに価値が出てくる本」みたいなことを
編集長があとがきで言ってたが、あまりにも先取りしすぎたのが敗因か。
でもみーみが死んじゃったのが廃刊の決定的要因かと（違

>「(プレビュー版は)まだ性能はよくない。だから、ハイエンドマシンにだけ搭載
>する方がいいだろう」

デバッグコードが入っているというよりは最適化がされていない程度のレベルのように聞こえる・・・。
劇的に速くなるんだろうか。

>>93
16ビットコード？？？

>>95
いつもなら(初期？)β版から出荷版の間までに
結構チューニングされては来ていたように思うが。。。

WinFXがネイティブになるなら劇的に変わるんじゃないかなぁ。

WinFS予想どうり限定採用か。
発表して引っ込められず、失敗したのに意地で採用かな。
あれはガンになると予言。

Future Storageだからいつまでも完全採用されることは無いんじゃない？ｗ

問題はFXという名前だ。
この名前にはいろいろと祟りがあるからな。

末端プログラマから見れば、「物凄い勢いで強化された .NET Framework」
みたいなもんかな？

まぁ、世の中がManagedアプリだらけになれば、AMDはｳﾊｳﾊだな。

Microsoft Professional Developers Conference 2003 レポート
Longhornに至る道のり
http://pc.watch.impress.co.jp/docs/2003/1031/pdc03.htm

OSが進化しなければWinFXなんてのも出なくてすんだのに。

俺の勘ではＭ＄はロングほーんで終わる。

ろんぐあぼーん

WinFXでシステムコンポーネントのSocketリスナーの
部分はmanagedで書き換えられてたらいいなあ。
いい加減、パッチ当てはウザイよ。Javaで書かれた
Webサーバだって実用的に使えてたりするんだし、
パフォーマンスよりセキュリティーや保守の手間が
減る方が嬉しい。

Longhornの推奨スペックは1000万パワー

BetaPlace の Yukon Beta が onPDC に更新されてたので
ダウンロードしてみたが、前にダウンロードしたBeta1と同一っぽかった

所詮はVCL+Indyの焼き直し。

焼き直されちゃ困るジジイが何か言ってます

LonghornのユーザーインターフェイスAvalon
http://pc.watch.impress.co.jp/docs/2003/1031/kaigai040.htm

Longhorn＆SDK体験談まだぁ〜？

セッションのpptファイルが落とせるよ。
http://msdn.microsoft.com/events/pdc/agendaandsessions/sessions/default.aspx

>>43
ただOSの買い控えが起こるだけだと思うが

>>114
WinFXでしかできないことを一気に広めることが出来れば、
Win95みたいな入れ食い状態になるよ。

>>115
それは何？って聞きたいんだけど。

>>116
DOSではなくてWindowsでしか出来ないことは何か？
一見無さそうだけど、最新ハードウェアへの対応とか
最新OSでしか動かないアプリとか、
DOSでは手間がかかる処理(GUI等)とかある。

WinFXでも同じだろう。

ようするにキラーアプリだな

nyがFX専用になったら一発だろうな

リッチクライアント

ネットワーク対応のエロだな

VBのフォームで作っていたアプリが今度はAvalonを使って作られるわけだな。
あとActiveXもAvalon。つまり大雑把に言えばVBフォーム + ActiveX = Avalonと。
そして、いままでネットワーク対応アプリケーションはインターネットの
時代にも関わらずServer/Client方式で書かれていたが、これからは
その多くがWebサービスという形で書かれるわけだな(セキュリティーは大丈夫か？)。
NAT環境でもサービス(というかこれからはC/S方式ではなく、Webサービスこそが
ネットワークアプリケーションのネットワーク機能と呼ばれるだろう)を公開出来るように
マイクロソフトがIPv6のトンネリング用のサーバーを用意してくれるだろう。
瀕死のciscoもIPv6ルーターが売れまくって　(ﾟДﾟ)ｳﾏｰ

>>121
釣りか？釣りならメール欄に釣りって書いてくれよ。

WinFXとともにIPv6は世界にはばたきます！！！

こんなMLができてますた。
http://discuss.develop.com/longhorn.html

>>113
Managed C++の文法見て激萎え。(;´Д`)
こりゃ手出せんわ。

>>124
first postがPortable.NETのRhys Weatherleyに見えるのは気のせいだろうか。

気のせいではなくノイローゼ

さて、そろそろハッシュを教えてもらおうか。

>>126
first postじゃないよ。スレ名で先頭に来てるだけ。

そういやGotDotNetじゃFXの話してんのかな。コミュニティはこのスレしか見てなかった。

（　´∀｀）ﾓﾅｰﾄﾞベータテスター募集中。
ttp://longhornblogs.com/abudja/posts/998.aspx

概要はこちら
ttp://weblogs.asp.net/jnadal/posts/34413.aspx

>>126
いきなり荒れてるスレですね･･･。

どうでもいいがAPIを

「あぴ」

とか言うな！

ATAPIを「あたぴ」とか言うのもやめろ！

あたぴ馬鹿よね♪
お馬鹿さんよね♪

か！

SDKサイトもアレだし

>>132
> あたぴ馬鹿よね♪
> お馬鹿さんよね♪
思いついても普通は口に出せないぞこれ。恥ずかしくて。

LonghornとSDKとそれを試すハイスペックマシンが欲しい。

ハード->ソフトのコンタクトではWin32も16も一緒。
64 FXもそうなる

>>125
どういう意味で萎えたんでしょうか

漏れには良く判らないけんど、AMDとintelの64bit違いWinFXで吸収するので￥

スケールがでかすぎるのか、ちんこにピンとこない

>>137
そこまで言語拡張してまでC++使いたいんかと

まずはTLS310の資料でも見てちょうだい
http://www.gotdotnet.com/team/PDC/4064/TLS310.ppt

IA64とamd64で同じバイナリが動くとなると
JIT作るの大変だな

Longhorn本
http://www.amazon.co.jp/exec/obidos/ASIN/0735620857/250-5548543-7530643

>>142
別に初代NTの時から普通に
PPCやAlpha、MIPS、PA-RISCでも動いてたわけだが

>>144
その時代にはJITなんて作ってなかったわけだが（俺が
マクロをネイティブに変換して実行してるのね。
だからそのまま移植できんなーと。

.NET CLR上で動くもののみがバイナリ互換とかならいいんだが。

>>145
お前がかよ

145が何を言っているのか微妙に分らない。

OSが変わるとプログラムの開発環境とかも変わっちゃうの？

そらソフトが違うんだから環境も変わるだろ

WinFXで作った実行ファイルは、MSILではないんだよね？
.NETのアセンブリをあらかじめネイティブ変換しておくためのツール（名前忘れた）
で変換したものと同じようなもんなのかな？

>>150
サンプルをXPで実行したら、「.NET 1.2 が必要です」って言われたけど？

Win32使ってようがWinFX使ってようが
.NETは.NETです。

.NET を想定して API を作ってて、.NET での開発が一番楽だけど
非 .NET でもアプリ作れるって書いてなかったっけ？

書いてあるけどそれがどうかしたか？

>>154
>>150がなんか勘違いしているみたいだから補足しただけでしょ。

Mac OS Xに大量の脆弱性、解決策は新バージョンのOSへの移行のみ
http://www.zdnet.co.jp/enterprise/0310/30/epn05.html
http://www.zdnet.co.jp/enterprise/0310/30/epn11.html
http://headlines.yahoo.co.jp/hl?a=20031030-00000005-vgb-sci
http://japan.cnet.com/news/tech/story/0,2000047674,20061692,00.htm
http://internet.watch.impress.co.jp/www/article/2003/0411/macos.htm

"Panther"に深刻な障害--一部の外付けHDでデータ消失の危険性
http://headlines.yahoo.co.jp/hl?a=20031031-00000004-cnet-sci
http://www.zdnet.co.jp/news/0310/31/nebt_15.html
ttp://japan.cnet.com/news/tech/story/0,2000047674,20061724,00.htm
tp://www.lacie.co.jp/product/hdd.html

　

鈴木祥子を語る〜I Was There I'm Here
http://music2.2ch.net/test/read.cgi/legend/1058624852/l50

WinFXの設計とは直接関係無いが・・・
Win32の、設計ミスと言える作りでセキュアな環境や、プログラミングが
難しくなっている部分もあるので、Windows/386 辺りからDOSを仮想86モード
使って互換環境として分離していったように、Longhornからは、買収した
VirtualPCやIntelがIDFでぶち上げたVanderpoolを使って、Win32を後方
互換環境として分離していってほしいなー。

いちいちｵﾝﾗｲﾝでﾄﾞｷｭ見んの('A`)ﾏﾝﾄﾞｸｾ

Microsoft Professional Developers Conference 2003 レポート
「Sold Out PDC」
http://pc.watch.impress.co.jp/docs/2003/1104/pdc04.htm

WinFXのAPIはどう見ても.NETの延長のように見えるが。
C++とかで開発するときって強制的に新managed C++使う事になるのか？

>>162
のように見えるんじゃなくて.NETだって。このスレで出てる関連記事のページ見たほうがいいよ。
C++で開発する時もWinFX使うならmanagedだし、Win32での開発も可能。これも関連記事見れば既出。

All about Longhorn
http://zdnet.com.com/2100-1107_2-5101117.html

スグルの腕に埋め込まれたんじゃなかったっけ？

>>162
　C++は速度的にクリティカルな部分にだけ使って、例えば映像音声コーデックなら
COMとかAVStreamとか、っていう風に下位レイヤーのコンポーネントとして実装する
風じゃない？

【PDC 2003レポート】長く険しいLonghornへの道(1) 搭載される新API「WinFX」
http://pcweb.mycom.co.jp/news/2003/11/04/08.html
【PDC 2003レポート】長く険しいLonghornへの道(2) 早期プレビューβの真意は?
http://pcweb.mycom.co.jp/news/2003/11/04/18.html

Longhorn、積年の夢「いつでも、どこでも」に一歩近づく（1/2）
http://www.zdnet.co.jp/news/0311/04/nj00_longmobile.html

とりあえず Software Licensing Service (slsvc.exe) は切っとけというのが
ML等での共通意見のようだ。

>>165
後に手術で取り出したんだよ。

WinFX is not a managed wrapper around new Win32 native APIs;
it's a new managed API, implemented primarily in managed code.
The only way to access the new WinFX features is through this managed API.
There are no corresponding native APIs. If you are starting a new project,
we recommend that you write it in managed code, which will provide
maximum benefit, particularly around the areas of security and reliability.
However, if you have existing native code and you'd like to take advantage of WinFX
without rewriting your app then you can use a language interop mechanism
such as that provided by Managed C++ to call WinFX from native code.

ttp://msdn.microsoft.com/longhorn/community/newsgroups/default.aspx?dg=microsoft.public.windows.developer.winfx.fundamentals&mid=af4f8cbf-299f-4b3e-bbaf-fd1ec2da5ea1

>>170
WinFX is not a managed

つまりunmanagedでもOKということでつね。

>>159
それを過度にやりすぎると速度落ちて評判悪くなるからやらないんじゃないの。
Intelだって下位互換捨ててエミュで凌いでいるItaniumで苦戦してるっぽいし。

>>171
???

>>171
WinFXはwin32APIのラッパーでなくてマネージドAPIだって言ってるように見えるが

ラッパのマークのWinFX

PDC 2003で公開されたWindows Longhorn Build 4051画面ギャラリー
http://wssr.nikkeibp.co.jp/win2003/longhorn4051/1.shtml

LonghornのデスクトップやAeroをデモ Build 4051画面ギャラリー（パート2）
http://wssr.nikkeibp.co.jp/win2003/longhorn4051_2/1.shtml

米国PDC 2003レポート ベールを脱いだLonghorn Avalon，WinFS，Indigoが明らかに
http://wssr.nikkeibp.co.jp/win2003/pdc_us2003/1.shtml

米Microsoft，次世代OSと開発ツールの姿を明らかに
http://itpro.nikkeibp.co.jp/free/NSW/NEWS/20031030/136033/

【PDC 2003】次世代.NET Frameworkの名称は「WinFX」，Win32は残し互換性を維持
http://itpro.nikkeibp.co.jp/free/NBY/NEWS/20031028/2/

【PDC 2003】次世代Webサービス環境「Indigo」の詳細が明らかに，信頼性と簡便性を同居
http://itpro.nikkeibp.co.jp/free/NBY/NEWS/20031030/1/

【PDC 2003】MS ResearchがLonghornの「先」を披露
http://itpro.nikkeibp.co.jp/free/NBY/NEWS/20031030/2/

エンタープライズ：Longhornのベールを解いたビル・ゲイツ氏
http://www.zdnet.co.jp/enterprise/0310/28/epc08.html

ZDNN：WinFX――Longhornが提供する「革新」の核心（1/2）
http://www.zdnet.co.jp/news/0310/29/nj00_winfx.html

ZDNN：Longhorn Developer Previewレビュー：Longhornの開発状況は今？
http://www.zdnet.co.jp/news/0310/29/nj00_ldprevue.html

エンタープライズ：PDCで注目を集めるMicrosoftのWinFS
http://www.zdnet.co.jp/enterprise/0310/30/epic02.html

ZDNN：Longhornでアプリケーションはどう変わるのか
http://www.zdnet.co.jp/news/0310/30/nj00_longap.html

ZDNN：手描きの振り子が数式に合わせて動き出す──MSが取り組む新技術
http://www.zdnet.co.jp/news/0310/31/nj00_msr.html

エンタープライズ：賛否両論渦巻くMicrosoftのWhidbey
http://www.zdnet.co.jp/enterprise/0311/04/epic01.html

ZDNN：Longhorn、積年の夢「いつでも、どこでも」に一歩近づく1/2）
http://www.zdnet.co.jp/news/0311/04/nj00_longmobile.html

【海外】ついにベールを脱いだ次世代Windows「Longhorn」
http://pc.watch.impress.co.jp/docs/2003/1029/kaigai039.htm

Longhornの詳細が明らかに
http://pc.watch.impress.co.jp/docs/2003/1029/pdc01.htm

Longhornはどんな構造になっている?
http://pc.watch.impress.co.jp/docs/2003/1030/pdc02.htm

【海外】LonghornのユーザーインターフェイスAvalon
http://pc.watch.impress.co.jp/docs/2003/1031/kaigai040.htm

Longhornに至る道のり
http://pc.watch.impress.co.jp/docs/2003/1031/pdc03.htm

「Sold Out PDC」
http://pc.watch.impress.co.jp/docs/2003/1104/pdc04.htm

【PDC 2003レポート】Longhornのための開発者会議が開幕、Windows 95以来の革新性をアピール(MYCOM PC WEB)
http://pcweb.mycom.co.jp/news/2003/10/29/11.html

12月開催の.NET Developers Conferenceにて、Longhornの配布が決定(MYCOM PC WEB)
http://pcweb.mycom.co.jp/news/2003/10/30/14.html

【PDC 2003レポート】MSリサーチ、パーソナルマップ、マジックペーパーなどを披露(MYCOM PC WEB)
http://pcweb.mycom.co.jp/news/2003/10/31/18.html

【PDC 2003レポート】長く険しいLonghornへの道(1) 搭載される新API「WinFX」(MYCOM PC WEB)
http://pcweb.mycom.co.jp/news/2003/11/04/08.html

【PDC 2003レポート】長く険しいLonghornへの道(2) 早期プレビューβの真意は?(MYCOM PC WEB)
http://pcweb.mycom.co.jp/news/2003/11/04/18.html


＠IT：Insider's Eye -- PDC 2003レポート No.1--Longhorn、Yukon、Whidbey。次世代コンピューティングに高まる開発者の熱き期待
http://www.atmarkit.co.jp/fwin2k/insiderseye/20031030pdc03-01/pdc03-01.html

Microsoft 開発ツール ロードマップ 2004-2005
http://www.microsoft.com/japan/msdn/vstudio/productinfo/roadmap.asp

GotDotNet Japan 掲示板 - PDC 2003 Report
http://www.gdncom.jp/general/bbs/ShowPost.aspx?PostID=3136

鈴木祥子を語る〜I Was There I'm Here
http://music2.2ch.net/test/read.cgi/legend/1058624852/l50

>>180
なにこれ？

>>180
誤爆？

>>181-182
スレの宣伝、あっちこっち貼りまくってるよ。

ZDNN：Longhornのグラフィックツールは“Flashキラー”？
http://www.zdnet.co.jp/news/0311/05/ne00_longhorn.html

コードネーム Sparkle

>>184
> （XAMLはオンライントランザクションのための標準言語で「ザメル」と読む）

おいおい･･･

FlashがVBを意識し始めたそばからこれか・・・。でもおもしろそう。

よほどアマゾンのデモが印象的だったと見える

アマゾンのデモってどっかで見られますか？

ttp://www.amazon.com/

Microsoft .NET Developers Conference 2003
早くも満員御礼だって。

＠IT：Insider's Eye -- PDC 2003レポート No.2--Longhornが切り開く次世代Windows環境とは？
http://www.atmarkit.co.jp/fwin2k/insiderseye/20031107pdc03-02/pdc03-02.html

PDC 2003 日本人カスタマー向け特別セッション
http://www.microsoft.com/japan/msdn/pdc/default.aspx

>>191
今までの記事の中でLonghornでのWin32を一番明確に定義してるかも。
Win32の機能拡張は無い、と。

>従来のWin32では、Longhornの（.NET Frameworkの）
>機能をすべて利用することはできないのである
これってただ単に、.NETFrameworkの機能がWin32からは使えないって
だけじゃないのか？変化変化と煽ってるけど、現状手に入るWin32+.NETから
それほど変わるわけじゃないんだな。

Win32上で動く.NETから
.NET上で動くWin32という大きな変化があるわけだが。

>>194
（・・？）

>>192
けっこう日本からの参加者も多かったんだね。
って、ダグたん大活躍。(藁

>>195
>.NET上で動くWin32という大きな変化があるわけだが。
？
技術的に詳しく説明してみてよ。
CLRでkernel32.dll,user32.dll,gdi32.dllの機能を呼び出してる。
これが変わるわけじゃないんだろ？で、今まで通りsystem32の下の
DLLもサポートされる。.NET上で動くWin32ってなんのことを言ってるのか。

>>194
Longhornの機能を提供するような新しいWin32APIも今後出しませんよ、という意味だと思われ。

>>198
>CLRでkernel32.dll,user32.dll,gdi32.dllの機能を呼び出してる。
>これが変わるわけじゃないんだろ？

変わるかもしれない。↑でまとめられた記事のどれかに書いてあったはず。

それともCLRが直にシステムコールを呼び出して、既存のシステムDLL群は
それに対するラッパーって感じに作りかえられたとかいうの？

ようするに.NETを大幅に機能拡張しOS標準APIとします。
ただしLonghorn以外のOSには搭載しません。
と、それだけの話だろ？

>>201
http://pc.watch.impress.co.jp/docs/2003/1030/pdc02.htm
詳しいことはわからんてこと。

LonghornでたらもうWin32APIなんていらないだろ。
最低限の互換性さえあればいい。

GDI+がWin32APIで使えるように、AvalonもWin32APIで使いたい、という需要も打ちのめされたわけだ

ただ、201のようにしたとろで、システムDLLに含まれてた機能を
CLRへ移動してパフォーマンスが上がる以外にどんな変化があるのか。

既存のWin32プロセスは今まで通り。.NETアプリケーションは
Win32DLLを殆ど使わず、CLRがダイレクトにシステムコールを
呼び出す。これならどちらの形式のアプリケーションも速くなる。
ただ、Win32をすっ飛ばしてシステムコールをダイレクトに
呼んだところで、どれだけパフォーマンスあがるのかな。
その割りにライブラリの保守の手間は2倍。まあWin32はそのうち
切られるだろうけど。

勝手な推測でしかないけど、

プリミティブな機能(ex. I/O)はネイティブだけど、
それらを組み合わせたより高度な機能(ex. ネットワークプロトコル実装)は
マネージドでしか作らないということかな？

ネイティブで同じ機能を実現するには、マネージドのものを利用するか
車輪の再発明をするかということだと思われ。

これももちろん勝手な推測だけど
>>207
Win32がなくなるからといって、システムDLLに含まれてた機能が
マネージドで書きなおされるわけはないでしょ。そうじゃなくて、
CLR内の機能に統合されるんじゃないのかなってこと。
どちらかっていうとCLRのパフォーマンスチューニングがその主目的。

>>208
> Win32がなくなるからといって、システムDLLに含まれてた機能が
> マネージドで書きなおされるわけはないでしょ。

漏れもそう思います。
従来のDLLは残すけどObsolete扱い、っていうか。

APIのインターフェイスをそのままに裏側でmanagedを呼び出すってのも
労力のわりにメリットがないから。(藁

> 漏れもそう思います。

あ、矛盾してるや。(藁

言いたかったのは、従来のものを新機能なしで書き直しはしないということです。

とするとカーネルは.NET, Win32両方を破綻なく処理しないといけないのか。
この二つを統一的というか同一のものとして処理できるのかね。
結局どこかにしわ寄せが行くだけのような。

>>211
そのしわ寄せが出荷時期。w

>>211
違うよ。カーネルは一つ。Win32プロセスとCLR上のプロセスの
形態が違うだけで。

Longhornの要求する超スペックなPC上ではWin32を全部エミュレーションにしても十分な速度出そうだがな・・・・

PDCのセッションCLI390に何か重要なヒントがあるような気がするのですが、
残念ながら資料が出てないでつね･･･。

CLI390 : Exploiting Windows "Longhorn" Features from within Win32/MFC Applications

カーネルを二つにするんじゃなくて
受け口を二つにしないといけないんじゃないかと言ったんだよ。

>>216
漏れはカーネルも受け口も一つだと思う。

.NETのアプリケーションのプロセスは
[カーネル]--[Win32]--[CLR]--[managed]
と現状こうなってるわけだけど、これが
[カーネル]--[CLR]--[managed]
こういうイメージになるのではないかっていう勝手な予測。
つまりメモリ空間にkernel32.dllやuser32.dllはもうないと。
だたし、システムコール、共有メモリなんかの
カーネルのインタフェイスは変わらないと。

今のデモバージョンは
＋−−−＋
｜WinFX ｜
＋−−−＋
｜Win32 ｜
＋−−−＋
で動いてるんでしょ？で、正式版でWin32をエミュレートするとしたら
＋−−−＋−−−＋
｜Win32 ｜　　　　　｜
＋−−−＋　　　 　｜
｜　　　WinFX　　　　｜
＋−−−−−−−＋
に書き換える必要があるわけで激しく面倒だな・・・

すべてのユーザが短時間で完全に移行出来るわけもなく
結局Win32ネイティブなOSが救済策で出されるとか。
NT併合時のMEみたいに．．．

Win32からCLRへの切り替え自体は簡単だろ
もともとPOSIXやOS/2のレイヤーもあるわけだし

そこら辺のすげ替えを円滑にするためのマイクロカーネル構造だし

>>219
FSを除けばNTカーネルのインタフェイスが劇的に変わるわけでもないし、
既存のWin32のシステムDLLは、MSとしてもそのまま活用できるだろうし、
問題ないでしょ。保守の手間は膨れ上がるけど。そこら辺がﾏﾝﾄﾞｸｻって
なったらWin32も切られるのではないかと。

@ITの次回記事がまとめてくれそうだから楽すむにしよっと。

いまの.NETのクラスってなんかWin32APIに引きずられてるところがあるけど
WinFXではそこらへんのしがらみが完全に断ち切られてくれればいいな。

ウィンドウの回転ってどういう風なインターフェイスになってるんだろう？
Rotationプロパティとか付くのかな？
LocationもVectorになる？

>>224
リファレンスはLonghornSDKへ。リファレンスに無かったら知らん。

今現在.netで作ってるシステム、そのままじゃLonghornで動かなそうな・・・

>>224
そういう建て増しはしないんじゃないのかな。
それやると波打つプロパティとか球面にするプロパティとか際限なく増えそうだし。
従来のフォーム+テクスチャをポリゴンに貼り付けるモードに分かれると予想してみる。

>>226
問題なく動くよ。

まあこれでも読んで味噌
http://www.watch.impress.co.jp/pc/docs/article/960919/nt40us.htm

良いこと考えた。




.NETは無かったことにしよう。

まぁ、.NETって用語は無かったことになるかもな。

カーネルを３６セット用意して、カーネル３ダース。

こんなの見つけた。
ttp://msdn.microsoft.com/longhorn/community/newsgroups/default.aspx?dg=microsoft.public.windows.developer.winfx.avalon&mid=4de9a26d-946c-4729-9e90-3c5cf07c1b7e

>>233
OSのカーネル自体は書き換えていないってこと？
>>217の図で言うと、[CLR]が[カーネル]を直接呼び出せるように、
CLRを書き直した？

>>232
(^Д^)ﾊﾊﾊ

Longhornのすべて
http://www.zdnet.co.jp/enterprise/0311/06/epn18.html

で、なんとか.NETというブランド名は残るのか？

Reflectorが.NET1.2に対応しますた。
ttp://aisto.com/roeder/dotnet/

>>238
おお。genericsの逆コンができてる。

結局WinFXってどういうことなの？

リンク先全部嫁

そこを2行くらいで要約してよ

AMD64用Windowsってことです。

LonghornはWindowsの.NETバージョン
WinFXはそのクラスライブラリの総称でWin32の代わりとなるもの

>>232
(^Д^)ﾊﾊﾊ

WinFAXにしたらよかったのに

WinMXにしたらよかったのに

WinSEXにしたらよかったのに

>>246-248
(^Д^)ﾊﾊﾊ

MSDN TV: What is WinFX -The New Programming Interface Introduced in Windows "Longhorn"
http://msdn.microsoft.com/msdntv/episode.aspx?xml=episodes/en/20031107WINFXBA/manifest.xml

その頃にはAMD64が普及して64bitWindowsって大々的に宣伝してるだろうな。
void*が64bitになってぶーたれてるような低脳は、managedでコードを書けと。

>>251
その頃にはP4系統が廃止されてItaniumがエンドユーザーに降りてきてるよ

>>252
だといいけどな。

>>253
え？

>>254
G5の時代だってことにまだ気がつかないのか？おめでたいやつだな。

>>255
え？

intel,amdは糞。IBMマンセー

>>257
え？

OSASKは糞。NWSOSマンセー

>>259
え？

>>262
え？

お前ら落ち着いてウンコでも食… （つづく）

Shit!!!!!

脱糞します!!!!!

64ビットなんぞ初代のNTからあったわけだが

ＷｉｎＦＸはFlashのパクリ
しかもFlashよりも重たくて使えない

はっはっはっ、残念ながらFLASHとはかなり構造が違う。
というかこれじゃストリーミングはでけんべ。＜XAML
サイズもコンパクトというに程遠い。
２ちゃん界隈に多いタイプのフラッシュには割と向かないと見た。

勘違いが多いようで。

ほっとこうよ。

最近のFlashはストレージやメッセージングのフレームワークまでついてるのか

面白いことに、Java陣営はWinFXに関して沈黙を保ったままだよな。
勘のいい奴はもう分かってるんだろうな。
もうすぐ自分たちがNetscapeやLotusと同じ道を歩むことを。
WinFXを否定したくてもできないもんな。
本来Javaがやるべきことを「また」MSにきっちりやられてしまったわけだから。

WEBアプリのリッチクライアントとしてのFlashブームがくるんじゃないかと思ってたんだけど
XAMLは似たような感じですか？Windows限定ですけど。

煽りうざい。純粋にWinFXの話だけすれ。

>>272
XAMLはUI専用ではないですよ、とどっかの受け売りを言ってみる。

>>272
だから、Flashキラーになるかもしれないのは>>184だっつの。

Win厨の吹き溜まりはここですか？

単純にGUIやグラフィックがリッチになって嬉しい

Javaは糞
Javaよりも遅いWinFXはもっと糞

なんとかして荒らそうと躍起になっている>>271=>>276=>>278

Thread.Sleep(２年)

>>272
XAML はクライアントアプリケーション一般のUI部分と
FLASHが狙っているリッチクライアント分野を押さえるものだけど、
それよりももう少し広い範囲をカバーできるようにはなってるよ。
http://longhorn.msdn.microsoft.com で Timline とか Animation ってのを
検索してみれば色々と出てくるぞ：）

@281
Timline → Timeline

MSの本気度が分かって、アンチも弱めになったし、
迎え撃つほうも何言われても平気になったな。

勝ち組の余裕というやつだ。

DelphiからC#に移行した香具師は本当に勝ち組だと実感してることでしょう

　　　　　　　　　　　＿ A_A
　　　　　　　　／￣　 （*ﾟーﾟ） ⌒＼
　　　__　 　　/　　＿|　　　　 |　　　|
　　 ヽヽ 　 /　　/　 ＼　　　 |　　　|　　　　　　　　　　 ,,,,,,,iiiiillllll!!!!!!!lllllliiiii,,,,,,,
　　　 ＼＼|　　|＿＿__|　　　.|　　 |　　　　　　 　 　 .,llllﾞﾞﾞﾞﾞ　　　　　　　　ﾞﾞﾞﾞﾞlllll,
　　　　 ＼/　　＼　　　　　　 |　　 |　　　　　　 　 　 .|!!!!,,,,,,,,　　　　　　 ,,,,,,,,,!!!!|
　　　　　| ヽ＿「＼　　　　　　|　　 |､　　　　　　　　　|　 ﾞﾞﾞﾞ!!!!llllliiiiiiiiiilllll!!!!ﾞﾞﾞﾞ　.|
　　　　　|　　　 ＼ ＼――､. |　　 | ヽ　　　　　　 　 .|　　　　　.ﾞﾞﾞﾞﾞﾞﾞﾞﾞﾞ　　　　　|
　　　　　|　　　/　＼ "-､,　 ｀|　　|　　ヽ　　　　　　　|　　　　　　　　　　　 　　 |
　　＿／　　　/　　　 "-, "' （_　　ヽ　　ヽ　　　　　　.|　　　　　　　　　　　 　　 |
／　　　 ＿_ノ　　　　　　"'ｍ__｀＼ヽ_,,,, ヽ 　　　　　|　　　　　　　　　　　 　　 |
｀ー―￣　　　　　　　　　 ヽ､__｀/ー_,,,, ﾞﾞﾞﾞ!!!!!!!lllllllliii|　　　　　　　　　　　　 　 |
　　　　　　　　　　　　　　　　　　　　＼ﾞﾞﾞﾞﾞﾞﾞ!!!!!lllllllliiiii|　　　Hammer　　　　|
　　　　　　　　　　　　　　　　　　　　　 ＼　　　ヽ　 　|　　　　　　　　　　　 　　 |
　　　　　　　　　　　　　　　　　　　　　　　ヽ　 　＼　 |　　　　　　　　　　　　 　 |
　　　　　　　　　　　　　　　　　　　　　　　　| 　 　 ＼.|　　　　　　　　　　　　 　 |
　　　　　　　　　　　　　　　　　　　　　　　　｀ヽ､,,＿ノ|　　　　　　　　　　　　 　 |
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 ﾞﾞ!!!,,,,,,,,　　　　　　 ,,,,,,,,,!!!ﾞﾞ
　　　　　　　　　　　　　　　　　　　　　　 　 　 　 　 　 　 ﾞﾞﾞﾞ!!!!llllliiiiiiiiiilllll!!!!ﾞﾞﾞﾞ
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　／.// P4EE∵ヽ＼

みんなの本音







てか、いらんなぁ･･･

.NETが出たばかりの頃、「managedアプリなんかすぐにサポート切られる」とか
言ってた人が多かったが、どうやら切られないようだな。

.NETのコードは全て書き直しだろ。
Longhornが出てまで.NET使う意味は全くないわけだし。

なんで書き直しと思うんだろ？

>>289
またアホが

アンチ勢の悔しさを察してやれよ。www

http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=7350&forum=7&2
ﾄﾞﾄﾈﾄ憎けりゃXMLも憎い。こういうアホが出てきます。どのレスかはあえて言いませんが。

JavaもDelphiも死滅しそうだというのにのんきなものだ。

>>293
そりゃあ、世界がJava一色になればXMLなんて要らないよなあ。(嘲笑
Write Once, Run Anywhereだもんなあ。(ｹﾞﾗ

>>294
それに気付かないから腐れ言語にいつまでもしがみついてるんだろ。(大爆笑

AMD64とIPv6、足回りだって強化されてるんです。
アプリケーション層だけ見ててもダメです。

WinFXでおまいらは何をつくりたがっているんだろうか。
あれで商売したくてもそう簡単にうれるもんでもないしな。
ビジネスには直接結びつかないくだらん機能てんこ盛りにされても邪魔なだけだしな。
得するのはM$だけでVS.NETユーザやC厨が得するとは限らない。

>>289
Win32 API部分は最終的にほとんど書き直しすることになるだろうな。
しかしM$はだらしないからそういうことはほったらかす

C#も十分腐れ言語。
ま、VBはもっと腐った言語だがw
そんな腐ったVB厨がC#をやっているんではいつまでたっても
VB臭い馬鹿コードしかかけないわけだが

>>244
完全にWin32から鞍替えするにはだいぶ時間がかかりそうだな。
といってもVC++を使ったことがないVB厨には理解できないことか。

WinFXによってバグ対策とバカ対策をとる仕事が増えそうだな。

結局VB厨やC#厨やMS厨をたたきたいだけの
低脳がさわいでいるだけか。恥ずかしい。

>>298
(Win16時代に)Win32でお前らは何を作りたがっているんだろうかと
言っているようにしか見えん。

>>299
お前分かってないね。.NETはそのまま下位のWin32がWinFXに変更される。
一部のWinFXは.NETライブラリそのもの。Win32はそのまま残る。

オンラインソフトとかの世界では.NETアプリですらまだ単なるWin32より導入障壁高いのに

導入障壁？

そういえば.NETランタイムってサイズ小さいね。
ADSLに変えてからそう思うようになった。
一番安い1Mbpsでも5分もかからない。

.NETはどう見ても生き残るだろ。
ただ、今やるのは愚かだな。
少なくともLonghornが出て、言語仕様が落ち着くまで待たないと。
言語習得何ぞ２週間で十分だから。
それに今.NET使ってる連中がいろいろ苦労してノウハウや情報を蓄えて
公開くれるだろうから。

アホアンチが釣れてしまったようだ。www

アホアンチが日に日にトーンダウンしてるのが笑える。w
C#は死滅するんじゃなかったっけ？w

はげどう。MFCやSwingなんかも無駄だったしな。
やらなくて正解だったよ。

名前がWinMXと似てるね。
もうWinnyに駆逐されちゃったけど。

せこいバージョンアップではもう生き残れないということをMSが示してくれたわけで。
倒産寸前のSunが同じことができるかな？www

お前らここは死滅スレじゃないんだぞ

プログラミング言語よりプログラミング技法を学んでもらいたい。

MXの次はFXですた。

>>305
それじゃWindows依存から永久に完全に逃れられないな(藁

>>308
> .NETはどう見ても生き残るだろ。
.NETの一部のみが生き残るが政界だろ。
ActiveXのようにほそぼそと生き残るんだな

>>304
お前はLonghornもまだでていないのに趣味で
高価なビデオカードを交わせないと動かないアフォアプリでも作るのか。

このWinFXとやらは派手なアニメーションができるようになった以外には魅力がないわけか。
さすがM$はミーハー厨房をひきつける商売がうまいなw

負け組みの遠吠え

>>320
IPv6とAMD64(つまりデスクトップ用64bitWindows)普及の
シナリオにWinFXは欠かせません。

うむ。どうせｵﾌﾟｿの盗人連中が中途半端なパクリ作ったら途端にﾏﾝｾｰするんだろ。(ｹﾞﾗ

RedHatあぼーん、SuSEあぼーん、Sun倒産寸前の今となっては抵抗勢力はﾏｸぐらいか？

322の事柄はPC-UNIXユーザーにも広い意味ではありがたいことです。
IPv6はWIDEやIIJができるのはインフラ整備まで。WinFXでのIPv6の
本格的な対応が待たれるところです。

ﾏｸは独禁法逃れのためにMSが飼い殺してるだけだし。

>>324
Lindowsがあるではないか！


Lindows! Lindows! Lindows! (組み体操しながら)

一気に駄スレ化したな・・・
お前ら死滅スレ立てろよ。

今度はLinghornとかいうﾊﾟﾁﾓﾝ作りそうだな。

>>328
最初から駄スレだろ。どこにまともな書き込みがあるんだよ

アホアンチが自作自演してるので要注意

>>328
ほんと、MacだのJavaだの比較して煽る奴とそれにまんまと乗っちゃう奴で一気にな。
まぁPDCが終わればこうなるとは思ってた。
数年後にWinFX質問箱出るまで待とうや。

盛り上げたいならWhidbeyとSDKを共有しろ。話はそれからだ。

無茶苦茶な言い分だな。w

インストールできるハイスペックなマシンがねーよ。
ハァ・・・\19,800で買っときゃよかった・・・

まあ、12月になればぼちぼち盛り上がるんでねーの？

つーか無理して盛り上げんでもいいよ。まったりで。

WinSEXしたい

今更こんなこと言うのもなんだが、
より一層Windowsプログラミングは敷居が下がり、単価も下がらないのか？

よんひゃく

>>339
商売の基本。安く出来ない奴は負け組み。

マルチ

>>339
当たり前ですよ。進歩というのはそういうものです。
受け入れましょう。

>>325
そいつはまるで高慢にWinFXがIPv6を流行らせるんだと主張しているみたいだ

>>327
馬鹿の煽りネタを信じてレスしようが無駄。

見た目だけが進歩したように見えて作者の趣味がもろにはいってそれ以外は中身がないWinFX

>>328
どんなタイトルがいい？

>>347
ここ池
http://pc2.2ch.net/test/read.cgi/tech/1067675719/l50

>>347
【MXの次】WinFXって流産しちゃうの？

WinFXの実態もろくに知らないアホアンチが何を語れるのか見ものだけどな。(嘲笑激藁

>>348
そこはWin32PGがWinFXによって絶滅させられるというスレだが

マジでたてやがった(;´Д｀)

たてた。
これで「嘲笑激藁」厨と愉快な仲間達はあちらのスレに隔離

隔離スレがたたっとして一件落着。

さて、気になることおありですよ。
Mono Projectの行方が気になりますよ。
将来WinFXのすべての機能がUnixで使えるかどうかも気になりますよ。
M$的にはそんなことやりたくもなく、ほったらかしですかねえ。
となると、Monoががんがってやるんですかねえ。

Mono Roadmap
http://www.go-mono.com/mono-roadmap.html

Mono Hacking Roadmap
http://www.go-mono.com/mono-hacking-roadmap.html

>>354
Monoは失敗するに100ペリカ
イイカゲンそんな妄想は捨てたほうが身のためだyo!

GNUプロジェクトに商用ソフトと同等の失敗という言葉はないと思われ。

なにせM$はGPLを恐れているから

チンコﾋﾟｸﾋﾟｸビルゲイツ

＞311
＞はげどう。MFCやSwingなんかも無駄だったしな。

飯の種にできなかったあんたが負け組み
MFCやSwingが出てから何年経つと思う？

隔離スレの意味が全くないな。(嘲笑禿藁

Windows板があるんだから、そっちでやれよ

WindowsユーザーはOS板にも板違いスレ立てまくるし最悪だな。

WinFXに絡めたプログラミングネタの話しするのでもなしに、
なんでこんなスレが許されるのか。

>>363
ならば、死滅スレは許されるのかい？アホアンチさん。www

まあ、正直.NET出始めの頃は煽られると内心不安なところもあったけど
WinFXに関してはまったく不安なしだな。努力が報われた思いだ。

>>365
ちゅうことは、.NET Frameworkは今のうちに究めておいたほうがよいのかい？

>>366
ライブラリは激変しそうな気がする。
下位互換はあるかもしれないけど。あと文法もね。
個人的にはライブラリはちゃんとgenericsベースで書き直してほしい。

>>367

http://pc.watch.impress.co.jp/docs/2003/1029/pdc01.htm
> どれも、基本的には現在提供されているさまざまな技術の延長上にはあるものの、
> これらが統合されて、グループ化され、単一の名前空間内に配置されている。
> 簡単にいえば、WinFXに属するオブジェクトは、すべてSystemオブジェクトクラスの
> サブクラスとして実現されている。

> ＞311
> ＞はげどう。MFCやSwingなんかも無駄だったしな。
>
> 飯の種にできなかったあんたが負け組み
> MFCやSwingが出てから何年経つと思う？

.NETは誰一人、飯の種に出来ずに終わりそうだけど、
負け組と言うより馬鹿組だな。

>>369みたいな奴がいるからこのスレじゃ用語使うの難しいよな。
.NET＝現行の.NETのみ　か、 .NET＝WinFXを含む かを文脈から理解できないと。

.NETがLonghornでネイティブになるってのは出た当初から言われてたのに

でも一連の報道ではWinFX以降もブランド名として
".NET"って使うのかどうかよくわからなくないか？

>>371
ネイティブとは言ってないよ。単にLHで標準搭載ってことでは。

MFCは十年近いんでねーの？

とりあえずリリースから何年経ってもMFCもSwingも身につかなかった>>311がバカだろってことは共通の理解だよな？
>>311にとってはWinFXも無駄に終わる、と。

>>373
Win32からWinFXに完全に移行して、Longhornの全機能を使うにはWin32ではなくWinFXを使わなければならないという事実から「Longhornのネイティブ」と言えるだろう。

>>372
あぁ、.NETの技術自体は基盤になるが、.NETって用語の行く末は語られてない。
ブランド名として残るなら今後ますます混乱する人が増えるだろうなぁ。

便宜的に今の.NETをクラシック.NETって言わね？現時点じゃクラシックじゃないけど。まぁ現.NETとかでもいいや。
単に.NETって言っちゃうと今の.NETだけなのかWinFXを含むのかと混同する可能性があるので。

.NET/WinFXでいいんじゃね。
混同してるやつはアホ安置ってことで。

厨房っぽいスレですね

>>365
まだ正式リリースもされておらずベータ版も配布されておらず
WinFXというものが具体的にどういうことができるのか
だれでもテストすることができるように公開されていないんでは
WinFXに対する不安は消えないて。

>>381
>>365が言ってるのは技術的な不安じゃなくてメジャーになるかどうかって不安じゃないかな。

.NETもWInFXに名前変えて結局短命だったね

>>381
すごい情報あるのに。

>>382
メジャー？　どういう分野の中でメジャーになるって？

>>383
MSは数年経てば名前変えるんだよ。

>>379
混同しているアホというか、
わざと混同させるようなネーミングをつけたがるM$がアホ

ぶっちゃけブランド名の寿命はどうでもいいよ。

>>385
Windowsのメジャー。

>>377
.NETをブランド名とするのはいい加減やめて欲しい。
ドメインに.netとつけたり、「ドットネット戦略」というとM$絡みと勘違いされる。

>>389
と、いうか、GUI分野なのか
サーバ系分野なのかもはっきり知りたい。

どうみてもWinFXはあのアニメーションから
GUIばかり凝っているみたいなのだが。

>>391
いや、いくらなんでも現時点じゃそこまではわからんだろ。OSにWindowsを使ってる環境、としか。

>>391
今のところPDCでもクライアントOSとしてのLonghornの話が主だし（サーバ版も用意するみたいだけど）>>365が言ってるのもクライアントサイドでWindowsを使ってる場合の話かと。

>>391
GDIを切り捨てて
GUI描写をD3Dで行うことのデモに過ぎないわけだが

上辺のウインドウがひらひらなんてのはどうでもいいこと。

>>394
だよなぁ。既出の記事にもそういうのけっこう書いてあるけど読まずに書き込んでる人多いのかな。数少ない日本語記事なんだからせめてそれらは読んで欲しい。

でもまぁ、API、WinFSとか内部的な話が分からない一般人にとっては
ウインドウのアニメくらいしか目を引くものがないのも確かなわけで…

Longhornのメリットが派手なGUIだけしか見えてないやつは終わってるだろ。

そう、.net という名はもう古い。
これからの時代は FX！

http://www.din.or.jp/~ideyama/fx-union/
http://pc-fx.moemoe.gr.jp/

>>396
そんな人はすみやかにWin板のLonghornスレへ誘導・・・

俺はWin板も見てるけど、GUIが派手だとかいう話しかわからないならあっち行った方がいいよ。
Aeroの話とか実際に入れてる人の話とかあるし。

LUNAの二番煎じに過ぎないわけだが

>>401
だからWin板にお逝きなさい。

Win板の連中がアホ過ぎるのがいけない

やつらはただのWindowsオタクの分際でやたらと排他的だからな。
だから、こんなところにまで厨が溢れ出してくる。

あっちはあっちでMacをネタに煽ろうとする奴がいるし
こっちはこっちでJavaをネタに煽ろうとする奴がいるし
どっちもどっちか

みんな放置よろしくね。

GUIが派手なだけだろという書き込みを見るたびに可哀想に思う。


Macが。

>>404
しかも溢れ出してくるのが一般ユーザの知識しか無いもんだからとんちんかんな煽り方を

ハイスペックマシン持ってないからLonghornSDK見ながら脳内コンパイルして・・・・・むなしい。

>>407
彼等はちゃんと自分等の板で厨房を処理して欲しいよ。
技術の話しをするつもりがない連中はこの板から出てって欲しい。

具体的にどんなAPIになるんだろう。
現APIは各種ハンドルを取得して、それを引数にして叩き込んだが、
やっぱり今度のはインスタンス取得してメンバ関数呼び出す、とかになるのか？

OSのAPIをクラスライブラリで提供したのってBeOS以来？
MacOSXもかな。

>>410
うん。

>>408
LonghornSDK見せて。

>>413
URLはこのスレじゃ何度も出てるが・・・

で、結局画面がゆらゆらして作業効率でも向上するわけ？

>>411
Javaチップはその部類に入るかな？

>>415
だからWin板にお逝きなさい。

>>415
少なくともインスタンス取得して・・・
なんて開発だから作業効率は上がると思うぞ。

>>415
Mac板にお逝きなさい。

>>415は画面をゆらゆらさせるための作業効率のことを言ってたのか！

お前ら何粘着に粘着してんだ？馬鹿なのか？

正直すまんかった。

画面をゆらゆらさせても作業効率は上がらんだろうが、
同じ技術の応用で、ウインドウを表示範囲を狭めることなく
縮小して表示するとかできるからデバッグとか便利だろうな。

ウインドウメッセージをスパイしているときとか
ウインドウが隠れたりしててもメッセージが
変わらなくなりそう。

デバッグ中にウインドウ切り替えてとかで
いたらんメッセージが発生していらつくんだよな。

WinFXもメッセージベースなのかよ

さて、PDCも終わったし関連記事も読んだし、そろそろこのスレをブックマークからはずそうかな。
でも@ITがそろそろ次のWinFX関連記事を書くんだよな。それが出たらまたここで話が進むかもな。
もうちょっと様子みるか。

>>426
こ　こ　は　日　記　ス　レ　で　す　か　？

正直ROMっててもしばらく新しいことは出てこないだろう。SDK入れて動かしてみた！って猛者もいないみたいだし、
仮にいても自分で確認できないから話についていけないし・・・

プログラミングしないようなWin板Longhornスレの人の方がLonghornもSDKも動かせるという皮肉・・・

>>425
そりゃ互換性あるんだから残っているでしょ。

本気でWinFXが新APIだとか思いこんでる奴って、プログラマの間にもいるの？
プログラムはアマチュアの記者とかならわかるんだけど。
どう考えても新ライブラリだよね。APIのかけらも感じられない。

>>431
関数じゃないとAPIじゃないと思い込んでる人ですか？

おれは64bitWindowsに萌えるね

AMDの90nm Opteronは45W？
http://www.theinquirer.net/?article=12570
SOIの真価が発揮するか、Intelと同じように地獄を見るか……

WIN32APIってWindowsのシステムコールってことでしょ？
それが変わるならWindowsじゃなくなるじゃん

>>434
そういう厨な疑問はWindows板でどうぞ

WinFXが新APIだとすると、WinFXが呼んでいるのは真APIか？

今までWindows用アプリの開発は、Win32APIも使ってたけど、今後はWinFXライブラリを使えと。
WinFXをみんなが本当に使い、Win32APIを使わないなら、API(アプリケーションから見たインターフェイス)と言えるんじゃないか？
Win32APIを使うのはWinFXだけになればさ。









ならないだろうけど。

なんでWinFXがWin32APIを呼ぶ必要があるんだ？

>>433
俺はOpteronに萌えてます。
マルチプロセッサ＆独立メモリコントローラマンセー

> なんでWinFXがWin32APIを呼ぶ必要があるんだ？

そうだよね WinFX は新たな API なんだから
Win32API なんて不要だよね ﾌﾟﾌﾟﾌﾟ

MSさんよ、
いくら包皮あつくしてもやるときゃ剥くんだから一緒だよ？

.NETは言語(C#)・ライブラリ・ツールを一通り覚えたので、
次はCOMおよびATLの勉強をはじめようとおもいます。

>>396
APIに関してはどうなんだ？
Win32 APIに依存しにくくなるのか？
M$はXMLファイルを書き換えるだけでボタンの配置やスキンなどを書き換えられるのをWinFXの売りにしたいのか？

派手なGUIを使わずともファイルシステムなどにまでXMLを使っている時点でかなり重たいものに
なるんではないか？

>>396-397
派手なGUIやアニメーションに目を引かせるような宣伝で厨房をひきつけようとするM$側の問題でもあるわな

>>409
一般ユーザの知識しかない厨房を煽る奴もほとんどVBしかできない嘲笑激藁厨房だから・・・

>>440
> > なんでWinFXがWin32APIを呼ぶ必要があるんだ？
>
> そうだよね WinFX は新たな API なんだから
> Win32API なんて不要だよね ﾌﾟﾌﾟﾌﾟ
.NET frameworkのように内部ではWin32 APIをまだまだラッピングしているようだが。
WinFXでもすこしはWin32APIが剥がれるようだ。
最終的にWin32APIをまったく必要としなくなるらしいがそれはまだまだ先のことだな。
すぐにWin32 APIをすてることができるんだったら.netのすべての機能はどのOSでも
問題なく動くはずだった。だがM$はその気すらなかた。だからMono Projectが誕生した。

>>442
COMか。WinFXや.NETが騒がれてもいまだにCOMから離れられない人が多いんだよな。
離れたくても離れられないからな。M$がすぐにユーザに鞍替えを簡単にできるようにしなかったのが問題

>>445
政権与党は何かと大変なんですよ

Windowsはそろそろカーネルのインターフェイスを公開しても
いいんじゃないのかね。今さらサードパーティーが.NETに匹敵するような
環境を作れるともおもえないし。UndocumentedなAPIを公開するよりも
こっちだろうと。

M$は互換性問題で苦しんでいる技術者の立場も考えずいつも一人歩きしているからな　

いや、おれが知らないだけでもう公開されてたりする？？

【MXの次】WinFXって流産しちゃうの？
http://pc2.2ch.net/test/read.cgi/tech/1068378099/l50

無職は平日午前が一番元気気だな。(ｹﾞﾗ

元気気？

そういう藻前こそ無職ですか？(ｹﾞﾗ

無職でーす

嘲笑劇藁厨はいつから無職になったんだ？

しかもゼンカモンでーすｗ

俺はAlpha派だな

Alpha21264C/21364用カーネルきぼん

俺はBeta派だな

厨房はWin板へお帰り願います

>>457
Alpha21164+NT4.0は正直遅かった

WinFXで何が変わるんだろう。
XMLでGUIをいじくりまわすことができファイルシステムWinFSにXMLが使われ重たくなり
それに単なるアニメが増えただけ？

XMLを使った重たさを派手なアニメーションつき激重スキンやテーマでごまかしているように
見えるのは気のせい？

これは関数型言語の夜明けです。天才バッカス先生の
ご存命のうちにこのようなOSが出ることは喜ぶべきことです。

>>462
このあたりの記事を読んで見ては
http://www.zdnet.co.jp/enterprise/0311/06/epn18.html

462は釣り

> ファイルシステムWinFSにXMLが使われ

ﾌﾟﾌﾟﾌﾟ

アホアンチもWinFXを学びたがってるようだ。(大爆笑

>>462
XMLはね。ファイル形式の一種なんですよ。
コードじゃないの。もうちょっと勉強してね。

ファイルシステムにXMLが使われるのなら、そのXMLを格納するシステムは何なのだろう？

構文としてXMLのシンタックスを採用したプログラミング言語だってありうるだろ

>>470
ありえたとして今の話と何か関係あるのか？
WinFX、WinFS、XMLの３語を使って完結に説明せよ。（20点）

>>470
まああるだろうけど、少なくともそういうプログラミング言語で
GUIを弄繰り回しているわけじゃない。
今で言えばダイアログのリソースファイルでGUIを弄繰り回すと
言っているようなもん。普通のプログラマは、はぁ？と言うだろうね。

>>462
> XMLを使った重たさを派手なアニメーションつき激重スキンやテーマでごまかしているように
> 見えるのは気のせい？
それマックじゃん。

つーかXML使わないとLonghornのGUIが実現できないと思ってるのかな

ごまかしているんじゃなくて、ごまかされているのさ。462が（藁

技術の話しをしろとあれほど（r

またGUIにしか目がいかなくてしかもそれがGPUを使うことを知らない奴が暴れてるのか・・・・
これで何度目だ

釣りでした。オチと見た。　　さて真実はどうだろう？

釣りの場合はメル欄に釣りとでも書かないと負け犬の遠吠えになるだけなのにな

>>462
おまえが厨房だということはすべて丸ごとGUIっとお見通しだ！

>>477
GPUつかっても現状ではVideoBoard高すぎでコストパフォーマンス悪すぎ

>>481
未来の話を現状にするなよ（ｗ

> 現状では

現状はどうでもいい。3年後を見ろ。

おまえらまとめてWin板に帰れ

>>469
ファイルシステムにXMLが使われるとは
XMLで修正、検索でき、それを利用するときは一旦XMLに変換してからコンバートできるとか？

つかXAMLでGUI作ったとしてもコンパイルすればただのリソースとしてコンパイルされるよな？
>>462の内容だと実行時にいちいちXAMLを解析して読み込むことになってない？

>>481
リリースは数年後。気にすんな。しかもその話は何度も既出。おまえも厨房決定。

Windows, .NET関連スレにはデフォルトでWindows板に追い返してやりたいVB厨房がついてくる。

たかが500弱のこのスレのログと、まとめられた十数個のニュース記事くらい読んでから書き込めよ

>>488
VB厨房と決め付けているお前も厨房確定。Windows版に返れ。

あのソースコードみたらC#やVB.NETのソースコードをそのまま
XML形式に変換しただけで嫌ーなコードに見えてきた。まるでXMIみたいだ。
もうちょっとシンプルに変換すれよ。
タグの定義がどうなってんだか。

>>490
どうせC#やってる奴の大半はブビ厨だろ

>>492
ノイローゼですか？

>>491
スキーマぐらい見とけカス

>>487
だから？

>>493
やっぱりVB厨だったんだ

>>496
どうしてそうなるのかな？ｗ 日本語もダメですか？

スレ違いな奴は放置で、な。

無職のブビ厨が暴れるなよ。
流産スレへお行き

>>498
荒らすことが目的なんだろうな。
それほどにLonghornが強力と。

>>499
だから、お前スレ違い。

所詮はMacのパク利

>>498
Windows関連スレ、.NET関連スレにはGUI好きなVB厨みたいな放置できない奴が多すぎるから

所詮はFlashのパク理

GUIやWinFSがXMLで動いているとか勘違いした>>499がノイローゼで大暴走（ｗ

>>500
Longhornは見た目と必要なスペックがあまりにも強力すぎて資源の無駄使いと評されました。

>>503
お前さっきからウザイよ。お前のせいで荒れてるんだよ。ぼけ。

>>505
お前、やっぱり放置できない奴なんだな。

語尾に(ｹﾞﾗをつけている奴が荒らしているのか

@ITのWinFX記事まぁ〜だぁ〜？（ﾁｰﾝﾁﾝ

アンチLonghorn厨もアンチM$厨もアンチVB厨も放置

>>509 どこにｹﾞﾗが？ ノイ(ry

>>482
所詮WinFXもまだまだ未来の話だろ。
そのくせこのスレの厨房どもはまるでLonghornとWinFXを神のように崇拝したカルト集団みたいだし

>>511
わざわざ「アンチVB厨」とかくくらいだ。VBしか使えないことにそうとうのコンプレックスを持っているみたいだね。

>>513
未来の話なのに現状のパフォーマンスで考える馬鹿がいるのですよ。

>>512
検索しましょう

>>514
Win板に返れ。

アホアンチが火病起こしたぞ。(ｹﾞﾗ

>>518
わざとらしい。

>>513
未来の話を現状のスペックを基準に話してるからおまえは馬鹿扱いされてるんだよ。気づけよ。

それと俺はLonghornのすべてがﾏﾝｾｰはわけではなく数年後にどうなるのか把握しておきたいだけだ。

>>515
でさ、M$は２年後の未来にはLonghornに殆どの人がすぐに乗り換えてくれると思ってるのかな？
Longhornが無いとWinFXアプリがほとんど動かないってのはさすがに情けない話

>>517
あんな厨房の巣窟の板には殆ど興味がないけど
Windowsしか知らない奴って厨房が多いし。本当に馬鹿が多いんだよね。

アホアンチは（・∀・）ｶｴﾚ!

>>520
それで馬鹿にしたと思い込んでいるとはお前も厨房

>>521
一夜にして乗り換えるかどうかとかそういう馬鹿話か？

Longhornのベータ版使ってみたがありゃとんでもなく重たかったな。
酷すぎ。

>>521
今までMS以外も含めて、新しいOSができたら
ほとんどの人がすぐに乗りかえたことあったか？
もっと常識的に物事を考えれ。

新しいOSのAPIを使ったら、（少なくともその部分は）
新しいOSでしか動かないのはMS以外でも当たり前。

>>525
人のいっていることをそういうふうに捕らえ思い込むお前が馬鹿

Java厨は明日にでも惨が倒産しそうだから必死なんだろ。(大爆笑

>>521
>Longhornが無いとWinFXアプリがほとんど動かない

　　　　「ほとんど」

やっぱり全然わかってねーのな。

馬鹿って言われたのでもう必死。でもことごとく論破され・・・

>>527
> 新しいOSでしか動かないのはMS以外でも当たり前。
ほー？　そうかな。WinNT/2000で動くものもまだまだ多いけど。
ちゃんと古いのでも動かないと個人でしか流行んないなあ。あんなもんは。
つーか、どのOSでも動くというのが.NETの売りだったのに、
それじゃ、なんのための.NETなのさ。

>>529
またおまえか。死滅スレに逝け

>>532
「新しいOSのAPIを使ったら」
言葉尻で反論しようとするから失敗するんだよ。

>>530
そういう抽象的な言葉に反応するお前もどうにかしてると思う。
厨房って言われちゃうよ

>>532
一部だけ取り出すな。ボケ。
> 新しいOSのAPIを使ったら、（少なくともその部分は）
> 新しいOSでしか動かないのはMS以外でも当たり前。

新しいAPI使わなければ過去のOSでも動くわ。

>>526
MS社員ですか？
ベータは来年の夏ですよ。

>>534
何だって？　失敗だって？　きみのいっていることがよくわかんないなあ(藁

>>536
はてさて、過去のOSとはいえUnixでも動くのかな(w

>>538
ほら、ボケって言われてるよ。

>>532
.NETはどのOSでも動きます。
ですがOS固有の部分は動きません。
Javaだって同じですが何か？

>>537
ベータといわずビルドいくつというやつだったかな？

>>539
OSの勉強から始めてください。

>>539
子供みたいなこと言うなよ。つみきで遊んで来い。

>>542
割れ厨ﾊｯｹｿ

>>540
くだらんことにしつこく反応して
何の議論しているのか忘れるお前も厨房だなw

ついのこのスレからﾀｲｰﾎ者が！

>>543
ほう、これから出るWinFXがUnixで直接動かせるというんだなw

Mac84 = Longhorn2006

相手がPerl使いだろうとC++使いだろうと論破されて泣きながら別スレに逃げるアホアンチ。(大爆笑

とにかくLonghornは糞重くて使えない

>>548
つみきが無いならレゴでもいいよ。

むしょーくまんせー

>>544
喪前の反応も十分子供っぽい。

>>552
そうか、WinFXはレゴだったのか

ひろゆきは逮捕だろ。こんな基底をかくまってるなんて。

>>554
さっきから「ｵﾏｴﾓﾅ」しか言ってないじゃないですかあなた。

>>555
あらゆるものがオブジェクトだからね。
ﾘﾅｸｿみたいな化石と違って。www

>>548 マジでそう思っているのか？ お前無知すぎ。

>>556
ひろゆきが嫌いなら2chやめなさいってこった

WinFX発売＝2chの終焉

>>558
VB厨なお前的にはオブジェクトではなく「コンポーネント」だろw

>>551
また、未来の話を現状のスペックで考えているのですか？

WinFXアプリを脳内コンパイルして脳内エラー出してどうしたら良いか質問するから、みんな答えてくれよ。
だって俺SDK動かせないんだもん・・・

>>562
VBではコントロールですが何か？ｗ

もう無知のまま叩くのややめろよｗ

>>561
2chで喪前がそういうレスを続けているからいつまで経っても2chは終焉しないんだよ。
2chで煽りに反応するようでは2chは終焉しない。

言語別叩きやりたいなら他逝ってくれな。

>>563
実際に使ってみての感想だよ(藁

>>565は自らVB厨であることを認めたようです

>>568
何をちんたらやってんだ。早くSDK使って報告しろ。

>>569
VBを使えるだけ。なにも使えないお前と違ってなｗ

>>568
ただインストールして動かすだけならWin板逝け。

>>558
馬鹿ですね
VB厨はWindowsしか使ったことが無いから
Linux == Unixにしか見えないんですね。
本当に馬鹿ですねえ

>>568
なるほど、面白いジョークです。
存在しない物を使ったわけですか。
タイムマシンで未来に行ってとかいうオチですね。

　　　　　　　　　　　　　　　　　　　　　ﾏﾁｸﾀﾋﾞﾚﾀｰ
☆ ﾁﾝ　　　　　　　　　　　　　　　　　　 ﾏﾁｸﾀﾋﾞﾚﾀｰ
　　　 　 　 ☆　ﾁﾝ　　〃　 ∧＿∧ 　　／￣￣￣￣￣￣￣￣￣￣￣￣
　 　 　 　 　　ヽ　＿＿_＼（＼・∀・）＜ SDKの使用体験談まだーーーー？
　　 　 　 　 　 　 ＼＿／⊂　⊂＿)＿　＼＿＿＿＿＿＿＿＿＿＿＿＿
　　　　　 　 　 ／￣￣￣￣￣￣￣／|
　　　　　　　　l￣￣￣￣￣￣￣￣|　.|
　　　　　　　　|　　○味噌カツ○　 |／

>>570
SDKはまだ使ったことが無い。
しかもあの派手なGUIはまだ使えなかった。それでも激重だったよ。
しかもアプリ何も入れなくてもメモリ数百MBも食いやがった。
派手なアニメーションなくてもあんなに重たいLonghornは終わってる。

>>573
だれもLinux==Unixとか言って無いじゃん。お前の脳内おかしいよ。

>>574
まだベータ版相当なんだが

>>577
Linuxの話をしていないのにいきなりLinuxの話をしだすからああいうことを言われて馬鹿にされるんだよw

>>576
アプリ入れただけでメモリが増えるのですか？（ｗ
PC初心者版逝け。

XML使っているかまでは確認しなかったが
XML使えばかなり重たくなるんだろうな。

>>576
だからその程度の報告ならWin板で十分だっつってんだろ。

ハードディスクとメモリの違いも区別できないのかｗ

バッファローマン最強

>>580
話の流れを読めないのですかw

>>581
まだお前いたの？ GUIやWinFXはXMLで動いていないってｗ

ういんっぽっぽー

>>583-584
お前ら何を言っているのか理解できない。
厨房化したか？

>>578
まだベータ版相当にもなってないんだが

>>586
あほ、動くんではなくXMLで修正できるってんだろが

>>588
放置できないお前も厨房

>>589
じゃ、ビルド番号いくついくつだな

>>590
何を修正するのでしょうか？ｗ

頼むからただの「使ってみました」ならWin板逝ってくれよ。

とにかくあんな糞重たいLonghorn向けWinFXを使ったプログラミングはまだまだ早い。
今はやるだけ無駄。

>>581の意味がわからん。
どこに「XMLを使っているかまでは確認しなかった」んだ？
で、「XML使えばかなり重たくなるんだろうな」ってデフォルトじゃXMLを使わない設定にでもなってるのか？
クライアントアプリのGUIの話？

>>595
社会の最下層貧乏人専用ﾘﾅｸｿでも使ってろよ。(大爆笑

>>595
そりゃ未来の話ですから、今はやるだけ無駄でしょうｗ

>>595
最初からLonghornを動かすことしかできませんと言えばいいのに。そしてさっさとWin板に移動すればよかったのに。

>>597
またLinuxか。お前はLindowsでも使ってろよ

>>598
無駄だけどそれに気づかずにまだ登場もしてもいないものを自慢するVB馬鹿が多いでしょうw

俺のグラフィックボードは3D機能を持っていないから、
Longhornでさらに遅くなることは確実。

おいおいSDKを今動かすのは無駄とか言ってる奴がなんでこの板のこのスレにいるんだ。
WinFXのスレなんだからむしろSDKを使ってみるのが筋だろ。

>>597
VB厨はここへ逝け

【MXの次】WinFXって流産しちゃうの？
http://pc2.2ch.net/test/read.cgi/tech/1068378099/

Win板のLonghornスレが止まってきたからこっちに流れ込んでるのかな。

来月になるとWinFX対応VS.NETベータ版が配布されるのか？

>>601
だから未来がどうなるか考えているだけだって。
未来の話を現状のスペックで考えて悪い噂を流して、
未来の話と指摘されれば、自分のことを棚に上げて
未来の話を自慢していると叩くわけですか。
やれやれ。

どんどんLonghorn軽くなっているね。
この分だと正式版はXPよりも軽くなっているかも。
GPUやデータベースを応用したファイルシステムのおかげだね。

>>607
このスレでLinuxなどM$製品と競合する製品を叩いている馬鹿(>>597)を見ろよ。
他のすれでもよく見かけるんだが。こっちこそやれやれ。

>>608
嘘コケ。XPより軽いことはまずありえない。

>>609
ﾘﾅｸｿ厨はLinux板に返れ

>>607
おい、見ろよ。>>608が未来の話をあたかも現在の話のように言ってるぞw
未来がどうなっているか考えている以前に、XPより軽くなったと断言している馬鹿がいるぞ。
こういう奴には文句言わなくてもいいのかw

>>611
ノイローゼですか。
ﾘﾅｸｿなんてものこの世にありませんが。

>>612
断言してる部分を指摘してみ。

>>612
ベータ版のLonghornが以前のベータより軽くなったのは現在の話でしょう。
XPより軽くなったとは書いていません。
日本語を勉強したらどうですか？

完全にWin板のアンチが流入してるな

>>607
Longhornのベータかアルファか忘れたがあれを使った感想では
どうみてもXPよりも重たかった。あれにさらにあのくだらないアニメーションを付け加える
ととんでもなくおもたくなる思われるのだが。

>>614
全部

>>618
指摘できないとみなします。

>>617
くだらないアニメーションてデモのこと？あれはあくまでもデモだって記事読んでないの？

>>615
お前ってああいえば上祐厨だな

>>617
あなたは常にアニメーション付きで使うのですか？
デモしながらプログラミングｗ

>>619
そんな誤魔化しは通用しませんよ。
日本語ちゃんと読めますか？
読めないなら日本語をもっと勉強したらどうですか？

>>621
これも指摘できないとみなします。

>>620
デモ以外でも、ああいうものをWinFXで作れるとどっかにかいてあったが。

>>622
プログラミングするときもにぎやかだろうなぁ

>>624
やっぱりお前はああいえば上祐

>>623 お前つまらん。誤魔化したのは自分だろ。

>>622
勝手に脳内妄想で話を進めるあなたは馬鹿ですか

アホは放置

>>628
やっぱりあなたは誤魔化しています

>>625
そりゃ作れるがだからといってGUIを全部そうするかどうかは別。

NavigationApplicationについて語る奴ぁいないのか。
あのAmazon.comの写真だけで語ることは腐るほどあると思うんだが。

>>629
じゃあもっと具体的に説明したら？

VB厨ってそんなもんだからなw

>>632
VB厨がWinFX使い始めたら真っ先にああいう馬鹿機能を自分のアプリに搭載しそうだな。

今日は厨房がおおいなぁ。

>>633
Avalonｷﾀ━━━(ﾟ∀ﾟ)━━━ !!! やっとWinFXによるプログラミングのレスが・・・

脳内妄想も多過ぎ。
ノイローゼか。

ウィンドウの背景で動画を動かすサンプルはどうした？

>>637
ドラゴンボールが2週間ぶりにあるからって
浮き足だってるんだろう

>>637
いつものことだし
VB厨ってしょせんそんなもんだよ

>>641
ねーよ

>>642
どうやら反応したのはお前のようだね。

>>641
まるでデータベース板で暴れているドラゴンボール厨みたいだ

とおもったら今週もなかった
http://tv.yahoo.co.jp/vhf/tokyo/2003111012.html

>>644
hun?

>>644
何が言いたいのかな？

とおもったら来週もなかった
http://tv.yahoo.co.jp/vhf/tokyo/2003111712.html

>>647
言われたくない奴が反応するもんだよ。

>>650
了解。

終わったんじゃねえの？＜DB

>>633
http://longhorn.msdn.microsoft.com/?//longhorn.msdn.microsoft.com/lhsdk/port_task_navigation.aspx

まあこれでも見なさい。

MSDN TV: Lap Around Longhorn
http://msdn.microsoft.com/msdntv/episode.aspx?xml=episodes/en/20031028LHORNDB/manifest.xml

NavigationApplication と言えば気になることがあるんだが、
例えばあの Amazon.com の写真は次のような構成をとるわけだろう？

XAML UI - - - - - code-behind - - - - - Amazon.com

XAML UI は Avalon の管轄、code-behind は .NET VM か。
code-behind と Amazon.com の間は Indigo だろうな。
WinFS は Cookie の化け物みたいなものになるのかな？
ともかく、XAML UI + code-behind が NavigationApplication 本体ということになると思うんだが、
code-behind の中の処理の一部を Amazon.com の側に置こうと思ったら、
これは必ず WebService として実装してやらなくちゃいけないのか？
WebService にできるほどよく定義されてもないし
特定の NavigationApllication に特有の処理で鯖側で処理したいもの、
って多少はあると思うんだが。
識者よ教えてくれ。

>>655
Amazonのデモって現在のAmazonのWebサービスを利用したもの？
いずれにせよIndigoでWebサービスを使うしか無いとおもうけど。

Amazonのデモの奴こそFlashキラーのように思える。
Flashが狙ってるのはまさにこの分野じゃないんだろうかと思ったんだけど激しく思い違い？

>>656
あれって今あるWebServiceで作ってあるんだ。へぇ。
でまあ、やっぱりそれしかないのかな。
リモートでバイナリを押し込むJiniみたいなことも危ないしなぁ。

うちは来月からLonghorn用のアプリ開発がはじまります。

WebServiceでなくちゃならないことはないかと。

>>657
FLASH MX が VB っぽくなったのはまさにそういうことだろうよ。
いわゆるリッチクライアント方面では正面からの勝負になる。
ただし FLASH にはコンテンツ単品としての利用もある。
XAML じゃその辺は難しいだろうよ。

>>658
いや、今のWebサービスでやってるかどうか知らんけど。
Amazonだってあれ提供するためだけにLonghornに依存するようなことしないだろうし。

>>660
一部モジュールを鯖側においてRMIみたいにして利用する方法ってある？
Whidbeyでそういう開発がやりやすいように機能整備されてるかどうかが知りたいところ。

>>662
ああ、そういう意味で書いてたのか。納得。
いや、あれはデモだから、LANで繋いだ先に適当なWebServiceをでっちあげたんだろうと思ってたのよ。
ま、どうでもいいことだけどね。

リッチクライアントといえば現状でも.NETでノータッチ・デプロイメントとか言ってるけど、Longhornの情報が出た以上、あれも地味ーに消えていくんだろうなぁ。

>>665
ClickOnceに置き換え

>>653
こっちの方が丁寧かな？
ttp://longhorn.msdn.microsoft.com/?//longhorn.msdn.microsoft.com/lhsdk/appcore/overviews/appmodel_navigation2.aspx

>>661
>FLASH にはコンテンツ単品としての利用もある
そこにMSはSparkleでまたも正面から勝負を

とりあえずイントロってことで。
HelloWorldも。
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnintlong/html/longhornch01.asp

ClickOnce にもよく分からんところがあるのを思い出した（ｗ
Longhorn ではソースをコンパイルすると、
.exe と .manifest と .deploy という３つのファイルができるらしいんだが、
この後ろの２つは一体どんな役割を持ってるんだ？
.manifest はコンフィグ関係で .deploy は配布のための情報とか書いてあったものの、
いまいちよく分からん。
鯖側に３つ固めて置いといて、.deploy へのリンクだけWebに張っておくと、
そのリンクをクリックするだけで全部まとめてローカルにインストールされて、
.deploy はバイナリ起動用のショートカットとしてデスクトップに現れる、
みたいなことも書いてあった(これが ClickOnce らしいが)。
.manifest が特に謎だ。別にレジストリ代わりに使うってわけでもないんだろう？

>>668
ZDNet の記事を読む限りじゃ Sparkle は XAML を使うとか書いてある。
XAML の持つアニメーション周りの表現能力は VRML みたいなもんだから、
あまり複雑なアニメーションを処理させるのは厳しいんじゃないか？

>>670
.manifestは今のと同じでは？

>>670
CLI400のpptを参照されたし

>>672
じゃあ今の VS.NET で既に導入されてるものなんだ。ふーん。＜.manifest
まだ VS.NET を弄ってないから知らなかったよ。
その方面で調べてみる。さんきゅ。

>>673
おお。ありがと(-人-)

>>671
うー、Sparkleに関してはスクリーンショットすら見たことがないのでなんとも言えないけど
XAMLで座標なり画像なりアニメの動きの情報を持たせておいてSparkleがガリガリ動かすと思ってるんだけどなぁ。

ClickOnceが出てもやっぱり「zipで配布して設定はｉｎｉで保存しれ！」て声は無くならないよな

>>676
そういうやり方で機能は用意されるだろうが、使える機能になるかどうかは微妙。

　<Line X1="20" Y1="50" X2="30" Y2="50" StrokeThickness="30">
　　<Line.X2>
　　　<LengthAnimationCollection>
　　　　<LengthAnimation From="20" To="300" Duration="9"/>
　　　</LengthAnimationCollection>
　　</Line.X2>
　</Line>

例えばこれが XAML でアニメーションをやった場合の記述。
Line というシェイプの X2 座標を９秒間で 20 から 300 まで動かす、という内容。
どうも XAML で記述した内容は、基本的にはタグの一個一個が MSAvalon 以下のクラスに直接マップされる仕掛けらしい。
実際、XAML と code-behind はそれぞれコンパイルによってパーシャルクラスとかいう中間バイナリになって、
最後には統合されて一つのクラスファイルになるという記述もあった。
こういう仕掛けだから、１コマごとに内容ががらっと変わるようなタイプのアニメーションにゃ向かないんでないかと思うわけよ。
その点 FLASH は、確かフレームごとにベクタ画像のデータを持っていたんでなかったっけ。
得手不得手はあると思うな。

>>678
少しだけ追記。
LengthAnimationCollection とか LengthAnimation っていうクラスが Avalon にはあるんだよ。

Object
　Changeable
　　Modifier
　　　LengthModifier
　　　　LengthTimedModifier
　　　　　LengthAnimation

こんなクラス階層になってる。

そんな仕掛けだったのか。

MSDNはLonghonSDKを日本語化せんのか

やっぱりこのスレは技術的な話で進んでると良いなぁ。情報が少ないからふわふわしたやりとりになるけど。だがそれがいい。ﾏｯﾀﾘ

>>682は釣り

>>683
早速釣れた(藁

http://www.gotdotnet.com/team/PDC/4149/CLI400.ppt

ははー、なるほどな。
application manifest ってのは Java のあれの亜流なわけね。
そういや Java にはそんなものがあったなと思い出したよ。

>>685
META-INF？
悪いけどあんなしょぼいものと一緒にしないでね。

>>669
なんだ？　そのページ。
白い背景に以下のリンクが羅列表示されているだけじゃねえか。
Welcome to the MSDN Library
Welcome to the MSDN Library
Component Development
Component Development
Data Access
Data Access
Development (General)
Development (General)
Enterprise Development
Graphics and Multimedia
Graphics and Multimedia
Messaging and Collaboration
Messaging and Collaboration
Mobile and Embedded Development
Mobile and Embedded Development
.NET Development
.NET Development
Networking and Directory Services
Networking and Directory Services
Office Solutions Development
(略)

>>686
自分に分かる単純なところからから理解していくのが早道だと思うんでね（ｗ
今からでも VS.NET 触っておいた方がいいのは確かだなぁ。
今の仕事が終わったらインストールしてみるか。

放置徹底でよろ

デスクトップはどうせ今まで通り独占状態に
変わりないんだけど、WinCE向けのアプリケーションまで
.NETアプリケーションで独占されちゃうんじゃないの？
こっちの方が心配。

何　で　こ　ん　な　に　い　き　な　り　レ　ス　が　の　び　た　ん　で　す　か　？

>>691
ドラゴンボールが放送中止になったらしい

これはともっち以来の祭りだな

>>685-686
どちらかといえばJavaの亜流と思えたものはClickOneじゃないか。
JavaWebStartの亜流に見えなくもない。
まさかとは思うがブラウザがInternet Explorer系限定ということはないよな。
さもなければ何のための.NETなんだか。

>>686
しょぼいって中身がXML記述になっただけでほかは何もかわってようだが。
ネストされたタグに署名などを入れるのか？
そのあたりの説明がないな、あのプレゼン資料には。

あのソースはまるでApache Antのbuild.xmlファイルみたいだ。

>>688
> 今からでも VS.NET 触っておいた方がいいのは確かだなぁ。
なんであんな糞を触るんだ？ C#で十分だろ。

放置徹底4649

>>687
IE系以外のブラウザだとそう見えるよ。
いかにもM$らしいよね。

>>690
CEまで独占されるとどんな心配が？

つかその前にWindows2003はどうなのよ？

>>698
日本の製造業壊滅

ms-help://MS.PSDK.1033/sdkintro/sdkintro/windows_server_2003_family.htm
この中で目新しい機能ってどれになるんだ？

誰か2003をHOTLINEでよろしく

板違い徹底放置で

あいてしてよぅ

おまえら2003つかってないのか？

Windows　マンセー

>>700
そもそもCE自体がそんなにはやってるのかと

>>701
なんだそのプロトコルは？

>>705
WindowsServer2003 Enterprise ならあるよ

Windows2003ﾏﾝセ―

おまいら、dotnetの前にCOM+1.5だろ！

>>701
その文字列をブラウザURL欄にペーストしたが
「アドレスタイプが不明であるか、サポートされていません」
とでてきたぞ。
M$め、またわけのわからん独自拡張をしおって。

>>711
何？ COMが新しくなったのか？
.NETによってとっくに死滅させられたのかと思ったよ。

>>713
ms-help://MS.PSDK.1033/cossdk/htm/whatsnewcomplus_350z.htm
Note COM+ 1.5 is included in Microsoft箸? Windows箸? XP and in Microsoft Windows Server 2003.
The new COM+ 1.5 features are not available in earlier platforms,
such as Microsoft Windows 2000.

COM、ひゃっほー
もっとCOMを研究しようぜ！！！

M$のブラウザ依存な独自仕様にはウンザリ

>>715
DCOMはどうした？

cv dsm;lc v,sdkp e-rw^ikobnferw-bn vjdo-^skc jspd,cm ,zpk@dgev@lzcp
s:
wbc:@
d vcdbc:.erq
gnd
eq]b
mvwpoebwop kdvw0-ooe0-r3bkdp0-cov9ibfugr^v
d] gt
mh
e
mh
53m
h5y4,y46t,ju46y
END

Application-Level Access Checks Enabled by Default
Application Pooling
Application Recycling
COM+ Partitions
COM+ Services Without Components
COM+ SOAP Service
Configurable Isolation Levels
Creating Private Components
DTC Security Settings
Low-Memory Activation Gates
Moving and Copying COM Components
Network Access
Pausing and Disabling Applications
Process Dumping
Process Initialization
Running COM+ Applications as NT Services
Side-by-Side Assemblies
Windows Error Reporting

>>718
アフォコードを無駄に貼り付けるな

Web版のLonghorn SDKって目次からたどり着けないドキュメントが多くない？
検索してたらsyncできないページがｲﾊﾟｰｲ出てきたよ。

>>218
MSの発表を注意深く読むと、全ての Win32 API の実装を書き換えるって言ってるわけじゃなくて、
WinFX API とバッティングして性能が出ない部分 (画面描画まわりが典型的) は Win32 over WinFX
にせざるをえない、みたいなこと言ってなかったっけ。。

実際 GDI なんかは、Direct3D ベースの WinFX 系の描画システムに合わせて内部の実装を変えないと、
そっちに引っ張られてグラフィック系の性能でなさそうだよね。。

Application-Level Access Checks Enabled by Default

As part of Windows Server 2003’s enhanced security, access checks
are enabled by default when creating a COM+ application.
In previous versions, access checks were disabled by default
at the application level and enabled by default at the component level.
In Windows Server 2003, access checks are enabled by default
at the application level and disabled by default at the component level.
See Creating a New COM+ Application, Enabling Access Checks for an Application,
and Enabling Access Checks at the Component Level for more information
and procedures on how to change the default settings.

COM+のデフォルトのアクセスチェックがコンポーネントレベルのそれから、
アプリケーションごとのものに変わりました。

スレ違いだから。

>>608
> どんどんLonghorn軽くなっているね。
> この分だと正式版はXPよりも軽くなっているかも。
> GPUやデータベースを応用したファイルシステムのおかげだね。

>>612
> >>607
> おい、見ろよ。>>608が未来の話をあたかも現在の話のように言ってるぞw
> 未来がどうなっているか考えている以前に、XPより軽くなったと断言している馬鹿がいるぞ。
> こういう奴には文句言わなくてもいいのかw

>>614
> >>612
> 断言してる部分を指摘してみ。

>>618
> >>614
> 全部

>>619
> >>618
> 指摘できないとみなします。

>>623
> >>619
> そんな誤魔化しは通用しませんよ。
> 日本語ちゃんと読めますか？
> 読めないなら日本語をもっと勉強したらどうですか？

アホアンチは徹底放置で

Application Pooling

With the new ConcurrentApps property of the COMAdminCatalogObject object
in the Applications collection, COM+ Application Pooling adds scalability
for single-threaded processes and integrates with the new COM+ Application
Recycling service. See COM+ Application Pooling for detailed information.

adds scalability for single-threaded processesってのは分るんだけど難しい。。。

そろそろ虚しくなって泣いてる頃かな？www

>>352
甘くておいしそう(*^-^*)

Application Recycling

Application recycling significantly increases the overall stability
of your applications. Because the performance of most applications
can degrade over time due to factors such as memory leaks,
reliance on third-party code, and nonscalable resource usage,
COM+ application recycling provides a simple solution to gracefully
shut down a process associated with an application and restart it.
See COM+ Application Recycling for detailed information.
Also see "Configuring Process Recycling" in the Component Services
Administration Help for a step-by-step procedure for configuring process recycling.

Application Poolingのところでも出てきたrecycling.
サーバーソフトウェアなどの連続稼動コードのパフォーマンス劣化を防ぐために
COM+コンポーネントではなくて、プロセスの方をリブートしてしまう機能らしいなふむふむ。

誤爆・・・

COM+ Partitions

In this release, COM+ introduces support for COM+ partitions,
a feature that allows multiple versions of COM+ applications
to be installed and configured on the same machine.
This feature can save you the cost and time-consuming effort
of using multiple servers to manage different versions of an application.
On a single machine, each partition acts, in effect, as a virtual server.
After installing the application into each partition,
you create partition sets that map users to the logical servers.
See COM+ Partitions for detailed information about how to set up
and manage COM+ partitions. Also see "Administering Application Partitions"
in the Component Services Administration Help for step-by-step procedures.

複数のバージョンのCOM+アプリケーションをインストールそして実行することができる。
COMコンポーネントのバージョンニングの概念をアプリケーションレベルまで
広げてるのね、なるほど！

COM+ Services Without Components

With COM+ 1.5, you can use the services provided by COM+ without needing
to build a component to contain the methods that call those services.
This greatly benefits developers who do not normally use components
but want to use COM+ services such as transactions or the COM+ Tracker.
By using COM+ services without components, developers can avoid the overhead
of creating a component that is used to access only the COM+ services they need.
See COM+ Services Without Components for detailed information.

シンプルなCOM+サービスというものが作れるようになったらしいよん。サービスごときに
コンポーネントのごてごてしたお約束はいらないと。

スレ違いなので誰も食いつきません。

COM+ SOAP Service

With COM+ 1.5, you can now expose a COM+ application as an XML Web service.
You can also transparently use an XML Web service, whether deployed using COM+
or not, as a COM component. This means that you can easily create new XML Web
services out of existing COM+ applications and easily incorporate XML Web services
into new COM+ applications. See COM+ SOAP Service for detailed information.

COM+アプリケーションをWebサービスに仕立てることができるらしい。
これは何ができるのかわからんけど、COMコンポーネント間の通信にSOAPが使え、
またCOM+アプリケーションを容易にWebサービスにすることができるということかな。
なかなか面白そうだ。

>>735
突っ込みを入れてもいけません

>>737
ごめんなさい。

Configurable Isolation Levels

COM+ developers can use the new TxIsolationLevel property
or the Component Services administrative tool to configure an application's
isolation level according to need, helping to increase concurrency,
performance, and scalability. This flexibility enables those
with the right amount of expertise to get every last ounce of throughput out
of their applications. See Configuring Transaction Isolation Levels
for detailed information.

アプリケーションのisolation levelってなんだ？ﾑｽﾞｲ。
5段階あって,(0)none,(1)read uncommitted, (2)read committed, (3)repeatable read, (4)serialized
わかんねえよ

次のWindowsについて知っておくべきこと
http://www.zdnet.co.jp/news/0311/10/cead_coursey.html

Creating Private Components

In scenarios where you have several helper components in an application
that are meant to be called only from other components within that application,
this release of COM+ enables you to use a new property, IsPrivateComponent,
to mark these components as private. (In the previous release of COM+,
all components had to be public to have access to COM+ services, which means
that these components could be activated from other applications.)
A private component can be seen and activated only by other components
in the same application, giving you more control over what functionality to expose.
You need only document and maintain the public components, while making use
of private components that cannot be accessed from outside the application
but that can still take advantage of all COM+ services.

特定のコンポーネントからのみアクセス可能なコンポーネントが作成可能になったと。
インナークラスみたいなもんか？

DTC Security Settings

Several new security settings have been added for the Microsoft
Distributed Transaction Coordinator (DTC), enabling you to customize
your security levels for managing distributed transactions.
See DTC Security Considerations about these settings and how to implement them.

To facilitate mutual authentication on Windows Server 2003 platforms,
the DTC is restricted to running under the NetworkService account.
See Managing Accounts and Privileges for detailed information.

For recovery with XA databases, it’s recommended that the NetworkService account
be provided the permissions and roles needed to perform this recovery.
The exact method of doing this is specific to each database.
See Disabling Native Distributed Transactions and Disabling TIP
and XA Transactions for more information.

To help provide a more secure system when using XA transactions,
Windows Server 2003 platforms include a new registry entry
for specifying XA DLL files. When upgrading to Windows Server 2003,
you can work with XA transactions as before by creating a registry entry
under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSDTC\XADLL where the value name
is the name of the DLL (in the format dllname.dll) and the value is the full path
of the DLL file. You need to create an entry for each XA DLL file in use.
If the computer running DTC is part of a cluster, the registry entry needs
to be made for each node in the cluster. See Managing XA Transactions for more information.

DTCわがんね。XAってなんだよ！！

Low-Memory Activation Gates

With this release, COM+ automatically checks memory before creating a COM+ server
or object. If the percentage of virtual memory available to the application falls below
a fixed threshold, the activation fails before the object is created. By failing
these activations that would normally run, the COM+ Low-Memory Activation Gates
service greatly enhances system reliability.

使用可能な仮想メモリ量を調べてからCOMオブジェクトを作成させることにより
システムの信頼性を高めると。

Moving and Copying COM Components

With this release, COM+ allows you to move and copy your components.
This means you can configure a single physical implementation of a
component many different times. You get component reuse at a binary
level rather than at the source code level, which results in less code,
lower development costs, and faster time to market. See Moving Components
and Copying Components for detailed information.

コンポーネントの移動および複製が可能となりました。
複製は分るけど、移動ってなんのメリットがあるんだろ。どこへ移動するのか。

>>740
WinFSがWinFXに似てるから名前が変わるかもってな。

Pausing and Disabling Applications

COM+ applications are now more manageable. An administrator can pause
and resume COM+ server applications or disable and enable COM+ library
or server applications, or even individual configured components.
Both the pausing and disabling features prevent future activations
without affecting existing component instances. See "Administering
COM+ Applications" in the Component Services Administration Help
for more information.

コンポーネントを使用不化にしたり、実行中のCOM+Serverを止めたりできるらしい。

その前にFXって何だ。なんかの略か。

Process Dumping

It's not easy troubleshooting applications in a production environment.
How do you gather information on a problem without disturbing the running processes?
COM+ now provides a solution through its new process dump feature.
This feature allows the system administrator to dump the entire state
of a process without terminating it. See "Administering the Process Dump
Tool for Debugging COM+ Applications" in the Component Services Administration
Help for more information.

実行中のプロセスを止めることなく、COM+アプリケーションのダンプ情報出力の
オン/オフの切り替えができるらすい。

Process Initialization

Many server applications need to do specific initialization and cleanup
when they are started and shut down. When running on Windows Server 2003,
you can create a class that implements the IProcessInitializer interface.
When the process starts up, it calls IProcessInitializer::Startup
and when shutting down, it calls IProcessInitializer::Shutdown.
This gives your component the opportunity to do needed tasks,
such as initializing connections, files, and caches.

プロセス用の初期化終了処理専用のインターフェイスというだけぽ。

俺が思うに、「フェラチオの後SEX」の略ではないかと

Running COM+ Applications as NT Services

COM+ developers can now use the Component Services administrative tool
to configure and implement a COM+ server application as an NT service.
This means that the server can be automatically started or restarted
if your application always needs to be running; that your COM+ application
can run as the local system account if it needs to perform privileged operations;
and that your application's dependent services can now be started automatically.
See COM+ Applications Running as NT Services for detailed information.

あるアプリケーションから求められたときに応じて、動作を開始するCOM+アプリケーション。
イメージとしてはinetdから起動されるftpdとかそんな感じか？

Side-by-Side Assemblies

Side-by-side (SxS) assemblies allow applications to specify which version
of a system DLL or classic COM component to use, such as MDAC, MFS, MSVCRT,
or MSXML. For example, if an ASP application relies on MSXML version 2.0,
you can ensure that this application still uses MSXML version 2.0 even after
service packs are applied to the server. That is, even when a new version
of MSXML is installed on the computer, version 2.0 remains and is used
by your application.

To configure SxS assemblies, you need to know the path to the DLL and that
the COM+ manifest file exists in every virtual directory that needs
to use the DLL. The COM+ manifest is an XML file that has information about
where a DLL is installed. The manifest is used to create an activation context
for the application. Activation contexts allow an application to load
a particular DLL version, COM object instance, or custom window version.
You can use the Component Services administrative tool or ApplicationDirectory
property to enter the full path of the application root directory that contains
a valid SxS assembly manifest file. For more information, see the Platform SDK
documentation topics “Internet Information Services 6.0” and
“Isolated Applications and Side-by-Side Assemblies.”

SxSとはあるアプリケーションがつかっているsystemDLLおよびclassicCOMの
バージョン情報とその利用を記しておくものらしい。COM+ manifestとは
DLLが置かれているディレクトリに配置されるXMLファイル。
OLEViewerのどこでClassicCOMの一覧を見るんだっけ。。。

Windows Error Reporting

COM+ 1.5 includes support for the Microsoft Windows Error Reporting component,
available in Microsoft Windows XP and later, which enables users to notify
Microsoft of application faults, kernel faults, and unresponsive applications.
These notifications allow the Microsoft customer support teams to solve technical
problems more effectively. In addition, the Windows Error Reporting component
enables COM+ developers to receive information that can be used to improve their
applications. For more information, see the Platform SDK documentation topic
“Windows Error Reporting.”

Error Reporting componentとはIEでたまに出てくる、強制終了したときの
エラー送信ダイアログのことかな。自分のアプリケーションでもあれと同じ物が
実装できると。果たしてこの機能は誰が嬉しいのだろうか。

>>728
.NETがあるのにわざわざCOM+をやる理由は？

と、COM+1.5の機能概要をｺﾋﾟﾍﾟしましたが、おまいらCOMの凄さを
もっと汁べきだとおもいます！！！オレモナー
MSのCOMエンジニアはがんばっています。.NETに負けるな！！！

　　　が　　　　　　　ん　　　　　　　　　ば　　　　　　　　れ

無駄に英文をコピーしてどうするか。
リンクだけ張っておけばいいものを。
リソースの無駄遣いだ。

>>755
ライバルのJ2EEはどうした。

ひゃっほう、COMひゃっほう！！

J2EEがあればCOMいらな(ry

COMがあれば、JなんとかもFXもイラネ

COMマンセー。COMの凄さが分らないのに
ドトネトどか言ってて恥かしくないんですか？
ものには順序ってものがあるんですよ！！

読もうぜ！インサイドCOM+基本編

次のWindows2006でCOMにどんな拡張がされてるか語ろうぜ！！

スレ違いの相手すんな。こういう馬鹿には何言っても通じないから。

MS社成長の原動力となったCOM、つまりエンジニアのがんばりを
勝手に切り捨てるゲイツ、逝ってよし！！

そういや2chでコテハンで荒らしてたフリーソフト作者のごるごるもあが逮捕されたよな。ちょっと古いけど。
ああいう奴見ると、精神的に逝っちゃってる人間が相手だと何言っても無駄だと改めて思うよ。

さてWin板のバカも掃除できたことだし、そろそろお暇させて頂きます。
引き続き、次世代Windowsの"技術ネタ"で盛り上がってください。

あ、シェアウェアだっけか。ま、どっちでもいいか。

WinFXネタで掃除できないところが言い訳として痛いよな。

わざわざ死滅スレを建てたのに本スレを荒らす馬鹿が・・・
嘲笑禿藁厨以下だな

>>769
おれのことか？

必ず放置で。

>>770
まあスレ違いだこと

COM の世界を斬る！
http://pc2.2ch.net/test/read.cgi/tech/981823340/l50
COMにはやられた...
http://pc2.2ch.net/test/read.cgi/tech/1044457085/l50
【メール】.COMはどこまでいける Part1【読んだよ】
http://pc2.2ch.net/test/read.cgi/tech/1053699973/l50

おまえらCOMぐらい知っとけ
http://pc.2ch.net/test/read.cgi/prog/1027670637/l50

.NETを先に出したのはまずかったんじゃないだろうか。

Windows 非依存の CLI と、それの Windows 拡張としての .NET Framework を先に出したせいで、
.NET = Windows の進化系列からははみ出た、Java対策のライブラリ・フレームワーク
という印象を与えてしまった。
Java vs .NET という構図を作ってしまったから、それを含んだまま OS の API にすると Java vs WinFX という構図に引きずってしまう。
当然 Java 陣営は MS が OS のシェアを不当に利用して云々とか言い出す。

.NET 無しで突然 WinFX を出せば、OS の API が関数ベースからクラスベースに変わっただけで Java 陣営からはぐうの音も出なかったのに。

それどっちかっていうとWin板向けの話だな。技術よりマーケティング的な話。

>>481
並みのボードならGDIの代替くらいはお安い御用なわけだが
でないとそもそもDirectX出た意味ねーだろ

>>754
そもそも今の.NET自体がCOM上で実装されているわけだが

窓自体がそうなんだから仕方ないがな

>>776
そりゃwindowsで動いている限りCOMの呪縛からは逃げられないわな。

COMじゃなくてDLLのままなら良かったのにとか思ったけど、
DLLってオブジェクト指向じゃないんだよな。
ただの関数の集まり。

COMとCOM+の違いを理解できていないバカが居るな。

>>773
> Java vs .NET という構図を作ってしまったから、それを含んだまま OS の API にすると Java vs WinFX という構図に引きずってしまう。
> 当然 Java 陣営は MS が OS のシェアを不当に利用して云々とか言い出す。
さすがにそんな程度のことでは言わないと思われ。
WinFXとJavaとは比べるのも違和感がある。
片方はGUI系、Windowsネイティブが多し。
もう片方はとにかくOSに依存しないことを目標に・・・。

>>776
WinFXにもCOMが入っているの？

>>779
そんな紛らわしい名前をつけて初心者を惑わしたM$にも責任がある。
M$がやることはいつもこうだが。

しかも検索し難いったらありゃしない

俺としては.net Framework最新版によって
WinFXに基づくバイナリも(重たくとも)動くようになって
下位互換性確保して(ﾟдﾟ)ｳﾏｰっていう想像をするんだが
やっぱりはずれだよな・・・

>>781
win自体からCOM追放しない限りは
必ず何らかの形で共存してゆくことになる。

THE 素人談義

追放なんてできるわけない
すでにCOM使って作られたシステムとかいっぱいあるのに

そうなのだカーネルの時点でCOMの塊なのに

つまりCOM==不滅

結局画面がぐりぐりするだけか

>>790
タイトルバーが太くなったり、右のほうに変な縦バーができたりして
画面が狭くなったりもするよ。

君らアレだな、Win板直行組だな。

単なる、.NET用の追加ライブラリでしょ。

GotDotNet Japan 掲示板 : 開発ツール＆プラットフォーム ロードマップ
http://www.gdncom.jp/general/bbs/ShowForum.aspx?ForumID=33

>>794
今日のMSDN FlashにはLonghorn関係のリンクも多かったね。英語だけど。

>>669のnavigation applicationて何？普通のapplicationと何が違うの？

>>796
NavigationApplicationはWebのページを基本とするようなもの。
CLI304.ppt見れば分かる。

見れないんだよ・・・

＠IT：特集 .NET開発者のためのPDC 2003レポート
http://www.atmarkit.co.jp/fdotnet/special/pdc2003/pdc2003_01.html

ケツから手入れて奥歯ガタガタ言わせたろか？

netdcに振り込んできたよ

>>800
その表現いっただきー!!

>>801
漏れも今回は参加しますよん。ヾ(´ー｀)ノ

NET厨だが、このFXとかいう安っぽいネーミングが理解できない。
さんざんあれだけ煽ったんだからNETとFRAMEWORKを残せよ。
というかFRAMEWORKって全部のPCの世界を包括するような事言ってたよな。新しいAPIかなんか知らんが、FXってなんだよ。

これってさ、HelpのAboutとか見たらNETFRAMEWORK3.0とか書いてるんじゃないんだろうな？
Server2003がNT5.2とかと同様に。

フレームワークとAPIの区別ぐらいつけなよ。

>>806
なんだかな。【新API ?】 WinFX 【ただのライブラリじゃん】
というスレも建ってるくらいなんだが。

>>807
お前が立てたんだろ（ｗ

>>808
違うわ。

どちらにしろアホアンチが立てたことにかわりは無い（ｗ

だいたいMSの用語がどうであろうと、NETFRAMEWORK自体、Win32APIの一層上のAPIの事だろ？

>>811
UNIXでmono向けに最適化されたlibcが書かれたとします。
もしくはmonoがlibcの機能を包含する。
それはどういう扱いになるのがいいと思いますか？

>>812
ゴミという扱いでいいと思います

とりあえずさ、
http://www.zdnet.co.jp/news/0310/30/l_winfx.jpg
これ見る限り、WINFXの構成にWindowsForm,ASP.NETっとか内包されてるし。
今の自分の理解では既存のNETFRAMEWORKはWindowsにAddOnのようにあとからダウンロードしてインストールできたものだけど、
WINFXは最初からWINDOWS３２APIと同レベルまで食い込んでいる、よりOSと結合度が高いNETFRAMEWORKの拡張版ってこと。

違ってたら指摘してくれ。

>>813
なぜですか？なぜ全てのプロセスで同じlibcを共有しなくてはならないのですか？

>>806
違うのかい？

>>814
それで正解だと思うよ。
WindowsとIEを融合とかいって、ただ抱き合わせでアンインストールできなくしようとしたのと、同じ事でしょう。
エクスプローラにもIEは必要とかいって。
IEはOS一部のはずが、独禁法がらみでアンインストールできちゃうけど(´∇｀)ｹﾗｹﾗ

ためになるなあ

結局NETFRAMEWORKはOS非依存で、すべてのPC世界を包括するとか言ってたのは、大方の予想通り嘘っぱちで、
最終的にはWINDOWS自体の拡張に舞い戻ったわけだな。よくわかった。

OS非依存なんて言ってないし、.NETがOS乗っ取るのは当初からの予定通り。

まあ、今書いてるC#のアプリケーションは、VisualStudioFXの上でそのままコンパイル実行できそうだな。
それならいいよ。

>>819
いや.NETの時点では非依存も目指してたかもよ。
むしろそれが今回方針を変えたってことで名前もWinFXなんて変えちゃったんじゃないか。

ITバブルが弾けたからでしょ＜方針転換。
っていうかそういうどうでもいい話しツマラン。

>>823
いや、今回のFXというネーミング、NETとの関係も含めてMSの挙動を理解するためには大変重要なことなんだよ。

>>824
そうなんですか

アホアンチの釣りに引っかかるなよ。相手にするな。

まぁここはWinFX質問箱スレではなく、あくまでも語るスレだからね。
今のところ実際にLonghornSDK動かしたって人も出てきてないから具体的なWinFXコードの話もしにくいし。
主旨としては新しく出てきた用語の意味を把握するとか、これからの動向についてとか。
それでも情報が少なくてあいまいなやり取りになりやすいので個人的にはﾏｯﾀﾘ進行でいきたい。

しかしアホアンチが邪魔してくる

>>822
変えていません。

Javaでも.NETでもWinFXを利用します。今まではWinFXではなくてWin32でした。

名前がどうこう言ってるのってホントにエンジニアなのか？
ただの趣味グラマなら分るけど。

>>829
その論理だとWinFXの上に.NETがあることになるね。

>>830
どんな話がしたいのか言ってごらん。というか自分から話ふれ。

>>831
その通り。ちなみにWinFXはWin32の関数レベルのライブラリではなく
クラスライブラリなので.NETから使いやすい。
C++でWin32にあるlstrcatがC++のstrcatを使うのとほとんど
同じように使えるのと同じくらい使いやすい。

>>833
アホなのか社員なのか判別がつかないんですけど

>>834
おそらく.NETの定義が極小なんでしょう。

WinFXは「Builds on the .NET Framework」でしょ？
http://itpro.nikkeibp.co.jp/free/NBY/NEWS/20031028/2/

>>>833
.NETから使いやすいじゃなくて.NETの時期拡張バージョンじゃん。

http://www.zdnet.co.jp/news/0310/30/l_winfx.jpg
で、君がどのようにFXとNETを切り分けているか明確にしてくれ。
というかそんな事はできないだろうが。

>>829＝>>833
おまえ・・・ここでも自信満々で言ってるな・・・
【新API ?】 WinFX 【ただのライブラリじゃん】
http://pc2.2ch.net/test/read.cgi/tech/1068628392/8-

>>838

さらし者にするのは可哀想です

> 13 ：デフォルトの名無しさん ：03/11/12 18:52
> 信じたい人
> 思いこみたい人
> 引っかかりたい人
> 工作員
> これらの人はそっとしておくべきだと思う

という結論らしいし

>>839
お前もしつこいね（ｗ

MSDN Subscriber Downloads で、Longhorn 一式落とせるようになってるな。

ウィンドウを回転してもたいしたメリットなさそうだけど、
スケーリングも出来るのはかなりよくない？

良いよ。

ウィンドウを回転と言えば、少し前に窓の杜だったかで、画面をさかさまにするソフトが紹介されてたなぁ。
客と対面で座りながらノートPCの画面を相手に見せるときに、ノートPCを相手方向に
ぐるっと回すのがめんどうなので、画面だけ相手方向に回せて便利、とか。
はっきり言ってそんな便利には思えなかった。

描画の手法が肝なのだよ
グリグリはどうでもよいのだ

WINFXってｼｽﾃﾑの改良かとｵﾓﾃﾀらﾎﾞﾘｭﾑﾐﾗｰとかｼｽﾃﾑﾌﾟﾛﾃｸｼｮﾝとかと同列の
Win備え付けの機能みたいなもんか。Meみたいにインストしたらいの一番に止める予感…ｗ

頭悪い子は放置な。

>>846みたいな香具師の事？

845のことでしょ。

FXって
Framework(s) → FrameworX → FX
でしょ。違うの?

Longhornの機能と構造
http://www.atmarkit.co.jp/fwin2k/insiderseye/20031114pdc03-03/pdc03-03_01.html

レベル低いな

CNET Japan - ビル・ゲイツに聞く、「Longhornで何が変わるか」
http://japan.cnet.com/news/maker/story/0,2000047861,20061874,00.htm

Microsoftが長年にわたって蓄積させていったPCのノウハウの集大成だね。

ActiveXが死滅？
笑わせるなよ
今のウインドウズのカーネル層から上はActiveX（COM）の固まりだぜ

>>854
それが全部置き換わっていくんじゃないの？

COMの固まりはそうだが、必ずしもActiveXではないし。

sunもsolarisだけ力入れてりゃいいものを

Longhorn SDKも共有で出回ってきたな。

NTカーネルのスケジューラとVM、ドライバインターフェイスといった
プリミティブなところ(CLR含)以外の部分は全てCLRの上で動くんだよ。
カーネルスレッドがそのままCLR上のスレッドとなるんだよ。
WinFXには旧来のWin32プロセスは特別として、WinFX向けに書かれる
アプリケーションにはOS側から見たプロセス、という概念がないんだよ。

まさにマイクロカーネル様様

テレビじゃカテキンで殺菌とか言ってるけど
俺は見ちゃったんだよねあけて何年か経った
お茶の葉にカビがびっしりと生えてるのをね

ロングホーンなんぞふたを開けてみればそんなもんよ

テレビじゃカテキンで殺菌とか言ってるけど
俺は見ちゃったんだよねあけて何年か経った
お茶の葉にカビがびっしりと生えてるのをね

Linuxなんぞふたを開けてみればそんなもんよ

↑好きな言葉を入れて遊びましょう。

>>862
茶葉にかびか。プーアル茶ができるね。

レジストリベースのCOM、旧来のファイルシステム、URLベース？の.NET、WinFSのスキーマ・・・
これらのさまざまに独立したネームスペースを個別に管理していかないといけないとしたら、
Longhornアプリ開発は地獄絵図が想像されますが、MSはこの辺を整理する気はあるのだろうか。
そのためのWinFXと思いたいのだが・・・・。

次世代WindowsでJavaは動きますか？

LonghornはMSの買い替え喚起作戦なので、
踊るのも悪くないでしょ。

サーバ用途ではlinuxが確実に足固めしている。
カーネルの完成度はWindowsもlinuxも似たり寄ったり。
どっちも、深刻なセキュリティホールというのは存在する。
でも、linux系のほうがマイナーなだけあって、狙われにくい。

ビジネスのサーバにlinux使おうなんて奴は
まだまだ一握りなわけだが。
安い雑誌の読みすぎ

大抵は商用UNIX使うのが現実

linuxなんぞsoralisの足元にも及ばん

windowsと比べようとされた時点でOSとして不当に矮小な評価をされたような気がする。
どんなに穿った見方をしてもクズはクズだ。クズ確定OSと比べるな。

>>869
Linuxをそんなにクズ扱いするなよ。
いくら事実とはいえ。www

人と違うということに優越感を感る。それがLinuxのメリット。

バカかお前ら。
長骨はこうなってるんだよ！

┌──────────────┐
│　　　　　　　　WinFX　　　　　　　　 .. │
├──────────────┤
│　.NET Framework.　　　　　　　　　..│
├──────────────┤
│ 　　　　　　　　　　　　　　　　　　　　.. │
│　　　　　　 冫─'　 ~　￣´^-、　　　...│
│　　　　　／　　　　　　　　　　丶　　　 │
│　　　　/　　　　　　　　　　　　　ﾉ、　　│
│　　　/　　／ヽ丿彡彡彡彡彡ヽヽ.....│
│　　　|　　丿　　　　　　　　　　　ミ　　..│
│　　　|　彡　＿＿__　　＿＿__ 　ﾐ/. ...│
│　　　ゝ_/／|　　　 |⌒|　　　 |ヽゞ　 ...│
│　　　|tゝ　　＼__／_　 ＼__／　| |　　.│
│　　　ヽﾉ　　　　／＼_／＼　　 |ﾉ　. ..│
│　　　　ゝ　　　/ヽ───‐ヽ　/　. . ..│
│　　　　 /|ヽ　　　ヽ──'　　 /　　　　│
│　　　　/ | 　＼　　　￣　　／　　　 .. .│
│　 　／　ヽ　　 　‐-‐-‐-　　　　　　　.│
│　／＼ ／　ヽ　　　　　　　　　　　　　.│
│○―○　 丿　　　　　　　　　　　　 　 │
│　　/ー／／=　　　　　　　　　　　　　 │
│γ /＼＼＼γヽ　　　　　　　　　　　 │
│|| /|　=＼l　l|ニ)l|　　　　　　　　　　　.│
│ゝノ　　　 ` ' ゝノ 　　　　　　　　　　　.│
└──────────────┘

総括するとTRONが最強ってこと?

>>859
デバドラは依然としてC++で書けってことですか……

>>874
ドライバを書いたことがあるのか？

>>874
残念だったな
君の大好きなVBではいつまでたってもデバドラは書けないよ

地味にFreeBSDが最高。

犬クスはウニクス最下級

>>859
つまり次々と子スレッドを作るようなウィルスを書いたら
ひとまとめに葬る方法はない、と。
デッドロックしたスレッドも気づかぬうちに山ほど溜まって
システムが死ぬほど遅くなる、と。

馬鹿な、VB厨にC#が使いこなせるわけがないだろう？
まともに使ったらJava以上の言語だぞ？










　　　　　　　　　　　　　　　　　　　使いこなせてないのか…

>>879
なぜmanagedだと途端にできなくなると思うのか理由を書きなさい

アホアンチは隔離スレへお帰りください。
http://pc2.2ch.net/test/read.cgi/tech/1068628392/l50

>>大抵は商用UNIX使うのが現実
いや、だからIBMだとかが商用のlinux、販売してるじゃん。
サポート引き受けてくれるんだったら、こっちのほうが絶対
ぜってー安上がりだってば。

apacheにしても、Windowsで動かすととたんにパフォ落ちるし。
そこから起動されるCGIも、unix前提のコードだったりするわで
なんだかんだunixのほうが安上がり。

んで、Windows向けのWEB-SERVERは？と聞かれれば対抗馬ないじゃん？
いや、カスでいいならいくらでもあるけどさ、
なんだかんだ、apache for win32 だとかひどいときは
apache for cygwinなんかを動かしてるのが現状じゃん？

なら素直にunixにしとけよって。

サーバ用途では、Windowsではあと10年はかかるね。まぁ、MSも頑張ってるとは
思うし、セキュリティホールに対する取り組みも真剣なのは確かなので
この分野でもunixを追い越すのは確実だとは思うけどさ。

全然詳しくないけど仮にWindowsでシステム組む場合はIISにASP、ASP.NET、
WebSphereなんかのJAVAベースのアプリケーションサーバ前提でないの？
apacheとか最初から論外のような気がするけどどうなんしょ。

apacheはまだしも
CGIでどーたら言ってるような素人じゃ
話にならんでしょ。

全然Longhornの話じゃねーな。そんな話したいなら他の板逝け。

>apacheはまだしも
>CGIでどーたら言ってるような素人じゃ
CGI と言うと、perlやpythonなどのスクリプトを連想するほうが
素人とまで行かないまでも、unix産業を知らなすぎでは？（おそらく他業種の人か？）

unixの世界じゃ、CGIといいつつ、CやC++でビルド済みのバイナリであることが
商用世界では茶飯事。そのとき、makeが通りませんでは話にならない。
そのソースが必要としている *.so などが、Windowsではないことが多く、
ファイル名指定時のパス区切り問題 '/' or '\' だとか、ファイルの
パーミッション操作のOS間仕様の違いなどで、make通ったあとも何かと
問題が多い。

結局、OSというか環境まるごとunix系にしてしまう以外、手段がない。
確かに、近年のcygwinのエミュレーションの完成度には目を見張るものが
あるが、所詮エミュレーションであり、その性能ではWindows本来の
性能を引き出すことができない。

MSの掲げてきた.netは、構想としては夢のインフラではある。
が、まだ使いまわしの利くライブラリモジュールが決定的に枯渇、不足
している。.netを公表してから3年と8ヶ月が経過した。
確実なペースで浸透してはいるが、このペースではunixを追い越すのに
10〜15年はかかる。unixも、linuxの影響でここにきて成長が加速している
ことも原因の一つだ。

> CGIといいつつ、CやC++でビルド済みのバイナリであることが
横槍ですまんが変な文章。

>>横槍ですまんが変な文章。
確かに妙ではあるけど、世間のトレンドとしてcgi=インタープリタ・スクリプト
という暗黙の誤認識が浸透してることを垣間見ると、妙には見えないかも。

>>889
いや、確かにそうなんだけど、ここム板だし。

サーバサイドは当分、unix系、特にlinuxが続くだろうな。
実績でいえば、当然solarisなんだが、最近、linux向けパッケージが
急増している。sunもlinuxの勢いで、サポートも怠慢になりがちだし。

>まだ使いまわしの利くライブラリモジュールが決定的に枯渇
横槍ですまんが変な表現。

.NETの時もそうだったが、批判のする余地がないと途端にIISの話にすり替えるな。

887って化石の人？
誰もCGI=スクリプトなんて言ってないよ。
アプリケーションサーバーって言葉知ってる？

Cで書かれていようとCGIはオーバーヘッドが大きすぎて
イントラなどの業務系ではどんどん使われなくなってきてるの。

それをまるでCGIが主流のような書き方をするから「論外」なの。

UNIXとLINAXを同列に語るなよ

894って化石の人？
誰もCGI=プロセス消費なんて言ってないよ。
Apache2.0のスレッドって言葉知ってる？

それをまるでCGI=オーバーヘッドが大きいような書き方をするから「論外」なの。

本当に知らないんだね。

apache2でマルチスレッドで動くのはapache本体。
それもmpmをworkerやperchildにした時だけね。
デフォルトのpreforkは従来通りのマルチプロセス/シングルスレッド。

それ以上に、
CGIを実行するのは別プロセスなんだけど。
まさかapacheモジュールのことをCGIと呼んでるわけじゃないよな？

それともdsoで実行することを「CGI」と呼んでるのかな。

いずれにしろ「主流」じゃないし、素人丸出しで「論外」なのは変わらないけどね。

いずれにしろ、スレ違いの話題で得意になってる時点で「論外」なのは変わらないけどね。

ﾄﾞﾄﾈﾄのスレでｵﾌﾟｿとかいうゴミの話題するなよ。(ｹﾞﾗ

>>804
> NET厨だが、このFXとかいう安っぽいネーミングが理解できない。
目薬サンテFX！　みたいな名前だから？

>>894
そんなときこそFastCGIがあるのだよ

>>889
> >>横槍ですまんが変な文章。
> 確かに妙ではあるけど、世間のトレンドとしてcgi=インタープリタ・スクリプト
> という暗黙の誤認識が浸透してることを垣間見ると、妙には見えないかも。
それはおまいがご認識しとる。
ASP.NETがトレンドとか抜かす電波な馬鹿よかはましだが。

どうでもいいからスレ違い、板違いな話やめれ

>>885
この辺の疑問は自宅サーバ板のIISスレだったかでも出てたよ。
Web制作、WebProgとかのネット関係カテゴリの範疇だね。

アホアンチもよっぽど構ってほしいんだな。(ﾜﾗ

perl6があればWinFXイラネ

どうでもいいからスレ違い、板違いな話やめれ

MSBuild最強！！
Antは糞。

MSDNに入りたくなってきた。whidbeyが出たら買おうかな。

CheckMenuItem()
keybd_event()
とかの、「違うAPIに取って代わられたが、まだ使用できます」系の
Win32APIは、 Longhornではどうなってるんでしょーか？

まだ残ってそうな予感

>>909
M$Buildは最低の糞。
Nant最強

>>900
いや、ﾄﾞﾄﾈﾄはｵﾌﾟｽﾝよりゴミがから

ｵﾌﾟｽﾝって何だ？
半島のメーカーか？(ｹﾞﾗ

そろそろポストモダンの周期に入る頃だしな。ＦＸでコケて終わりだろ。

>>915
>>900が言っていたから(ｹﾞﾗ

WinFXが圧勝すぎてアホアンチも耳をふさいで叫ぶしかできないようだ

Ant >>> Nant >>> Gnu make >>> M$Build

>>918
(-Д-)寒〜

900超えたけど続きはアンチスレでね。

>>921
アホアンチは本スレにくんな。

むこうの方が、進行早いよ

>>922
そんなに怖がることはないのでは？ｗ

アホアンチもLonghornを怖がりすぎだな

WinFXは64bit版しか出ないってよ

ageて書くほどのネタだろうか･･･

NT4.0までの64ビット版もWin32でした

>>927
馬鹿だなあ。Win32なんてもうサポートしないってことだよ。
Win64APIだけをWinFXでサポートするってよ。つまりWin32は
バイナリ互換性だけしかサポートされないってこと。

> Win32なんてもうサポートしないってことだよ。
> つまりWin32はバイナリ互換性だけしかサポートされないってこと。
どっちかはっきりしろｗ

あっ。バイナリ互換でサポートするってことか。
バイナリ互換じゃないサポートってなんだ？改良するってことか？
Win32はもう放置するってのはさんざん既出なわけだが。

>>930
ヘッダファイル、コンパイラなんかの開発環境だよ。
で、バイナリが上手く動かないときは、
「Win64API向けにでコンパイルしなおしてください」ってなるそうな。

> ヘッダファイル、コンパイラなんかの開発環境だよ。
> で、バイナリが上手く動かないときは、
開発環境なのか開発環境で生成されたバイナリのかはっきりしろｗ

馬鹿だなあ。(新しい開発環境では)Win32なんてもうサポートしないってことだよ。
(新しい開発環境では)Win64APIだけをWinFXでサポートするってよ。つまり(新しい開発環境では)Win32は
バイナリ互換性だけしかサポートされないってこと。

あ〜。ぜんぜん意味がとおりませんなぁ。

いつまでも３２ビットWindowsなんて使ってて恥かしくないんですか？

Win32もWin64も同じ日陰の扱いだが。

ということは64bit版LonghornのCLRはWin32APIに依存せず
Win32APIは互換のために残すだけってことでいいんですかね？

>>934
Alpha21164&NT4.0使ってますが何か？

いつになったらMSは後方互換なんてくだらないものをやり続けるつもりなのか

そんなものはVirtualPCでやればいいんだ

>>937
で、それが32bit Windowsじゃないとでも？(ｹﾞﾗ

>いつになったらMSは後方互換なんてくだらないものをやり続けるつもりなのか
>そんなものはVirtualPCでやればいいんだ

ま、その考えが所詮技術者なんだよな。
確かにそのとおりさ。ゲイツだって知ってる。でも、やらない。
そんなことしたら、儲からないだろ？

やらないとなぜ儲かるんだ？

>>938
過去のデータやプログラムは完全無視ですか、そうですか。

後方互換無しなんてアホアンチが喜ぶこと
わざわざするわけないだろ（藁

> いつになったらMSは後方互換なんてくだらないものをやり続けるつもりなのか
こんな文章に、すんなりついていけるお前らっていったい･･･

>>944
自演のタネを明かしてはいけません

やらないとなぜ儲なんだ？

３２ビットWindows恥かしい。いまどきLinuxですら64ビットなのに。。。

新APIは　ハ　ン　ガ　リ　ア　ン　でなくなったんだろうな！？

>>947
普及版Windowsが恥ずかしいならさっさと64ビット版買えよ。

>>949
おまえも買えよ。ボケ。

>>950
既に使ってますが何か？氏ね

>>951
どうせ割ったんだろ。(ｹﾞﾗ

こんな糞スレ次は要らねえな

アホアンチが火病起こしてるな。www
何か嫌なことでもあったのか？
あ、WinFXの圧勝そのものが嫌なことなのか。(大爆笑

64ビットWindowsマンセー！！！

(´Д｀)よ〜く考えよ〜〜〜
(´Д｀)移行は大事だよ〜〜〜
(´Д｀)う〜〜うっ　う〜〜うっ　ううう〜〜〜

【WinFX】次世代Windows Longhornを語るスレ Part2
http://pc2.2ch.net/test/read.cgi/tech/1069394880/

64ビットWindowsマンセー！！！

やっぱ、ビデをファイル、とか、文章ふぁいるとかで、エロい物を
検索してくれで持ってきてくれるのがＯＳだね。

>>939
当たり前だろ（ゲラ

早く埋めろﾉﾛﾏ

ったく使えねーなﾉﾛﾏ

埋め〜このみかん

健康のために一日一埋

借金返済の為に一日一埋

あの娘に告白するため一日一埋

人と自然と響きあうために一日一埋

>>966みたいなのをスレタイにつけるのを延々とやってたスレがあったけど、
なんだっけ?

1000への第一歩

二歩目

三歩目。
そして二歩下がる。

一気に1000歩前進!

そして999歩後退

俺しか居ない?

君しか居ない

　

俺しか居ないので1000ｹﾞﾄ余裕

ホントに俺しか居ないのか?
1000まで残り32か

違った
残り22

また違った
残り21

くっそ!
残り19!!

WinFXは糞ってことは既に判明したわけだし、
もう話すことないよね。

>>982
ここはもう俺しか居ませんし、俺しか居てはいけません。
次ｽﾚはこちら
ttp://pc2.2ch.net/test/read.cgi/tech/1069394880/

俺だけのｽﾚ
984ｹﾞｯﾂ

人生はママレード

けけけ

うめっぞ！

をぁ！

やっぱやめた(^^;

>>985-989
俺のｽﾚを荒らすな

さて、風呂に入るか。

風呂から上がった
ちょっとのぼせた

さて
毛すぐ1000なわけだが

トリﾌﾟでも付けてみるか

誰も居ないなら俺が1000とっちゃうぞ〜

どうぞ。俺は写経で忙しい。

'`,､(´∀｀)'`,､

998

999

俺を邪魔する物は誰もいねぇ!!!

1000

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。