جمع آوری زباله (Grabage Collection)
تخصیص حافظه در D کاملاً با جمعآوری زباله همراه است. تجربه شهودی بیان میکند که تعداد زیادی از خصوصیات ++C برای کنترل رهاسازی حافظه لازم است .با وجود جمعآوری زباله، زبان بسیار سادهتر میشود.
گروهی میگویند جمعآوری زباله برای جوجه برنامهنویس ها و تنبلها است. زمانی این حرف در مورد ++C گفته میشد. اما شاید هیچ چیز در ++C نیست که با C یا اسمبلر قابل انجام نباشد .
جمعآوری زباله ، کد خسته کننده پیگیری تخصیص حافظههای مستعد خطا که در C و ++C لازم است را حذف میکند. این نه تنها بدین معناست که گسترش برنامهها سریعتر انجام میگیرد و هزینههای نگهداری کاهش می یابد ، بلکه برنامه به میزان زیادی در دفعات اجرا سریع تر است.
با وجود اینکه D یک زبان دارای جمعآوری زباله است ، اعمال new و delete میتوانند طوری تعریف شوند که به عنوان یک تخصیص دهنده حافظه ی سفارشی به کار روند.
RAII یک تکنیک پیشرفته گسترش نرمافزار برای کنترل تخصیص منابع و آزادسازی آنها است ، D از RAII در یک روش کنترل شده قابل پیشبینی که مستقل از چرخه جمعآوری زباله است پشتیبانی میکند.
D ساختمانهای سبک ساده C را پشتیبانی میکند هم برای سازگاری با ساختمان دادههای C و نیز به خاطر اینکه آنها در جاهایی که قدرت کامل کلاسها کارایی ندارد مفیدند.
Inline Assembler
درایور سخت افزار ، کاربردهای سیستمی با کارایی بالا ، سیستم های تعبیه شده و کدهای خصوصی شده ، بعضی وقتها نیاز به غرق شدن در زبان اسمبلی دارند تا کار انجام شود . در حالی که پیاده سازی های D نیاز به کارگیری اسمبلر خطی ندارند ، این خصوصیت،در زبان تعریف شده و قسمتی از آن است . اغلب نیازهای کد اسمبلی به وسیله این بخش قابل برآوری است که نیاز به اسمبلرهای جداگانه و DLL ها را مرتفع می سازد .
همچنین بسیاری از پیاده سازی های D توابع اصلی را (شبیه به پشتیبانی ذاتی C از پردازش درگاههای ورودی خروجی ، دسترسی مستقیم به عملیاتهای ممیز شناور و …) پشتیبانی می کند .
قابلیت اعتماد
یک زبان پیشرفته باید برنامه نویس را در رفع تمامی اشکالات از کد یاری کند . این کمک به چندین صورت می تواند ارائه شود . از آسان سازی کاربرد تکنیکهای قدرتمند تر ، تا گوشزد کردن کد غلط به طور آشکارا توسط کمپایلر و کنترل زمان اجرا .
معاهدات ( Contracts )
طراحی به وسیله کنتراکت (اختراع B.Meyer ) یک تکنیک انقلابی برای کمک به مطمئن شدن از صحت برنامه است و نسخه DBC زبان D شامل پیش شرطهای توابع ، پس شرطهای توابع ، یکسانی های کلاس و کنتراکتهای ثابت کننده است .
آزمایش واحد
آزمایش قسمت ها می تواند به یک کلاس افزوده شود طوری که به صورت خودکار در آغاز اجرای برنامه ، اجرا شود . این در هشدار دادن اینکه پیاده سازی کلاس در هر بار ساخته شدن ،سهواً با شکست مواجه نشده است مفید است . آزمایش واحد قسمتی از کد کلاس را تشکیل می دهد. ایجاد آنها یک بخش طبیعی پروسه ی گسترش کلاس ها خواهد شد برخلاف پشت گوش انداختن کد تمام شده از دسترس گروه آزمایش.
آزمایش واحد در دیگر زبان ها قابل انجام است. اما تا خود زبان شامل این مفهوم نباشد، نتیجه جالب از آب در نمی آید . آزمایش واحد یک خصوصیت اصلی و بارز در D است . برای توابع کتابخانه ای به خوبی عمل می کند، هم ضمانت می کند که تابع حقیقتاً کار می کند و هم با مثال بیان می کند که تابع چگونه کار می کند . خیل کثیرمنابع کدهای کاربردی و کتابخانه های ++C موجود در اینترنت برای دانلود را در نظر بگیرید . چه تعداد از آنها با تستهای کلی همراه است ( تست واحد را هم در نظر نگیرید ) ؟ کمتر از یک درصد . روش معمول این است که اگر کامپایل شده است اجرا هم می شود و شگفت زده خواهیم شد اگر هشدارهای کامپایلر اشکالات واقعی باشند .
در کنار طراحی با کنتراکت ، آزمایش واحد ، D را به مراتب به بهترین زبان برای نوشتن قابل اعتماد و کاربردهای سیستمی قدرتمند تبدیل می کند.
اکنون اشکال زدایی بخشی از املای زبان است ( debug ) . که در زمان کامپایل قابل فعال یا غیر فعال شدن است بدون کاربرد دستورات پیش پردازنده یا ماکروها . املای debug یک ابزار تشخیص سازگار، استوار و قابل حمل و قابل فهم را فعال می کند که بفهمد آیا نیاز است که کد منبع قادر بر ایجاد هر دو کامپایل اشکال زدایی و کامپایل نهایی باشد ؟
مدل برتر try–catch-finally به جای مدل فقط try–catch به کار رفته است .دیگر هیچ نیازی نیست که اشیای زائد ایجاد کنیم فقط برای اینکه معناهای نهایی را توسط مخرب ( destructor ) پیاده سازی کنیم .
هماهنگی و هم روندی(Synchronization)
برنامه سازی چند رشته ای (Multi Thread Programming) متداول تر می شود و D مبناهایی برای ساخت برنامه های چند رشته ای فراهم می کند . هم روند سازی می تواند هم در سطح متد و هم در سطح شیئ انجام شود .
synchronize int func ( ) {.}
توابع هم روند (سنکرون) در هر زمان فقط به یک رشته (Thread) اجازه می دهند که آن تابع را اجرا کند . عبارت synchronize در اطراف قطعه ای از عبارات انحصار متقابل(mutex)ایجاد می کند و دسترسی به وسیله شیئ یا به صورت عمومی را کنترل می کند .
۱. آرایه های دینامیک به جای اشاره گر ها
۲. متغیرهای ارجاعی به جای اشاره گر ها
۳. اشیای ارجاعی به جای اشاره گرها
۴.جمع آوری زباله به جای کنترل دستی حافظه
۵. مبانی پیش ساخته موجود برای هم روندی رشته ها
۶. عدم وجود ماکرویی که به طور غیر عمدی به کد آسیب بزند .
۷. توابع inline به جای ماکروها
۸. کاهش وسیع نیاز به اشاره گرها
۹. سایز انواع مرکب واضح و مشخص است
۱۰. عدم شک در مورد علامت دار بودن کاراکتر ها
۱۱. عدم نیاز به دو بار اعلان در کد منبع و فایلهای header
۱۲. پشتیبانی واضح از تجزیه و تحلیل برای افزودن کد اشکال زدایی
۱. به طور واقع بینانه ، هیچکس قصد تبدیل میلیونها خط از C/++C به D ندارد و از آنجا که D کد منبع اصلاح نشده C/++C را کامپایل نمیکند ، برای این مورد مناسب نیست. (D به هرحال API های C را به خوبی پشتیبانی میکند).
۲. برنامه های خیلی کوچک : یک زبان اسکریپتی یا دارای مفسر مانند Perl , Dmdscript , Python احتمالاً مناسبتر است.
۳. به عنوان زبان برنامهنویسی برای شروع: برای مبتدیها Python یا java مناسبتر است . D برای برنامه نویسان متوسط تا پیشرفته یک زبان دوم عالی است .
۴. زبان به کاربرد کلمات صحیح وسواس دارد. D یک زبان عملی است و هر خصیصه از آن ترجیحاً قابل مقایسه و ارزیابی در همان حداست تا در حد ایدهآل . به طور مثال D ساختارها و مفاهیمی دارد که به طور مجازی نیاز به اشارهگرها را برای امور پیش پا افتاده ازبین میبرد. به طور مشابه تغییر نوعها هنوز وجود دارد برای آن جایی که سیستم نوع ، نیاز به نادیده گرفتن دارد.
خصوصیات اصلی D
این قسمت برخی خصوصیات جالبتر D(نسبت به C) را در دستههای مختلف طبقهبندی میکند.
کلاسها : طبیعت شییء گرای D از کلاسها آغاز میشود. مدل وراثت ، وراثت یگانه است که با روابط تقویت میشود. شییء کلاس در ریشهی درخت وراثت می نشیند. بنابراین تمام کلاسها یک مجموعه متداول تابعی را اجرا میکنند. کلاسها به وسیله ارجاع معرفی میشوند و چنان کد پیچیدهای برای آنکه پساز استثناها پاک شود نیاز نیست.
تعریف مجدد عملگرها: میتوان کلاس را برآن واداشت که با استفاده از عملگرهای موجود ، سیستم نوع را برای پشتیبانی نوعهای جدید گسترش دهد. مثلاً ایجاد کلاس اعداد بزرگ و سپس تعریف مجدد عملگرهای (/,*,_,+) برای توانایی استفاده از آن ها در املای عبارات جبری معمولی.
فراوری( Productivity)
پیمانهها : فایلهای منبع دارای ارتباطی یک به یک با پیمانهها هستند. به جای include# نمودن یک فایل از اعلان ها ، فقط پیمانه را import مینماییم. هیچ نگرانی در مورد importهای متعدد از همان پیمانه نیست همچنین نیازی به پوشاندن فایلهای header با ifndef# یا endif# یا pragma once# و از این قبیل نیست.
اعلان در برابر تعریف
++C معمولاً نیاز دارد که توابع و کلاسها دوبار اعلان شوند یک اعلان که در فایلهای header صورت میگیرد و تعریف که در فایل منبع با پسوند “C.” . این یک روند مستعد خطا و کسل کننده است . به طور واضح برنامهنویس فقط نیاز دارد که یک بار آن را بنویسد و سپس کامپایلر باید دادههای اعلان را بسط دهد و برای وارد کردن نمادین در دسترس قرار دهد. دقیقاً آن گونه که D میکند:
مثال:
class ABC
{
int func() { return 7; }
static int z = 7;
}
int q;
دیگر نیاز به تعریف جدای توابع عضو، اعضای استاتیک ، extern ها یا املاهایی مانند زیر نیست:
int ABC::func() { return 7; }
int ABC::z = 7;
extern int q;
تذکر : البته در ++C توابع جزیی مانند {;return 7} به صورت inline هم نوشته میشوند اما توابع پیچیده نه. علاوه برآن اگر یک ارجاع بعد از آن موجود باشد تابع نیاز به الگو دارد که از قبل موجود باشد مثال زیر در ++C کار نمی کند.
class Foo
{
int foo(Bar *c) { return c->bar; }
};
class Bar
{
public: int bar() { return 3; }
};
اما کد همارز در D کار می کند:
class Foo
{
int foo(Bar c) { return c.bar; }
}
class Bar
{
int bar() { return 3; }
}
اینکه یک تابع D به صورت inline است یا نه توسط تنظیمات بهینهساز قابل کنترل است .
قالبهای D روشی واضح برای پشتیبانی برنامهسازی عمومی همراه با قدرت اختصاصیسازی به صورت قسمت به قسمت ، پیشنهاد میکند.
آرایههای شرکتپذیر
آرایههای شرکتپذیر آرایههایی هستند با یک نوع داده قراردادی (اختیاری) به عنوان ایندکس به جای آنکه به یک ایندکس از نوع اعداد صحیح محدود باشند. در اصل آرایههای شرکتپذیر جدولهای در هم سازی(hash ) هستند. این آرایهها ساختن سریع ، کارا و خالی از اشکال جدولهای سمبل را آسان مینماید.
تعریف نوعهای C و ++C در حقیقت نام مستعار نوع هستند طوریکه هیچ نوع جدیدی به طور واقعی مطرح نمیشود. D ، تعریف نوعهای واقعی پیادهسازی میکند جایی که:
typedef int handle;
به طور واقعی یک نوع جدید به نام handle ایجاد میکند . بر کنترل نوع تأکید شده است و تعریف نوعها در تعریف مجدد توابع شریک میشوند. برای مثال :
int foo(int i);
int foo(handle h);
نوع bit
نوع داده پایه بیت است و D یک نوع داده با نام bit دارد . این امر بیش از همه در ساخت آرایههایی از بیتها مفید است:
bit [ ] foo;
D توقع پشتیبانی از توابع معمول از جمله توابع عمومی ، توابع مجدد تعریف شده ، توابع inline ، توابع عضو ، توابع مجازی ، اشارهگرها به توابع و … را داشته است علاوه برآن :
توابع میتوانند درون توابع دیگر قرار گیرند. این امر در ساخت کد ، خاصیت locality و تکنیکهای بستهبندی توابع بسیار مفید است.
لفظهای توابع Functionliterals
توابع بینام میتوانند به طور مستقیم در یک عبارت جای داده شوند.
توابع محصور شده و توابع عضو کلاس بوسیله وکالت (delegate) میتوانند ارجاع داده شوند که این باعث آسان تر شدن و type safe شدن برنامهسازی عمومی میشود.
این خصوصیسازی نه تنها کمک میکند که توابع خود مستندتر شوند بلکه بسیاری از موارد لزوم اشارهگرها را بدون قربانی کردن هیچ چیز حذف و امکاناتی را برای کمک بیشتربه کامپایلر در پیدا کردن اشکالات کد فراهم میکند.
بدین ترتیب برای D این امکان فراهم میشود که مستقیماً با یک بازه وسیعتری از APIهای بیگانه ارتباط برقرار کند. و هیچ نیازی برای کارهای جانبی مانند زبانهای تعریف ارتباطات وجود ندارد.
آرایههای C اشتباهات متعددی دارند که میتوانند تصحیح شوند:
۱. اطلاعات بعد با آرایه همراه نیست و بنابراین باید ذخیرهشده و جداگانه ارسال شود . مثال کلاسیک این مورد پارامترهای argc و argv هستند که به main فرستاده میشوند.
main (int argc , char*argv[])
۲. آرایهها اشیاء سطح اول نیستند. وقتی یک آرایه به عنوان پارامتر به یک تابع فرستاده میشود به یک اشارهگر برگردانده میشود . حتی با اینکه الگوی تابع به طور گیج کنندهای می گوید که این آرایه است. وقتی این برگرداندن انجام میشود تمام اطلاعات نوع آرایه گم میشود.
۳.آرایههای C قابل تغییر اندازه نیستند . این بدان معنی است که حتی چیزهای ساده ،انبوه و متراکم میگردد. مانند یک پشته که نیازدارد به عنوان یک کلاس پیچیده ساخته شود.
۴.مرز یک آرایه C قابل کنترل نیست چون اصلاً مرز آرایه مشخص نیست.
۵.آرایهها در C با علامت [ ] پس از شناسه اعلان میشوند . این به یک املای بیخود و گیج کننده در اعلان اشیایی مانند اشارهگر به یک آرایه میانجامد :
int (*array ) [3];
در D علامت [ ] در سمت چپ قرار میگیرد که فهم آن بسیار سادهتر است.
int [3] * array; // اعلان یک اشارهگر به یک آرایه سهتایی از اعداد صحیح
Long [ ] func (int x); //تابعی که آرایه ای از اعداد صحیح بلند را برمی گرداند
آرایههای D در چهار نوع میآیند : اشارهگرها ، آرایههای استاتیک ، آرایههای دینامیک و آرایههای شرکتپذیر ،قسمت آرایهها را ببنید !
پردازش رشتهها آن قدر متداول است (و آن قدر در C و ++C زمخت و بدترکیب) که نیازمند پشتیبانی مستقیم در زبان برنامه سازی است. زبانهای مدرن از جمله D ، الحاق رشتهها ، کپی کردن و … را در دست میگیرند . رشتهها رهاورد مستقیم پردازش بهینه شده آرایهها هستند.
D چیست؟
D یک زبان برنامهسازی سیستمی و کاربردی همه منظوره است . D یک زبان سطح بالاتر از ++C است اما توانایی نوشتن کدهای قدرتمند و تعامل مستقیم با APIهای سیستم عامل و سخت افزار را حفظ میکند.D به خوبی برای نوشتن برنامههای متداول و برنامههای بزرگ چند میلیون خطی با تیمهای برنامه نویسی مناسب است . D به آسانی قابل آموختن است ، توانائیهای زیادی را برای کمک به برنامه نویس فراهم میکندوبه خوبی برای فناوری پرتکاپوی بهینهسازی کامپایلر مناسب است.
D یک زبان اسکریپتی(متنی) یا دارای مفسر(interpreter) نیست. همچنین دارای ماشین مجازی ، مذهب خاص یا فلسفه برتریجویی نمی باشد. بلکه یک زبان عملی است برای برنامه نویسان حرفهای که به انجام سریع و قابل اعتماد پروژه و کد قابل فهم آسان نیاز دارند و مسئول عملکرد صحیح برنامه هستند.
D اوج چند دهه تجربه به کارگیری کامپایلرهایی از زبانهای گوناگون و تلاش برای بنانهادن پروژه های بزرگ توسط آن زبانها است.
D از زبانهای دیگر مخصوصاً ++C الهام میگیرد و آن را با تجربه و کاربرد به معنای واقعی درهم میآمیزد.
چرا D ؟
واقعاً چرا؟ چه کسی نیاز به زبان برنامه نویسی جدید دارد؟
صنعت نرم افزار راه درازی از زمان اختراع زبان C تا کنون پیموده است. به وسیله ++C تعداد زیادی مفاهیم جدید به زبان C افزوده شد. اما سازگاری با گذشته C در آن ادامه یافت ، شامل سازگاری با تقریباً تمام ضعفهای طراحی اصلی زبان C .
تلاشهای زیادی برای برطرف ساختن آن ضعفها تاکنون صورت گرفته است اما در پی پا فشاری بر حفظ سازگاری با گذشته خنثی شده است. در ضمن هر دوی C و ++C دستخوش یک رشد پیوسته خصوصیات جدید شده اند.
این خصوصیات جدید باید به دقت و بدون نیاز به بازنویسی کد قدیمی به ساختار موجود خورانده شود. نتیجه نهایی بسیار پیچیده است ؛ C استاندارد تقریباً 500 صفحه است و ++C استاندارد حدود 750 صفحه ! در زمینه کامپایلر های ++C واقعیت این است که تعداد اندکی از کامپایلر های موجود ،استاندارد این زبان را به صورت مؤثر و کامل پیاده سازی می کنند.
برنامه نویسان ++C گرایش می یابند که در جزایر خاصی از زبان برنامه بسازند ، از بعضی خصوصیات ماهرانه بهره می گیرند در حالی که از به کار بردن بسیاری از خصوصیات دیگر اجتناب می کنند. با وجود اینکه کد ++C از یک کامپایلر به کامپایلر دیگر قابل حمل است میتواند به سختی از برنامه نویسی به برنامه نویس دیگر منتقل شود.
توانایی بزرگ ++C این است که میتواند تعداد زیادی سبک های اصلی برنامهنویسی را پشتیبانی کند. اما در کاربرد طولانی مدت ، سبکهای دارای اشتراک یا تناقض یک مانع و در نتیجه وقت گیرند.
ناامید کننده است که زبانی چنین قدرتمند ، اعمال پایها ای مانند تغییر اندازه آرایهها و الحاق رشتهها را انجام نمیدهد. البته ++C توانایی برنامه نویسی قدرتمند برای پیاده سازی آرایه های قابل تغییر اندازه و رشته ها را فراهم میکنند (مانند نوع بردار در STL ) . اما به هرحال چنین خصوصیات بنیادی ، بایستی جزء قسمتهای زبان باشد. آیا قدرت و قابلیتهای ++C ، قابل گسترش ، طراحی مجدد و پیادهسازی به یک زبان ساده وارتگنال (منحصر به فرد و مستقل) و کاربردی می باشد؟ آیا تمامی آنها می تواند داخل بسته ای قرار گیرد که برای کامپایلرنویسان به آسانی قابل پیادهسازی صحیح باشد و کامپایلرها را قادر کند که به نحوی کارا ، کدهای بهینه شده و پرتکاپو ایجاد کند؟
فناوری پیشرفته کامپایلر به نقطهای رسیده است که خصوصیاتی از زبان که به منظور جبران کردن ناتوانی فناوری ابتدایی کامپایلر وجود دارند ، میتوانند حذف شوند. (مثالی ازاین نمونه میتواند واژه کلیدی 'register' در C باشد ، مثالی ظریفتر ماکروی پیشپردازنده در C است) . ما میتوانیم به فناوری پیشرفتهی بهینه سازی کامپایلر اعتماد کنیم تا دیگر به خصوصیاتی از زبان که برای دست یافتن به کیفیت کد قابلقبول (جدای از کامپایلرهای ابتدائی) لازم است نیاز نداشته باشیم.
D درنظر دارد که هزینههای گسترش نرمافزار را حداقل %10 کاهش دهد توسط افزودن خصوصیات بهینهسازی بالابرنده میزان سودمندی و تولید ، همچنین با تعدیل کردن خصوصیات زبان ، به طوری که اشکالات وقتگیر متداول از ابتدا حذف میشوند.
منظره کلی D شبیه C و ++C است . این موضوع آموختن D و انتقال کد به آن را آسانتر میکند. گذر از C/++C به سوی D باید طبیعی حس شود و برنامه نویس مجبور نخواهد بود که یک راه کاملاً جدید انجام کارها را فراگیرد. استفاده از D به این معنا نیست که برنامه نویس به یک ماشین مجازی خاص زمان اجرا محدود شود مانند ماشین مجازی جاوا یا Smalltalk . هیچ ماشین مجازی D وجود ندارد .D یک کامپایلر سرراست است که Objectfile های قابل پیوند (Link) تولید میکند. D دقیقاً مانند C به سیستم عامل متصل میشود . ابزارهای آشنای متداول مانند make مستقیماً در برنامهنویسی D گنجانده شده است.
منظره عمومی و احساس موجود در C/++C ابقا خواهد شد . همان املای جبری به کار خواهد رفت و اغلب عبارات و فرمهای دستورات و طرحبندی عمومی. برنامههای D هم به سبک C (توابع و دادهها) و هم در سبک ++C (شیءگرا) یاترکیبی از هردو قابل نوشتن است .
D برای چه کسانی مناسب است؟
۱. برنامه نویسانی که به طور مداوم از ابزارهای تجزیه و تحلیل کد استفاده میکنند تا خطاها را حتی قبل از کامپایل شدن ازبین ببرند.
۲. افرادی که عمل کامپایل را با بالاترین سطح هشدارها انجام میدهند یا از کامپایلر میخواهند که هشدارها را به منزله خطا تلقی کند.
۳. مدیران برنامهنویسی که مجبورند به راهنماییهای سبک برنامهنویسی برای اجتناب از اشکالات معمول C اعتماد کنند.
۴. افرادی که براین باورند که وعدههای سبک شییءگرای ++C به خاطر پیچیدگی هایش برآورده نمیشود.
۵. برنامهنویسانی که از قدرت زبانزد ++C لذت میبرند اما به خاطر نیاز به صرف تلاش زیاد برای اداره حافظه و یافتن اشکالات اشارهگرها ، ناامید شدهاند.
۶. پروژههایی که نیاز به تست همراه و تصدیق و تأیید دارند.
۷. برنامهنویسانی که فکر می کنند زبان باید دارای خصوصیات کافی باشد . برای رفع نیاز دائمی اداره دستی و مستقیم اشارهگرها.
۸. برنامهنویسان محاسبات عددی . D دارای خصوصیات زیادی برای پشتیبانی مستقیم اعمال مورد نیاز برنامه نویسان محاسبات میباشد ، مانند پشتیبانی مستقیم از نوع داده مرکب و اعمال تعریف شده برای بینهایت و NAN’S (این خصوصیات در استاندارد C99 اضافه شد ولی در ++C نه)
بخش تجزیه لغوی و تجزیه نحوی D از یکدیگر در نهایت مجزا هستند و همچنین از تجزیهگر معنایی.
این بدین معناست که نوشتن ابزارهای ساده برای اداره کردن کد منبع D در سطح عالی آسان است بدون این که مجبور به ساختن یک کامپایلر کامل باشیم . همچنین بدین معناست که کد منبع ،برای کاربردهای خاص قابل انتقال به فرم tokenها می باشد.
تعدادی نرمافزار و امکانات اضافی برای هسته لینوکس ارائه شده است. یکی از این امکانات برای توسعه دهندگان نرمافزار، آزمایش کنندگان بتا، نویسندگان و بررسی کنندگان محصولات، سرویسهای فضای اینترنتی و... بسیار ارزشمند است. این امکان User Mode Linux یا اختصارا UML نامیده میشود. UML همانند Vmware، این امکان را فراهم میکند تا ماشینی را در یک ماشین دیگر اجرا نماییم. یعنی در آن واحد چندین نسخه مجزا و ایزوله شده لینوکس در حال اجرا روی یک سیستم واحد باشند.
نام این امکان چندان تشریح کننده عملکردش نیست. به این دلیل User Mode Linux نامیده شده است که در فضای کاربر یا User Space اجرا میشود. به کمک UML شما قادر خواهید بود تا یک سیستم مینیاتوری لینوکس را که دارای هسته و فایل سیستم خودش است را اجرا نمایید، بدون اینکه نیازی به داشتن مجوز ریشه روی تمام سیستم باشید. UML شما دنیای کوچک خودتان است و شما میتوانید هسته آنرا تنظیم کنید، شبکه بندی آنرا ایجاد نمایید و تمامی کارهای دیگر را میتوانید با این ماشین مجازیتان انجام دهید!
شما به یک توزیع خاص و یکسان لینوکس محدود نیستید. در حالی که Vmware به شما اجازه اجرای انواع مختلف سیستمعاملها را در فضای ماشین مجازی میدهد، UML به شما اجازه اجرا و نصب هر نوع توزیع و فایل سیستم لینوکس را میدهد. به این صورت که شما هسته UML را همانند تمامی دستورات معمولی سیستم اجرا میکنید و سپس هسته UML با هسته ماشین مادر ارتباط برقرار میکند. فقط هنگامی که یک بسته خاص نیاز به برقراری ارتباط مستقیم با سختافزار داشته باشد، ممکن است مشکلی پیشآید ولی برای این مشکلات نیز راهحلهایی وجود دارد.
فایل سیستم UML شما در حقیقت بصورت یک فایل به ازای هر UML ای است که اجرا میکنید. یعنی کل فایل سیستم هر UML در یک فایل مجزا قرار میگیرد. در بین هسته و فایل سیستم ایزوله شده، UML میتواند همانند جزیرهای عمل کند که کاربران میتوانند در آن وارد شوند، ولی نخواهند توانست به سیستم اصلی دست پیدا کنند. در صورت که اشکالی پیشآید، تنها UML دچار مشکل خواهد شد و هسته و فایل سیستمهای اصلی بدون تغییر باقی خواهند ماند.
موارد استفاده متعدد
چندین مورد استفاده برای امکانی مانند UML وجود دارد. مثلا برای آزمایش کنندگان بتا که دائما باید با نرمافزارهای مختلف سرو کله بزنند، UML یک امکان ایدهآل به شمار میرود. آنها مجبور نیستند نرمافزارها را بر روی ماشین خودشان و یا سیستم دیگری که ممکن است دورتر از دسترسشان باشد آزمایش کنند. نرمافزارهای آزمایشی را میتوان در یک نشست UML اجرا نمود بدون اینکه به سیستم اصلی آسیبی برساند و همه چیز (سیستم اصلی و سیستم مجازی) بصورت یکجا و همزمان قابل استفاده است.
UML برای هنگامی که شما به یک سرویس خاص اطمینان کافی ندارید بسیار مناسب است. آیا میترسید کسی به FTP Server شما نفوذ کند؟ کافی است آنرا در یک فضای UML اجرا نمایید. حتی اگر چنین اتفاقی رخ دهد، سیستم اصلیتان محفوظ است. آیا از هشدارهای امنیتی BIND نگران هستید؟ آنرا هم در یک UML قرار دهید.
البته نکته مهمی که در استفاده از UML باید در نظر داشته باشید دارای بودن حافظه کافی است. هر UML همانند هسته اصلی سیستم برای اجرا کردن برنامههای خود نیازمند حافظه جداگانهای است. بنابراین داشتن مقدار زیادی حافظه RAM به شما کمک زیادی خواهد کرد.
افت سرعت هنگامی که تعداد زیادی UML رد یک ماشین درحال اجرا باشد قابل ملاحضه است. در صورتی که تعداد زیادی UML در حال اجرا باشند، به سرعت حافظه سیستم به پایان خواهد رسید. برای جلوگیری از چنین رخدادی، شما امکان تخصیص جداگانه حافظه به هر یک از UML ها را دارا هستید. بنابراین سرویسهای مهمتر میتوانند از مقدار حافظه بیشتری بهرهمند گردند. به مجموع UML های روی یک ماشین ممکن است از مقدار حافظه موجود روی سیستم حافظه بیشتری تخصیص داده شده باشد. مشکلی نیست. هسته اصلی سیستم این درخواستها را همانند درخواستهای swap انجام میدهد. حتی این امکان وجود دارد که برای هر یک از UMLها یک فضای swap نیز اختصاص دهید.
آزمایش UML
ممکن است که UML هنوز کیفیت خیلی بالایی نداشته باشد، ولی به طور گسترده توسط آزمایش کنندگان بتا استفاده میشود که بیشترین رضایت را از آن دارند. برای نصب آن میتوانید از بستههای RPM یا دبیان موجود و یا کامپایل کد منبع استفاده نمایید. ولی قبل از انجام آن حتما مطالعه و بررسی زیادی را انجام دهید.
نصب UML شامل دو مرحله است. نصب هسته و ابزارهای UML سپس نصب سیستمفایل آن. نصب هسته UML در یک سیستم مبتنی بر دبیان بسیار آسان است:
# apt-get install user-mode-linux
البته شما میتوانید به سادگی بستههای UML را از سایت http://packages.debian.org دریافت و نصب نمایید. در صورتی که از یک توزیع مبتنی بر RPM استفاده میکنید، کافی است به سایت پروژه UML مراجعه کرده و آنرا دانلود و نصب نمایید:
# rpm -ivh user_mode_linux
که بجای user_mode_linux باید نام کامل بسته را وارد نمایید. پس از نصب هسته UML همانطوری که گفته شد باید سیستم فایل UML را در سیستم خود اضافه نمایید. این فایل سیستم بسته به نوع توزیعی که مایلید از آن استفاده نمایید متفاوت خواهد بود. این فایل سیستمها نیز در صفحه دانلود صفحه پروژه UML موجود میباشند. این فایل سیستمها بصورت فایلهای bz2 ارائه شدهاند که باید با استفاده از دستور bzip2 آنها را از حالت فشرده خارج نمایید.
بطور پیشگزیده، UML فرض میکند که شما در حال اجرای X هستید و از داخل X میخواهید آنرا اجرا نمایید. بنابراین در صورتی که بخواهید بدون X آنرا اجرا نمایید با پیغام خطایی مواجه خواهید شد. البته امکان اجرای UML ها در محیط متنی خالص و بدون GUI نیز وجود دارد ولی برای انجام آن به تنظیمات جداگانهای نیاز میباشد.
هنگامی که تمامی اقلام مورد نیاز را نصب کردید، آسانترین راه برای اجرای UML از درون X تایپ دستوری مشابه زیر است:
$ linux ubd0=/path/to/unpacked/filesystem
هنگامی که UML شما شروع به کار کرد، پنجره کنسول مخصوص به خودش را باز میکند که نمونهای از آن را در تصویر زیر مشاهده میکنید. به صورت پیشگزیده دو حساب مختلف در UML فعال میباشد. حساب root با نام کاربری root و حساب user با کلمه عبور user که باید آنها را تعویض نمایید.
در صورتی که تنها میل به آزمایش UML باشید همین حد اطلاعات برای شما کفایت میکند. ولی برای اینکه آنرا در امور جدی مانند ایجاد ماشینهای مجازی که روی شبکه موجود باشند و سایر امور جدی بکار ببرید به اطلاعات بیشتری مانند نحوه شبکه بندی و ... نیاز خواهید داشت که در آینده به آنها خواهیم پرداخت. البته اکنون میتوانید از مستندات موجود در سایت پروژه UML استفاده نمایید.
در صورتی که نمیخواهید به خودتان دردسر نصب UML را بدهید، راهحل سادهتری نیز برای آزمایش آن وجود دارد. دیسک زندهای به نام Adios. یکی از قابلیتهایی که این دیسک زنده استثنایی ارائه میکند، User Mode Linux است. همه چیز آماده است! کافی است که سیستم خود را با استفاده از آن بوت کنید و سپس در منوی KDE روی آیکون User Mode Linux کلیک کنید. با هر کلیک، یک سیستم UML بوت و اجرا خواهد شد که قادر خواهید بود از آن استفاده نمایید. در صورتی که به UML علاقه مند شدهاید، توصیه میکنم که حتما نگاهی به آن بیاندازید.

