WINEBUILD(1) Wine Developers Manual WINEBUILD(1)

winebuild - ابزار ساخت dll واین

winebuild [options] [inputfile...]

winebuild فایل‌های اسمبلی لازم برای ساخت یک dll واین را تولید می‌کند، که در اصل یک dll ویندوز ۳۲بیتی (Win32) کپسوله‌شده درون یک کتابخانه یونیکس است.

winebuild بسته به این که چه نوع فایلی برای تولید از آن خواسته شده است، حالت‌های متفاوتی دارد. حالت مورد نظر توسط یکی از گزینه‌های حالت که در ادامه آمده‌اند مشخص می‌شود. علاوه بر گزینه حالت، گزینه‌های خط فرمان متنوع دیگری نیز می‌توانند تعیین شوند، همان‌طور که در بخش گزینه‌ها (OPTIONS) توضیح داده شده است.

شما باید دقیقاً یکی از گزینه‌های زیر را تعیین کنید، بسته به این که می‌خواهید winebuild چه چیزی را تولید کند.

ساخت یک فایل اسمبلی از روی یک فایل .spec (برای جزئیات به بخش SPEC FILE SYNTAX مراجعه کنید)، یا از روی یک فایل استاندارد .def ویندوز. فایل .spec/.def توسط گزینه -E مشخص می‌شود. فایل حاصل باید اسمبلی شده و به دیگر فایل‌های شیء پیوند داده شود تا یک dll واین کاربردی و اجرایی ساخته شود. در این حالت، input files باید فهرستی از تمامی فایل‌های شیء باشد که در dll نهایی پیوند می‌خورند، تا به winebuild اجازه دهد فهرست تمامی نمادهای تعریف‌نشده‌ای که باید از دیگر dllها وارد شوند را دریافت کند.
ساخت یک فایل اسمبلی برای یک فایل اجرایی. این حالت اساساً همانند حالت --dll است، به جز اینکه نیازی به فایل .spec/.def به عنوان ورودی ندارد، زیرا یک فایل اجرایی نیازی به صادر کردن توابع ندارد. با این حال برخی فایل‌های اجرایی توابعی را صادر می‌کنند، و برای آن‌ها یک فایل .spec/.def می‌تواند از طریق گزینه -E تعیین شود. نام فایل اجرایی از روی نام فایل .spec/.def در صورت وجود برداشته می‌شود، یا به صراحت از طریق گزینه -F تعیین می‌گردد. فایل حاصل باید اسمبلی شده و به دیگر فایل‌های شیء پیوند داده شود تا یک فایل اجرایی واین کارآمد ساخته شود، و تمامی فایل‌های شیء دیگر باید به عنوان input files فهرست شوند.
ساخت یک فایل .def از روی یک فایل spec. فایل .spec از طریق گزینه -E تعیین می‌شود. این گزینه هنگام ساخت dllها با یک کامپایلر PE (Win32) استفاده می‌شود.
ساخت یک کتابخانه واردسازی .a از روی یک فایل spec. فایل .spec از طریق گزینه -E تعیین می‌شود. اگر نام کتابخانه خروجی به .delay.a ختم شود، یک کتابخانه واردسازی با تأخیر ساخته می‌شود.
ساخت یک کتابخانه ایستا .a از روی فایل‌های شیء.
تولید یک فایل .o حاوی تمامی منابع ورودی. این گزینه هنگام ساخت با یک کامپایلر PE مفید است، زیرا ابزارهای binutils در PE نمی‌توانند چند فایل منبع را به عنوان ورودی اداره کنند. برای یک ساخت استاندارد یونیکس، فایل‌های منبع هنگام ساخت فایل spec به طور خودکار گنجانده می‌شوند، بنابراین نیازی به یک فایل واسط .o نیست.
علامت‌گذاری یک ماژول PE به عنوان ماژول داخلی واین، با افزودن رشته شناسه "Wine builtin DLL" بعد از هدر DOS.
اصلاح سازنده‌ها پس از ساخته شدن یک ماژول. این کار باید روی ماژول نهایی .so انجام شود اگر کد آن شامل سازنده‌ها باشد، تا تضمین شود که واین پیش از اجرای سازنده‌ها فرصت مقداردهی اولیه ماژول را دارد.

