windows.po

# SOME DESCRIPTIVE TITLE.
# Copyright (C) 2001-2025, Python Software Foundation
# This file is distributed under the same license as the Python package.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
# Translators:
# tomo, 2021
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Python 3.13\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2025-04-11 14:19+0000\n"
"PO-Revision-Date: 2021-06-28 00:52+0000\n"
"Last-Translator: tomo, 2021\n"
"Language-Team: Japanese (https://app.transifex.com/python-doc/teams/5390/"
"ja/)\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Language: ja\n"
"Plural-Forms: nplurals=1; plural=0;\n"

#: ../../extending/windows.rst:8
msgid "Building C and C++ Extensions on Windows"
msgstr "Windows 上での C および C++ 拡張モジュールのビルド"

#: ../../extending/windows.rst:10
msgid ""
"This chapter briefly explains how to create a Windows extension module for "
"Python using Microsoft Visual C++, and follows with more detailed background "
"information on how it works.  The explanatory material is useful for both "
"the Windows programmer learning to build Python extensions and the Unix "
"programmer interested in producing software which can be successfully built "
"on both Unix and Windows."
msgstr ""
"この章では Windows 向けの Python 拡張モジュールを Microsoft Visual C++ を使っ"
"て作成する方法について簡単に述べ、その後に拡張モジュールのビルドがどのように"
"動作するのかについて詳しい背景を述べます。この説明は、Python 拡張モジュールを"
"作成する Windows プログラマと、Unix と Windows の双方でうまくビルドできるよう"
"なソフトウェアの作成に興味がある Unix プログラマの双方にとって有用です。"

#: ../../extending/windows.rst:17
msgid ""
"Module authors are encouraged to use the distutils approach for building "
"extension modules, instead of the one described in this section. You will "
"still need the C compiler that was used to build Python; typically Microsoft "
"Visual C++."
msgstr ""
"モジュールの作者には、この節で説明している方法よりも、distutils によるアプ"
"ローチで拡張モジュールをビルドするよう勧めます。また、Python をビルドした際に"
"使われた C コンパイラが必要です; 通常は Microsoft Visual C++です。"

#: ../../extending/windows.rst:24
msgid ""
"This chapter mentions a number of filenames that include an encoded Python "
"version number.  These filenames are represented with the version number "
"shown as ``XY``; in practice, ``'X'`` will be the major version number and "
"``'Y'`` will be the minor version number of the Python release you're "
"working with.  For example, if you are using Python 2.2.1, ``XY`` will "
"actually be ``22``."
msgstr ""
"この章では、Python のバージョン番号が符号化されて入っているたくさんのファイル"
"名について触れます。これらのファイル名は ``XY`` で表されるバージョン名付きで"
"表現されます; ``'X'`` は使っている Python リリースのメジャーバージョン番号、"
"``'Y'`` はマイナーバージョン番号です。例えば、Python 2.2.1 を使っているなら、"
"``XY`` は実際には ``22`` になります。"

#: ../../extending/windows.rst:34
msgid "A Cookbook Approach"
msgstr "型どおりのアプローチ"

#: ../../extending/windows.rst:36
msgid ""
"There are two approaches to building extension modules on Windows, just as "
"there are on Unix: use the ``setuptools`` package to control the build "
"process, or do things manually.  The setuptools approach works well for most "
"extensions; documentation on using ``setuptools`` to build and package "
"extension modules is available in :ref:`setuptools-index`.  If you find you "
"really need to do things manually, it may be instructive to study the "
"project file for the :source:`winsound <PCbuild/winsound.vcxproj>` standard "
"library module."
msgstr ""

#: ../../extending/windows.rst:48
msgid "Differences Between Unix and Windows"
msgstr "Unix と Windows の相違点"

#: ../../extending/windows.rst:53
msgid ""
"Unix and Windows use completely different paradigms for run-time loading of "
"code.  Before you try to build a module that can be dynamically loaded, be "
"aware of how your system works."
msgstr ""
"Unix と Windows では、コードの実行時読み込みに全く異なるパラダイムを用いてい"
"ます。動的ロードされるようなモジュールをビルドしようとする前に、自分のシステ"
"ムがどのように動作するか知っておいてください。"