منبع:http://technotux.com
نویسنده: Scott Lowe
مقدمه:
برخی ازسازمانها در حال تجربه نسخههایی از لینوکسهای رومیزی هستند؛ اما بیشتر کاربران هنوز برای انجام کارهایشان به برنامههای کاربردی ویندوز نیاز دارند که برنامه مشابه ای در لینوکس ندارند. یکی از گزینههای موجود برای این برنامههای کاربردی استفاده از ابزارWine است. در اینجا به بیان مزایای استفاده از این ابزار میپردازیم:
واژه Wine به اختصار مخفف 5 کلمه انگلیسی است که مفهوم نهایی آن را میتوان اینچنین تعریف کرد: "Wine Is Not an Emulator." (واین یک تقلید کننده نیست) . در واقع این عبارت یک کلمه ترکیبی زیرکانه برای برنامه Wine است که به شما کمک میکند تا برنامههای ویندوز را در محیط لینوکس اجرا کنید. Wine در حقیقت یکی از ابزارهای API ویندوز است که به برنامه مورد نظر شما اجازه میدهد تا با استفاده از API در محیط سیستم عامل دیگری اجرا گردد البته با این نکته که اساسا از آن برنامه پشتیبانی نمیکند. شایان ذکر است که Wine از سیستمهای مبتنی بر x86 بصورت کامل پیروی نمیکند. اما زمینه را برای اجرای نرم افزارهای API جهت بکار گیری برنامههای ویندوز فراهم میسازد. همچنین به علت خاصیت غیر تقلیدیWine برنامهها با سرعت مناسبی اجرا میشود. در حالی که فرایند تقلیدسازی معمولا باعث کندی اجرای برنامهها میشود. حال با نصب Wine در محیط سیستم عامل لینوکس میخواهیم چگونگی اجرای برنامههای کاربردی معمول در ویندوز را بیشتر بررسی کنیم:
بارگذاری و نصب برنامه:
در این مثال برای بیان مقصود خود از سیستم Red Hat Linux 9 استفاده میکنیم. آخرین نسخه Wine را از سایت www.winehq.com دریافت کرده و بسته RPM آن را در محیط لینوکس اجرا میکنم. به نسخه ای از Wine نیاز داریم که glibc 2.3 را پشتیبانی نماید. در هنگام نوشتن این مقاله نسخه موجود در سایت Wine تنها قابلیت پشتیبانی از glibc 2.2 را دارا بود. به هرحال نسخه مورد نیاز در سایت Wine با لینک به یک سایت دیگر میتوانید بیابید. برای نصب نسخه RPM که از اینترنت دریافت کردیم و با توجه به اینکه پردازشگر کامپیوتر مورد اشاره Athlon است دستور زیر را در خط فرمان تایپ کنید.
$ rpm –i wine-2003011-1rh9winehq.athlon.rpm
اگر شما از نسخه دیگری از Red Hat استفاده میکنید و یا پردازشگر شما از انواع دیگری است؛ باید فایل مناسب را دریافت نمایید. در سیستم ذکر شده؛ مرحله نصب بصورت کامل صورت گرفت.
چه کارهایی صورت گرفت؟
پس از مرحله نصب RPM ، ابزار Wine پیکره بندی و در مسیر /usr/share win-c آماده اجرای برنامههای Windows میشود. در حقیقت Wine چندین برنامه کاربردی مشترک مانند Notepad و بازی (مهم!) Minesweeper را نیز نصب میکند.
چنانچه شما تصمیم به کامپایل Wine به جای نصب RPM داشته باشید ، ممکن است آدرس این مسیر متفاوت باشد. شکل شماره ۱ اجزای آشنای این مسیر را نشان میدهد. همانگونه که مشاهده میشود؛ زیرشاخههای مشترک ویندوز ساخته شده است و Wine از این زیرشاخهها برای نصب برنامهها ی مورد نظر استفاده میکند.
شکل شماره ۱