دستور مورد استفاده برای کامپایل فایل‌های اسمبلی را تعیین می‌کند؛ پیش‌فرض as است.
پردازنده و پلتفرم مقصد را که کد تولیدشده بر روی آن ساخته خواهد شد تعیین می‌کند. مشخصات مقصد در قالب استاندارد autoconf است، همان‌گونه که توسط config.sub برگردانده می‌شود.
دایرکتوری را به مسیر جستجو برای ابزارهای مختلف binutils مانند as، nm و ld اضافه می‌کند.
کامپایلر C مورد استفاده برای کامپایل فایل‌های اسمبلی را تعیین می‌کند؛ پیش‌فرض استفاده از اسمبلر مشخص‌شده با --as-cmd است.
ماژولی می‌سازد که تنها شامل داده‌ها و منابع بوده و هیچ کد اجرایی ندارد. با این گزینه، winebuild به جای یک فایل اسمبلی یا شیء، مستقیماً یک فایل PE خروجی می‌دهد.
حالت واردسازی با تأخیر را برای کتابخانه تعیین‌شده تنظیم می‌کند، که باید یکی از کتابخانه‌های واردشده با گزینه -l باشد. حالت تأخیری به این معنی است که کتابخانه تا زمانی که تابعی که از آن وارد شده است واقعاً فراخوانی نشود، بارگذاری نخواهد شد.
برای سازگاری با کامپایلر C نادیده گرفته می‌شود.
تصادفی‌سازی چیدمان فضای آدرس (ASLR) را در تصویر اجرایی غیرفعال می‌کند. پیش‌فرض 'ASLR' فعال است.
تابع نقطه ورود ماژول را تعیین می‌کند؛ در صورت عدم تعیین، پیش‌فرض DllMain برای dllها، و main برای فایل‌های اجرایی است (اگر main استاندارد C تعریف نشده باشد، WinMain به جای آن استفاده می‌شود). این فقط برای ماژول‌های Win32 معتبر است.
یک فایل .spec (برای جزئیات به SPEC FILE SYNTAX مراجعه کنید)، یا یک فایل استاندارد .def ویندوز را تعیین می‌کند که صادرات مربوط به DLL یا فایل اجرایی در حال ساخت را تعریف می‌کند.
اجازه پیوند به نمادهای خارجی را مستقیماً از فایل spec می‌دهد. به طور معمول نمادهای صادرشده توسط یک dll باید در خود dll تعریف شوند؛ این گزینه استفاده از نمادهای تعریف‌شده در یک کتابخانه دیگر یونیکس را ممکن می‌سازد (برای نمادهای تعریف‌شده در یک dll دیگر، باید به جای آن از یک مشخصه forward استفاده شود).
یک گزینه تولید کد را تعیین می‌کند. در حال حاضر -fPIC و -fasynchronous-unwind-tables پشتیبانی می‌شوند. سایر گزینه‌ها برای سازگاری با کامپایلر C نادیده گرفته می‌شوند.
به جای فایل اسمبلی یا شیء معمولی، یک ماژول PE ساختگی برای یک dll یا exe ایجاد می‌کند. ماژول PE حاوی منابع ماژول است، اما هیچ کد اجرایی ندارد.
نام فایل ماژول را تنظیم می‌کند. پیش‌فرض استفاده از نام پایه فایل spec (بدون هیچ پسوندی) است.
نمایش پیام نحوه استفاده و خروج.
اندازه هیپ محلی ماژول را بر حسب بایت تعیین می‌کند (فقط برای ماژول‌های Win16 معتبر است)؛ پیش‌فرض بدون هیپ محلی است.
برای سازگاری با کامپایلر C نادیده گرفته می‌شود.
حذف تزئینات stdcall از نام‌های نماد در فایل .def تولیدشده. تنها در حالت --def معنادار است.
برای سازگاری با کامپایلر C نادیده گرفته می‌شود.
تنظیم یک پرچم در فایل اجرایی تا به بارگذار اعلام کند که این برنامه از فضاهای آدرس بزرگتر از ۲ گیگابایت پشتیبانی می‌کند.
دستور مورد استفاده برای پیوند فایل‌های شیء را تعیین می‌کند؛ پیش‌فرض ld است.
به ترتیب کدهای ۱۶ بیتی، ۳۲ بیتی یا ۶۴ بیتی تولید می‌کند.
گزینه‌های تولید کد را برای اسمبلر تنظیم می‌کند.
کتابخانه‌ای می‌سازد که به جای کتابخانه C یونیکس از زمان‌اجرای ویندوز استفاده می‌کند.
هنگام ساخت یک dll شانزده‌بیتی، نام همتای ۳۲ بیتی آن را به module تنظیم می‌کند. این گزینه برای این استفاده می‌شود که ترتیب بارگذاری dll شانزده‌بیتی با نسخه ۳۲ بیتی مطابقت داشته باشد.
نام داخلی ماژول را تنظیم می‌کند. فقط در ماژول‌های Win16 استفاده می‌شود. پیش‌فرض استفاده از نام پایه فایل spec (بدون پسوند) است. این برای KERNEL استفاده می‌شود، زیرا در KRNL386.EXE قرار دارد. در غیر این صورت نباید مورد نیاز باشد.
دستور مورد استفاده برای دریافت فهرست نمادهای تعریف‌نشده را تعیین می‌کند؛ پیش‌فرض nm است.
مشخص می‌کند که آیا ماژول با پشتیبانی no-exec سازگار است یا خیر. پیش‌فرض yes است.
نام فایل خروجی را تعیین می‌کند (پیش‌فرض خروجی استاندارد است). اگر نام فایل خروجی به .o ختم شود، خروجی متنی به یک فایل موقت فرستاده می‌شود که سپس برای تولید فایل .o تعیین‌شده، اسمبلی می‌گردد.
مشخص می‌کند که اگر DLL بومی در زمان اجرا در دسترس بود، باید ترجیح داده شود. این گزینه می‌تواند روی ماژول‌هایی که بخش عمده آن‌ها پیاده‌سازی نشده است استفاده شود.
بارگذاری منابع از فایل دودویی منابع مشخص‌شده. فایل rsrc.res می‌تواند از یک فایل منبع سورس با wrc(1) (یا با یک کامپایلر منابع ویندوز) تولید شود.
این گزینه تنها برای فایل‌های منبع Win16 لازم است، فایل‌های Win32 می‌توانند به سادگی به عنوان input files فهرست شوند و به طور خودکار به درستی مدیریت خواهند شد (هرچند گزینه -r برای فایل‌های Win32 نیز کار خواهد کرد).
علامت‌گذاری فایل‌های شیء به عنوان سازگار با SEH.
فایل‌های موقت مختلفی را که winebuild تولید می‌کند حذف نمی‌کند.
دستور مورد استفاده برای استریپ ماژول‌های PE را تعیین می‌کند. تنها در حالت --builtin معنادار است.
زیرسیستم فایل اجرایی را تنظیم می‌کند، که می‌تواند یکی از موارد زیر باشد:
console برای یک فایل اجرایی خط فرمانی،
windows برای یک فایل اجرایی گرافیکی،
native برای یک dll در حالت بومی،
wince برای یک dll ویندوز CE.
نقطه ورود یک فایل اجرایی خط فرمانی تابع معمول C یعنی main است. در صورتی که نیاز داشته باشید آرایه آرگومان‌ها از رشته‌های یونیکد استفاده کند، می‌توان از تابع wmain به جای آن استفاده کرد. یک فایل اجرایی گرافیکی دارای نقطه ورود WinMain است.
به صورت اختیاری نسخه اصلی و فرعی زیرسیستم نیز می‌تواند تعیین شود؛ نسخه پیش‌فرض زیرسیستم 4.0 است.
افزودن symbol به فهرست نمادهای تعریف‌نشده هنگام فراخوانی پیونددهنده. این امکان را فراهم می‌کند که هنگام حل واردات، گنجاندن یک ماژول خاص از یک کتابخانه ایستا اجباری شود.
نمایش زیرفرمان‌های مختلفی که توسط winebuild فراخوانی می‌شوند.
نمایش نسخه برنامه و خروج.
فعال‌سازی هشدارها.
تولید کتابخانه واردسازی بدون استفاده از dlltool.

