WinRTスレ (Metro, .NET Core, C++/CX)
誰が使うん?
遅い。1週間早ければ乙だった。
VistaとかXP用の開発環境も出てくるということは
WinRTってWin32のただのラッパーなのか
VisualStudio11はWin8以外でも動くけど、
WinRTアプリはWin8でしか開発できないよ。
とおもったら
>>1のやつはWindows8のリンクじゃん
Windows8からはWin32よりもWinRTを直に呼び出す方が速い
Win32はわざと遅くするみたいな小細工してくるんだろうな
あーやだやだ
「50ms以上かかるAPIはすべて非同期になります(キリッ」
C++やJavaScriptでも使えるけど、非同期APIとか面倒すぎて
C#のasync,awaitがないとやってられない
これ使うメリットって
Win7以前で動かないのと、公式ショップでしか配れない以外に
何かあるの?
それはメリットじゃなくてデメリットじゃないのか?
メリットは高速なWPFってとこかね。
WPFは便利なんだけど、パフォーマンス面で問題が出てたから。
WPFってなんでとろいの?
>>8 そのためのライブラリがC++やJSにも導入されている
JSだとPromise、C++だとPPL。
俺は使ったことないが、Dev Centerのサンプル見るとどちらもラムダを主軸としたものに見えるから
.NETのTPLと似たようなものだろうが
async/awaitは糖衣構文でフラットに書けたりする分有利ではあるな。
>>13 C++ のやつは C# でいうと event-driven async pattern。
JS のは、C# でいうとろの Task.ContinueWith つなぐタイプ。
C# 5.0 で導入される async/await と比べるとだいぶやっぱ使いにくい。
>>14 なるほ
まあ他はライブラリの中async/awaitだけ言語拡張だしなぁ
これは流行らんな
>>12 理由は色々あるが、その一つにオブジェクト大量生成によるGCの負荷がある
(Templateの仕組みにより、どうしてもオブジェクトが大量に生成されてしまう)
実装がネイティブになることで、この点は解決されるだろう
WPFはImageコントロールがUIスレッドをブロックしたり、
実行時にBinaryXAMLの読み込みが必要以上に頻発したりと、
どうもおかしな実装が多かった
ネイティブにしたところで、同じような実装なら遅いままだろうなぁ・・・
ちゃんと、パフォーマンスを考えて、まともな実装をしてくれるといいんだけど
Win8でしか動かないってのがなあ
わざわざ旧OSで使いたがる人がそんないるとは思えんけどね。
さしあたりメインターゲットはタブレット機辺りだし、これから出てくるのは
基本8搭載でしょ。
所詮MSがAppStoreで儲けるための布石でしかないからね
Win8メトロ切ったら快適だわw
Metroアプリが旧デスクトップ上にウィンドウ表示できないとビジネスアプリなんかに使えないよ。
タイルをデスクトップに置けたり、MetroアプリをZune Softwareみたいな形式で使えたら面白そうだとも俺も思ったが
そもそも、ここはWinRTスレだ。
タブレットではメトロアプリしか使えないとか
そんな感じになるのかな?
価格が安い代わりにメトロしか動かせないエディションとか出るかもね
なんだそのゴミパソ
Win8上で仮想マシン(スマホもどき) 作って、そこでメトロったらいいのでは?
ARM版はメトロしか動かないんじゃないのかな?
ARM版タブレットはMetroのみでおk
いさぎよいし
Metroの普及に弾みがつく
動くのか
CPUエミュとかするんだろうか
エミュなんてめんどうなことはやれねー
再コンパイルしてくれって言ってたじゃん
やっぱりバイナリ2つリリースしないといけないのか
>>34 ちがうよ、3つ。x86とx64とARM。
IA-64「」
そんなんでARMタブレット売れるの?
そんなに電池の持ちが違うのかな
WOW64は無くなるの?
そろそろwin32apiなくせよ
>>35 さらにARMはCPUによって4バージョンだっけ?
>>38 引き続き搭載されると思うぞ。なかったら暴動モノ
>>39 WinRTが活躍すればWin32はレガシとなる。完全に消え去るのはもっと後のことだろうが。
レガシーサポートはエンプラ版とUltimateだけでいいよ
値段もぼったくってやれ
Win8 タブレット→ほとんど売れず
Windows Phone→Win8ベースになるも、ほとんど売れず
パソコン→Metro上のアプリが増えず、ユーザーもMetroに移行せずの悪循環に陥る
このありがちなシナリオで、Win32が主流のままに5万ペセタ
ただでMetroアプリ作れるならお父さん、頑張って小遣い稼ぎしちゃうぞ
某所に張られたからか頭おかしいのが増えたな
ここはWinRTスレなんだが
ネイティブで実装され、.NET, C++/CX, JavaScriptから利用可能な
Windows用 次世代API Windows Runtime (WinRT) は不要ですか?
Win8でしか使えないんでしょ
当分様子見かな
8の時点で使うやつはそりゃ結構いるだろうが、本格的に広がるようになるのはもう一世代後だろうな
MSの新規物はバージョン3からとよく言われてることもあるし
そもそもマイクロカーネルは非同期通信が前提なんじゃなかった?
MachはlibcでUNIX的な同期処理しようとするから遅い遅い言われてたような
んで、おまいら何か作ってみた?
ARM版みないとよくわからんが、結局Win32ラッパなんだな
図説の通りならカーネルの上にサブシステムとして乗ってるはずだが今の実装はどうなんだろうな
>>52 WinRT は…
∧__∧ ∧__∧ なんでラッパやねん!
( *‘ω‘=m===く| ポッポコポー♪ (><;)
( つ((ニΦニ)) (つと )
v v v v
8のWinRTはネイティブだぞ
7でMetro開発出来ないのはその辺に理由があるんだろ
んや、サブシステムでもカーネル側での細工が必要でない限り後からサブシステムは追加可能だぜ
SUAとかあるし。
Win32とは別のサブシステムって事は
WinRTアプリからWin32APIの呼出しはP/InvokeやCOM経由でもできないのかな?
>>58 Win32上のレイヤかー
でもいつものろくでもないラッパーよりは差を吸収してくれそうだな。
Win32をレガシと呼びたいらしいから時代が進んだら依存関係を逆転したりとか考えてそう
まぁ、既存コンポーネントの利用を考えればそうなるよな。
サブシステム化はWinRTコンポーネントが充実してからってところかな?
>>57 できないらしいぞ
WinRTからWin32はP/InvokeやCOM経由も完全に排除されるらしい
逆もまた無理だそうだ
>>58 山田祥平は何を根拠にマイクロソフトの発表と異なる見解を述べてるの?
まあどういった実装でもP/InvokeやCOMは使えないだろうな
そのためのWinRTだろうし、権限管理の観点からもそうだろうし。
山田祥平が間違っている
いつも想像で適当な記事を書くカスだろ
>>61 簡単に言うとこういうこと?
Win32 WinRT
┗━━━━━━━━━┛ ┗━━━━━━━━━━━━┛
┏━━━━━━━━━━━━━━━━━━━━━━━━┓
カーネル
>>61 GetCursorPosならちゃんと動いたぞ。
同一プロセスでWin32APIを呼び出しているはずのMS以外のIMEが
不完全ながら動いたという話もあるし、
完全排除は未実装なんじゃないか?
Win32上のレイヤーだったら、ARM版Win32の分岐が大変なことになるから
ARM版だけWinRTが独立してると予想してる
すでにWin7でWin32 APIは仮想化しているから
WinRTはWin32サブシステムを経由せずに実装を直接コールしているんじゃないかな?
これなら2つの記事がどちらも間違っていないコトになるしw
ARM版デスクトップアプリは機能限定Win32で作るの?
Dependency Walkerで見る限りはWin32の関数を一部呼び出してるよ
ARMはどうせタブレットしか出ないでしょ
デスクトップスタイルは要らないと思うんだがなあ
マイクロソフトさん考え直してよ
名前もwin8tabletとかにしちゃってさ
タブレット側はスマートフォン側と共有で良かったのにな
戦略的には分かるが
WinRTでデスクトップアプリ作れたら問題なかった
Win9ではウィンドウにメトロ表示出来るようになりましたとかウリにしそうだが
それは無いんじゃないか
メトロ上にウィンドウが立ちあがったら
それこそ2chに画像貼られて馬鹿にされるレベルだと思うが
タスクマネージャとかTopMostなウィンドウはMetroよりも前面に出てくるけどね
そうじゃなくて逆にデスクトップにウィンドウとしてMetroアプリが出てきたらってことだろうよ。
>>69 Win32 APIをフル実装するよ >ARM版Windows 8
Win16やWin32sやWin64 APIのサポートはしないだろうけど
アルファ版windows2000思い出すな…
>>63 C/C++/C#/HTML/Javascriptができる俺はこの先も飯にありつけるな
WinRTはWin32の次世代版でしょ
Win32でできることはWinRTでも当然できる
より簡潔に書け、さらに新しい機能を盛り込んだ内容となっている
>>79 > Win32でできることはWinRTでも当然できる
本気でそう思ってんのかw
まあ、少なくとも version 1状態の今のWinRTはできないことだらけだろ。
実装が間に合ってないものはいずれたされるだろうけども、セキュリティの都合であえてできなくしてることも多いだろうし。
83 :
─☆─ [ X | I.I.T. ] COURANT DE CONSOLE ◆TXFAX7cidQpG :2011/09/25(日) 08:13:12.14
WinFSと名前似てるけどなんか関係あんの?
85 :
─☆─ [ X | I.I.T. ] COURANT DE CONSOLE ◆TXFAX7cidQpG :2011/09/25(日) 09:32:39.32
…こういうコトかな。
仮想コンソール環境への第一歩。
・ 従来の開発者の場合
[ 従来の開発者 ] → [ WindowsAPI ] → [ ブリッジインターフェイス ] → [ 新型インターフェイス ] → [ OS ] → [ PCハードウェア ]
・ 新規開発者の場合
[ 新規開発者 ] → ……………………………………………………→ [ 新型インターフェイス ] → [ OS ] → [ PCハードウェア ]
86 :
─☆─ [ X | I.I.T. ] COURANT DE CONSOLE ◆TXFAX7cidQpG :2011/09/25(日) 09:34:23.70
って言うコトで、あんまり小さい部分にこだわってると切り捨てられる可能性が出てくる。
要するに、アーキテクチャを意識しないでアプリを走らせる様にする事?
88 :
─☆─ [ X | I.I.T. ] COURANT DE CONSOLE ◆TXFAX7cidQpG :2011/09/25(日) 10:09:24.55
んで、仮想コンソール環境にはもう一つオマケがある。
[ 新型インターフェイス ] → | → [ インテル系CPU ] → | → [ OS ] → [ PCハードウェア ]
. | → [ ARM系CPU ]──→.|
. | → [ nVIDIA系CPU ]─→ |
新型インターフェイスの部分がCPUの違いを吸収すると言うコト。
89 :
─☆─ [ X | I.I.T. ] COURANT DE CONSOLE ◆TXFAX7cidQpG :2011/09/25(日) 10:11:01.37
>>87 実際にはメーカー間の取引条件にしてあんまり変わらないかもな。
普及させる気あんのかね、これ
91 :
─☆─ [ X | I.I.T. ] COURANT DE CONSOLE ◆TXFAX7cidQpG :2011/09/25(日) 10:28:51.03
普及って言うより、旧世代の技術を吸収しながら再統合するにはこういう方法しかないだろうな。
重厚長大になりすぎてスリム化が必要なとき。
最終的にAppleのエコシステムをパクりたいMSが、
全Metroアプリをマーケットプレイスで一元管理するための布石だからな
ARMでWin32フル実装なら.NETも全部乗るってこと?
その図ってIE、Win32、.NETが並んでる時点でおかしいだろ
>>93 全部載るよ。
というか再コンパイルなしでも動作する可能性が非常に高い.NETアプリを対応させない理由がない。
>>94 それを言うならWin32も終了じゃないか。
IEはシェルなんだよ! の頃を思い出したw
>>94 え、名前が変わるくらいで今までとまったく同じように開発出来てるよ。
Desktop appsのやっつけ感が半端ない
Win32は残るでしょう?
遅い上に非推奨のUIアプリしか作れない.NETはそのうち切られるんだろうな
独禁法訴訟が終わった途端、MetroでIE以外締め出しか
やるなw
>>85 Windows 7 の時点ですでに
[ Win32 アプリ] → [ Win32 API ] → [ Virtual DLL ] → [ OS ] → [ ハードウェア ]
[ .NET アプリ] → [ CLR ] → [ Virtual DLL ] → [ OS ] → [ ハードウェア ]
だったところに Windows 8 になって新しい下記パターンが追加されるだけでしょ
[ Metro アプリ ] → [ WinRT API ] → [ Virtual DLL ] → [ OS ] → [ ハードウェア ]
>>94 なんで終わるのかがわからん
いきなり従来のwindowsUIが消えるの?って話だし
.net関連の言語はそのままwinRTで使えるんだし
MetroでXAML以外のViewが使えるのか?
言語は残るけど実行環境とかライブラリはVB6みたいになっていくんじゃないの?
Metro推しは分かるとして、デスクトップアプリ開発の方向性がわかんないんだよな
>>100 それはない。
.NET と WPF の普及は Vista 開発時からのMSの悲願。
それが ARM 対応する時点でやっと WinRT として昇華できたわけで
今後も WinRT を構成する重要パーツとして残り続けることになる。
.NETはAzureの方で生き残ればそれでいいや
あれほどたくさんあったVB6のスレって今もうないんだなw
[ Win32 アプリ] ─────┐
-・-・-・-・-・-・-・-・-・- |
[ .NET アプリ] ───┐ |
↓ ↓
[ Metro アプリ ] → [ WinRT API ] → [ Virtual DLL ] → [ OS ] → [ ハードウェア ]
↓ ↑
[ Win32 API ]
でおk?
AppStoreパクって
上前はねたいだけって感がありありなのがなあ
とりあえず全画面表示強制をなくしてもらわんと。
デスクトップでメトロは使いにくい
そもそもデスクトップ向けじゃないし
デスクトップパソコンなんてものが数年後にはほとんど消滅してるし
それはどうかな。
ノートでもメトロは使いにくい
デスクトップとMetroってずっと並行、共存していくのか?
今でもMS-DOSアプリが動くぐらいだし
>>115 それもまた妄想だけどなw
少なくとも日本では、パソコン使うよりその代用でケータイ使ってる人のほうが
多いし、それがケータイからスマートフォンやタブレットに置き換わりつつあるだけの
話で、マイノリティとしてのデスクトップパソコンは、10年先も健在。
いやーマジでパソコンなくなるよ
今の時点でも携帯だけで不自由なく生活してる人いっぱいいるし
ノートパソコンはまだいくらか売れてるけど殆どの人は
iPadにキーボードがついた程度の使い方しかしてないし
PCが無い場合スマホ向けコンテンツを何で製作するつもりなんだ
ないならスマホ向けIDE作って売ったらいい
おまえはそれでいいよ。
>>118 それは神にしかわからないな。
Win8タブレットが売れなかったら、Metro自体がこけるかもしんないし、
Win8タブレットが一定の成功を収めて、ノートPCやデスクトップ機でも
案外メトロ使いやすいじゃん、というライトユーザーが多ければ、
遠い将来従来タイプのデスクトップUIはほぼ絶滅するかもしれない。
>>107 主役はWinJSだろ。
.NETはそれしか使えない開発者向けの撒き餌。
もうメトロ プログラマ 募集でググると大量にヒットするな
好む好まずにかかわらず、PCメーカーは、AndroidかWindows 8のどちらかを選択しなければならない。
Android選択する罠。
>>122 何のために日本はスパコンに国家予算出してると思ってるんだ
東京メトロ・・・
>>121 携帯で不自由ないという人はいっぱいいるが、パソコンがないと
不便でしょうがないという人もいっぱいいるんだが
>iPadにキーボードがついた程度の使い方しかしてないし
つーか、iPadのようなタブレットマシンと、パソコンをまったくの別物と
分けて考える事自体間違い。iPadが大型液晶とキーボードを持ったら、
パソコンと何が違うんだ?
モバイル系の端末とPCとの境界線がだんだん曖昧になってきてる訳さ。
Win8もその流れの中で出てくるOSな訳で。
何か開発する人はべつだよ
大昔は高価なSunのワークステーションとかNT3.51入ったパソコン買ってなんか作ったりしてましたよねw
それに戻るだけの話で
一般ユーザーはもうパソコンが完全に要らない一歩手前のところまで来てる
開発する人向けのツール作るのに必要なのはWin32APIだけ
.NETは要らない子
妄想乙
最近、一般人にPC要らなくなる論で熱くなる奴多いな
自分自身、PC世界が常識すぎてショッキングな話に聞こえるんだろうな
今でもガラケーしか持ってない人一杯いるのに
WinRTがすべてのAPIをカバーするなら、Win32と.NETはレガシーって事で放置にしてくれていいよ
BUILDで配られたキーボード付きタブレット、あのあたりが妥協点だね
Metroがデスクトップっぽく進化すると思う
>>137 プログラマが飯を食うために開発ツールを取っ払う魂胆だろ
それはそれでありがたい話だ
>>110 [ Metro アプリ ] → [ WinRT API ] → [ MinWin ] → [ ハードウェア ]
↑ ↑ │ ↑ ↑
│ │ │ │ [ Virtual DLL ]
│ │ ↓ │ ↑
[ .NET アプリ] ───┴─→ [ Win32 API ] ─┘
│ ↑
-・-・-・-・-・-・-・-・-・- │ │
[ Win32 アプリ] ────┴──┘
開発ツールに限らずフォトショやAE、3Dツール、DTP、DAWみたいな専門ツール使う層は嫌がるだろうけど
普段のネットや2ch、ゲームなんかはMetroの方が楽だろうなと思う
今のままじゃタブレット以外で使い道ないだろ
そうかな?
>>145 その分け方は両極端すぎだが、少なくとも20インチ程度の液晶+キーボードありの
環境で使うなら、現状ではMetroには魅力を感じないな。ウインドウの位置・個数・
サイズを自由に調整できないのは不便すぎるし、タッチするには画面が遠すぎ、
そもそもタッチ対応の液晶なんて誰も持ってない。
ソフトウェアレベルじゃなくて操作含めたハードウェアレベルで
家庭用、専門用とかに分かれる可能性もなくはない。
タブレットにこだわるのは
企業が大量に入れるところあるから
メトロ普通に使いやすいじゃん
普段からカスタマイズをゴテゴテやってる人から見るとカスタマイズの余地が少なくて嫌なのかもしれないけど、
そんなにカスタマイズしないでそのまま使う人にとっては普通に使いやすい
>>150 事実上CEやめたからだろ
今までの客層をやすやすととられたくない
先祖返りだなぁ。
Metroなんかよりマルチディスプレイ対策の方が需要あるだろ
別にWinRTでマウスやキーボードショートカットを使ってもいいのよ?
確かに思えばマルチウィンドウな事務作業とかと違って
画面の解像度フルに活かすために全画面が基本かもしれないな。
VSもMDIからタブと分割表示、ドッキングウィンドウが基本になったし
用途特化という意味ではブラウザが全画面だろうフォトショが全画面だろうが同じだな。
まあ全画面=Metroという意味ではないが、
オブジェクトブラウザ見たところWinRTでもマウスデバイスの入力情報はちゃんと取り使えそうだし。
>>157 うん、もちろん使ってもいいけど、えらい工数かけて移行するメリットってなんかあんの?
マウスとキーボード使うなら逆にメトロに魅力感じないなあ
俺はアイアンマンみたいに開発したいんだ
MacのLion使った時も思ったけど、
フルスクリーンUIは10インチくらいまでの画面がサイズが
相性が良いと思った。
うん、一定サイズ以上のディスプレイだと、フルスクリーンにしなくても
快適な場合も多いからな
逆にフルスクリーンにした場合、視線やマウスの移動距離が
増えて使いにくく感じる場合もある
Lionが使いにくい原因はフルスクリーンがどうのって問題ではない気が
>>159 「専門ツール使う層は嫌がるだろう」っていうから今でもMetro Styleと大差ないよって返したのに
「工数掛けて移行させるメリットがない」と何故か開発者視点と来たもんだ。
>>165 じゃあ、こう聞こうか。「Metroに移行すると、フォトショがぐんと使いやすく
なったりするわけ?」
お前しだい
はあ、そうですか
>>162 フルHDクラスやそのマルチディスプレイな環境なら
マウスなんて捨ててペンタブレットに移行した方が便利だよ。
精度は民生用でもマウスなんか比較にならないレベルだし
(読取分解能:0.01〜0.005mm、クリック強度:1024〜2048段階)
>>163 マウスクリックもタップも両方「押す」だから統合したんだろ
RightTapとかButtonDownがTapに変わっただけじゃねーか!変わらねー
なんで
>>166の脳内では「嫌がらない」≒「ぐっと使いやすくなる」に変換されるの?
まぁ、Direct3DやDirect2D、DirectWriteで描画されるから快適にはなるんじゃないの?
今でもGPU使ってるぞ?
そりゃ今時の画像処理ソフトが「GDI使ってるんで速度でませんでした」とか言ってたらぶち殺されるわ
>>165 開発者視点で反論してるのは俺じゃねーし
なんか俺がダブスタしてるみたいに言うなw
>>176 先生、WinRTの開発者にふさわしい話題をください!
Expression BlendなんかWPFの完全C#アプリだけど
デザインツールとしては意外とそんなに重くないよね
179 :
デフォルトの名無しさん:2011/09/25(日) 14:49:35.64
180 :
デフォルトの名無しさん:2011/09/25(日) 15:05:32.11
メトロUIは一般人には好評だと思う
どういうときにシングルクリックなのかダブルクリックなのか理解できない人がいるんだよな
ワープロみたいにそれだけの機能使うときには余計なとこ見えない方がいい
しかしWinRTがメトロしか作れないのならWin32の置き換えにはならんよね。
WinRTでデスクトップアプリを作れるようにするつもりなのか。WPF的なものを乗せてくるのか。
C++、WinRT(COM)、ネイティブなWPF?、XAMLなんかで組めたら全部ネイティブで最高だなw
183 :
─☆─ [ X | I.I.T. ] COURANT DE CONSOLE ◆TXFAX7cidQpG :2011/09/25(日) 16:25:11.59
…メトロ化(モバイル系フルスクリーンUI)は時代の流れだから仕方ない。
メトロ化で過去の遺物になりそうなデバイスがマウスになるが、これも長い時間をかけて消されていく。
意外と長期的な視野に立っている。
184 :
─☆─ [ X | I.I.T. ] COURANT DE CONSOLE ◆TXFAX7cidQpG :2011/09/25(日) 16:27:34.78
タッチスクリーンとマウスが入れ替わるか、それとも分離されるか。
スタイルの変化だな。
デスクトップPCの開発環境は変わらないと思うけど。
デスクトップもメトロになると思ってるお花畑な奴がやっぱ沸いてくるんだなw
186 :
─☆─ [ X | I.I.T. ] COURANT DE CONSOLE ◆TXFAX7cidQpG :2011/09/25(日) 16:31:26.37
Metroなエロゲの登場に期待
プルプルした乳を撫で撫でしたら興奮するよね
188 :
─☆─ [ X | I.I.T. ] COURANT DE CONSOLE ◆TXFAX7cidQpG :2011/09/25(日) 16:32:56.76
>>185 いや、MSならやりかねんぞw
あっと言う間に塗り替えるからな。
189 :
─☆─ [ X | I.I.T. ] COURANT DE CONSOLE ◆TXFAX7cidQpG :2011/09/25(日) 16:34:39.82
…仮想コンソール環境とクラウド・コンピューティングとはまた別枠の話だからな。
混同しないように。
仮想コンソール環境はクローズド・コンピューティングが前提。
SilverlightのOOBみたいなやつで良いから
WinRTで作ったアプリをデスクトップでも使える形にしてほしいかな。
もちろんAppStore(だっけ?)経由じゃなくても配布可能な形で
191 :
─☆─ [ X | I.I.T. ] COURANT DE CONSOLE ◆TXFAX7cidQpG :2011/09/25(日) 16:42:36.45
今後普及が拡大していくスレートPCとか、メトロインターフェイスの需要は大きいからな。
192 :
─☆─ [ X | I.I.T. ] COURANT DE CONSOLE ◆TXFAX7cidQpG :2011/09/25(日) 16:44:16.63
アンドロイドの駆除体勢は整ってきたなw
技術的な話ができる奴がほとんどいねーな
昔のWPFスレを見てるようだ
今のところコテが喚いているだけのスレだな
195 :
─☆─ [ X | I.I.T. ] COURANT DE CONSOLE ◆TXFAX7cidQpG :2011/09/25(日) 16:56:22.32
ほらねw
その前にWPFとSilverLightを統合しろよ
覚えるの面倒だよ
WinRTはメトロUI専用ではないのだが
>>197 ふ〜ん。
じゃあ、VS11でWinRTを使って非メトロアプリを作る方法を教えてよ?
普通にWin32や.NETのプロジェクトから、WinRTのAPIを呼び出すだけじゃないの?
>>196 違いが多すぎて統合なんて無理。
どっちかを廃止するしかない。
廃止するとしたら、HTML5のおかげで急速に存在感を失っているSilverlightだろうな。
WPFで使われてるフルバージョンの.NETはAzureやASP .NETがあるから廃止なんてありえないし。
>>199 WinRTが使えるのは.NET Core。
普通の.NETとは実行環境自体が異なる。
>>200 Silverlight Out of Browser がこちらを見ている
なんか"Longhorn"が発表になってWinFXがどうのと騒いでた頃を思い出すな。
その前にやるべき事はWindowsPhoneを普及させる事だと思うのだが
>>202 どうしてもWPFと比べて見劣りするんだよね
SilverlightってWPFからデスクトップ向けの機能が削られたようなものだから
>>204 Win8リリースと同時にPhone対応もお願い。
ホーム画面だけならWindowsPhoneはiPhoneよりはるかにかっこいい。
やっぱりMetroはいいよ。
だが、Win8のMetro。お前はダメだ。
あの長い横スクロールは酷い。
.NETベースにして、Win32 API用のラッパを提供するという計画がとん挫して、現実的な対処をした感じ。
androidアプリでNative触るのと同じだな
212 :
デフォルトの名無しさん:2011/09/25(日) 17:38:06.47
http://blogs.microsoft.co.il/blogs/sasha/archive/2011/09/15/winrt-and-net-in-windows-8.aspx Next, a C++ Metro application will still load Win32 DLLs such as kernel32 and ntdll. Moreover, the WinRT APIs call into the Win32 DLLs so they are not a replacement but rather a wrapper, an API flavor, on top of Win32.
(Historical note: Windows used to have a feature called “environment subsystems”, which can be roughly described as API flavors. WinRT is not an environment subsystem it is a library on top of the Win32 environment subsystem.)
213 :
デフォルトの名無しさん:2011/09/25(日) 17:44:51.69
What about the limitations, then, that a Metro application has in terms of API surface?
Indeed, a Metro application written in C++ will be able to access only a part of the Win32 API surface, and this is accomplished through a bunch of preprocessor definitions.
よくわからんがただのWin32ラッパーで、しかもプラットフォーム呼び出しの機能がいろいろ制限されててダイアログすら作れないのか
なんか嬉しいのかこれ?配布もアプストア経由のみで、自由にできないんだろ
デスクトップ用途には要らない子にしか見えんな
WPFを普段から使ってると、あまりワクワク感が無いなぁ。
とりあえず、WPF+AsyncCTPでTask周りに慣れておいて、
WinRTを使うのは正式公開されてからでいいや、って気分になってしまう。
>>213 その制限されたAPIのみが宣言されたヘッダファイルは用意されているのかな?
無いとしたらかなり面倒な事になるぞ。
>>215 そのブログに書いてあるけど勿論ヘッダは利用できて
RT用のコンパイルだと#pragmaや#ifdefの制御で色々無効になるっぽいな
まあWindowsフォンが売れたらそれで商売したい人が飛びつくのかもしれんが
今のところの情報の範囲では、俺には関係ないものと分かったわ
>>211 今までと同じように作れちゃうのが凄い。
XAML様様だな。
なに?メトロアプリではMessageBoxが許されない?
嫌だね。
あえて俺はMessageBoxをコールするッッ!!
>>213 ダイアログはあるが、ダイアログウィンドウではない。
NTFSではasync I/O使っても全てのI/Oが実際に非同期化はされないわけだが
その辺WinRTではどうなってるんだろう
単に裏でスレッド回してるのかな
マルチウィンドウをそもそも想定してないんだよな?
完全にWindowsフォンアプリ/ゲーム用環境じゃねーのこれ
Win32のラッパーとして、.NETより少しは速いのか?
>>220 .NETだと非同期っぽく見せるために裏でスレッドを回してるから
WinRTでも同じことをするんじゃね?
>>222 .NETはIOCPのワーカーを裏で回してるんだったかな
多分同じなんだろうな
時間かかる処理を明示するために時間かかりそうなものは基本非同期APIのみだって言ってるから
まあ裏でスレッドは回してるだろうよ
UIレスポンスを重視してるようだからUIスレッドをブロックするような構造を排除したいんだろうね
>>215 使用できないAPIを使うとちゃんとコンパイルエラーになりますよ。(´・ω・`)
ただし、"identifier not found"のメッセージなので分かりづらい。(´・ω・`)
会社で社員がみんなスマホやタブレットで仕事してる姿想像して吹いた
あり得ん
今のキーボードより速く打てるのが出ないとな。
特定業務向けアプリにいいな>全画面
ダイアログでZオーダー狂わされんのはもうイヤ
WinRTってViewの部分だけ?
全部ある
実は業務アプリに向いてたりして
マルチウィンドウで余計な事されないし
Windows.UI.Xamlってどうなん
DataGridが無いと
InfoQに
Windows 8は、Win32 APIを置き換える
だの
WinRT:Win32のオブジェクト指向による代替
だの
煽り文句が書いてあるから、おいおいどうなるんだよとか思ってたが
要はWin32の上で動作するWinRTのホストアプリケーションの上で動作する
ただのスマホアプリ開発環境か
ハイプもいい加減にしろよな
(苦笑)
>>235 ウィンドウを並べて表示されることは要求されることは多いが
ウィンドウを自由に動かせることに意味があることは少ない
むしろその場合ウィンドウ揃わないとストレスだからAero Snapとかできっちり合わせるほうが見やすいし
MDIだろうがドッキングウィンドウだろうがクールバーだろうが重ねずに並べることが多い
オーバーラップが必要なのはダイアログ程度
そういう意味ではMetroの画面分割は理にかなってるしMetroの場合表示領域内のアプリの入れ替えが簡単
だから分割の自由度向上をだな
241 :
─☆─ [ X | I.I.T. ] COURANT DE CONSOLE ◆TXFAX7cidQpG :2011/09/25(日) 23:37:28.18
>>240 …複数のウィンドウを重ねて表示すると言うのは現実的にはあまり意味がないと言うコトが
分かって来た感じだな。
どうしてもと言う場合はディスプレイをもう1台追加して…と言うコトになる。
やっぱり.NET終了か
>>242 WinRT 上でも .NET が一番使いやすよ。
特に非同期処理。
244 :
─☆─ [ X | I.I.T. ] COURANT DE CONSOLE ◆TXFAX7cidQpG :2011/09/25(日) 23:51:29.02
…前にどっかのHPに書いてたけど、WindowsAPIを中間言語で表現できるフォーマットに統一して
CPUの差異をなくすと言う話。
これによってARMやnVIDIAが互角に参入できる形を作ろう、っと。
この背景はインテルとマイクロソフトが独禁法で潰されると言う懸念を予め排除しておこうと言う
目論見がある。
ただこうなるとマイクロソフトがアーキテクチャを牛耳るコトになるので話半分と言うコトにもなる。
現実的には、古くなって仕様頻度の低い技術や普及しなかったAPIが切り捨てられる。
置き換えはなさそうだよね。メトロ作るためのCOM実装のAPIとサンドボックス化されて他のAPIは呼べないでFAかな
あとMinimum supported client Windows XPって書いてるAPIあるからバックポートするつもりなのか
246 :
─☆─ [ X | I.I.T. ] COURANT DE CONSOLE ◆TXFAX7cidQpG :2011/09/25(日) 23:57:36.13
>>245 …いや、古いAPIを使ってる人たちには、当分の間、ブリッジインターフェイスを経由してそのまま
使えるようにするが、将来的には廃止されると言うコト。
7も含めて終わるかもな。
247 :
─☆─ [ X | I.I.T. ] COURANT DE CONSOLE ◆TXFAX7cidQpG :2011/09/26(月) 00:00:12.27
それとこの、新しいインターフェイスはインタープリター(スクリプト)で動くと言うコト。
中間言語だからそういうコトになる。
>>234 .NETだと結局今までのSystem.*使わないと足りないんだな。
いやJITなんでインタープリタとは違うと思うけど。
250 :
─☆─ [ X | I.I.T. ] COURANT DE CONSOLE ◆TXFAX7cidQpG :2011/09/26(月) 00:07:32.67
>>249 アプリケーションの話ではない。
インターフェイスを動作させる部分を書いてるコアの部分。
251 :
─☆─ [ X | I.I.T. ] COURANT DE CONSOLE ◆TXFAX7cidQpG :2011/09/26(月) 00:10:28.62
…もうちょっと分かりやすく言うと、システムそのものをBASICで書いて共通化させようってコト。
そのBASICに相当する部分が仮想コンソール環境と言うコトになって、CPUの差異を解消する。
253 :
─☆─ [ X | I.I.T. ] COURANT DE CONSOLE ◆TXFAX7cidQpG :2011/09/26(月) 00:15:02.68
>>252 いやいや、MS宗主様はオマエらが嫌いだから遷都して別の場所で豊かになりたいってさw
>>253 互換性をなくすとMSが潰れるのでやりません
256 :
─☆─ [ X | I.I.T. ] COURANT DE CONSOLE ◆TXFAX7cidQpG :2011/09/26(月) 00:17:27.68
>>254 どうせ不正コピーが流行るからそれにあわせて業務もメトロスタイルに変わっていくよw
257 :
─☆─ [ X | I.I.T. ] COURANT DE CONSOLE ◆TXFAX7cidQpG :2011/09/26(月) 00:18:13.90
>>255 互換性は残すけど古い世代に新しいコトはさせないらしいよw
どこのニートだ
>>254 Phoneだってプライベートアプリできるんだから解禁するっしょ。
App StoreのEnterprise何とかと一緒で、企業向けにストアなしで配布できるんだろ。
262 :
─☆─ [ X | I.I.T. ] COURANT DE CONSOLE ◆TXFAX7cidQpG :2011/09/26(月) 00:20:37.46
このパラドックスはWindowsAPIに深く精通した者ほどダメージが大きいと言うコトなるなw
265 :
─☆─ [ X | I.I.T. ] COURANT DE CONSOLE ◆TXFAX7cidQpG :2011/09/26(月) 00:25:39.28
>>263 いちばんダメージがデカいのはIT利権にしがみついてきた連中。
早くこの世からいなくなれ〜♪
なんか目が痛いから、せめてコテの文字数を少なくしてくれんかのう
>>264 OSのコアを置き換えるどころかただのWin32の上のラッパー
サブシステムですらなく、メトロスタイルアプリとは、
いちWin32ホストアプリの上で動作するアップレットのようなもの、というのが正確だな
まあWinFX構想とは比べるまでもない
なんつうか
スマホ・タブレット用にレイヤー足しました的やっつけ感が拭えないのはなぜだ
----------ここまで実コードの話なし----------
別に現時点でコード調べなくてもいいかなと思ってるわw
>>238 違う
WinRTはWin32にあたる部分についても再構築されてるんだよ
全くの新作
>>269 タブレットブームなんて今がピークだからな。おまけ足すくらいで十分だよ。
>>274 「再構築」ってどういう意味で言ってる?
APIのトレースでもして調べたの?
メトロアプリはWWAHost.exeというWin32プロセス上で実行されるし
(多分一種のアプリケーションドメインみたいなもん)
APIとしてのWinRTがWin32の上に乗っかってるラッパーなのは
>>212などに記述されてる
.netもその中でCLRホストして動かすだけでしょ?
WinRT呼び出しはCOM interop、それ以外は今まで通りのライブラリが使える
何も新しくないな
iOSのアプリとか作るのに比べると言語も豊富で色々便利にできてるのかもしらんけど
普通のWindowsアプリ開発(.NETやLLなども含む)との対比で考えると、
単に不便な機能制限版で、特に選ぶメリットが無いように見えるな
サンドボックスの中に入れたいんでしょ。
配布を楽にするのと、フル権限もらうのは両立しない。
>>235>>240>>241 業務アプリなんかでは、ウィンドウ操作の無意味な自由度によって画面遷移を崩されない方がいいからね。
定型業務なら尚更、画面遷移が固定された方がスムーズで不意なミスオペも解消できるね。
Metro Styleがタブレット向けだというならマーケットによる流通は当然の選択。
特に業務用なら光学ディスクは当然としてUSBディスクなども使えるのは困る場合もあるし
282 :
─☆─ [ X | I.I.T. ] COURANT DE CONSOLE ◆TXFAX7cidQpG :2011/09/26(月) 04:06:49.09
…ここにヒントがある。
>271 名前: デフォルトの名無しさん [sage] 投稿日: 2011/09/26(月) 00:34:38.39
>----------ここまで実コードの話なし----------
実コードって言うけど…そう、仮想コンソール環境で仮想コード環境(中間言語)なんだよな。
だからCPUに依存したコードがなくなるというのが仮想コンソール環境の目標なんだろうな。
Windows8の間にどこまで持って行けるかお楽しみってなところ。
>>212 は MinWin や Virtual DLL のことを知ってて書いてるとは思えん。
このクソコテはGoogleからの刺客か
CLRの代わりにWinRT自体がCLIとして動くのかね
>>285 いや、そういう仕組みじゃないから。
WinRT は .NET のメタデータ部分だけ持ってて、
今までの P/Invoke が楽になるだけのネイティブ。
.NET なコード動かすためには、CLR 自体はまだ要る。
しかしWinPhoneはWinCE&.NETCompact?&Silverlightでよくさくさく動くよな。激重になりそうな気がするもんだが
ここには Windows Phone なんて使ってる情弱いないよな?
すみませんWindowsMobile使ってます
WindowsMobileの話なんて誰もしていないから
Windows PhoneはWP7機だけじゃなくてWM機も指すんだがな
Windows7が載っているのは仲間には入れませんか?
それは電話というよりタブレットと呼ぶんじゃね
D4もタブレット扱い
FATなPCでリッチな開発は、空前のモバイルブームで低電力消費のネイティブAPIに方針転換か
AndroidもC++だけで開発できるようになったって
WP7使ってるわ、メインじゃないけど
今や旧Windows MobileもWindows Phoneに改名
298 :
デフォルトの名無しさん:2011/09/26(月) 17:20:19.07
専用のアドレス空間で分けられてるんだからそれ以上の安全性はOSで努力してなんとかするべきだよね
Javaじゃなきゃ安全じゃないとかSunの刷り込みで世の中おかしなことになってる
C/C++で開発するメリットあるの?
デスクトップアプリならwin32と相性が良かったりするんだろうけど
WinRTだと一つもメリットなくね?
>>298 OSが専用のアドレスに振り分けで動作させているんだから
それ以上の安全性は開発者が努力してなんとかすべきだよ。
したくないならC#などのマネージコードで開発すれば.NETが面倒見てくれる。
ん?WinRTのBrokerが危険な操作をガードしてくれるんじゃないの(´・ω・`)?
DirectXってMetroアプリから使えるの?
>>305 へ〜知らなかったよ
DirectXは使えるけどwin32は使えないんだね
boostなんかも内部でWin32呼んでるわけだしほとんどのライブラリが使えないんじゃね?
ほとんどのライブラリが使えない・・・ ガ━━(;゚Д゚)━━ン !!
なんでWin32触れないという話になってるんだ
相当に限定はされてるが、
http://msdn.microsoft.com/en-us/library/windows/apps/br205757(v=VS.85).aspx
ここに書いてあるものは使えるはずだぞ
ごく一般的なところで目に付く使えない関数は
CreateFile(), LoadLibrary(), VirtualAlloc(), CreateProcess(), CreateThread()
user32系全般(CreateWindow()など)、GDI、winsock2といったところ
スレッドは作れないがInterlockedなどの排他機構は使える
また、CreateFile()が使えない代わりにCreateFile2()という関数が使える
多分サンドボックス化のため
メトロ用のCランタイムのfopen()系はCreateFile2()を用いて実装されてるんだろうな
LoadLibrary()が使えないので、「ほとんどのライブラリが使えない」
というのは、ある意味間違いではないだろうな
WinRTに許可された範囲のCランタイム関数やAPIのみで実装されたライブラリを
staticリンクするか、WinRT用のライブラリとして構築する必要があるんだろう
>>299 アンドロイドが仮想マシン上でアプリを作成する上でのデメリットを明らかにしただろ
省電力、アプリの速度に関しては、ネイティブアプリのほうが優位性を示している
>>287 WP 7.0 時代はやっぱりちょっとガベコレの性能悪かったけどもね。
まあ、CF のチューニング甘いのは確かだけど、.NET 自体はそんなに遅くないし。
WP7 も最低ハードウェア要件高めだし。
>>312 あれはGoogle独自の仮想マシンが糞なだけ。
その証拠にWindows Phone 7.5は基本マネージコードだけどAndroidの1.5倍はバッテリー持つよ
>>311 そうすると各ライブラリがWinRTに対応しました!ってのを待ちくたびれることになるのか‥
VirtualDLLはローダー拡張しただけの話で何か実態がわけじゃない
LoadLibraryについては
DLLの関数もメタデータファイルを用意しろということだろう。
呼べないWinAPIを中で使ってればダメなのは一緒だけど。
WinRTってのがそもそもサンドボックスの中に閉じ込められるものなのか、それともビルド設定によってそうなるのか。
WinRTがWin32の後継orデスクトップ向けにも提供されるものなら後者であるはずだが
Win32が使えないのではなく使う必要がないことに気づきなさい
4.8GBのやつが入らないからDPの3.6GB版を入れて、VS2011を単体でインストールしてみた
ApplicationでWinRTアプリを作ってみようとしたら、こんなメッセージが出てきた
Installation of this application requires a Windows Store Developer License or enterprise-qualified client. (Exception from HRESULT: 0x80073CFF)
4.8GBが入るメディアを買ってきて再インストールするのもかったるいんで、動かす方法があったら教えてほしい
はあ?
>>322 ISOの中身展開して回復コンソールのコマンドプロンプトからsetup.exe叩けばメディア要らんぞ
>>320 WinRTはあくまでメトロ開発用。メトロ以外はいままでどおり安心してWin32/MFC/.NETでお作りください。
Metro開発できるのは現状VS2011Express DPだろ
>>326 単体で配布されてるやつだとWindows8にいれても動かんよ
開発できるのは全部入りのDPだけっぽい
>>324 その手があったか
ほかの手段がないならそれでやってみる
実行可能メモリを確保して動的にネイティブコードを生成する事すらできないのか
AndroidNDKの方がまだマシだな
お前は何を言ってるんだ
>>330 最近こんなの貼って喜んでる白痴が大杉w > お前は何を言ってるんだ
本当にわからないの?
VirtualProtect系が使えないから
じゃ不足?
Win32使えよ
白けた
WinFXも同じことを言ってたよね。
二度も釣られた・・・
全く逆のことを言っている
笑えるのはどっちも今月の記事だということだぜ
結局Metro用ライブラリなの?
最初からそれは一貫して言ってるだろう
ARMにWin32全部載るってのも早漏の飛ばしだろ
ゲイツ先生はソフトウェアの保守コストがかさむのをとにかく嫌うから
Win32の他にWinRTなんて二つもやるわけないわ
大して意味ないし
つ.NET
どっかのGoogleみたいにいいかげんなもの乱発して
すぐ放置したり切り捨てたりするところとは訳が違うからな
今回はそうなるよ…
まともにサポートポリシーあって10年くらいサポートしてくれるのはMSだけ。
カーネルとドライバは使い回せたけどな。
>>344 一番最初にMSが公式に発言しているよ。
完全なWin32 APIが載るからフルスペックのMS Officeも動作するってね。
大丈夫。どんなにクソでもJ#程度にはサポートしてくれるはず
ん?今どっちをdisってるの?
WinRT にかけてる本気度かなり高いよ。
WinRT がいいというよりは、本気で Win32 の保守に疲れてる。
お前の気持ちかMSの気持ちわからんぞw
Vistaや.NETも、当初計画ではWin32やCOMを捨て去る計画だったからね。
レガシー呼ばわりしてたCOMでWinRT作ってんだからおもろいよな
COM は結局、.NET のメタデータ自体が COM みたいなもんだったけども。
Win32 は隙あらば消したがってる。
今回は、WinDiv(C++ 好き)とDevDiv(.NET 好き)の対立もないしねぇ。
まさかこんなオモチャでWin32消せると思ってないだろMSは
こんなお子様仕様で普通のPCアプリがどの程度「メトロアプリ」になると
思ってるんだ
まあ、今すぐ消せると思ってたらさすがに頭おかしいと思う。
投資バランスを徐々に変えて、新機能の追加を凍結 → サポートのみ → それからやっと排除でしょ。
5年10年覚悟じゃないかな。
というか、WinFX の時からすでに Win32 消す算段立てて、
.NET で培った経験と、WinFX 失敗の反省踏まえてようやく WinRT があって、
すでに5年越しか。
そこからさらに5年10年よねぇ、きっと。
タブレット用にWin32に依存しないの作って、
徐々にデスクトップ用でそのアプリが動くようにすれば良かったのに。
この仕様だと、はっきり言って7にもWinRTやメトロはバックポートできそうに
見えるんだがな
>>357 Vistaは.NET 4.5で捨て去られたぞ。
Win32 廃止が冒険なことはわかってるし、
まず手始めに、出遅れててどうせいろいろ作り直さないといけないタブレットをターゲットにしただけでしょ。
デスクトップ向けな WinRT も将来的には考えられるかもしれないけど、
まず第一の投資先がタブレットだっただけ。
機種依存性無くすのが狙いなのに.NETじゃなくCOMを選んだのは
やっぱりパフォーマンスの問題なのか?
機種依存よりは、App Store経由配布のためのサンドボックスの方が目的だと思う。
機種は、CPU に関してはパッケージ中に x86, x64, ARM バイナリ全部入れろってので今のところ対応可能だし、
Phone と比べると機種固有のペリフェラル使う用途多いだろうし。
WinFX が成功しなかった理由、やっぱりパフォーマンスによるところは大きいはずで、
WinRT が COM なのはやっぱそこだと思う。
あと、WinDiv(Windows 開発部門)が C++ 好き。
.NET の中で重要な点は、CPU 独立である部分よりも、むしろ、
メタデータによるプログラミング言語中立と、サンドボックスによるセキュリティだってことかと。
369 :
デフォルトの名無しさん:2011/09/28(水) 02:34:53.01
なあに.NETを捨てるわけじゃないさ
一段落ついたところで別のに取り掛かったということだ
さらに厚みを増してきたWindowsから目が離せそうもないぜ!
>>371 J++は、Visual Studio とC#の基礎。
Java開発環境として優れていたため、最終的にSUNのVMを使う場合でも、開発ではよく使われていた。
今じゃ完全に死亡扱い受けてるものも、何かしら成果としては今の製品につながってるよね。
まあ、今はサポートの話してたはずだから、切られてることには変わりないけども、
J++ の場合は大体の開発者 C# に移っちゃってるし。
374 :
─☆─ [ X | I.I.T. ] COURANT DE CONSOLE ◆TXFAX7cidQpG :2011/09/28(水) 09:59:49.77
そんなにコロコロ変えてたら馬鹿になってしまうぞw
あなたとの出会いは無駄じゃなかったわ、とかガキみたいなこと言ってんじゃねーよ
376 :
デフォルトの名無しさん:2011/09/28(水) 11:06:30.57
C++でメトロアプリ作っても、WWAHost.exe上で実行されるのですか?
>>364 コストを無視すればWindows98にだってバックポートできるだろうけど
>>376 WWAHostはHTMLアプリだけのはず
WinRT向けに書いたGUI以外のコードを.NET4で再利用するためのライブラリ作成中なのか。気が早い。
だいたい一緒なんだから #if WINRT でいいよそんなもん
WinRTをWindows7で使える日は来ると思う?
>>382 メリットなくね?
今現在、タブレットの方に開発リソース裂いてて、
かつ、これだけ Win7 タブレットが売れてないと。
>>383 XAML & C++で開発できるってメリットが個人的にすごく魅力的
C++じゃないよ
C++/CLIっぽい独自言語
C++を拡張したもんだからC++だろ!
部分的な拡張は構わんよ。
VC++だってC++の拡張だしな
C++/COMか
だっさw
同じメトロなのにWindowsPhoneとWindows8でポータブルに作れないのか‥
もう腐敗臭しかしてこないな
M$も収拾不可能になるなw
つ[HTML5]
>>388 それはATLをまともな構文で糖衣したものになるので魅力的。
Win32 MFC WinForms WPF Silverlight WinRT
どれ使えばいいんだ
好きなの使え
そんなアナウンス現時点ではない
数行書き換えるだけで動作するぐらいには互換性が取れているけど
>>392 Win32用のATL/WTL開発にも使えるのか?
そうならWin32プログラマも喜ぶかもしれない
COMのテクノロジーによって
インターフェイスが実装とべったりくっついてしまってる
Win32を置き換える、とか昔言ってなかったっけ?
ソフトは増えたけど目的はいつまでたっても果たせませんね
>>393 WinXP以降で使えて
ネイティブで軽くて
優れた設計のAPIはどれ?
>>400 COM自体は、Win32からは独立した別のものだろ。
>>401 XP以降で使えるのは
Win32 MFC WinForms WPF Silverlight WTL
さらにネイティブ限定だと
Win32 MFC WTL
優れているかどうかは分からないが
ナウい設計なのはWTL, MFC, Win32の順
ネイティブなんてものに拘らなければ.NET Frameworks。
メモリ周りのネック部分をunsafeすれば速度的な問題もだいぶ改善されるし。
unsafe使うくらいなら
最初からC++でやった方がましぽ
んなこたーない。
開発効率はまだWinFormsが最高かな。
WPFは思っていたより効率上がらなかったけど
WinRTはまだマシなんだろうか。
たかが数行のボトルネックのためにいちいちC++なんか持ち出さなくて済む
APIが非同期だらけになるんだろ
.NETはasync入るからいいけどC++なんかクソ面倒臭そう
WinRTではCは切り捨て?
どうせAPI呼び出しにはC++ですらない言語を使わないといけないので
条件はCも同じようなもん
>>409 大丈夫、C++がクソ面倒なのは、そういうもんだと我慢して使うものだから大丈夫。
まあ、C++ も C++11 でラムダ式入ってるから多少楽。
ラムダ式の書き方が冗長すぎて泣きそうになるけど、C++はそういうもんだから大丈夫。
>>412 それはさすがに土俵違うだろ。
白黒な代わりに軽量でしょ?また。
俺もWinPhoneのSilverlight開発はつなぎで、いずれWinRTに統合されると思ってるよ。
で、Silverlightはブラウザプラグイン&メトロでいらなくなり終了と。
そうするとモバイルデバイスで.NET動かすなんてバカな設計も片付いてかなり開発環境はすっきりするな
自分が習得した技術がゴミになっていく
だってお前もゴミだからしょうがないよね
>>415 WPはSilverlightが亡くなってもマネージコード オンリーなのは変わらないと思うぞ
>>409 C++も次Beta版から非同期用構文が導入される予定
>>419 ?
AMP のこと言ってる?
あれ、全然違うよ?
むしろWinRTとWPFとSilverlight間では知識を結構共有できると思うが。
XAMLだし
>>421 なんか、1行でも書き換えが発生するものは別物だと思ってる人がいたり、
名前だけで判断してる人がいるみたい。
>>422 SilverlightとWinRTじゃまったく別のコード書く必要があるけどね
知識っつてんだろおおおお
BCLはだいたい一緒だよ
GUIなんか環境が全然ちがうんだからAPIに互換性あったとしてもどうせ作り直し
プログラマー自体が交換可能の互換性のある部品だからなにも心配することはないぞ
でも、新品プログラマーは互換性に難のある部品だからな・・・
そして互換性ができた頃には別の新品プログラマーと入れ替えw
>>428 新しい技術はおっさんにやらせるより、若手にやらせた方がはるかにまし
うちの画面開発のオッサン共はMVCという単語すら知らないのどうにかしてくれ。
こんなやりづらい職種もないわ
普通は年取れば熟練すんのに
COBOL みたいな息の長い技術を身に付けないから。
なんだかんだでC++とかその周辺は長く飯が食えてるな。
Web系に行ってたら寿命は短かったろうな。一発当たったかもしれないけど
Flashとかってまだ仕事ある?
正直、COMがここまで息が長いとは思わなかった。
>>432 後発者利益なんて言葉、他の業界じゃありえないよね。
他の業界も、過去、急成長期にはこんなのだったのかねぇ。
.NETでCOM終わったと言ってた人たち今頃どうしてるんだろう
そもそも.NET出てもCOMコンポばんばん出てたし今更だろう
みんなwin8でしかつかえないWinRT使うの?
このスレを見ても分かる通り皆様子見
googleでメトロの求人検索したら山ほど出てくる
今すぐ始めるべき
わろた
そんな使い捨て求人に群がるほどの買い手市場
落ち着け。これはそのう、そういう笑い話ではなくてな
>>438 昔の COM の書くのがたいへんなのは復活してないし、別にいいんじゃない。
CoCreateInstance とか ComPtr が面倒だから消えてほしかったものであって。
>>446 報告すれば直してくれるだろうけど、今はまだベータ版以前なので細かい部分まで実装が行き届いてないかと
個人的にはCOMなんて消えてほしい
COMと.NET系列との相性が悪すぎる
excelとか呼び出す場合、変な風に扱うとゾンビプロセス化してしまう
.NET 世代で育った人間なんで、あのアウトプロセス COM はほんと意味わからなさすぎる…
でも、WinRT って、COMベースだけどそのあたりのどうしようもなさの解消目指してるんじゃないの?
adobe の人間なら、もっと上手く構築できたんだろうけど、MS 様ではなぁ・・・
adobeはflashでバグ出しまくってるじゃん
COMは、難しいけれどもWindows というより、Microsoft の競争力の源。
>>452 あれ、ほんとに Macromedia 買収したのよかったのかねぇ。
バグひどすぎて頭抱えてるんじゃなかろうか。
Flashとか世のブラウザを落とす原因の八割(体感)だし脆弱性の元にもなりまくってる
Macromedia由来じゃないReaderも同様だし
Readerを初めて使ったときは
あまりの重さに絶対はやらないと思ったのに。
>>451 アホすぎ、adobeのソフトってひどいのばっかじゃん。
大量♪w b(^o^)
たしか、情弱性とかいうのを突かれるんだっけ?
これ書いた人.NETわかってないんだな
>>463 462 とは別人だけども…
うーん、なんだろ。
とりあえず、命令のネイティブ/マネージの差と、メタデータの概念を区別できてないかな。
COMベースって言っても.NET側から見たら.NETオブジェクトにしか見えない(本気で区別つかない)し、
Win32APIは低レベルであり.NETも同様っていうくだりが酷い
XAMLがWPFの一部っていうのはどうなんだ
まあ、今回、BUILD は事前情報の箝口令ひかれてて唐突に大量の情報出たのと、
かなりガチで開発者寄りのイベントだったいせいもあって、
記述わかってる人とわかってない人の差が残酷なまでに記事に表れてるよね。
ちょっと面白い。
×記述わかってる → ○技術わかってる
.NETベースで作ったCOMのMarshal.ReleaseComObject周りのうまいやり方見つかったのかな。
COM側をGC任せで問題ない(解放の順序、タイミング、スレッドに依存しない)ようにしておけばOK
>>464,465
全然間違いを指摘できてないのな
.NETのAPIは低レベル過ぎて面倒とか聞いたことあるの?
逆はともかく
.NETはむしろ低レベル触ろうとしたらP/Invokeいちいち書かなきゃいけなくて面倒
>>464で指摘されてる事以外はだいたいあってるじゃないか。
>>471 DirectWriteやDirect2Dを触るのがめんどくさい
その手向けのアセンブリはあるけど、IDWriteTextLayoutにCutomTextRenderを渡すことができないからいちいち定義して、IntPtrにキャストしないといけない
>>464 IMEを触るにはTSFを触れとさらっと書いてあった
.NETからTSFを利用することは事実上できない
IME周りは終わったな
> .NETからTSFを利用することは事実上できない
普通にできるって。
NyaRuRuちゃんが昔ラッパー書いてたよ
もともと.netにちゃんとしたAPIが提供されてないものを持ち出してもな
少なくとも.netで普通に使えるAPIに関してはWinRTより低レベルとは言えないでしょ
DirectXはC++からしか使えないからもっと面倒になるし
.idlはあるんだから、ちょっと修正して.tlb作ればいいだけだし。
ITfThreadMgrEventSink、ITextStoreACPを実装するのはnyaruruちゃんのやつでも無理だったような…
>>478 DirectWriteやDirect2Dのidlはあったっけ?
なかったような記憶があるんだが
.tlb作れ、ってのは、TSFの話ね。おれはDirectXはほとんどやったことないから知らない。
「ちゃんとしたAPIが提供されてないもの」っていったら、ほぼすべてのCOMが使えない、
ってことになっちゃうでしょ。
481 :
デフォルトの名無しさん:2011/10/02(日) 23:02:24.65
.NETからCOMを直接利用する時のAPIが低レベルで困るのは、
.NETのAPIが低レベルかどうかと何か関係があるのか?
.NETに用意してあるラッパーを使うなら別だが。
という話なのではないのですかね?
.NETのAPIに低レベルな物が用意されていないからCOMを直接利用するさいに困るって話でしょ。
ならそう書けって話でしょ。
元の記事を.NET知らない人が読んだら10人中10人が.NETのAPIが低レベルなんだと誤解するよ
.NETが低レベルAPIかどうかとかオレオレ定義論にしかならんだろうに
>WinRTは、より高レベルの独自APIを提供する。
>例えば「Media Capture」は、静止画撮影だけでなく動画などの撮影やプレビュー表示、撮影後のトリミングといった関連機能を提供するライブラリオブジェクトだ。
多様な機能を提供するライブラリを高レベルと評するのであれば、従来のWin32や.NETは低レベルだろ。
WinRTにはCreateFile2みたいなWin32レベルのAPIもあるんだしどっちが高だの低だの言ってもしょうもないだろw
低レベルの定義も知らんのかw
んなもんねーよカス
間をとって.NETは中レベルということでひとつ
下流で低レベルのコード書いてます
心底どうでもいいわ
WinRTを使ったアプリってWindowsフォルダの中のどれがそうなの?
>>492 \Program Files\Applications
\Applicationsに仕切りなおせば良かったのに
PureJava的なクロスプラットフォームやデスクトップLinux全否定か
もっともだけどぶっちゃけすぎ
Windowsの個々のソフトウェア割り込み番号を解説したドキュメントとかありますか?
int **の**の数字の意味です
sysenterしか使ってないの?
int 20h
int 21h
DOSのでよければ分かるけど・・・
ブレークは何だっけ
INT3?
いやしかしメトロの四角いボタンが並んでるだけみたいなションボリGUIじゃこの先勝負していけるのかと思うよ
手抜きUIで開発効率UP
品質は同等に手抜きできる技術が一番素晴らしい
511 :
デフォルトの名無しさん:2011/10/09(日) 19:09:27.82
>510
Silverlightからできることはそんなに減ってないはずなので、
その動画に出てくるような操作はできるのではなかろうか。
画面上に自由自在にいろんな情報を並べるとか、
操作するたびにアニメーションを付けるとかはできるはず。
ただ、できるからと言ってやりすぎると操作しにくくなるからなるべくやらないように、
と言っているだけだと思う。
別に、地味なことしかできなかった時代に戻すと言っているわけではない。
>>510 それぐらいActive DesktopとVista以降のガジェットで実現できてるでしょ
作ればできるだろってw
そりゃ作ればなんでもできるだろ
簡単に作れるかどうかは大事なところ
1年半後に出るメトロが現在のAndroidにすら劣っている件
しかしこれほど消費者・開発者共に期待されてない感が半端ないのは久しぶりだな
517 :
デフォルトの名無しさん:2011/10/09(日) 19:59:57.38
Active DesktopとVistaのガジェットはHtml+Scriptで超簡単だけどな
Windowsはデスクトップ見てニヤニヤするようなOSじゃないから凝ったことしても無理
タブレットもガジェットもMSが過去に失敗した分野
そこで他社がうまくやったわけだから、なんとも歯がゆいんだろうな
おまえら、メトロのボタン押しこんだらどういうエフェクトかかってるのかも知らんのか?
観察眼がないな
観察しないと使えないの?
観察眼が無いと分からんようなもの一般人の目に入るかって話だ罠
ホントそう
目線がユーザーじゃねえよ
ガラスマもそんな感じで、なんでiPhoneが作れねえんだとか言ってるけど
.NET FRAMEWORK Mobile Phone Profile
みたいなわかりやすいのにしてくれればいいのに
525 :
デフォルトの名無しさん:2011/10/10(月) 14:33:25.02
自分自身が使いやすいかどうかも観察できんのかバカ、
とかいう意味ではないですかね?
少なくともしょんぼりGUIとか言っている人はそう。
押したときの感触とか全然違うだろうに。
というか、
>>510の動画がいいと言ってる理由が分からない
どうみても個別でまとまってないから、情報見るだけのレベルで結局個別にアプリ起動せざるを得なくないか?
とりあえずそのデスクトップに張ってあるショートカットを一元化するのがあればMSだろうがAppleだろうがGoogleだろうがどこでもいい
>>510 キーボードから手を離してマウスに手を伸ばすだけでメンドクサイのに、画面を触れだと?
タブレットPCにキーボード付いてるの?
529 :
デフォルトの名無しさん:2011/10/10(月) 21:48:22.61
それはタブレット作るメーカー次第じゃないの?
OSにはスクリーンキーボード付いてるし物理的なキーボードは無くても何とかなる
スクリーンキーボードだと画面が狭くなるのが欠点だな
人間の手を機械にすれば解決。
532 :
デフォルトの名無しさん:2011/10/10(月) 22:26:53.63
>>530 まあそもそもタブレット+スクリーンキーボードってビューワー用途向けみたいな物だからな・・・
パソコン大先生はマルチタッチ液晶持ってないからwin7やwin8でタッチしたらどうなるか知らんのよ
だからどろいどすげーって言っちゃう。かわいいよね
Androidに嫉妬するスレか
AndroidなんかUIフレーワークも開発環境もXAMLとは比べ物にならんぞ
WinFormsよりWPF面倒とか言うのとは次元が違う糞さ
結局シェアが全て
というほどMSの開発環境にアドバンテージはないだろうに。
SilverLightに集客力はないし
名前を間違えるような奴に言われても…
MS信者あわれだのう、みじめだのう
結局、win32製のライブラリってこと?
>>539 Previewの実装としてはそう
仕様上はそうではない
RTMではどうなってるのかねー
正直
>>510を見るとメトロは見劣りはする。今後のガジェット類の強化に期待だな
VB6でメトロは作れますか?
もちろん必要に応じてtlbは作るつもりです。
Windows8上のVB6動作が保証されたらまたここに来てください。最高の返答をいたしますよ。
COM呼べるんだから最悪でも他の言語でホストしてやればできるだろ
Windows8でVB6が動くなら、だけど
動かした人はいるから動くのだろう
絶対とはいえないけど
お前らのVB6は動かない前提の話にワロタ
まぁあながち間違ってないが…
もしかしてOCXが何も使えないVB6が動くんじゃね?
間違ってないのかよ
ランタイムがはずされることはあっても、動かないはないだろう。
ランタイムが無きゃ何もできんだろ
vbvm6.dllと、vbrun.dllだっけ。
それがあれば最低限のところはうごくんじゃなかったっけ
VB6ってwin9x/NT4/NT5/NT6の移植に耐えたんだろ?
コントロール群はともかく、コア部分がいまさら動かなくなるとは思えんのだが。
Windows8でも動かすだけなら可能だろうがVB6でメトロは実用的レベルでは無理だろ
もちろん無理矢理なら仮想マシンとかプロセス間通信とかいくらでも方法は思いつくが
そもそもMetro Styleで(従来の意味の)COM interop使えるの?
使えないならVB6がWin8でサポートされてもMetroなんか絶対無理でしょ
でも仮にMetroからCOM使えたとしてもVB6のUIをMetroに統合するのは無理だろうからほとんど無意味か
そういうの関係なくてもうVB6使うのはいい加減やめてほしいっていうのが本音
>>555 WinRTは普通のCOM経由でラッパーかませずに使えるんじゃないの?
スレ斜め読みの想像だけど、いろいろ制限つくらしいから内部でWin32と排他的なサブシステムになってて、
VBランタイムが読んでるWin32APIと競合して不具合出たり、manifest的なものをリソースに埋め込む必要があったりで結局ダメになるんじゃないの?
俺の理解正しい?
一応動くってのはARMでも動くのけ?
559 :
デフォルトの名無しさん:2011/10/13(木) 14:32:43.06
exeやらdllやらのヘッダ部にサブシステムを指定するところがあるから、おそらくそこからして違うんじゃないかと思った。
つまりまた新しいコンパイラを買わされることになる?
コンパイラなんかMSがタダで配ってるだろ
当然VSは新バージョンで対応だろうから事実上は買わないといけないが、それは今までの.NETもそうだし
無料のexpress版も提供されるだろ
なんかVB6が人気だなw
開発環境はすでにサポート終了しててランタイムのみがなんとか残ってるから動けばラッキーって状態…
んですでにサポート外で動かない or 動作が異なるコンポーネントとかもあるし、それらをムリクリ動かす必要があるのかもわからん…
なんで『あながち』間違ってないとは書いたんだよね
Win8でやっとランタイム外せそうだし、サポートされた開発環境もないからMetroも無理かと…
VBAのついでに動くだろ
VBAがJavaScriptに置き換わるのはまだか
サブシステムからして違うんじゃmetroは無理ってのはわかった。
そうなるとVBSが有望じゃないか?HTAのmetro版みたいなものは当然出してくるでしょ?
いいかげん諦めてVB.NET使えよ…
ActiveBasicみたいのだったらわりと楽勝で対応してきそう
おっさん的にはC++/CXに失望した。
MSってほんと非標準拡張大好きだな。
だがもしC++/CXの拡張が全て
#defineによるものだとしたら・・・
COM丸出しじゃ使い物にならんだろ
だからって特別にラッパー用意したりしたらWinRTのコンセプト丸潰れ
COM丸出しが好きなんだよ
HRESULTチェックの重厚なリズム感が好きだった
VBとかDelphiと同じになってしまうのは残念
なんかWindowsDNA時代のATL/COM大好きレガシーおっさんがいっぱい復活してきそう。
.Net厨が余裕で駆逐されまくる展開を予想する。
レガシーおじさんワロタwwwww
574 :
デフォルトの名無しさん:2011/10/14(金) 07:43:02.90
スプーンおばさんは知ってるけど
レガシーおじさんは知らなかった
COM復権が決定的になったんだから、Windowsで飯食うならレガシーおじさんにまずおいつかないと。
レガシーおじさんは拡張切って使えばいいよ
>>568 マクロ実装 = non-contextualキーワード = std::ref爆死
だからダメ
以前gcc拡張がマクロ実装で同じようなことやってboost使えなくなった前例もある
COM例外が普通の例外みたいに扱えるようになってしまうん?
勝手に例外スレッドが走っちゃったりするの?
だとしたらC++でやる意義がよくわからない。
レガシーおじさんは今時のヌルいプログラミングスタイルを受け入れらないんだな
>>577 ネタだってばw
レガシーおじさんもそろそろヴィンテージおじいさんになる頃だし
老後の趣味に良質な国産フリーソフトを生み出してくれ。
わかってないなぁ
今の時代一番金になるのはレガシーだし
せっかく中国・インド人から隔離されてたのにCOM復権とかされるとむしろ困る
DOSやWin3.1のドライバ書けたりするとお金稼げるの?
うちは稼げるよ。FA系だけどレガシーで難問抱えまくってる。
超古い仕様のメモリーカードのドライバ書くとか
割り込み使ったfor文ロックだらけのタイミング勝負の通信コードを保守するお仕事とかいろいろある。
C++でCOMプログラミングできたら高給とり。
>>583 FA系ってほんとレガシーだよなw
PC9801の修理した中古が売れるとかもうねw
レガシーおじさん:C++でコンポーネント書き
安いPG(オフショア含む):HTML・JSでそれらを使うだけ
中堅:.NETでこれまで通り
完璧だな
>>585 しかもそれが原発で動いてる。これマジ。
>>586 レガシーおじさんはいままで冷や飯食わされてたからドトネト厨を目の敵にすると思うよ
たぶん容赦なく潰しにくるはずだから俺はErlangで対抗する
受け流す
C++/CLIが世に出た時も.NET開発の主流になるとか言われてたな
原発で最新のパソコンなんか使われてる方が怖くてたまらない
HTML + JS + 独自css filterでMetro UIエミュレーションできないかな。
何がやりたいかっていうとHTAでMetroもどき作りたい。
単体じゃ機能的に限界があるだろ
COMコンポーネント作ってもいいけど、そんなことするくらいなら
HTAやめてC#やC++でHTMLをホストしてやったほうがスマートだと思う
>>593 HTMLをホストって、IEコンポーネント乗っけるってこと?
IViewObjectやIHTMLRendererで重ねレンダリングするってこと?
HTAにSilverlightのっけようぜ!
SilverlightならHTAなんか使わんでもout of browser使えば単体で動くぞ
権限昇格で好き勝手やれるし、中でhtmlホストするのも
その中で動くJavaScriptからC#のメソッドを呼び出したりも簡単
VSとか使い始めちゃったらHTAでやる意味ないじゃん
メモ帳でぶりぶりっと垂れ流せるのがいいんだよ
ぶりぶりっと垂れ流すにはCOMはだるいしUIもいらん
スクリプト言語でいいわ
やっぱりVB6が最強だわ
2003年頃かな。VBマガジンの裏表紙でほんとにあったMSの広告。
中心にはアンモナイトとか恐竜とかの絵が描かれていて
でっかく「進化できないものは、生き残れない」って煽ってた。
あれはまじで吹いたからもう一度見たい。どこかで見れないかな。
VB6の政党後継版マダ?
VB.NETがあるだろ
VB.NETは.NET1.1の機能でやめとけば初心者向けとしていい言語だった
今じゃ劣化C#
SmallBasicでも使っとけ。
VB2005はMyとかデフォルトインスタンスとかVB6erにとって使いやすいように独自に頑張ってただろ
その後は方針が変わって完全にC#に隷属してるけど
>>610 そういう安直な機能を満載する方向に進化すれば良かったのにな
言語機能を増やせば初心者にはとっつきにくくなるなんて当たり前のことがなぜわからなかったのか
初心者のために機能を削るとかやっちゃダメ。
昔、素人は VB、プロは C++ みたいな二分論、
VB から C++ に移行できない = ずっと初心者使いされる開発者が山ほど出て問題だった。
向上心ある奴ならC++やC#勉強するっしょ
お金のために好きでもないのに必死こいてVB覚えた開発者なんか
機能増えたらついてけなくてコード読めなくなっちゃうじゃん
たとえばラムダ式とかプログラム好きじゃない奴には完全に不要な機能だよ
メソッドとしてならラムダ式あれば楽に書けていいじゃん。
なにも難しくないだろ
そんなにプログラムを書きたくない奴こそラムダ式を覚えてLINQ使うべきだと思うが
使ってて恥ずかしくなったり劣等感を感じたりするような言語にするべきだったな
>>613 しなかったんだよ、90年代の現実として、そういう人らは。
別にそれで、勉強しなかった当人だけが困るならいいんだけど、
「VB の方が使える人多いから」って理由で、VB を採用するところ多かった。
>>614,615
そりゃわかってる人間はLinqでガリガリ書いたほうが楽だよ
でもPG向いてない人らは書き方が2つ以上あると混乱するんだよ
>>618 2つ以上で混乱するなら LINQ のほうだけでOK
ループ使った書き方が理解できない奴がLINQ使うとか恐ろしすぎるわ
再帰見せたら一体どうなっちゃうのやら
現実問題、再帰処理覚えるよりのらくら規定数の製造片付けて家族と遊ぶ方を選ぶ奴が大半なんだわ
奴らだってやってやれない訳じゃないんだろうがね、ぐぐって得たサンプルコードは自在に料理するし
目の前の安仕事を上手く片付けるのは得意だし口も上手いし人付き合いも上手い
くそったれ
>>620 コレクションを扱うための概念としてはLINQの方がより直感的書けるだから
ループより先に習得してしまうこと自体は別に変でないと思う
ループが理解できないってこたないと思うが
訂正 × 直感的書けるだから
○ 直感的に書けるんだから
実際ループが分からないからLinqしか書けないという人は居るから困る。
早いところこんな外注は切りたい。
むしろそんな外注に頼んでしまった
自分のアホさ加減を困った方がいい
単純に能力だけで外注選べるなんてことはないがな
能力だけが基準じゃなくても
能力0の奴に頼む必要ないよな
>>628 前いい仕事した外注にまた頼むとするだろ?
そしたら新人割り当てられたりすんだよ
PGの外注なんて下策だわ
おとなの事情って事もあるよなw
ループが書けないってネタだろ
LINQを使いこなせない奴の僻み
LINQってコレクションに対するループの一種だろ
ふらっとかと思ったらWinRTスレだった。
低レベルの釣りは向こうでやれよ
VS11のC#プロジェクトrで
DataGridコントロールやChartコントロール使えた人いる?
DataGridは.NET4で正式採用されたのに
まさかRTでは使えなくなったのか?
使えなくなったも何もWPFやSilverlightとは別物なんだから
そりゃ新しく作ってないなら使えないだろう
タッチ操作に向いてないし
Metro AppからDesk Appの実行は無理?
コンソールアプリをキックして、そいつのExitCodeを
取得して条件分岐したいのだが。
無理だとしたらDLL化すれば良いのかなぁ。
DLLはこれから勉強だからパパっとは
作れない。。
637 :
636:2011/10/26(水) 16:07:35.89
ひとまずcppでのDLL化と、WPF4でのDllImportは成功。
でも、同じようにVS11のC#で記述しても
やれDLLファイルが見つからないだの、
やれアクセス権がないだので開けない。
■やったこと
1.ReleaseフォルダーにDLLをコピーして、
DllImport("hoge.dll")
→ファイルが見つからない
※WPF4の場合はこれでokだった
2.DLLをCドライブ直下に置いてフルパス指定
→アクセス権
3.System32にコピーしてフルパス指定
→アクセス権
4.ライブラリにコピーしてフルパス指定
→アクセス権
どうすれば良いの??
>>637 DllImportはappx内のリソースならできたはず。(´・ω・`)
Releaseフォルダーにファイルをコピーじゃなくて、
VSでAdd Existing ItemでDLL追加 → プロパティのContent = True で試してみて。
Metro は WinRT がランタイムだから Win32 で作った dll とかはつかえないんじゃない?
>>636 Metro <-> Desktop 間の連携は無理。
>>640 MetroスタイルでサポートされるWin32 APIのみ使ってるのならばおkですよ。(´・ω・`)
>>638, 636
ありがとうございます。
Desktop->Metroも無理なんですか。
Desktop AppぽいVS11からMetroを実行できているから
どうにか方法があるかなと思っていたけれど。
これってソースあります?
>>639 VSでDLL追加したら、DllImportは通ったみたいです。
追加したDLLのプロパティを見ても、Content = True とできる
ところはありませんでした。
また、DllImportはできているっぽいですが、別のエラーが出ました。
---
Managed Debugging Assistant 'PInvokeStackImbalance' has detected a problem
in '******.exe.'
Additional Information: Acall to PInvoke function '****' has unbalanced the
stack. This is likely because the managed PInvoke signature dose not match the
unmanaged target signature. Check that the calling convertion and parameters
of the PInvoke signature match the target unmanaged signature.
---
>>640, 642 さんの会話が原因かなと思いましたが、
Managed Debugging Assistant 'PInvokeStackImbalance' has detected a problem
などでググってみると、それ以前に問題がありそうな気がしました。
が、まだよく分かりません。そろそろWinRTスレと関係なくなってきましたかね。
645 :
644:2011/10/27(木) 10:23:33.51
cdecl指定したら、エラーが無くなりました。
.NET4以降ては、明示的に指定しないと駄目なんですね。
お騒がせしました。
monoからMS製のWPFやMetroのGUIは呼べるのか?
MS.NETが使えないからMono使うんだろ?
何を行ってるのか
649 :
デフォルトの名無しさん:2011/10/30(日) 10:54:46.39
WPは現状、自分で作ったアプリでさえ実機に自由に入れられないのがなあ・・・
開発しやすくするためにもChevronWP7には頑張ってほしい
メトロもそうなるんだろ
なるよ
これでWindows 7がXPの後継、次の10年間のOS確定
このスレにもXPの後継だとか10年だとか言うアホがいるとは思わなかったわ
まともな人は2chの隅の過疎スレなんて見てないよ。居るのはプログラム書けない変な粘着だけ。
2chみたいな知識の蓄積のない書き捨て掲示板に来ちゃう情弱だしな
>>654,655
つ鏡
と思ったら俺が写っていた。
何を言っているかわかry
真面目な話、ペアレンタルコントロール機能みたいなの付けて、
エロ専門の板を閲覧不可にできるようにしたら、審査通るのかね?
審査でたまたま見られたスレにエロ画像貼られてたらアウトなんじゃね
MSがVB6を超える物を作り出せていないのが問題なんだよね
.NETは超えたじゃん、アホでもWinアプリ作れるようになった
つーかVB6がアホ
VB6って.netにコンバート出来ないほど別物なのかい
コンバーターは.NET1.1からついてたよ
俺は使ったことないから性能は知らんが
>>663 ソースはできても人間がアップデートされない
C++/CXって正式な読み方なのか
VS2008添付のコンバーターでVB6からのコンバートをしたことがあるが、
コンバートして終わりってわけにはいかなかった。
やってくれるのは単純な置き換えぐらいで、仕様の違いからコンバート
出来ない部分が多数あった。
そういう部分についてはソース中にコメントを挿入してくれるし、
変換できない理由やオンラインヘルプの参照箇所をまとめたレポートも作ってくれる。
それ見てどうするかは人間次第。
話だけだとM$十分頑やることやってるな
>>665が至言か
うちのクソVB6プログラマをC++プログラマにコンバートしたい
余計ひどいことになるだろ
VB6ではできるが、VB.NETではできないことが多すぎる。
人前でうんこしてはいけないのは当然ですよね
673 :
大便:2011/11/03(木) 17:52:20.57
VB6は犯罪です。
早速警察に通報しました。
ActiveX EXE
どっちも微妙に違う。
ActiveX EXEはただの手段なんだから
あんまりこだわっても仕方ないだろ
COMから見ても、.NETから見ても、違いが大きすぎ。
VB6に拘ってるやつは手段が目的になってる。
VB6に対抗できるのはDelphiぐらいしかない。
つまりC# + .NETですね
QtもWinRTもJavaScript採用してるけど流行ってるの?
ブラウザ高速化のために使った労力を有効利用しようぜってかんじ?
全然流行ってないよ
JavaScriptなんか10年前から.NETで使えたよ
>>683 HTML かけて、JavaScript ならわかるかもって勘違いする開発者を拾い上げるため。
どうせ、なにこれ難しいやっぱりMSは糞、とか言われて離れていきそう
アプリさえ揃えばMetroでもいい、あるいは従来のウインドウインターフェースより
Metroのほうがいいって人って、世の中の何割くらいなんだろうね。
AppStoreへの地ならしだろ
Aeroどころか、Lunaですら使わずに、未だにWindowsクラシックで使ってるやつもいることを
考えると、それほど多くない気がするなぁ。
スレートでオールドデスクトップ使うのがめんどいのはわかりきってる
スタイルとしてはC#で書いてMVVMでビジュアルだけ乗せ換えるのが妥当なんだろう。
メッセージの上にメッセージが飛び交う2階建てになるけど、
フレームワークさえ守ってればむしろ今までより楽だろう。業務ソフト開発の場合には。
基本的にCOMだからそりゃデスクトップでも呼べるんじゃないの。
でも、UI部分は別だろうし、マーケットプレイスに出したければ(単なるリンクじゃなくてその場でダウンロードできて、バージョンアップまで管理)、Metro styleでないと無理なんでない?
MSのMarketPlace の審査はとても厳しい。
審査に落とされたアプリはどうなるの?
C#だからiPhoneやAndroidに流用できないよね?
ゴミになるの?
ショップ通さないと実行できない完全なプロテクト環境を用意してくるなら
むしろデスクトップの方で商機あるよ
それになによりobjectCで書いたほうががらくただろ?
C++で書けばいい
どういう層が荒らしてるんだろう。
携帯の板から流れてきたのかな?
技術的な事は全く分かってないみたいだから少なくとも開発者じゃないよね。
別に荒れてねーよカス
そういうのはいいから
>>692 >Note: Custom WinRT components are only supported in Metro style applications. They are not supported in Desktop applications.
Custom WinRT componentsって何?
703 :
デフォルトの名無しさん:2011/11/07(月) 16:46:33.94
要はカスタム ウィンアールティー コンポーネンツっちゅうことや
なるほどわからん
>>695 ModelとViewModelは流用し、Viewだけ差し替えてSilverlightにでも何でもすりゃいいだろw
デスクトップOSもだんだんAppStoreみたいな審査を通さないアプリは駆逐されていく方向に行くのかなぁ
そうなると、PCという汎用機の役目は終わったって感じがして何かさびしいな
自由なアプリの実行環境はそりゃ欲しいが
同時にそれらのアプリからデータの保護された実行環境も欲しい
電子署名のないドライバが禁止になったので、電子署名のないアプリ禁止は近いかもね。
ていうかWinRTは砂場の中で動かすわけで変なことは出来んよ
完全に防ぐのは不可能だけど今あるようなアフォみたいなマルウェアは
大概排除できるんだから多少不便があってもかなり大きなメリットだと思うんだけどな
スマホみたいに広告だらけのアプリが増えるのは勘弁してほしいな
↑なんでユーザーがこのスレにいるの?
そもそもWinRTアプリが流行らない罠
COMだとレジストリさらに肥大化するのかな。
もともとCOMプログラマなので歓迎
VB6も復活して欲しい
718 :
デフォルトの名無しさん:2011/11/11(金) 14:12:26.14
結局HTAで十分だったな
[PR] トイレトイレで困っている50代のあなたも前立腺肥大かも?
お医者さんへGo! 治療薬があります。
Windows8のタブレットって、silverlightで何がいけなかったんだろう。
WinAPIを10年がかりでリプレイスするつもりではないかと。
OSチームがやりたがりなんじゃね。
非同期APIをどうしても作りたかったとか?
なんとなく起動していつのまにか終了してるそういうフレームワークが欲しかったんじゃね
xaml+C#で書けるのは同じだもの
XAMLの仕様を見ているとCOMへの回帰が垣間見える。
XAMLは思いっきり.NETの仕様だけど
それも完全にWPFでUIを置き換えるつもりだった頃の設計の産物
VSチームはC#推しなのにOSチームはC++一択なのをどうにかしないと
いつまで経っても足並みはそろわない
Singularity
VSチームがC#でOS作ればいい
AndroidのUI周りとかまんまWPFだな
実装はともかく、XAMLやWPFの基本的な設計自体は非常にうまくできてる
>>728 そこを揃えるためのWinRTであり、WinMDであるのだろう
C++って本当扱いの難しい子ですね
>>731 その為には先ず、C#でネイティブコードを吐ける環境の実装をだな…
マジでこれさえ有れば、C++なんていらねーのに
念のために言っておくがネイティブ吐くのと.NET Frameworkが不要になるのでは意味が違うからな
馬鹿でかい.NET Frameworkをスタティックリンクするんなら
再配布.NET同梱するのと変わらん
スタティックリンクなら
いらない部分は含まれないでしょ
10年は前にさんざん言われたことだなぁ。
配布サイズ10倍以上にしてまでスタティックリンクしたいのかとか、
セキュリティホール見つかった時に放置されるリスク犯すのかとか。
Silverlightはランタイムに含まれてるDLLが最小限で
必要な.NETライブラリはスタティックリンクというかプライベートコピーが基本だが
それだけでも結構パッケージがデカくなるよね
配布サイズよりメモリサイズのほうが問題じゃないの?
CIL->ネイティブコードの変換くらいそう難しくないだろ
誰でも考えることだけどiPhoneでC#使いたいとか特殊な状況以外大して意味がないからやらない
ILは実質的にはネイティブと同じ。変わるのは、実行時コード生成するときぐらい。
STLつかうと一気に実行ファイルサイズが10倍に?!
>シングルプロセッサ上でのみ動作する。
実用には程遠い感じ
STL使うと実行ファイルサイズが10倍とかいつの時代だよ
まともなコンパイラなら仮にsizeof(int)==sizeof(long)の環境で
templateをintとlongで実体化すると二つは一つにまとめられる
膨れないようなものならテンプレート使っている意味があまりないが。
10倍とか異常値ではなくて妥当なサイズのコードを生成するって言っただけ
それにバイナリには直接現われないテンプレートの使い方もあるんだぞ
(初心者は) 「WinRT = Metro用DLL」 って認識でおk?
どういう意味合いで言ってるのか正確にとりかねるけど、
C#から見たら(C#しか使わない&内部的な実装気にしないなら)
「WinRT = Metro用DLL」 って認識でおk。
>>753 初心者じゃなくてもその認識でおk
.NETアセンブリでもなければCOMコンポーネントでもない
>>725 wp7のSilverlightで良さげ。
>>756 まあ、ぶっちゃけ、WP7のSilverlightに似てるしね<WinRT。
SilverlightってWPFと違ってUIフレームワークは元々ほとんど全部ネイティブで実装されてるしな
DllImportだったのがCOMになっただけ
えっ
そういやSilverlightがJSから使えたこともあったな・・・
むしろネイティブ以外で実装されているライブラリってあるのかと
WPFのライブラリ逆コンパイルできるじゃないILで
WPFだってネイティブの上に成り立ってるけどな
ネイティブはネイティブの上にネイティブを作らずってことやな、うん
ネイティブならナァドウゥ
WPFは最終的な描画や入力でごくプリミティブな機能としてネイティブ使ってるだけで
だけでフレームワークそのものはほぼC#だよ
Silverlightはかなり高レベルなところからネイティブ
お前らカタカナ禁止な
「カタカナ使うな?片仮名を使って欲しいという事ですか?」
ねいてぃぶ
斧゜裏魅手異武
Metroスタイルで「出来ない事」ってどれくらいあるんだろう
カスケード表示
まだアンチエイリアスを切れないの?
複数ウインドウは、技術的に無理な感じ?
技術的に可能でも、コントロールがたっくさんあると
現実的には難しそう。
複数ウィンドウにしたところで複数使うのかって話
C#に移るのはいやだけど、C++でGUIアプリ作るのはめんどくさくなってきた
ネイティブC++でWPF扱えるようにならないものかと思ってたが、こんなもん新しくできてたんだな
C++erは期待していいんだろうか
C++erのOSチーム作だからいいんでね。
metroアプリ作るためのもので、WPFの代わりになるもんではないよ
言語もC++ではなくC++/CLIに似た何か
デスクトップだとタッチ用のUIのアプリなんて誰も使いたがらないだろうけど
タブレットやタッチスクリーンPCが普及するかどうかだな
逆にタッチファーストなデバイスで従来のソフトを積極的に使いたがる奴もいないだろうしな
あらゆる面でGUI作るんなら素直にC#に移ったほうがいいと思う
学習コストを支払っても回収できるよ
WPFは糞重いしWinRTはWin8でしか使えない
C++でQt使った方がMacでもLinuxでも使えて
幸せになれる
785 :
デフォルトの名無しさん:2011/11/23(水) 01:04:07.94
互換性に囚われてそのプラットフォームで最適な表現が出来ないならユーザーには不幸だな
write once run anywhereとかjavaですでに絶望したはずなんだけどな
まだ幻想を抱いてるとか貴重種だよ
普段モデルの方ばっかり書いててビュー書いてないと、
write once, run anywhereの幻想抱きがちかなぁとかは思う。
確かに、モデルだけならかなりポータブルに書けるのよね。
でもそれをビューに期待しちゃ絶対ダメ。
今後、ネイティブでマルチプラットフォームというとChrome Papper(NaCl)かな。
Webフォーム程度なら、QtでもwxWidgetsでもいいよね。
プラットフォームごとに最適なUXを実現するためにもビューはあんまり流用できるものではないな
NaClに変に期待してる人をたまに見かけるけど何考えてるのか分からんな。
塩?
>>495がまさに真理
Webページですら事実上環境依存だというのに
そこでflashだrp(ドヤッ
Metroで殺される予定のFlashさん何やってんすか
Metro向けのAIRがあるだろ
>>796 最後の「Metro インターフェースは,実を言うと,HTML5 ベースなのだ。」が大嘘。
ろくな記事じゃない。
ランチャーとかのホストのUIがHTML5ベースで作られてると思ってるのかな?
とんでもなく重くてガクガクで使い物にならないだろうな
xaml知らなくてhtmlだと思ったんじゃないの
多分、HTML5+JavaScriptでもMetro UI書けるって部分を勘違いしたんだと思う。
実際は、2系統、XAML(WPFの焼き直し)とHTML5(IEと同じエンジン使ってる)が実装されてて、
HTML5側からも、WinRTの非UI部分のAPIが参照できるってだけなのに。
HTML5のWinRT表層はIE独自拡張満載とはいえ
CSSやらJSやらかなり手書き感あふれる実装だな
IE以外のブラウザの独自拡張はきれいな独自拡張
そうでもない
他のは平気で互換性を切る
その違い
>>803 はネタでしょ。
アンチMSは本気でそう思ってそうっていう。
ブラウザー以外でも、GCCの独自拡張を標準C++だと思ってて、
「VC++は標準対応してない」って文句言う人ほんとにいるし。
他にもマイナーだけどVistaでMS書体(やメイリオ)の「辻」や「葛」などの漢字の形が
略字形から本字形へと変更された時もWindowsは叩かれまくって
後から真似をしてヒラギノを変更したMac OS Xは褒め称えられる、とかあったしね。
今のIEは過去の失敗を踏まえてメジャーなブラウザの中では最も拡張に慎重だろ
MS以外ならロクに仕様の固まってない規格実装して
後でポシャったり大変更されたりしても最悪互換切り捨てることができるが
MSはそれが許されない
被害妄想癖あるやつがいるな
そこで名前だすのは、macじゃなくてAdobeだとおもう。
JIS78問題以降、変更があると
フォント名を変えることで対応している。
Adobeが細かい名前を決めてる訳ではないけど、DNSのヒラギノの場合、ProNとかNが末尾に付いたのが標準体
MSの場合、フォント名については、文章表現よりOSの容量削減にこだわってる。
重複が気になるなら、TTCにすればいいのに、TTCも扱いが難しいのか
増やしたくないのかもしれない。
本文のどこをまとめたらそのタイトルになるのかよくわからん
2010から腐ってるよな
WPFなんか使うからだ
2010ってかなりの部分がC#になってるんだろ?
そんな思い切ったことした割にはまともな出来だと思うがな
WPFや.NETがどうとかいう以前に製品として成熟しきってないだけだろ
ARM版ってデスクトップも無くて、デスクトップアプリも動かないのな
やっぱ.NET開発用に.NET WinRTサブセットでやる方向だよな
そりゃそうなるわな
俺は.NET使わない(キリッ
実は使ってるコンポーネントがCLRをロードしてました
となるのは目に見えてる
818 :
デフォルトの名無しさん:2011/12/08(木) 19:23:56.00
WindowsPhoneも死亡したようだし
MetroUIもすこぶる評判がよろしくない
四角いタイルがとてつもなくダサく思えてきたよ
そうかな?新UIの出だしなんていつもこんなもんだと思ってるけど
Winの新しい物が批判されるのはいつものこと
そして批判されたものほど後で普通になる
後で消えるものは最初から話題にすらならない
アンチも居るけど新規UIにしては意外と評判いいような気がするけどな。
まぁ、出てみないと何とも言えんけど今から騒いでる人は…アレな人たちだから参考にならん。
次期Officeはメトロみたいだな
メトロ推しはいいんだけど
オフィスをメトロにしてもなぁ
WinRT上でOfficeを構築するのは有用
タブレット向けのOfficeは必須であろう
825 :
デフォルトの名無しさん:2011/12/09(金) 00:36:38.46
Officeで作った資料をタブレットでサクッと見られれば便利だろな
COMの知識を整理し直さないといかんなぁ。
今存在するCOMの資料はみんな古いモノしかない上に、
従来のCOMで、WinRTの新機能で置き換えられるもの、
新たに追加させるものがかなりあるので。
WinRTって内部的にCOM使っているだけでAPIレベルでみるとWPFに近くなる
ものと勝手に想像していたのだけれども違うの?
いぇs
ARM版の公開まだなの?
OEM提供のみだから一般公開はない
開発者どうすんの?
>>831 HTMLとJavaScriptで作れってことだよ
言わせんな恥ずかしい
WPFよりWindowsフォームのほうが1万倍ぐらい使いやすいよね
釣りは他所でやって
つーかARM版公開したところでお前ら入れるデバイスも入れる手段も無いだろって話
開発者はWinRT上で組んでればなんも心配はいらんだろう
WPFのアプリがとうとう一つも登場することなくWinRTへ移行することになったな
自分が作れなかったからって全世界のことのように言われても
あれを「移行」と考えてる時点でおかしい。
世界中で大量に購入されたWPFアプリがあるというのに何も知らないんだなほんと
有名パッケージソフトで出なければ説得力はない
VS2010が一応WPF使ってるんじゃないの
評判悪いけど
Office2007以降とか、VS2010とか、WebMatrixとか
最近のMS製品は、WPF製が多い様な
MS以外のWPF製で一番インストールされてるのはATIのCatalyst Control Centerかな。
PowerShellISEもWPF製だな
Officeは違うでしょ。少なくとも手元の2007は違う。
WPFといえばExpressionでしょ。
簡単な見分け方
ウインドウを全画面に切り替えたとき
一瞬、横や下に何もない空白が表示されるのがWPFやwinforms
>>848 あーやっぱり。おれのPCがおかしいのかと思ったよ…
文字列描画とかボタン類とかフォーカス枠とかでなんとなくわかるだろ
852 :
デフォルトの名無しさん:2011/12/11(日) 19:27:47.17
これ別にosじゃなくね?
853 :
デフォルトの名無しさん:2011/12/11(日) 19:45:22.96
Ubuntuですね
OSSじゃなくて「GPL」だろ?
コメント欄といい、相変わらずMSアンチOSS信者はアホばっかりだな
セキュアブートのときも文章よく読まずにファビョってたのと同じ連中だろ
ストアに公開したらソース公開しちゃいけないとかあり得んだろうw
WP7のときにも勘違いしてファビョってる連中がいたが、
>>856の記事を書いてる本人は常識的に考えておかしいと思わないのか?
860 :
銀ピカ:2011/12/20(火) 21:41:18.72
個人的に、 「見せ場を分け合う」 と云う一点においては
DXの 「シーン登場時に侵食率を上昇させる」 ルールも、中々の物かなと思ってるぜよ。
侵食率調整の都合等で、ミドル以降にも 「全PCの内、1〜2人だけが登場するシーン」 が珍しく無い分
そのシーンに登場している限られたPCに、より注目が集まると云うか。
特にリプレイを読んでる時は、顕著に感じる部分デスね。
うわあああああああああああああああああああああああああああ
誤爆ソーリーorz
>>859 Appleはそのありえない規約ですけど?
WP7やiPhoneでダメなのはGPLのようなライセンスによって
配布するバイナリに変な制限が付くことじゃないの?
たとえばMonoTouchの大部分のソースは公開されてるが、あれ違反なのか?
同じようなソフトが登録されるのを嫌ってるということじゃないの?
見た目だけ変えたようなソフトが1000も2000も登録されたら・・・
865 :
デフォルトの名無しさん:2012/01/05(木) 09:08:35.86
アフィ広告だけ差し替えたアプリだらけのAndroidマーケット状態
>>863 GPL は GPL 以外の制約があっては駄目だっはず。
その制限とアプリマーケットの規約がコンフリクトする。
CESでは盛り上がってた。スマフォはちょっと微妙だが
タブレットはiOSとWin8の2強になるかも。
>>868 今の時点で盛り上がってるのはメーカーだけだろ
iOSとAndroidの2強だろw
>>868 今のノートがほとんど置き換わって一強だろ。
x86のandroidタブとスマホもでてくるけど、
wpあきらめて、win8のx86タブとスマホで攻めれば、少しはシェアとれると思う。
メトロアプリは独自でバイナリ配れないんだな
知らなかったんだけど川西さん亡くなってたのか
876 :
デフォルトの名無しさん:2012/01/26(木) 19:14:15.90
OpenGLならこんなことには
ES付いてるのと付いてないのとの差とか、バージョン間の差でなけばいいよ。
2月末にwin8 betaが出るって…
操作性がどうなっているのか
ASCII.jp:Windows 8向け新アプリは新実行環境「WinRT」で動く|ついに姿が見えた! Windows 8最新情報
http://ascii.jp/elem/000/000/633/633763/ > また、Windows Liveとの連携を前提にした「Mail」「Photo」「Calendar」「Documents」「People」というアプリケーションが提供され、
>Windows 8ではWindows LiveのSkydriveを簡単にアクセスできるようになっている。PhotoやDocumentsは、Skydriveの機能を利用したもので、
>自宅のマシンに外出先のノートパソコンやWindows Phone 7などからアクセスして、ファイルを利用するような機能も提供されるようだ。
個人的にはβで Live Essentials の Metro 版が付いてくるかが気になる。
β楽しみだな
883 :
デフォルトの名無しさん:2012/02/05(日) 05:59:28.17
NTカーネルになるって冗談じゃなかったのか
WPは8で終わりそうだな
WP8はx86版もあるらしいよ
WinRTをC++からハンドルする場合、Win32みたいにC(またはC++)の文法の範囲内で呼び出せるのか
それともCLIのキモい文法を使わなくちゃいけないのか、どっちなんだい^^
ただのコード生成だから絶対に拡張使わないとできないというわけではないだろうな
想定されてないし推奨もされてないけど
非同期APIとか悪夢ですね
C++/CXと呼ぶ構文拡張で、 WinRT(COM)オブジェクトを管理するらしい。
C++/CX は async をコンパイラが頑張って低級な命令に直し、
テンプレートを頑張って展開し、
キモイ構文を頑張ってパースする。
yield も追加して欲しい。
まあ誰にも見向きもされずMSにも放置されて今のC++/CLIみたいな状況になるんだろうけどな
今のWin32アプリって、Windows8でも動くんでしょ?
タブレットに興味ない人がわざわざWinRT使う意味ってなんだろう。
ないよ
C++でも使える新しいWPF系GUIツールキットだと勘違いして期待しちゃってる人もいるようだけど
MeinRTというかMetroアプリのことかね?
それならMetroアプリとしてしか動かないもの、そっちで動かしたほうが便利なもの以外は使わないでしょ。
894 :
デフォルトの名無しさん:2012/02/06(月) 11:04:35.52
マイクロソフトきもい
お前よりまし
>>895 お前よりまし
>>890 まあ誰にも見向きもされずMSにも放置されて今のC++/CLIみたいな状況になるんだろうけどな
>>51 んで、おまいら何か作ってみた?
>>852 これ別にosじゃなくね?
WOAでもデスクトップ使えるって言ってるけど
開発はARM用の.netとかネイティブとかも存在するって事なの?
教えてエロい人?
その前に、お前の尻の穴を開発する所から始めようか
再コンパイルするだけで、二度売るチャンスができるので期待。
Windows PhoneアプリってC++で開発できる?
現状個人ではできないはず。
>>897 .NET Frameworkの上で動かすなら、配布されるアプリは中間コードの塊で
OS起動後のアプリ初回実行時に、実装されているCPUに合わせてJITコンパイルされるだろ。
x86用とかx64用とかARM用とか気にしなくても良い、ハズ。
(ビルドターゲットはAnyCPUにして)
ネイティブアプリ書きの人は無くかもだが。
端から数バイト(しかも決め打ちのジャンプコード)しかx86のネイティブコードがないから
現時点の.netアプリケーションも問題なく動くはずなんだよねー
今はWindowsが直接.NETアプリを認識してCLRを起動してるんじゃなかったっけ
どっちにしろライブラリが違うから動かないよ
そのライブラリ部分を保証するのがフレームワークだし、
環境の差を埋める為に中間言語なわけじゃんか
いや参照してる.NETのマネージコードのDLLが違う
WinRTの.NET Frameworkはデスクトップ版のサブセットだから
訂正
×WinRTの ○Metro style appsの
バイナリ互換性が無いのは当たり前だけどソースレベルでも結構厳しいと思うぞ
GUIが全滅なのはもちろん、BCLもIOやスレッド周りが変わりまくってるから
今あるソースでそのままMetro向けにコンパイルできるものはほとんど無いんじゃないかな
まぁどこまで色々同じソースで書けるようになるかは期待したいところだ・・・
Silverlight系だから非ジェネリックコレクションとかICloneableとか
.NET Remoting系のシリアライザ(BinaryFormatterなど)とかXML DOMとか
不要になったもの一掃されてるんだぜ
信じられないだろ?w
今後MSに考えて欲しいのは、WebアプリもC#+XAMLで開発出来る様にする事だわな
Silverlight 6 を作るか、XBAPを推奨していくか
もうHTML+JavaScriptは嫌だ
HTML5+JSがSilverlight並に生産性高くてSilverlight並に性能良くてSilverlight並にブラウザ互換を気にしなくて良ければ
何の問題も無かったんだけどね。
PCでもスマホでも見れますつったって、スマホ用サイトがPC用と同じでいいわけ無いんだから意味ねーし
誰だこんなの推し進めたヤツらは
残念ながら今一番HTML5を推してるのはMSだ
>>907 一年前の時点ですべての.NETのライブラリの移植が終わったって言ってたが。
Classic Style(Aero)があるのに .NET の GUI が全滅とか何を言ってるのか。
そもそも WOA での従来の .NET アプリの話題を WinRT 前提で話しても意味ないよ
というか ?.NET Core と ?.NET Framework 4.5 を混同しているだけの残念な人なのか
WOAのデスクトップに.NETアプリが動くかは不明だがもしあるとすればAnyCPUで動くだろう
WinRTは言わずもがな
Windows 95におけるMS-DOSプロンプト == Windows 8におけるクラシックデスクトップ
>>918 そのクラッシックデスクトップの中にコマンドプロンプトがあった場合は、何に該当するんだ?
そういう問題じゃないんだが
WOAにはユーザがデスクトップアプリを入れることはできないんじゃなかったっけ?
動かないでしょ普通に
デスクトップ版.NETがWOAでサポートされるなんて今まで発表されたことないし
そんなの宣伝しない訳がないし
Metroでないと配布できないしデスクトップ版使えたら何のための.NET Coreかわからなくなるし
常識的に考えたら「従来のデスクトップアプリは使えない」に.NETも含まれてるだろ
>>922 従来のアプリじゃなくて、
WOA向けデスクトップアプリを新規作成・インストールするには
MSと契約しないとダメだって話しだと思う。
x86/x64アプリが動かないのはMSと契約しようとそもそも技術的に動かないだろ
>>923の言うようにMSと契約すればARM向けにビルドした非Metroアプリを配布できるとしても、
そのためだけにフルセット.NETを移植するようなアホなことMSがするわけがないわな
BUILDの発表内容見て.NET Frameworkの将来に期待してるのって頭弱いんじゃないの?
WinSockでちまちま書く時代に逆戻りは怖いなあ
なんでWinSock時代に逆戻りするんだよ
Roslynみたいにいつ完成するのかわかりませーん、そもそも完成できるのかもわかりませーんなんてのが認められてる時点で終わってるよね
Researchでは日常茶飯事だが
Googleのことですね
「野良アプリが動かない」ってことはMSのデジタル署名がないと動かないってことだろうから
ゲーム機以上のプロテクトになる
>>931 企業は大変だなw。こりゃARMの企業採用はなさそうだw。
まともな企業なら当然レベルだろ・・・
コンパイラをC#で実装しなおしてRoslynみたいなのを作りたいってのは前から言ってたね。
完成しなくても得られた知見は次世代のVSに生かされていくだろう。
>>924 だからとうの昔に移植完了してるって >フルセット.NET
販売戦略の関係上、WOAに搭載されることはなさそうだけどな。
939 :
デフォルトの名無しさん:2012/02/13(月) 21:09:38.41
WPFはWin32 APIで使われるHWNDを呼び出さないとOPENGLプログラムできないけど
WinRTでOpenGL使うときはどうやってプログラミングするんですか?
参考になるサイトあれば教えてください。
使えないでしょ
Direct3D使う
あとWinRTっていうのはAPIの呼称(Win32相当)で
プラットフォームとしての名前はMetro style appsね
941 :
デフォルトの名無しさん:2012/02/13(月) 22:02:52.07
WebGLにも反対してるからな
糞だわ
なるべく仕様を絞って移植性を上げるって方針だからだろ
WebGLなんてMSが反対しなくても終わってる
いやならドロイドで書けばいいじゃない
946 :
デフォルトの名無しさん:2012/02/13(月) 23:50:34.14
移植性ってマイクロソフト製品内だけってことですよね?
androidやiosとかプラットフォームが複数出てきた今の時期に
クロスプラットフォームなOpenGLを排除するのはやめてほしかった...。
ありえないわー
AndroidやiOSがDirect3Dをサポートすればいい
つーかWebGLは仕様バグで埋められない脆弱性があるから
いつの時代のはなしだよ
【寄生虫】 ロシアで韓国人を狙った襲撃事件が多発 【朝鮮猿狩り】
また韓国人留学生が刺殺される
死亡した学生はロシアのバル・ナウル市にあるアルタイ国立大学で交換留学生として研修中だった22歳の男性
で、15日夜、寄宿舎に戻る途中に後ろからロシア人3人に取り囲まれて暴行を受け、意識を失って病院に運ばれましたが、18日に死亡しました。
ロシア警察は事件の直後に暴行を加えた3人を逮捕して調べていますが、まだ具体的な事件の経緯は分かっていません。
ただ、被害者は金品を奪われなかったため、外国人を対象にした人種差別的な暴行事件ではないかという見方が強まっています。
ロシアでは2005年にも10代の韓国人学生2人が刃物で刺されて死亡し、2007年には韓国人学生1人が集団暴行
を受けて1か月後に死亡した事件が起きています。
KBSWORLD
http://world.kbs.co.kr/japanese/news/news_In_detail.htm?No=36056 寄生虫朝鮮猿の駆除が全世界のトレンドです^^
日本でも世界を見習って寄生虫の犯罪集団である在日チョンを一匹残らず駆除しましょう
WinRTな時点でWindows限定なんだから わざわざOpenGLを使う必要も無いだろ
>?選択されたデバイスに対してアプリを配布できるようになる。
なにこれ?
InfoQの翻訳は日本語として意味が通らないモノが多いから、
原文を読んだ方が良いと思うよ。
Metroな環境ではopenGLは終了か
実際そんな困らなけど
x86の環境では使えるだろうし
じゃあグラフィック系のマルチプラットフォームなアプリだとMetro対応は難しいな。
PCゲームの開発者を取り込むつもりなんだろ
一応PCじゃDirectXは圧倒的なシェアを持ってるんだし
windows8cpって2月29日って詳しい日付出てたのか
http://www.computerworld.jp/contents/201716 一部のニュースによると、マイクロソフトはWindows 8のベータ版「Windows 8 Consumer Preview」を
今月末の2月29日に公開する“らしい”とのこと。マイクロソフトは昨年12月に
「Windows 8のベータ版の一般公開は2月下旬」と発表していますが、
それが2月29日であるとは明言していません。このニュースのソースは、マイクロソフトが
2月29日にスペインのバルセロナで開催するプレス向けイベントへの招待状に
「Windows 8 Consumer Preview」という記述があることからの想像のようです。
><
>>954 配布側が〜さんと〜さんの携帯にって感じで対象を
指定してアプリを配布できるようになるんだろ
明後日(日本時間)本当に来るのか?
Express版でソース管理対応とな
ダウソ中...
Webインストーラーでやってるが糞遅いわダメだこれ
みんなそんな初日に落とすほど待ち遠しいわけVSが
しかしC++/CXなんて即死確定のものを作らされて大変だな
拡張は、WinRTのオブジェクト管理する為の指示みたいだけど、
osx/iosのARCみたいに自動生成に変わったらいいな。
そうなったとしても、CのobjC拡張みたいに、他のコンパイラ使えない時点で別言語だと思うが。
いや自動生成だぞ
拡張使わずに書くことは想定されてないだけで
ローカルマシンデバッグめんどくさい
シミュレーターもなんだかよくわからない
どうやってデバッグしてる?
もう一つ疑問
アプリバーの位置って統一されてないけど好きなところに置いていいのかな?
なぁMetroアプリって見るもの見るもの全部横長の拾い画面を左右にフリックして気になったのを深く見るってスタイルのしかないんだが、それ以外のって全部弾かれんの?
もし他のスタイルのものあったら教えてくれ。
WPと同じような基準なら別にそうしなくても弾かれはしないだろうが
代わりにゴテゴテでUI糞使いづらいって感想を抱かれると思うぞ。
>>976 別にMetroスタイル以外が全部ゴテゴテってことにはならんだろ。
iPhoneやiPadのアプリで使いやすいのあるけど、Metroスタイルとは違うもの多数あるからどうなのよと思った次第。
980 :
hage:2012/03/05(月) 20:39:43.26
hage
VBAできるやつ大勝利だな。息長すぎ。
VBよりJ++のほうが長生きすると思ってたあの頃
J++なんて即死すると思ってたぞ
あれDELLのためだけだろ
VBA給料安いやんけ
JavaとJavaScriptが違うように
VBとVBAは違うだろ
J++はヘルスバーグがMSに移って最初に入ったプロジェクトって書いてあった
早めに解放されてほんとによかった