چنانچه اشاره شد؛ حال برنامه Notepad نصب شده است. برای اجرای آن در قسمتRun Program… ، نام برنامه Notepad را تایپ کنید. از آنجایی که Notepad توسط Wine آماده شده؛ میتوانید آن را به صورت مستقیم فراخوانی کنید. البته این موضوع در مورد سایر برنامهها صادق نیست. شکل شماره ۳ برنامه Notepad بر روی لینوکس را نمایش میدهد. به هر حال کندی سرعت ماوس در زمان اجرای برنامه امری بدیهی است و زمانی که شما فایلی را برای اولین بار باز میکنید اشاره گر به کندی حرکت میکند.
شکل شماره ۲

و اما اجرای سایر برنامههای کاربردی:
هر چند Notepad برای حصول انجام کارهای متنی مناسب است اما احتمالا شما تصمیم به نصب سایر برنامههای مفیدتر نیز در محیط لینوکس خواهید داشت. مجموعه نسبتا زیادی از برنامهها (بالغ بر 1604 برنامه در هنگام نوشتن این مقاله) در بانک اطلاعاتی Wine لیست شده بود. آما این بدین معنی نیست که همه این برنامهها به خوبی اجرا شوند بلکه مستلزم صرف زمان و سعی زیادی توسط کاربران میباشد.
نصب برنامهها با استفاده از ابزار Wine مسلما زمان و تلاش فراوانی را میطلبد. بعضی اوقات تنها قراردادن CD در درایو و اجرای برنامه نصب کافی نیست. به هر حال باید بسیار تلاش کنید و در صورتی که به اندازه کافی خوش شانس باشید میتوانید شاهد اجرای برنامههای مورد نظرتان در محیط لینوکس باشد. این همان هزینه ای است که برای نصب برنامه در محیط سیستم عاملی که اساسا برای آن برنامه طراحی نشده است خواهید پرداخت. به عنوان مثال، در اینجا تصمیم به نصب یک نسخه غیر نهایی از برنامه JASC's Paint Shop Pro 8 گرفته میشود.
Paint Shop Pro 8
ابتدا، از سایت JASC این نسخه را دریافت میکنیم. سپس با استفاده از دستور زیر آن را اجرا کنید:
$ /usr/bin/wine psp801ev.exe
در این دستور psp801ev.exe نام فایل مورد نظر میباشد. در شکل ۳ پنجره نصب ویزارد را میبینید.
شکل شماره ۳