یک فایل spec باید حاوی فهرستی از اعلانات ترتیبی باشد. قالب کلی به صورت زیر است:

ordinal functype [flags] exportname ( [args...] ) [handler]
ordinal variable [flags] exportname ( [data...] )
ordinal extern [flags] exportname [symbolname]
ordinal stub [flags] exportname [ (args...) ]
ordinal equate [flags] exportname data
# comments

اعلانات باید در یک سطر جای گیرند، مگر اینکه انتهای سطر با استفاده از نویسه بک‌اسلش اسکیپ شده باشد. نویسه # در هر کجای سطر باعث می‌شود باقی‌مانده آن سطر به عنوان کامنت نادیده گرفته شود.

ordinal شماره ترتیبی متناظر با نقطه ورود را مشخص می‌کند، یا '@' برای تخصیص خودکار شماره ترتیبی (فقط Win32).

flags مجموعه‌ای از پرچم‌های اختیاری است که با نویسه '-' شروع می‌شوند. پرچم‌های پشتیبانی‌شده عبارتند از:

نقطه ورود در ردگیری‌های اشکال‌زدایی رله نمایش داده نمی‌شود (فقط Win32).
نقطه ورود به جای نام، با شماره ترتیبی صادر خواهد شد. نام همچنان برای واردسازی در دسترس است.
تابع یک مقدار ۱۶ بیتی برمی‌گرداند (فقط Win16).
تابع یک مقدار ۶۴ بیتی برمی‌گرداند (فقط Win32).
تابع از رجیستر CPU برای انتقال آرگومان‌ها استفاده می‌کند.
تابع نمی‌تواند از dllهای دیگر وارد شود؛ تنها از طریق GetProcAddress قابل دسترسی است.
نقطه ورود به جای نام، با شماره ترتیبی وارد خواهد شد. نام همچنان صادر می‌شود.
تابع از قرارداد فراخوانی thiscall استفاده می‌کند (اولین پارامتر در رجیستر %ecx روی i386).
تابع از قرارداد فراخوانی fastcall استفاده می‌کند (دو پارامتر اول در رجیسترهای %ecx/%edx روی i386).
تابع یک فراخوانی سیستمی NT است. یک تانک فراخوانی سیستمی تولید خواهد شد، و تابع واقعی توسط تابع __wine_syscall_dispatcher در ntdll فراخوانی می‌شود. شماره فراخوانی سیستمی می‌تواند صراحتاً تعیین شود؛ به طور پیش‌فرض به صورت متوالی از 0 تخصیص می‌یابد.
تابع از یک ماژول دیگر وارد می‌شود. این گزینه می‌تواند به جای مشخصه forward استفاده شود هنگامی که یک برنامه انتظار دارد پیاده‌سازی تابع را درون dll پیدا کند.
نقطه ورود تنها در معماری‌(های) CPU تعیین‌شده در دسترس است. نام‌های win32 و win64 به ترتیب با تمامی معماری‌های ۳۲ بیتی یا ۶۴ بیتی CPU مطابقت دارند. در dllهای ۱۶ بیتی، تعیین -arch=win32 باعث می‌شود نقطه ورود از ماژول بسته‌بندی ۳۲ بیتی صادر شود. نام یک CPU می‌تواند با ! پیشوند شود تا تنها آن معماری خاص مستثنی گردد.

