PDA

View Full Version : Win32 هنوز نفس میکشه !



توسعه نویس
چهارشنبه 21 آذر 1386, 01:02 صبح
خیلی از برنامه نویسان فکر می کنند دیگر win32 منسوخ شده و دیگر کاربردی نیست. اما اشتباه می کنند. سیاست ماکروسافت این است که با ارائه دات نت و حمایت از اون، برنامه نویسی win32 رو کاملا نابود کند.! چون با این کار دست برنامه نویسان رو از بیش از پنج هزار تابع API ویندوزی کوتاه میکنه. مایکروسافت همیشه انحصار طلب بوده و اینجا میخواهد فقط برنامه نویسی حول امکاناتی که اون میگه باشه.
فکر میکنید چند تا تابع API تا حالا شناخته شده؟ فقط حدود 500 تا. در حالی که توابع خیلی زیاد هستند. گفته میشه که در آینده win32 از ویندوز حذف میشه. اما باید بدونید حالا حالا ها WIN32 میمونه. چون بیس خود ویندوز و بیس دات فریم ورک، win32 هست. همچنین تمام کراس پلتفرم ها مانند GTK+ و ... نیز بر پایه WIN32 کار میکنند. پس خیلی سخته که win32 از بین بره. توی ویستا هم win32 مبنای خیلی از جاهای پایه ای هستش و تا اومدن سیستم عامل آینده مایکروسافت حداقل 5 سال دیگه زمان مونده و بعد از اون 5 سال هم حداقل باید از win32 حمایت بشه. به این ترتیب حداقل تا 10 سال دیگه win32 وجود داره و منتخب بزرگترین نرم افزارهای دنیا از شرکتهای بزرگی چون Adobe و Autodesk و ... خواهد بود.
امنیت توی win32 خیلی زیاده و به نسبت دات نت شکستنش خیلی سخت تره. البته نرم افزار های زیادی کار disAssembly رو انجام میدهند. ولی الگوریتم های کامپایل هم که این کار رو سخت می کنند هم کم نیستند.
سرعت زیاد برنامه ها بخواطر اجرای مستقیم هم خیلی قابل توجه هست. این قضیه سرعت اجرا توی دات نت حال همه رو گرفته. آخه توی دات برنامه یه بار یه دور قمری دست به دست میچرخه تا به اجرا برسه. دست آخر باید به همون Native تبدیل بشه و اجرا بشه.
خیلی از بازی سازها و Game Engin ها دارند با win32 کار می کنند.
حتی خود MFC هم روی win32 داره کار میکنه.:متفکر:

با این تفاسیر توی ایران حتی نتونستم یه کتاب پیدا کنم که آموزش win32 (نه MFC ) رو به فارسی داشته باشه.:افسرده:

برای بعدا یه تفحصی توی API ها میزنم و نشون میدم که چقدر API وجود داره.

Alireza Orumand
چهارشنبه 21 آذر 1386, 07:43 صبح
سلام
کلی روحم شاد شد یه نفر پیدا شد این حرفارو زد. تو گلوم گیر کرده بود که آخه چرا و به کدامین گناه؟ چرا یه روزی همه کف میکردن وقتی میگفتی من c++ کد مینویسم تازه تومحیط بورلند همه انگشت تحیر به دهن میگرفتن ولی الان ...
ولی خودمونیم اشکالاتی که درباره سرعت و امنیت زدی وجود داره ولی نه به این شدت که شما فرمودید. مثلا جایی که گفتید یه دور قمری میزنه تا اجرا بشه هرکی ندونه فکر میکنه سرعت دات نت 1000 برابر کمتر از برنامه های native هست. ولی در کل خوب شد که گفتید باز هم بگید که ما صبح که میشینیم پشت میز کار اول یه دو خط از این مطالب دوست داشتنی بخونیم بعد با روحیه ی بیشتری کار کنیم.
موفق باشید.