در هنگام نصبPaint Shop Pro 8 در پنجره ویزارد، مسیر "C: drive" نمایش دهنده مکانی است که Wine قرار دارد. متاسفانه این زمانی است که بدون تشریفات کاربر را به خط فرمان Wine بر میگرداند. در این شرایط، با تایپ دستور quit از پنجره دستورات خطی خارج شده و نصب برنامه متوقف میشود. در این هنگام که با تعداد بسیار زیادی از پیامهای خطا یا "errors " که در پنجره دستورات وجود دارد بر خورد میکنیم . این پیامها موقع نصب Wine/PSP8 ایجاد شده اند.
فکر میکنیم شاید عدم نصب کامل برنامه Paint Shop Pro 8 به علت جدید بودن آن نرم افزار یا به خاطر قابلیتهای جدید آن بوده که Wine نمیتوانسته است از آن قابلیتها پشتیبانی کند. بنابراین نسخه 7 آنرا را از روی CD نصب کنید اما مجددا مانند نمونه قبل بی نتیجه خواهد بود.
در قسمت پشتیبانی سایت Wine به راهنمای نصب PSP7 مراجعه کردم. متاسفانه در آنجا فقط نسخه معینی از PSP7 وجود داشت. مشکل اصلی اجرای برنامه PSP7 نحوه اجرای آن تحت Wine است که اساسا مبتنی بر نصب بر روی سیستم ویندوز است. مشکل بعدی کپی کردن کامل فایلهای در حال نصب به registry key بر روی سیستم لینوکس میباشد.
زمانی که سعی دارید این مشکل را حل کنید و هر بار با مشکل به هم ریزی Regedit رو به رو میشوید؛ مجددا registry keys را که PSP7 لازم داشت فراهم کنید.
نرم افزار که بتواند کار را به خوبی انجام دهد:
در سایت Wine شما لیستی از نرم افزارهای کوچک و غیر اساسی را مشاهده میکنید. این برنامهها شامل PuTTY WS-FTP LE، mIRC، Acrobat Reader 5.05 ، WinZip، WinAmp، و SnagIt. گر چه با همه احترامیکه به این کاری که انجام میشود قائل هستم اما به اهمیت که این برنامههای ویندوز در لینوکس مطمئن نیستم مخصوصا زمانی که برنامههای مشابه به این برنامهها در لینوکس است و همه این کارها را به خوبی در لینوکس انجام میدهند. با این وجود من شخصا ترجیح میدهم که از Microsoft Office به جای OpenOffice استفاده کنم مخصوصا وقتی که توابع و کارهای متفاوتی بین این دو نرم افزار باعث سردرگمیکاربران میشود. همچنین من ترجیح میدهم از برنامههای موجود در خود سیستم عامل استفاده کنم حال آن که بیشتر کاربران در صدد هستند تا از Wine برای اجرای برنامههای کابردی ویندوز استفاده کنند مخصوصا وقتی که مشابه آن برنامهها در لینوکس وجود ندارد.
نتیجه:
سوال این است که میتوان Wine را به عنوان یک محیط تولید مناسب برنامههای کابردی تلقی کرد؟ متاسفانه پاسخ منفی است. با وجود همه احترامیکه من به تلاش برنامه نویسان این پروژه قائل هستم اما این محیطی است پر دردسر برای کاربران که سرانجام به خروجیهای ناقص به جای اجرای برنامههای کاربردی ختم میشود. یک خانه کاغذی که به تنهایی باعث تولید برنامههایی اکثرا نا کارآمد که معظلاتی برای تیمهای متخصص پشتیبانی کامپیوتر و همچنین باعث مشکلاتی برای کاربران میشود. مطمئنا شما نیز هم عقیده هستید که اجرای یک برنامه مستلزم یکسری فرآیند منطقی است اما رفع مشکلات یک نرم افزار بسیار پیچیده تر از اجرای آن و مستلزم عیب یابی همه عوامل مرتبط با آن نرم افزار میباشد. در ضمن برای اجرای یک برنامه کاربردی شما بایدDLLهای مربوط به آن را نیز بر روی دایرکتوری مناسب آن برنامه در محیط Wine کپی نمایید.
من شخصا کار با برنامه CrossOver Office 2 محصول CodeWeaversرا ترجیح میدهم ( www.codeweavers.com/products/office).
با این برنامه شما تعدادی از برنامههای مفید ویندوز مانند Microsoft Office 2000 را به خوبی میتوانید اجرا کنید. همچنین برنامه Paint Shop Pro 8 نیز به خوبی بوسیله CrossOver Office 2 قابل اجراست. همچنین از برنامههای غیر سودمند مانند mIRC و WS-FTP LE که Wine به خوبی پشیبانی میکنند اما برای کارهای تجاری و تخصصی ضروری نیستند نیز خبری نیست.
شاید Wine به عنوان یک نقطه شروع برای کاربرانی که در حال تجربه کردن اجرای برنامههای ویندوز بر روی لینوکس هستند مناسب باشد اما برای شرکتها و موسسات تجاری که به طور جدی تصمیم به اجرای برنامههای ویندوز بر روی لینوکس دارند بهترین و مطمئن ترین انتخاب نصب CrossOver Office بر روی لینوکس آن شرکتها و موسسات است.
منبع:http://technotux.com