نحو:
ordinal functype [flags] exportname ( [args...] ) [handler]

این اعلان یک نقطه ورود تابع را تعریف می‌کند. پیش‌نمونه تعریف‌شده توسط exportname ( [args...] ) نام در دسترس برای پیوند پویا و قالب آرگومان‌ها را مشخص می‌کند. به جای exportname می‌توان از '@' برای صادرات فقط-ترتیبی استفاده کرد.

functype باید یکی از موارد زیر باشد:

برای یک تابع عادی Win32
برای یک تابع عادی Win16
برای یک تابع Win16 یا Win32 با استفاده از قرارداد فراخوانی C
برای یک تابع Win16 یا Win32 با استفاده از قرارداد فراخوانی C با تعداد متغیر آرگومان‌ها

args باید یک یا چند مورد از موارد زیر باشد:

(مقدار ۱۶ بیتی بدون علامت)
(کلمه ۱۶ بیتی علامت‌دار)
(مقدار عدد صحیح به اندازه اشاره‌گر)
(مقدار عدد صحیح ۶۴ بیتی)
(مقدار عدد صحیح ۱۲۸ بیتی)
(مقدار ممیز شناور ۳۲ بیتی)
(مقدار ممیز شناور ۶۴ بیتی)
(اشاره‌گر خطی)
(اشاره‌گر خطی به یک رشته ASCII با پایان تهی)
(اشاره‌گر خطی به یک رشته Unicode با پایان تهی)
(اشاره‌گر قطعه‌بندی‌شده)
(اشاره‌گر قطعه‌بندی‌شده به یک رشته ASCII با پایان تهی).

توجه: انواع ۱۶ بیتی و اشاره‌گر قطعه‌بندی‌شده تنها برای توابع Win16 معتبر هستند.

handler نام تابع واقعی C است که آن نقطه ورود را در حالت ۳۲ بیتی پیاده‌سازی می‌کند. گرداننده همچنین می‌تواند به صورت dllname.function مشخص شود تا یک تابع ارجاع‌داده‌شده (تابعی که پیاده‌سازی آن در dll دیگری است) را تعریف کند. اگر handler تعیین نشود، فرض می‌شود که با exportname یکسان است.

این مثال اول یک نقطه ورود برای فراخوانی ۳۲ بیتی ()GetFocus تعریف می‌کند:

@ stdcall GetFocus() GetFocus