#: ../../extending/windows.rst:57
msgid ""
"In Unix, a shared object (:file:`.so`) file contains code to be used by the "
"program, and also the names of functions and data that it expects to find in "
"the program.  When the file is joined to the program, all references to "
"those functions and data in the file's code are changed to point to the "
"actual locations in the program where the functions and data are placed in "
"memory. This is basically a link operation."
msgstr ""
"Unix では、共有オブジェクト (:file:`.so`) ファイルにプログラムが使うコード、"
"そしてプログラム内で使う関数名やデータが入っています。ファイルがプログラムに"
"結合されると、これらの関数やデータに対するファイルのコード内の全ての参照は、"
"メモリ内で関数やデータが配置されている、プログラム中の実際の場所を指すように"
"変更されます。これは基本的にはリンク操作にあたります。"

#: ../../extending/windows.rst:64
msgid ""
"In Windows, a dynamic-link library (:file:`.dll`) file has no dangling "
"references.  Instead, an access to functions or data goes through a lookup "
"table.  So the DLL code does not have to be fixed up at runtime to refer to "
"the program's memory; instead, the code already uses the DLL's lookup table, "
"and the lookup table is modified at runtime to point to the functions and "
"data."
msgstr ""
"Windows では、動的リンクライブラリ (:file:`.dll`) ファイルにはぶら下がり参照 "
"(dangling reference) はありません。その代わり、関数やデータへのアクセスはルッ"
"クアップテーブルを介します。従って DLL コードの場合、実行時にポインタがプログ"
"ラムメモリ上の正しい場所を指すように修正する必要はありません; その代わり、"
"コードは常に DLL のルックアップテーブルを使い、ルックアップテーブル自体は実行"
"時に実際の関数やデータを指すように修正されます。"

#: ../../extending/windows.rst:70
msgid ""
"In Unix, there is only one type of library file (:file:`.a`) which contains "
"code from several object files (:file:`.o`).  During the link step to create "
"a shared object file (:file:`.so`), the linker may find that it doesn't know "
"where an identifier is defined.  The linker will look for it in the object "
"files in the libraries; if it finds it, it will include all the code from "
"that object file."
msgstr ""
"Unix には、唯一のライブラリファイル形式 (:file:`.a`) しかありません。 :file:"
"`.a` ファイルには複数のオブジェクトファイル (:file:`.o`) 由来のコードが入って"
"います。共有オブジェクトファイル (:file:`.so`) を作成するリンク処理の段階中"
"に、リンカは定義場所の不明な識別子に遭遇することがあります。このときリンカは"
"ライブラリ内のオブジェクトファイルを検索します; もし識別子が見つかると、リン"
"カはそのオブジェクトファイルから全てのコードを取り込みます。"

#: ../../extending/windows.rst:76
msgid ""
"In Windows, there are two types of library, a static library and an import "
"library (both called :file:`.lib`).  A static library is like a Unix :file:`."
"a` file; it contains code to be included as necessary. An import library is "
"basically used only to reassure the linker that a certain identifier is "
"legal, and will be present in the program when the DLL is loaded.  So the "
"linker uses the information from the import library to build the lookup "
"table for using identifiers that are not included in the DLL.  When an "
"application or a DLL is linked, an import library may be generated, which "
"will need to be used for all future DLLs that depend on the symbols in the "
"application or DLL."
msgstr ""
"Windows では、二つの形式のライブラリ、静的ライブラリとインポートライブラリが"
"あります (どちらも :file:`.lib` と呼ばれています)。静的ライブラリは Unix にお"
"ける :file:`.a` ファイルに似ています; このファイルには、必要に応じて取り込ま"
"れるようなコードが入っています。インポートライブラリは、基本的には特定の識別"
"子が不正ではなく、 DLL がロードされた時点で存在することを保証するためにだけ使"
"われます。リンカはインポートライブラリからの情報を使ってルックアップテーブル"
"を作成し、DLL に入っていない識別子を使えるようにします。アプリケーションや "
"DLL がリンクされるさい、インポートライブラリが生成されることがあります。この"
"ライブラリは、アプリケーションや DLL 内のシンボルに依存するような、将来作成さ"
"れる全ての DLL で使うために必要になります。"

#: ../../extending/windows.rst:86
msgid ""
"Suppose you are building two dynamic-load modules, B and C, which should "
"share another block of code A.  On Unix, you would *not* pass :file:`A.a` to "
"the linker for :file:`B.so` and :file:`C.so`; that would cause it to be "
"included twice, so that B and C would each have their own copy.  In Windows, "
"building :file:`A.dll` will also build :file:`A.lib`.  You *do* pass :file:"
"`A.lib` to the linker for B and C.  :file:`A.lib` does not contain code; it "
"just contains information which will be used at runtime to access A's code."
msgstr ""
"二つの動的ロードモジュール、B と C を作成し、別のコードブロック A を共有する"
"とします。Unix では、 :file:`A.a` を :file:`B.so` や :file:`C.so`  をビルドす"
"るときのリンカに渡したりは *しません* ; そんなことをすれば、コードは二度取り"
"込まれ、B と C のそれぞれが自分用のコピーを持ってしまいます。 Windows で"
"は、 :file:`A.dll` をビルドすると :file:`A.lib` もビルドされます。 B や C の"
"リンクには :file:`A.lib` を渡します。 :file:`A.lib` にはコードは入っていませ"
"ん; 単に A のコードにアクセスするするために実行時に用いられる情報が入っている"
"だけです。"

