問題タブ [windows-nt]

I need to create an executable for Windows NT ( yes, Windows NT still exists ). The problem that I have is that VS2005 uses CRT/MFC 8.0, therefore after running the application using the CRT 8.0 libraries I will get an error complaining that GetlongpathnameW doesn't exist on the target environment, which should be fixed by going back to MFC 7.1 CRT libraries.

I have the libraries that I acquired from somewhere else (mfc71.dll, msvcp71.dll, msvcr71.dll....) but how do I get VS to use those instead of the default ones (MFC80.dll....)?

Here is the link of a person with the similar problem: https://social.msdn.microsoft.com/Forums/vstudio/en-US/b6027b6d-7e30-4b76-b92b-b19982a33dfc/the-procedure-entry-point-getlongpathnamew-could-not-be-located-in-the-dynamic-link-library?forum=vcgeneral

Thanks!

クラッシュしている Windows アプリケーションをデバッグしています。アプリを起動し、WinDbg でアタッチしてからクラッシュさせた後、WinDbg コマンド ウィンドウに次のように表示されます。

(119c.1794): Unknown exception - code 0000071a (first chance)

Web を検索してきましたが、これらの例外コードを解釈する方法についての説明は見つかりませんでした。

違いがあるとすれば、それは 64 ビットの Windows 8 で (WoW64 を介して) 実行されている 32 ビットの .NET アプリケーションです。

cl オプション

実際には、カーネル dll を構築しています。

このmio.cppファイルは私のシステムには存在しないので、これは cl.exe ソース コードの一部だと思います。gcc には、コードのどの行でコンパイラ エラーが発生したかを知らせるオプションがあります。
コンパイル済みヘッダーを無効にしようとしました。すべての最適化でターゲットが R10000 に変更されますが、エラーは引き続き同じ場所に追加されます。

そしてマイクロソフトは確かにエラーを修正しません。このプラットフォームをサポートする別のコンパイラは見つかりませんでした。

また、エクスポートは構造の構造の構造であるため、インクルードファイルを使用する必要があります。

Raymond Chen によるこのブログ エントリによると、 Windows NT はウィンドウを座標 (-32000、-32000) に移動することで「最小化」しました。 (3.x、4...)。

Windows NT の最近のバージョン (7、8、10 など) では、これはまだ当てはまりますか?

最新の Windows OS でこの機能の有無を示すために作成できるプログラムはありますか?

Windows NT は、Windows NT API 全体でデフォルトのエンコード方法として Unicode (2 バイト幅の UTF-16) を使用します。デフォルトの文字セットとして ASCII またはマルチバイト文字セットの使用を選択すると、ASCII が Unicode に変換されます。また、ASCII 文字セットを使用すると、Unicode よりも遅くなります。この変換は何を意味するのでしょうか? ASCII API を Unicode API に変換するだけですか、それともすべての文字列を変換しますか? 例: で C/C++ ファイルを作成するとしconst char* text = "Hello, world!"ます。Windows NT でコンパイルすると、コンパイルされたバイナリ ファイルに "Hello, world!" が格納されます。Unicode (26 バイト) または ASCII (13 バイト) として?

Windows OSにappiumをインストールしようとしています。システム パスに tools と platform-tools フォルダー パスを追加しました。しかし、それでも adb はシステムによって認識されません!!!!

CMD 出力イメージ:

フォルダ ビュー:

私は、node.js を実行できる OS の命名規則で違法となるルールの決定的なリストを作成しようとしています。

これまでのところ、インターネット上の多くのリソースや同様の質問を読むことはできませんが、これは私が見つけたものです:
名前のどこかに不正な文字:

1. windows_nt - /?<>\,:*|"
2. Linux - /
3. ダーウィン- / そしてたぶん : ? （OS Xで許可されていると言う人もいますが、そうではないという人もいますが、私にはよくわかりません）

不正な名前:

4. windows_nt - CON、PRN、AUX、CLOCK$、NUL、COM1-9、LPT1-9 (他のいくつかのデバイス名は、古い dos ディストリビューションでのみ違法であり、node.js を使用できないため、含まれていません)

5. Linux -

6. ダーウィン-

不正な末尾文字:

7. windows_nt - . (ドット) と (スペース)

8. Linux -

9. ダーウィン-

不正な先頭文字:

10. windows_nt -

11. Linux -

12. ダーウィン-

ファイル/ディレクトリ名の最大長:

13. windows_nt -

14. Linux -

15. ダーウィン-

最大パス長:

16. windows_nt -

17. Linux -

18. ダーウィン-

ここで設定されたルールのギャップを埋めるのを手伝っていただければ幸いです. また、node.js を実行できる OS のみを考慮する必要があります。

職場では、Jenkins の助けを借りて、複数のビルド マシンでユニット テストを定期的に実行しています。単体テストの 1 つは、でファイルを開き、このファイルFILE_FLAG_WRITE_THROUGHに対して何万回ものWriteFile呼び出しを行います。なぜそうするのかは、この質問には関係ありません。ビルド マシンの 1 つだけで、このテストは常にタイムアウトしていました。いくつかの調査の後、これの根本的な原因は、 への各呼び出しWriteFileがブロックされ (スレッドが切り替えられ、後で切り替えられた)、テストの実行が大幅に遅くなったことであることが判明しました。不思議なことに、このマシンでテストを手動で開始したとき、WriteFileはブロックされなかったため、テストはタイムアウトしませんでした。

何時間もの試行錯誤の後、「回避策」を見つけました。影響を受けるマシンで、Jenkins がタスク スケジューラで起動WriteFileされた場合、ブロックされました。手動で起動した場合、またはスタートアップ フォルダーに BAT ファイルを配置して起動した場合は、そうではありませんでした。もっと調査する必要があると思ったので、最小限の再現、ファイルを で開き、ランダムなデータで 10000 回FILE_FLAG_WRITE_THROUGH呼び出す小さなプログラムを作成しました。WriteFileこの最小限の再現では、WriteFile起動方法に関係なく、常にブロックされます。私は本当に混乱しているので、ここでこの動作の説明を求めています。テストを実行したすべてのマシンには、デフォルト設定 (書き込みキャッシュと Windows 書き込みキャッシュ フラッシュが有効) の SATA ドライブが搭載されていました。

まず第一に、何FILE_FLAG_WRITE_THROUGHをすべきかは 100% 明確ではありません。インターネット上の情報によると、特別なフラグがデバイスに渡され、書き込み後にキャッシュをフラッシュするように求められます。Raymond Chen (および他の多くの人々) によると、パフォーマンス上の理由から、大多数の SATA ドライブがこのフラグを黙って無視するため、これは今日ではほとんど無関係です。「ブロックすべきか、すべきでないか」の側面では、このページはブロックFILE_FLAG_WRITE_THROUGH WriteFile すべきであると明確に述べています。

データがファイルに書き込まれるまで、書き込み呼び出しは戻りません。

この奇妙な動作が (一貫性なく) 見られる理由について何か考えはありますか? どうすればさらに調査できますか?