Win32 APIにはファイルの変更を監視する方法として、少なくとも2つの方法がある。 私は従来よりファイル監視のためのAPIとして、FindFirstChangeNotification関数を愛用している。 だが、WindowsNT系のUNICODEビルドであれば使えるというReadDirectoryChangeW関数によるファイル監視を使うことにより、パフォーマンスの改善が望めそうに思えたため、これを用いた場合には、どのような実装方法となるのか確かめたく実験してみることとした。 FindFirstChangeNotification APIを使ってファイルを監視する方法 Win32でファイルの変更通知を行うものとしては、Windows95時代から使える方法として、FindFirstChangeNotification関数があげられる。 このAPIは、指定したディレクトリまたは、その配下
ググったら32bit→64bitはNGだけど、64bit→32bitは行けるという情報があったので試したら行けた。DLL Injectionって何?という人は「別のプロセスにコードを割り込ませる3つの方法」にとても詳しく書かれているのでそちらを参考に。(こういうマニアックな記事は好きだ) 面倒なので自作アプリのソースの一部をそのまま貼る。本筋じゃない処理も混ざってるけど自力で読み飛ばし推奨。GOTO_Eは最後のラベルにgotoするマクロ。 bool pAttachRemoteThread(DWORD pid, const char* dllName, bool autoFree, bool waitRemoteSemaphoreRelease){ bool result = false; HANDLE hThread = NULL; PWSTR vDllPath = NULL; HANDL
The keyboard is used for several distinct types of input, including: Character input. Text that the user types into a document or edit box. Keyboard shortcuts. Key strokes that invoke application functions; for example, CTRL + O to open a file. System commands. Key strokes that invoke system functions; for example, ALT + TAB to switch windows. When thinking about keyboard input, it is important to
CDHtmlDialog はなぜ IE のユーザー補助設定に依存するのか・・・ というエントリもありましたが、本日ついに CDHtmlDialog ベースのアプリで IE の設定に依存しない方法がわかりました。 全ては、WebBrowser Customization (MSDN) に記載されておりました。IDocHostUIHandler::GetOptionKeyPath を適切に実装すれば良いだけです。翻訳されていればもっと早く気がついたのかもorz 日本語の情報だけを検索しているようではプログラマとしてダメダメですね。 詳細は、CrystalDiskInfo 3.9.0 Beta5 以降もしくは CrystalDiskMark 3.0.0h 以降のソースコード (CDHtmlDialogEx クラス) を参照してください。ただ、本来は自アプリケーションへのパスを設定するべきですが、
通常ディレクトリを作成する場合は、CreateDirectory関数を用いるが、この関数では1度に階層化されたディレクトリを作成することができない。 例えば、以下の例ようにCreateDirectory関数で階層化されたディレクトリを作成しようとするとエラーになり、GetLastError関数の戻り値は「3(指定されたパスが見つかりません。)」となる。 例:CreateDirectoryでカレントディレクトリに階層化されたディレクトリを作成する(エラーになる) if (!CreateDirectory(L".\\a\\b\\c\\d\\e\\f", NULL)) {//エラーになる printf("%d\n", GetLastError()); } そこで、階層化されたディレクトリを1度に作成したい場合は、MakeSureDirectoryPathExists関数を用いる。 MakeSur
ディレクトリの変更を監視するの変更を監視するには、ReadDirectoryChangesW関数を用いる。.NET Frameworkでは、System.IO.FileSystemWatcherがこの関数の機能に相当する。 ReadDirectoryChangesWのプロトタイプ BOOL ReadDirectoryChangesW( HANDLE hDirectory, // 監視するディレクトリのハンドル LPVOID lpBuffer, // 読み取った結果を受け取る // バッファへのポインタ DWORD nBufferLength, // lpBuffer の長さ BOOL bWatchSubtree, // ディレクトリまたはディレクトリツリーを // 監視するためのフラグ DWORD dwNotifyFilter, // 監視に使うフィルタ条件 LPDWORD lpBytes
ファイルが実行可能であるか調べるには、GetBinaryType関数を用いる。 GetBinaryTypeのプロトタイプ BOOL GetBinaryType ( LPCTSTR lpApplicationName, // ファイルのフルパス LPDWORD lpBinaryType // バイナリタイプ情報 ); 使用例 #include <windows.h> #include <stdio.h> int main() { char lpBuffer[1024]; GetSystemDirectory(lpBuffer, sizeof(lpBuffer)/sizeof(lpBuffer[0])); strcat(lpBuffer, "\\notepad.exe"); DWORD dwBinaryType; if (!GetBinaryType(lpBuffer, &dwBinaryTy
ファイルやディレクトリの名前や属性、サイズ、書き込み日時、セキュリティ属性変更の変更を検知する 使用するAPI FindFirstChangeNotification FindNextChangeNotification FindCloseChangeNotification HANDLE FindFirstChangeNotification( LPCTSTR lpPathName, // 監視するディレクトリの名前へのポインタ BOOL bWatchSubtree, // ディレクトリやディレクトリツリーの監視用の // フラグ DWORD dwNotifyFilter // 監視のためのフィルタ条件 ); dwNotifyFilterに設定可能な定数 FILE_NOTIFY_CHANGE_FILE_NAME監視中のディレクトリ、またはサブツリーでファイル名が変更されると、変更通知の待
概要 ここでは、非常にシンプルでフリーのデフラグソフト JkDefrag に関しての個人的な覚書を記す。 尚、JkDefrag 3.34 の書き直しとなる。 Build ソースファイルから実行ファイルを生成する場合には付属の Make.bat を利用すると簡単に行えるが、 特定環境に依存する記述内容なので、環境によっては若干修正が必要となる。 また、Makefile で all が指定されているので、 スクリーンセーバーなどの不必要なモノを省き、 普段必要とするものだけをビルドする様に修正しておくのも良い。 Make.bat ( Default ) rem @call "C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\SetEnv.Cmd" /2000 /RETAIL @call
常駐型のプログラムでよくあるのが、通知領域(俗にタスクトレイと呼ばれます)に常駐するというやつです。 普段はウィンドウが表示されていないけど、通知領域のアイコンをクリックとかするとウィンドウが開くというものです。 こういうのを実現してみましょう。 私は、以下のようにして実現するのがいいと考えました。 目に見えない「メインウィンドウ」を作成する。 メインウィンドウが作成されたら、通知領域にアイコンを追加する。 通知領域のアイコンがクリックされたらメインウィンドウに通知されるようにする。 メインウィンドウは、通知を受けたらそれに対応した動作を行う。 以上です。 目に見えない「メインウィンドウ」を作成する理由ですが…。 当サイトで公開している「看板」というソフトのバージョン 1.xx では、このようなメインウィンドウを作成していませんでした。 ダイアログベースでプロジェクトを作成し
概要 † このコンテンツは、C/C++言語でWindowsプログラミングをしていて、かつMFCやATLにある CString クラスを使っていない人くらいにしか実益はないかもしれません。 が、内容的に知っておいて損はないことなので書いておきます。 概要としては、 LPTSTR 型や TCHAR 型について知り、NT系(Unicode環境)と9x系(非Unicode環境)のどちらにも最適化できるソースコードを書こうというお話です。 TCHAR 型を見たことがなくても、 LPTSTR 型なら見たことがある人も結構いるでしょう。 初心〜中級のWindowsプログラマは、大抵は LPTSTR 型と LPSTR 型の違いを特に意識せずにコードを書いています。 しかし、この二つの型を混同するのは非常に危険なことです。 まずはこれらの型の定義を説明し、 TCHAR 型を用いることでUnicode対応プロ
自分のプロセスのコマンドラインを取得するのは非常に簡単だ。main関数が存在するならargc, argvで取得できるし、そうでなければ、__argv, __argv, (__wargv/__targv)で取得することもできる。また、APIとしては、GetCommandLineというものもある。好んで使う理由は見あたらないけど。 しかしながら、リモートプロセスのコマンドラインとなると、とたんに敷居が高くなる。プロセスハンドルを持っていても、GetRemoteCommandLineというAPIは見あたらないのでどうしようもない。となると、考えられる方法としては、 CreateRemoteThreadなどで相手プロセス内でGetCommandLineを呼び出す 相手のプロセスのメモリを直接読み込む という2つのうちのいずれかを選択することになる。一つ目の案は、大げさすぎるのと、相手プロセスに送り
ZeroMemory や CopyMemory などの Win32 API は CRT (C Runtime Library) の呼び出しに置き換えられる模様です。 // Winbase.h より抜粋 #define MoveMemory RtlMoveMemory #define CopyMemory RtlCopyMemory #define FillMemory RtlFillMemory #define ZeroMemory RtlZeroMemory// Winnt.h より抜粋 #define RtlMoveMemory(Destination,Source,Length) memmove((Destination),(Source),(Length)) #define RtlCopyMemory(Destination,Source,Length) memcpy((Desti
win32 の WinMain で main みたいに argc と argv を使いたかった。コンパイラが dmc なら stdlib.h をインクルードして __argc と __argv か __wargv を呼び出せば目標達成。下は stdlib.h からの抜粋。 #ifdef _DLL extern int * __CLIB __p___argc(void); extern char *** __CLIB __p___argv(void); extern wchar_t *** __CLIB __p___wargv(void); #define __argc (*__p___argc()) #define __argv (*__p___argv()) #define __wargv (*__p___wargv()) #else
UsefullCode.net Visual Studio 2005/2008/2010やandroid SDK/NDKでの開発者向けに便利なソースコードを提供 This site provide you with useful source codes under 'USEFULLCODE license'. HRESULTとはlong型の数値だ。この型はCOMインターフェース関連の関数の戻り値として利用されることが多い。 関数の戻り値として使われることの多いBOOL型が成功を意味するのは「1」(=TRUE)で失敗が「0」(=FALSE)なのと似ている。 大きな違いはBOOL型がTRUEとFALSEの2値しか取らないのに対して、HRESULT型では0x00000000~0xFFFFFFFFまでの多くの値が利用される。そのためBOOL型では失敗の原因を取得するためにGetLastError
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く