Nima_NF
چهارشنبه 21 آذر 1386, 17:14 عصر
سیاست ماکروسافت این است که با ارائه دات نت و حمایت از اون، برنامه نویسی win32 رو کاملا نابود کند.! چون با این کار دست برنامه نویسان رو از بیش از پنج هزار تابع API ویندوزی کوتاه میکنه. مایکروسافت همیشه انحصار طلب بوده و اینجا میخواهد فقط برنامه نویسی حول امکاناتی که اون میگه باشه.درسال های اولیه انتشار دات نت ، بله این سیاست تا حدودی مد نظر مایکروسافت بود ولی پس از چند سال به دلیل مخالفت های شدید و جایگزین نکردن آن توسط بسیاری از برنامه نویسان با دات نت از جمله سازندگان بازی های کامپیوتری (حرفه خودم) و توسعه دهندگان نرم افزار های cross-platform (یعنی تمامی شرکت های بزرگ سازنده نرم افزار که می خواهند برای لینوکس و mac-os هم یک نسخه ارائه دهند ) این سیاست کاملا تغییر کرد و عملا اعلام کردند که توسعه Windows API به طور کامل مانند قبل ادامه خواهد یافت (و علاوه بر گفته هایشان این مورد را با چند چیز ثابت کردند مانند: ارائه پارسر litXML برای Win32 ، قابلیت های جدید 2008 MFC و...) و اگر در این چند سال اخیر از جایی و یا به خصوص در ایران چیزی شنیدید ، بدانید که مرجع علمی ندارد و شایعه ای میان برنامه نویسان دات نتی است و برای اطلاعات بیشتر به بلاگ توسعه دهندگاه ++VC (http://blogs.msdn.com/vcblog/) مراجعه کنید. (ضمنا خودم برنامه نویس win32 هستم)

جالب است بدانید که مایکروسافت در توسعه API های ++C/C صوت جدید در ویندوز Vista اعلام کرد که "به دلیل نیاز به دقت و latency کوتاه ما برای توسعه این API ها از دات نت استفاده نکردیم "
Because some aspects of audio streaming depend on low latency and precise synchronization, the implementations of the MMDevice, WASAPI, DeviceTopology, and EndpointVolume APIs do not use the Microsoft .NET Framework or managed-execution environment
که این نشان دهنده این است که خود مایکروسافت هنوز از ++C برای بسیاری از قسمت ها استفاده می کند.


سرعت زیاد برنامه ها بخواطر اجرای مستقیم هم خیلی قابل توجه هست. این قضیه سرعت اجرا توی دات نت حال همه رو گرفته. آخه توی دات برنامه یه بار یه دور قمری دست به دست میچرخه تا به اجرا برسه. امروزه بسیاری از شرکت های بزرگ برای کارهای ابزاری خود که ارتباطی با مشتری ندارد و فقط در شرکت استفاده می شوند (Tools) از برنامه نویسانی استفاده می کنند که علاوه بر Win32 ، در زمینه #C نیز مطلع باشند و دلیل آن را اینگونه ذکر کرده اند که با وجود این که کمی کاهش performance داریم ، ولی افزایش سرعت انجام پروژه ارزشش را در برخی موارد دارد و می توان گهگاهی performance را فدای سرعت توسعه کرد.

ضمنا این کاهش سرعت در همه جا خیلی زیاد نیست و بستگی به حوزه کاربردی آن دارد ، چرا که واقعا در بسیاری موارد از جمله رشته مورد علاقه هم وطنان ما "نرم افزار های پایگاه داده ای" نیاز به performance بسیار بالا نیست.
ولی متا سفانه این جایگزینی در برخی موارد باعث شد تا win32 در کشورمان به جایگزینی در همه موارد تغییر کند و رو به نابودی کامل برود.

دست آخر باید به همون Native تبدیل بشه و اجرا بشه.توسعه دان نت واقعا این طور نیست و از همان کدهای native استفاده نمی کند ، بلکه به شیوه دیگر و متفاوت از win32 عمل می کند تا وابسته به پلتفرم خاصی نباشد ولی در هر حال ، از هر شیوه ای که استفاده می کند ، شیوه تبدیل آن و استفاده خودکار حافظه و واقعا کراس پلتفرم نبودن (بلکه مایکروسافتی بودن) از نقاط ضعف آن است که من هم موافقم.

موفق باشد

mehrzad007
چهارشنبه 21 آذر 1386, 23:45 عصر
دوستان لطف کنید از پست های احساسی و کم ارزش از نظر فنی خودداری کنید .

سیاست ماکروسافت این است که با ارائه دات نت و حمایت از اون، برنامه نویسی win32 رو کاملا نابود کند.!

چون با این کار دست برنامه نویسان رو از بیش از پنج هزار تابع API ویندوزی کوتاه میکنه

مایکروسافت همیشه انحصار طلب بوده و اینجا میخواهد فقط برنامه نویسی حول امکاناتی که اون میگه باشه

اما باید بدونید حالا حالا ها WIN32 میمونه.

سرعت زیاد برنامه ها بخواطر اجرای مستقیم هم خیلی قابل توجه هست. این قضیه سرعت اجرا توی دات نت حال همه رو گرفته. آخه توی دات برنامه یه بار یه دور قمری دست به دست میچرخه تا به اجرا برسه. دست آخر باید به همون Native تبدیل بشه و اجرا بشه.


کلی روحم شاد شد یه نفر پیدا شد این حرفارو زد. تو گلوم گیر کرده بود که آخه چرا و به کدامین گناه؟ چرا یه روزی همه کف میکردن وقتی میگفتی من c++ کد مینویسم تازه تومحیط بورلند همه انگشت تحیر به دهن میگرفتن ولی الان ...
نکنین این کارا رو تو رو خدا

توسعه نویس
پنج شنبه 22 آذر 1386, 01:26 صبح
با سپاس فراوان از دوستان و عرض پوزش و شرمندگی از عنوان با لفظی افراطی.

البته خود بنده با VB.Net و C# برنامه نویسی می کنم و تجربه عملی با فضای اجرای برنامه دات نت دارم. بر همین اساس مطالبی که عرض کردم تا قسمتی از تجربه های شخصی بوده و تا قسمتی از دغدقه های جامعه برنامه نویسان در دنیا. البته اگر اشتباهی در قسمتی از گفته ها موجود هست ناشی از تجربه بنده بوده که بوسیله همین تعامل ها انشاء الله اصلاح میشود.

توسعه دان نت واقعا این طور نیست و از همان کدهای native استفاده نمی کند ،
منظور من سیستم اجرای دات نت هست. دات نت برنامه کامپایل شده را به کدهای MSIL تبدیل کرده و در زمان اجرا توسط موتور JIT با توجه به نوع CPU به Native Code تبدیل کرده و اجرا می کند. و این تا زمانی که برنامه Run می باشد ادامه دارد. این مسأله سرعت اجرای برنامه ها را پایین آورده و محسوس هست.

درسال های اولیه انتشار دات نت ، بله این سیاست تا حدودی مد نظر مایکروسافت بود ولی پس از چند سال به دلیل مخالفت های شدید و جایگزین نکردن آن توسط بسیاری از برنامه نویسان با دات نت ..... این سیاست کاملا تغییر کرد
البته نه کاملا، میل مایکروسافت به عنوان جانشین مطلق امپراطوری نرم افزار در دنیا هنوز باقی است. اگر اشتباه نکنم نرم افزارهایی مانند SilverLight به جای Flash و DX به جای OpenGL، دات نت به جای جاوا نمودهایی عینی از این مسأله هستند. مایکروسافت از توسعه نسخه های جدیدتر OpenGL جلوگیری کرد تا DX الزامی شود. همچنین حدود یک سال قبل از ارائه دات نت از حمایت جاوا هم دست برداشت و مانع جاوا شد تا دات نت الزامی شود. بعید نیست که در آینده از نصب Flash Player هم جلوگیری کند تا همه به سمت SilverLight هدایت شوند. و این سیاست بدی است. باید فضای رقابت سالم وجود داشته باشد تا راه درست پیشرفت کج نشود.

در مورد Win32 دغدقه من قطع ارتباط آزاد برنامه نویسان از منابع سیستمی و فضای باز LowLevel هست. ممکن است با گسترش ابزارهای حاضر آماده و توسعه سازی با کنترلهای آماده، باعث عدم حمایت از برنامه نویسی LowLevel شود و فضای باز برنامه نویسی فقط در اختیار شرکت های خیلی بزرگ قرار گیرد.
-----------------------------------------------------------------------------
در مورد توابع API یک فایل ضمیمه می کنم ببینید و خود قضاوت کنید.
12836

فایل فشرده حاوی دو تا فایل txt می باشد. یکی برای GDI32.DLL که حاوی تمام نام توابع در این DLL به تعداد 600 تابع است و دیگری برای USER32.DLL است به تعداد 732 تابع. این در حالیه که کلا از مجموع چندین DLL سیستمی ویندوز ما فقط بیشتر از 500 تابع معرفی شده در اختیار داریم. اما حدودا بیشتر از 5000 تابع وجود دارد.

Inprise
پنج شنبه 22 آذر 1386, 12:01 عصر
ما فقط بیشتر از 500 تابع معرفی شده در اختیار داریم. اما حدودا بیشتر از 5000 تابع وجود دارد.

نمیدونم منظورت از "ما" کی هست دقیقا ولی تمام API های Win32 در MSDN مستند شدند و چیزی مخفی نیست .

توسعه نویس
یک شنبه 25 آذر 1386, 00:40 صبح
به جای خوبی اشاره کردی.

حالا یک مقدار دقیق تر صحبت می کنیم:

در MSDN تعداد 2330 تابع API مستند شده، که البته قبلا کمتر از این بود.

اما از تعداد 18 فایل سیستمی منتخب تعداد 7100 تابع API شمارش کردم.

18 فایل بصورت زیر است:
ADVAPI32.DLL
COMCTL32.DLL
comdlg32.DLL
GDI32.DLL
Kernell32.DLL
MPR.DLL
NetAPI32.DLL
ntdll.DLL
OLE32.DLL
RASAPI32.DLL
rpcrt4.DLL
shell32.DLL
SHLWAPI.DLL
User32.DLL
VERSION.DLL
WINMM.DLL
WinSpool.DRV
WSOCK32.DLL

البته تعداد فایلهای سیستمی حاوی API های ویندوز بیشتر هست ولی مهمترین ها رو آوردم. البته من مایکروسافت رو محکوم نمی کنم و از بابت متون MSDN هم ازش ممنونم. ولی اینکه بگیم هیچ چیزی برای مخفی کردن وجود نداده یکم سنگینه و قابل قبول نیست.:متفکر:

امیدوارم در آینده مقدار بیشتری از API ها رو مایکروسافت معرفی کنه.

Inprise
یک شنبه 25 آذر 1386, 03:41 صبح
بهتر هست که اول الفبای یک مسئله رو بشناسی و بعد در موردش صحبت کنی یا نتیجه ای بگیری . ntdll.dll فراهم کنندهء خدمات Native API ویندوز هست نه Win32 یا بقیه Sub System ها . کاربران بطور عادی لزومی نداره و نباید که از Native API استفاده کنن . البته مستنداتی وجود داره اما بهر حال مایکروسافت این توابع رو "ارائه" نکرده . در مورد بقیه ، قرار نیست تصور کنی هر تابعی که هر DLL ای اکسپورت میکنه یک جور API است . یعنی این خطاست که DLL های موجود در ویندوز رو لیست کنی و توابع اکسپورت شده رو ببینی و خیال کنی که اینها APIهای مفیدی هستند که مخفی شدن ، چون اینطور نیست . آن چیزی که مایکروسافت برای Sub System اصلی یعنی Win32 در MSDN مستند کرده کافی و همان چیزی است که بهش میگن Win32 API . خیلی وقتها یک DLL تابعی رو اکسپورت میکنه که توسط توابع دیگه مورد استفاده قرار میگیره تا ...نهایتا خدمتش بصورت یک API ارائه بشه . هر چیزی که قابل دیدن هست ، نه لزوما مفید هست و نه لزوما قابل کاربرد .

اساسا این ادعا که مایکروسافت چیزی رو پنهان کرده غیر فنی و بی معنا است و اگر مقدار ناچیزی با کد نویسی و ساختار و سازمان ویندوز آشنا باشی نباید چنین حرفی رو بزنی . منهای متن کد سی و اسمبلی سیستم عامل ، که به باینری ترجمه شدن ، هیچ چیزی از عناصر سیستم عامل نه پنهان هست و نه قابل پنهان کردن . تو میتونی تمام توابع اکسپورت شده رو ببینی ، میتونی ازشون استفاده کنی یا هر چی . این فقط DLL ها نیستن که توابعی رو ارائه میکنن ، در مواردی فایلهای اجرائی و درایورها هم توابعی رو اکسپورت میکنن که قابل استفاده است و کسی هم نمیتونه اونها رو پنهان کنه . نه دلیلی وجود داره و نه شدنی است

مایکروسافت به عنوان سازنده سیستم عامل یک منطق و سازمان برای برنامه نویسی ارائه کرده . اگر بخواهی کد کرنل بنویسی باید از DDK و روتینهای کرنل استفاده کنی . تعدادی ‌API ارائه شدن ، ممکنه دهها درایور ویندوز توابع متعددی رو اکسپورت کرده باشن که قابل مشاهده هم هست اما وقتی مایکروسافت اونها رو "ارائه" نکرده یعنی بر اساس برنامهء او ، این تابع قرار نیست در این محل و به این شکل استفاده بشه ، و میتونی مطمئن باشی که او بهتر از تو میدونه چه تابعی به چه شکل و به زمانی باید استفاده بشه . وقتی قرار است برای یکی از Sub System های ویندوز کد بنویسی باید از SDK مربوطه استفاده کنی . روی ویندوز Win32 و POSIX و OS2 سه تا Sub System شناخته شده هستن ، که هر کدوم توابع و زمان اجراهای خودشون رو دارن . توابعی که مایکروسافت برای Win32 ارائه کرده همگی در MSDN مستند شدن . معنای این حرف این است که مایکروسافت بر اساس معماری پیشنهادی اش به تو گفته که از این توابع استفاده کنی ، حالا اگر تو دلت خواست که بگردی و یک تابع رو که از یک DLL اکسپورت شده پیدا کنی این به خودت مربوطه ولی بر اساس معماری Win32 چنین تابعی کمک خاصی به تو نمیکنه ، یا بهتر هست که از API ارائه شده استفاده کنی چون به اندازه کافی بهش فکر شده . برای Posix و بقیه موارد هم همینطور هستش .

همانطور که گفتم فقط Native API ویندوز مانند بقیه بخشها چندان بهش پرداخته نشده . این API ها فقط یک سری Proxy بین توابع Kernel و توابع Sub System ها هستن . یعنی بجای اینکه Sub System ها مستقیما با کرنل صحبت کنن با Proxy ای بنام Native API صحبت میکنن که این یه مزیت مهم در طراحی سیستم عامل است . وقتی مایکروسافت مستنداتش رو ارائه نکرده یعنی بر اساس ساز و کار و سازمانی که او تدوین کرده این توابع به درد کسی نمیخورن ولیکن باز چیزی پنهان نشده ، تو میتونی ببینی و ازشون استفاده کنی ، و خیلیها همینکار رو کردن و حتی براش مستندات Third Party متعددی وجود داره .