#: ../../extending/windows.rst:94
msgid ""
"In Windows, using an import library is sort of like using ``import spam``; "
"it gives you access to spam's names, but does not create a separate copy.  "
"On Unix, linking with a library is more like ``from spam import *``; it does "
"create a separate copy."
msgstr ""
"Windows ではインポートライブラリの使用は ``import spam`` とするようなもので"
"す; この操作によって spam の名前にアクセスできますが、コードのコピーを個別に"
"作成したりはしません。Unix では、ライブラリとのリンクはむしろ ``from spam "
"import *`` に似ています;  この操作では個別にコードのコピーを生成します。"

#: ../../extending/windows.rst:103
msgid "Using DLLs in Practice"
msgstr "DLL 使用の実際"

#: ../../extending/windows.rst:108
msgid ""
"Windows Python is built in Microsoft Visual C++; using other compilers may "
"or may not work.  The rest of this section is MSVC++ specific."
msgstr ""

#: ../../extending/windows.rst:111
msgid ""
"When creating DLLs in Windows, you must pass :file:`pythonXY.lib` to the "
"linker. To build two DLLs, spam and ni (which uses C functions found in "
"spam), you could use these commands::"
msgstr ""
"Windows で DLL を作成する際は、 :file:`pythonXY.lib` をリンカに渡さねばなりま"
"せん。例えば二つの DLL 、spam と ni (spam の中には C 関数が入っているとしま"
"す) をビルドするには、以下のコマンドを実行します::"

#: ../../extending/windows.rst:115
msgid ""
"cl /LD /I/python/include spam.c ../libs/pythonXY.lib\n"
"cl /LD /I/python/include ni.c spam.lib ../libs/pythonXY.lib"
msgstr ""

#: ../../extending/windows.rst:118
msgid ""
"The first command created three files: :file:`spam.obj`, :file:`spam.dll` "
"and :file:`spam.lib`.  :file:`Spam.dll` does not contain any Python "
"functions (such as :c:func:`PyArg_ParseTuple`), but it does know how to find "
"the Python code thanks to :file:`pythonXY.lib`."
msgstr ""
"最初のコマンドで、三つのファイル: :file:`spam.obj` 、 :file:`spam.dll`  およ"
"び :file:`spam.lib` ができます。 :file:`Spam.dll` には (:c:func:"
"`PyArg_ParseTuple` のような) Python 関数は全く入っていませんが、 :file:"
"`pythonXY.lib` のおかげで Python コードを見つけることはできます。"

#: ../../extending/windows.rst:123
msgid ""
"The second command created :file:`ni.dll` (and :file:`.obj` and :file:`."
"lib`), which knows how to find the necessary functions from spam, and also "
"from the Python executable."
msgstr ""
"二つ目のコマンドでは、 :file:`ni.dll` (および :file:`.obj` と :file:`.lib`) "
"ができ、このライブラリは spam と Python 実行形式中の必要な関数をどうやって見"
"つければよいか知っています。"

#: ../../extending/windows.rst:127
msgid ""
"Not every identifier is exported to the lookup table.  If you want any other "
"modules (including Python) to be able to see your identifiers, you have to "
"say ``_declspec(dllexport)``, as in ``void _declspec(dllexport) "
"initspam(void)`` or ``PyObject _declspec(dllexport) *NiGetSpamData(void)``."
msgstr ""
"全ての識別子がルックアップテーブル上に公開されるわけではありません。他のモ"
"ジュール (Python 自体を含みます) から、自作の識別子が見えるようにするには、"
"``void _declspec(dllexport) initspam(void)`` や ``PyObject "
"_declspec(dllexport) *NiGetSpamData(void)`` のように、"
"``_declspec(dllexport)`` で宣言せねばなりません。"

#: ../../extending/windows.rst:132
msgid ""
"Developer Studio will throw in a lot of import libraries that you do not "
"really need, adding about 100K to your executable.  To get rid of them, use "
"the Project Settings dialog, Link tab, to specify *ignore default "
"libraries*.  Add the correct :file:`msvcrt{xx}.lib` to the list of libraries."
msgstr ""