問題タブ [windows-nt]

Windows NT 4.0 dll ファイル内の txt ファイルの読み取りで問題が発生しています。質問する前に、私は現在、これを新しい OS に移行することに興味はありません。この 1 つの問題を修正して、この超レガシー ソフトウェアの移行について他の人に心配してもらいたいだけです。

次のように、fscanf を使用して txt ファイルを読み取ると、問題が発生します。

MATLAB で作成された txt ファイルは、5 つのスペースで区切られた 8 列の 128 行で構成され、MATLAB 内で次のようにフォーマットされます。

このコードは私が書いたものではなく、数年間機能しました。しかし、最近、Windows NT 4.0 OS とソフトウェアを再構築/再インストールする必要があり、奇妙なエラーが発生しました。プログラムは、行 123 に到達するまで、上部にあるコードを使用して txt ファイルを正常に読み取ります。この時点で、8 番目の列を 2 回読み取ります。その結果、後続のすべての変数が 1 桁シフトされ、最後の変数が完全に台無しになります。プログラムの数行。興味深いことに、この問題は、最初の 123 行をまとめて新しい txt ファイルに手動でコピー アンド ペーストし、最後の数行を 1 つずつ同じ新しい txt ファイルにコピーして貼り付け、それを入力として使用することで解決できます (コピーが完了しました)。ワードパッド内の NT マシン上)。そうすることで、この二重読み取りの問題が解消されます。どのような問題がこのエラーを引き起こす可能性があるのか​​ わかりませんが、しかし、そのような奇妙で不格好な方法で修正することもできます。問題は新しい入力と古い入力で発生するため、入力ファイルは変更されていないため、問題ではないと思います。

ああ、さらに、txt ファイルの各列間のスペースの数を変更すると、エラーの場所が移動します。スペースを 1 つに減らすと、120 行目あたりでエラーが発生しますが、スペースの数を増やすと (5 ではなく 7 を試行)、エラーが 124 行目まで押し下げられます。

私はプログラミングの専門家ではありません (常に必要に応じて学習する人でした)。ありがとう！

Windows NT は当初、マイクロカーネル アーキテクチャを実装するように設計されましたが、ハイブリッド カーネルに移行したと聞いています。

変化の原因は何ですか？これに関する情報を見つけるのに苦労しています。

Windows DDK ビルド環境として知られる NT ビルド環境では、build.exe に -M パラメータを指定することで、複数のプロセッサを使用してソース ツリーをビルドできます。それが行ったことは、プロジェクトを依存関係の順序で順番にビルドすることでした。各プロジェクトをビルドするときに、複数のスレッドを起動して個々のソース ファイルをビルドし、明らかに最初にプリコンパイル済みヘッダーをビルドし、その他の必要な作業を行いました。ソースの残りの部分をビルドする前 (midl など)

Visual Studio/MSBuild は、非常に異なるアプローチを採用しています。複数のスレッドを使用してプロジェクトをビルドしますが、個々のソース ファイルを順番にビルドするだけです。これは、小さなプロジェクトがたくさんある場合にうまく機能します。ただし、多くのソース ファイルを含むプロジェクトがある場合、これはイライラします。

Visual Studio の人々が Windows の人々のように個々のソース ファイルをビルドするためにスレッドを使用しない (または少なくとも使用していた) 理由を十分に知っている人はいますか?

ディスクファイルの場合のように、可能な場合に真のファイル記述子クローンメカニズムがないのはなぜですか。

POSIX:

これらのシステム コールの 1 つから正常に戻った後、古いファイル記述子と新しいファイル記述子を交換可能に使用できます。これらは同じオープン ファイル記述 (open(2) を参照) を参照するため、ファイル オフセットとファイル ステータス フラグを共有します。たとえば、記述子の 1 つで lseek(2) を使用してファイル オフセットを変更すると、もう一方のオフセットも変更されます。

ウィンドウズ：

複製ハンドルは、元のハンドルと同じオブジェクトを参照します。したがって、オブジェクトへの変更は両方のハンドルを介して反映されます。たとえば、ファイル ハンドルを複製した場合、現在のファイル位置は両方のハンドルで常に同じになります。ファイル ハンドルが異なるファイル位置を持つようにするには、CreateFile 関数を使用して、同じファイルへのアクセスを共有するファイル ハンドルを作成します。

クローン プリミティブを使用する理由:

• ファイル アーカイブを操作する場合、アーカイブ内の各ファイルに個別にアクセスできる必要があります。ファイル アーカイブは、仮想ファイル システムのように動作する必要があります。

• ファイルタイプのチェック。ファイル オフセットのクローンを作成できるため、元の位置に影響を与えることなく、ファイルのごく一部を読み取ることができます。

Microsoft Pressの Windows Internals, 6th Editionによると、Windows NT では、各スレッドに2 つのスタックがあります。1 つはユーザー モードでの実行時に使用され、もう 1 つはカーネル モードで使用されます。

これはなぜですか？システム コール中にユーザー モード スタックを使用することもできるようです。このデザインに利点はありますか？

テナント対応の Web アプリケーションで複数のデータベース タイプをサポートする必要があります。とりわけ、「jdbc:jtds:sqlserver://192.168.1.189:1433/ApplicationName」のような接続文字列を持つ net.sourceforge.jtds.jdbc.Driver クラスを使用して、Microsoft の SQL Server を正常にサポートしました。これは機能しますが、ユーザーが SQL Server インスタンスで明示的にユーザーを定義し、SQL Server 認証を有効にする必要があります。

現在、必然的に要件が変更され、Windows 認証を介した SQL Server への接続をサポートすることになっています。データベースサーバーは、データベース接続に渡された資格情報が SQL Server インストールで定義されたユーザーのものか、Windows OS で定義されたユーザーのものかを何らかの方法で区別できる必要があるため、明らかにこれには接続文字列への何らかの変更が必要です。しかし、それは何ですか？

で接続文字列を拡張するまで進んだ場合は、インターネットからのアドバイスに基づいて行動します;useNTLMv2=true;domain=WORKGROUP。これにより、Windows ユーザーとして認証したいことをデータベース サーバーに認識させるようですが、実際のログインは失敗します。

現在、私のテスト セットアップでは、J2EE アプリと SQL サーバー インスタンスの両方が実際には同じマシン上にあり (本番環境ではそうではないかもしれません)、それでもこのコンピューターはそれ自体にログオンするのに十分なほど信頼されていませんか? 明らかに、ここでパズルの大部分を見逃しています。SQL Server インスタンスを開始したユーザーが実際に JDBC 経由でログオンできることを SQL Server インスタンスに納得させるには、どうすればよいでしょうか?

編集

Web アプリケーションを完全な Microsoft インフラストラクチャ スタック (SQL Server、Active Directory、ドメイン ネーム サービスなど) に統合しようとして失敗に終わった努力をすでに沈めているため、この質問を制限する必要があります。

Active Directory、Web アプリケーションを実行している Windows マシン、および独自の DLL を使用せずに、J2EE アプリケーションからJDBC経由で「Windows ユーザー」として定義されたユーザー アカウントでSQL Serverインストールにアクセスする方法を知っている人はいますか? 報奨金は、そのサブ問題の解決策に対するものです。1 つのフォーラム投稿で回答するには、問題全体が広範すぎることは明らかです。