این مثال دوم یک نقطه ورود برای فراخوانی ۱۶ بیتی ()CreateWindow تعریف می‌کند (شماره ترتیبی 100 تنها یک مثال است)؛ همچنین نشان می‌دهد که چگونه سطرهای طولانی می‌توانند با استفاده از بک‌اسلش شکسته شوند:

100 pascal CreateWindow(ptr ptr long s_word s_word s_word \
s_word word word word ptr) WIN_CreateWindow

برای اعلان تابعی با استفاده از تعداد متغیر آرگومان‌ها، تابع را به عنوان varargs مشخص کرده و آن را در فایل C با یک پارامتر '...' برای تابع Win32، یا با یک آرگومان اضافی VA_LIST16 برای تابع Win16 اعلان کنید. برای نمونه به توابع *wsprintf در user.exe.spec و user32.spec مراجعه کنید.

نحو:
ordinal variable [flags] exportname ( [data...] )

این اعلان ذخیره‌سازی داده را به عنوان کلمات ۳۲ بیتی در شماره ترتیبی مشخص‌شده تعریف می‌کند. exportname نام در دسترس برای پیوند پویا خواهد بود. data می‌تواند یک عدد ده‌دهی یا یک عدد هگزادسیمال با پیشوند "0x" باشد. مثال زیر متغیر VariableA را در شماره ترتیبی 2 و حاوی ۴ عدد int تعریف می‌کند:

2 variable VariableA(-1 0xff 0 0)

این اعلان تنها در فایل‌های spec مربوط به Win16 کار می‌کند. در Win32 باید به جای آن از extern استفاده کنید (به زیر مراجعه کنید).

نحو:
ordinal extern [flags] exportname [symbolname]

این اعلان ورودی‌ای را تعریف می‌کند که صرفاً به یک نماد C (متغیر یا تابع) نگاشت می‌شود. این تنها در فایل‌های spec مربوط به Win32 کار می‌کند. exportname به نماد symbolname اشاره خواهد کرد که باید در کد C تعریف شده باشد. در حالت دیگر، می‌تواند به شکل dllname.symbolname باشد تا یک نماد ارجاع‌داده‌شده (نمادی که پیاده‌سازی آن در یک dll دیگر است) را تعریف کند. اگر symbolname تعیین نشود، فرض می‌شود که با exportname یکسان است.

نحو:
ordinal stub [flags] exportname [ (args...) ]

این اعلان یک تابع جانشین را تعریف می‌کند. این اعلان نام و شماره ترتیبی را برای پیوند پویا در دسترس قرار می‌دهد، اما در صورتی که این تابع فراخوانی شود، اجرا را با یک پیام خطا متوقف خواهد کرد.

نحو:
ordinal equate [flags] exportname data

این اعلان یک شماره ترتیبی را به عنوان یک مقدار مطلق تعریف می‌کند. exportname نام در دسترس برای پیوند پویا خواهد بود. data می‌تواند یک عدد ده‌دهی یا یک عدد هگزادسیمال با پیشوند "0x" باشد.

نحو:
apiset apiset_dll = target.dll [host.dll:target.dll]

این اعلان مشخص می‌کند که apiset_dll (به فرم api-ms-*) به target dll حل می‌شود. به صورت اختیاری می‌توان اهداف دیگری را تعیین کرد تا برای dllهای میزبان خاص به طور متفاوتی حل شوند. برای مثال:

api-ms-win-core-processenvironment-l1-1-0 = kernelbase.dll
api-ms-win-core-processthreads-l1-1-0 = kernel32.dll \
kernel32.dll:kernelbase.dll

اگر apisetها تعریف شده باشند، یک بخش .apiset متناظر در باینری PE تولید خواهد شد. این کار نیازمند ساخت ماژول با گزینه --data-only است.

winebuild طی سال‌ها توسط افراد زیادی توسعه یافته است. نویسندگان اصلی عبارتند از Robert J. Amstadt، Alexandre Julliard، Martin von Loewis، Ulrich Weigand و Eric Youngdale. بسیاری افراد دیگر نیز در افزودن قابلیت‌های جدید و رفع اشکالات مشارکت داشته‌اند. برای مشاهده فهرست کامل، گزارش‌های کامیت گیت را ببینید.

در حال حاضر استفاده از یک dll با فرمت PE در مشخصات واردسازی امکان‌پذیر نیست؛ تنها dllهای واین را می‌توان وارد کرد.

اشکالات را می‌توان در سامانه ردیابی اشکالات واین گزارش کرد.

winebuild بخشی از توزیع واین است که از طریق WineHQ در دسترس قرار دارد؛ مرکز توسعه واین.

wine(1), winegcc(1), wrc(1),
مستندات و پشتیبانی واین.

October 2005 Wine 11.17