Visual Studio でビルドする場合は、"{" を "BEGIN" に "}" を "END" に変更してみてください。
基本的には、"{ }" でもコンパイルできるはずなんですが、"BEGIN" と "END" を使う方が
無難ですね。

CreateWindow() あたりのバグは既に指摘されているとおりですね。

akindo さんが書きました:下記のサイトの方法を試してみたのですが、どうやらリソースの書き方が
現在の方式とあっていないようでそのままやるとエラーが出ます。
http://wisdom.sakura.ne.jp/system/winap ... win84.html

リソーススクリプトに を加えてみてください。
それで、コンパイルができるようになるはずです。

プロジェクトのプロパティでデバッグ/作業ディレクトリはどうなっていますか？
当方ではGetCurrentDirectory()で取得するディレクトリはそこで指定したものと
同じになるようです。デフォルトでは "$(ProjectDir)" ですが、直接指定することも
可能で、へにっくす さんがおっしゃるように Windows は大文字小文字を区別しま
せんので、存在するディレクトリならば、そのまま実行できます。
または、 "$(ProjectDir)" がどうなっているかですね。

こちらも質問者さんと同じような環境ですが、現象は再現しません。 現象を再現できる最小限のプログラムを提示することは可能ですか。 こちらで使用したプログラムは以下のようなものです。 #include <windows.h> #include <stdio.h> #include <string.h> int main(void) { const int MAX_LENGTH_PATH = 256; char dir[MAX_LENGTH_PATH]; memset(dir, '\0', sizeof(dir)); GetCurrentDirectory(sizeof(dir), dir); pr...

4 45 55 45 95 1 65 95 90 60 2 65 60 70 70 3 90 80 65 65 としたいです。 こうゆうことでしょうか #include <stdio.h> #include <stdlib.h> int cmp(const void *p, const void *q) { return ((int *)p)[1] - ((int *)q)[1]; } int main(void) { int i; int data[][5] = { { 1, 65, 95, 90, 60, }, { 2, 65, 60, 70, 70, }, { 3, 90, 80, 6...

ちょっと書き漏らしました。

暗黙的リンクならば Dependency Walker を使用してリンクしている DLL は特定できます。
明示的リンクでも、ある程度は調査できます。

実行環境が良くわからないのですが、64bit Windows で 32bit Exe を実行する場合と考えてよろしいですか？

まず、DLL のリンクには明示的リンクと暗黙的リンクがあるのはご存じだと思いますが、32bitのEXEから64bit
のDLLをコールしようとした場合、明示的リンクでは、LoadLibrary() でエラーになりますし、暗黙的リンクでは
プログラムの開始時にエラーになると思います。どちらもハングアップすることはないはずです。

プログラムがハングアップするのは別の原因ではないのですか？

そうですね。そういう理解でいいと思います。
ただファイルの終わりではなく、何らかのエラーを検出した場合も
fgetc()関数は EOF を返します。このときは、feof()関数は0 を返
し、ferror()関数が非0 を返します。

ちょっと違うかな まず fopen() 関数が返すのは FILE * です。どこかに FILE型の オブジェクト（一般的には構造体）があるわけですが、FILE型には "ファイル位置表示子"と"ファイル終了表示子"が含まれます。 feof() 関数はこのファイル終了表示子を調べているだけです。 ファイルを読み込んで初めてファイルが終了したかどうかわかるの で、ファルを読まないうちにファイル終了表示子がセットされるこ とはありません。 つまり、fgetc()関数が正常終了した場合はファイル終了表示子が セットされることはないです。 ファイル位置表示子はこれから読もうとしている文字の位置が格納 され...

ノベルゲームなら、Console.KeyAvailable と Console.ReadKey() で間にあうような気もしますが、 DxLib 風のキー入力関数って、こういうことでしょうか？ using System; using System.Threading; using System.Runtime.InteropServices; class prog { [DllImport("user32.dll")] public static extern short GetAsyncKeyState(int key); static void GetHitKeyStateAll(int[]...

サモサ さんが書きました:この他にメリットはあるでしょうか？

メリットと言えるかどうかわかりませんが、getch() は入力をエコーバックしません。
例えば、パスワード入力などの場合 getchar() ではエコーバックしてしまうので、
何らかの処置が必要になります。

コンソール入出力関数のメリットは特別には考えとことがなかったです。
前にも書きましたが、目的が違うので使い分けが肝要ではないでしょうか。

getch() と getchar() では目的が違います。 getch() がコンソール入出力関数であるのに対し getchar() は標準入出力関数です。 getch() がリダイレクトすることは出来ないのに 対し、getchar() はリダイレクトされていれば、 ファイルからの入力も出来ます。 getchar() は文字の入力のための関数で、多くの 場合行単位の入力になります。Enterキーを押した と言うことは、行の終わりを意味するので、改行 (\n) に変換されます。 一方 getch() はそういった変換は一切行われません。 文字の入力と言うよりも、キーの入力といった方が いいかも...

mecabは使ったことがなかったのですが、興味があったのでダウンロードしてみました。
installすると、sdkというフォルダーができて、その中のヘッダーとライブラリをVisual Studioで
プロジェクトのVC++ディレクトリまたは、C/C++の追加のインクルードディレクトリとリンカーの
追加の依存ファイルに設定すればビルドはできると思います。

実行時にはDLLが必要になるようですので、同じくbinというフォルダーのDLLを実行ファイルと
おなじフォルダーにコピーすればいいと思います。

MoonGate さんが書きました:using namespace std;

が抜けてるせいだと思うんですがね。

そうすると、"string" ゃ "ifstream" でもエラーになりそうな気がします。
また、"ifstream" を使うときは <fstream> が必要な気がしますが、
その部分はエラーではないんですよね、不思議ですね。

ええ、そうなんですよね。ソースを提示できればいいのですが、ご免なさい今手元のありません。 これだけじゃなんなんで、概要だけでも．．． INPUT input[] = { { INPUT_MOUSE, 0, 0, 0, MOUSEEVENTF_ABSOLUTE | MOUSEEVENTF_MOVE, 0, 0 }, { INPUT_MOUSE, 0, 0, 0, MOUSEEVENTF_RIGHTDOWN, 0, 0 }, { INPUT_MOUSE, 0, 0, 0, MOUSEEVENTF_RIGHTUP, 0, 0 }, }; こんな構造体を用意して、マウスを移動する位置を決めます。 そし...

どのような環境で、どのようなプログラムを実行していますか。
また、キー入力を受け取るアプリケーションは何ですか？

簡単なプログラムを書いて実行したところ、うまくキーを拾えているようです。

当方の環境は
Windows7 Pro 32bit
Visual Studio 2010でコンソールアプリケーションを作成
OS標準のスクリーンキーボードからメモ帳に文字を入力

以上です

Resource.rc で Resource.h をインクルードしていますか？
リソースコンパイラのメッセージを見ると"TEXT_DATA"が文字列のまま使われているようです。
Core.cppでは"MAKEINTRESOURCE"が使われているので、Resource.h をインクルードしていると思います。
そうするとプログラム（数値）とリソース（文字列）で不整合が起こって読み込めないのでしょう