PDA

View Full Version : MFC یا WIN32API ?



simul8or
پنج شنبه 11 بهمن 1386, 13:33 عصر
در اصل این دو با هم تفاوت ندارند چون هر زبان و هر framework در نهایت باید از api استفاده کند ولی:
MFC توسط microsoft برای ساده کردن آشفتگی های موجود در برنامه نویسی API ارائه شده است.
MFC با encapsulates کردن (در پوشش گذاشتن) توابع API در مجموعه ای از کلاسها این امر را فراهم کرده است. برای مثال کلاس CDialog در mfc، کار تابع DialogBox را در win32api انجام می دهد.
MFC یک قالب از پیش تعریف شده (framework) برای برنامه نویسی ویندوز است، بنابر این نمیتواند تمام نیازهای یک برنامه نویس را پیش بینی کند.
mfc یک کتابخانه جامع مانند C run-time library نیست. برای مثال ساخت سرویسهای ویندوز با mfc به راحتی امکان پذیر نیست و در واقع باید گفت :"Microsoft does not support using MFC to build Windows services" بدین معنا که: مایکروسافت ساخت سرویسهای ویندوز توسط mfc را حمایت نمی کند. اما MFC همچنان از محبوبیت بالایی در بین برنامه نویسان ویندوز برخوردار است.

در مقابل win32api ، هرچند در نگاه اول کمی سخت به نظر می رسد ولی به شما این اجازه را می دهد تا از تمامی امکانات ویندوز استفاده کنید. به طور کلی یادگیری win32api به شما کمک می کند تا فهمی بسیار عمیق و دقیق از چگونگی عملکرد درونی windows و برنامه های کاربردی به دست آورید.

دوباره تاکید می کنم که این دو در بیس و پایه متفاوت نیستند. هر framework در نهایت باید از API استفاده کند.
read windows SDK documents for more informations

unix_svr4
پنج شنبه 11 بهمن 1386, 14:57 عصر
دوست عزیز
درسته که Win32Api از MFC قوی تر هست! ولی این دلیل نمیشه MFC را نادیده بگیریم! در پروژه های بزرگ بیشتر از MFC استفاده می می کنند! چرا؟؟ چون ساده تر از Win32 هست! پروژه ای که با MFC طراحی شود باگ کمتری خواهد داشت زیرا بیشتر کارها قبلا توسط شرکت انجام شده و فقط شما باید از اشیای کلاس مورد نظر استفاده کنید! بهر حال انتخاب به عهده خود شماست من مدتی با ++VisualC کار کردم فقط هم MFC کار کردم به نظر خودم که خیلی بهتر از Win32 هستش. خیلی راحت میشه با اون برنامه نوشت ولی در Win32 به همین راحتی ها هم نیست! به تجربه زیادی نیاز دارید تا بتوانید یک برنامه بنویسید که از نظر کارایی با MFC رقابت کند.

موفق باشید.

Nima_NF
پنج شنبه 11 بهمن 1386, 16:07 عصر
دوست عزیز
در پروژه های بزرگ بیشتر از MFC استفاده می می کنند! چرا؟؟ چون ساده تر از Win32 هست!

اگر شما در مورد برنامه نویسی ++C در کشور ما صحبت می کنید ، بله این حرف درست است ، چون هدف اول مدیران و برنامه نویسان ما با توجه به در آمد کمتر آن به نسبت سایر کشور ها ، سریع به نتیجه رسیدن است نه کیفیت فوق العاده بالا. اما در مورد شرکت های سایر کشور ها دقیقا برعکس است !

انتخاب MFC یا Win32 در کشور های دیگر بر مبنای نوع کار آن ها انتخاب می شود،
از آنجایی که هر دو native هستند ، افرادی که MFC را انتخاب می کنند هدفشان چند چیز است : سرعت در توسعه نرم افزار و ضمنا قصد ارائه نسخه دیگری برای سایر سیستم عامل ها را نیز ندارند (چرا که در پروژه های MFC کار بسیار مشکل می شود) و تفاوت اندک کارآیی (performance) آن با استفاده مستقیم از API ها نیز برایشان چندان مهم نیست : مثل برنامه رایت Nero
چند نرم فزار یافت می شود که نیازمند به ساخت سرویس باشند یا در آینده این نیاز برایشان پیش آید ؟ بسیار اندک.

اما سایر شرکت های بزرگ ، از آنجایی که قصد دارند تا خودشان یک framework که OOP نیز باشد را بسازند و برنامه را cross-platform کنند (البته بدون استفاده از کیت های cross-platform آماده) تا قابل اجرا بر روی سایر سیستم عامل ها نیز بشود ، از win32 استفاده می کنند تا هم به همه امکانات دسترسی داشته باشند و هم بتوانند راحت تر ، از برنامه نویسی native سایر سیستم عامل ها نیز استفاده کنند و مثلا آن را به Mac Os نیز ببرند. مثل Adobe

ضمنا برنامه نویسی MFC علاوه بر انحصاری بودن آن در ویندوز ، امروزه به یک نوع برنامه نویسی آشفته یا کثیف(Mess) در مقابل سایر رقبای خود مثل Qt معروف است.

در هر حال هر دو MFC و win32 همچنان هر دو جایگاه خود را حفظ کرده اند و بسته به پروژه انتخاب می شوند.

simul8or
پنج شنبه 11 بهمن 1386, 17:04 عصر
دوست عزیز
در پروژه های بزرگ بیشتر از MFC استفاده می می کنند!

کاملا با این مطلب شما مخالفم!!. اتفاقا بیشترین کاربرد win32api در پروژه های بزرگ است.
در ساخت پروژه های بزرگ همیشه سرعت اجرای برنامه و حجم کم دارای اهمیت بالایی است. در این صورت، استفاده از win32api بهترین گزینه خواهد بود.
در برنامه ی ساخته شده توسط MFC کافیست به جای shared dll ، از static library استفاده شود (برای استفاده از جدیدترین کلاسهای MFC ، برطرف کردن نگرانی های ناشی از عدم وجود dll یا cross-platform کردن) تا حجم یک برنامه ساده به بیش از 2mb افزایش یابد.
در ضمن در ساخت یک پروژه ی بزرگ همیشه از یک تکنولوژی استفاده نمی شود، برای مثال ممکن است قسمتی از یک پروژه توسط framework های شرکت Borland نوشته شوند.

vcldeveloper
جمعه 12 بهمن 1386, 02:42 صبح
ما سایر شرکت های بزرگ ، از آنجایی که قصد دارند تا خودشان یک framework که OOP نیز باشد را بسازند و برنامه را cross-platform کنند (البته بدون استفاده از کیت های cross-platform آماده) تا قابل اجرا بر روی سایر سیستم عامل ها نیز بشود ، از win32 استفاده می کنند تا هم به همه امکانات دسترسی داشته باشند و هم بتوانند راحت تر ، از برنامه نویسی native سایر سیستم عامل ها نیز استفاده کنند و مثلا آن را به Mac Os نیز ببرند. مثل Adobe

نیما جان، چرا باید برای نوشتن یک نرم افزار cross-platform از ++VC و Win32 که مختص ویندوز هستند استفاده کنند؟ Win32 در سیستم عاملی مثل Mac یا لینوکس چه کاربردی می تونه داشته باشه؟ آیا برای همچین نرم افزارهایی شرکت هایی مثل Adobe از زبان هایی مثل C یا ++C که مستقل از سکو هستند استفاده نمی کنند؟

تشکر

Inprise
جمعه 12 بهمن 1386, 09:54 صبح
درسته که Win32Api از MFC قوی تر هست! ولی این دلیل نمیشه MFC را نادیده بگیریم! در پروژه های بزرگ بیشتر از MFC استفاده می می کنند! چرا؟؟ چون ساده تر از Win32 هست!

به اینجور مقایسه های غلط و بی معنی میگن قیاس مع الفارق . اساسا کسی نمیتونه یک برنامه کمی پیچیده تر از سلام دنیا برای ویندوز بنویسه ولی از API استفاده نکنه . با هر محیطی من جمله وی سی ، سی++ بیلدر یا حتی دلفی که برنامه بنویسی بهر حال از API باید استفاده کنی . Framework ها باعث تسریع کار و مهندسی زمان و هزینه میشن . قیاس API و MFC یا VCL بی معنی هستش . اغلب برنامه های وی سی طبیعتا از API استفاده میکنن ولی برای تسریع کار خصوصا در پروژه های بزرگ از کتابخانه های مختلف استفاده میشه . خیلیها از همین کتابخانه های معروف مثل MFC و VCL و QT استفاده میکنن ، عده ای هم کتابخانه های خودشون رو مینویسن و استفاده میکنن . مثلا Adobe برای اغلب محصولاتش از یک کتابخانه داخلی بنام Adobe Owl استفاده میکنه که برای کاربرد عموم منتشر نشده ، اما رابط کاربری محصولاتی مثل فوتوشاپ با این کتابخانه نوشته شدن . ولی بهر حال API یک عضو ضروری و غیر قابل اجتناب برنامه های ویندوز هست .

simul8or
جمعه 12 بهمن 1386, 12:28 عصر
دوستان عزیز، لازم دیدم توضیحاتی در مورد api و Cross-platform programming بدهم، البته با اجازه ی بزرگان.
همون طور که می دانید اصولا هر سیستم عامل توسط API های آن تعریف می شود. API شامل تمامی توابعی است که یک برنامه کاربردی می تواند توسط سیستم عامل آنها را فراخوانی کند. همچنین API شامل تعاریف نوع داده های وابسته (associated data types) و ساختار ها نیز هست.
به طور کلی API شامل مجموعه ای از روال هاست (routines) که یک برنامه کاربردی از آن برای رهبری کردن اجرای پردازه ها (procedures) توسط سیستم عامل استفاده می کند، پس همان طور که جناب Inprise گفتند وقتی شما برای یک سیستم عامل برنامه می نویسید، باید از API های آن استفاده کنید.
win32 همان طور که از نامش پیداست API برای ویندوزهای Microsoft و کاملا native است، بنابر این سیستم عاملی مانند linux دارای API متفاوتی از windows است و این مساله Cross-platform کردن یک برنامه اجرایی را بسیار دشوارمی کند.
برای Cross-platform کردن یک برنامه معمولا از روش های زیر استفاده میشه:
1. اولین راه ساختن نسخه های چندگانه از برنامه توسط "source tree" های مختلف. که بسیار پرخرج و زمان بر است.
2. استفاده از نرم افزارهایی که تفاوت بین سیستم عاملها را مخفی میکنند. برنامه Java Virtual Machine یکی از این نرم افزارهاست که با redistributed کردن (دوباره تعمیم دادن) bytecode های یک executable binary (برنامه اجرایی کد شده) برنامه را Cross-platform می کند.(این برنامه با شعار Write Once, Run Anywhere ارائه شد)
3. استفاده از toolkit های برنامه نویسی multi-platform مانند Qt ، GTK+، ParaGUI و...

البته من خودم شخصا با Cross-platform مخالف هستم! به نظر من آینده در دستان مایکروسافت است!

Nima_NF
جمعه 12 بهمن 1386, 16:57 عصر
نیما جان، چرا باید برای نوشتن یک نرم افزار cross-platform از ++VC و Win32 که مختص ویندوز هستند استفاده کنند؟ Win32 در سیستم عاملی مثل Mac یا لینوکس چه کاربردی می تونه داشته باشه؟ آیا برای همچین نرم افزارهایی شرکت هایی مثل Adobe از زبان هایی مثل C یا ++C که مستقل از سکو هستند استفاده نمی کنند؟

همان طوری جناب inprise هم توضیح دادند ، نرم افزار های Adobe از جمله مهم ترین آن ها photoshop از کیفیت فوق العاده بالایی برخوردار هست که دلیل آن هم داشتن برنامه نویسانی در هر دو حوزه هست که به طور مجزا برای هر دو پلتفرم Mac و windows ، جداگانه از طریق API ها همان سیستم عامل ها ، framework خودشان را می سازند و برنامه را می نویسند ، یعنی win32 در ویندوز و carbon در mac. استفاده از win32 سبب می شود تا ساختن این framework از آنجایی که هر دو شیوه سطح پایین هستند راحت تر و به نوعی شبیه هم باشد.
حتی سال ها قبل وقتی Apple تغییرات زیادی در API های carbon داد ، adobe را با مشکلاتی روبرو کرده بود.

simul8or
شنبه 13 بهمن 1386, 10:20 صبح
چرا باید برای نوشتن یک نرم افزار cross-platform از ++VC و Win32 که مختص ویندوز هستند استفاده کنند؟
برنامه های نوشته شده با win32 قابلیت بیشتری برای cross-platform شدن دارند.
دوستان علاقه مند میتوانند از مطالب کتاب "Porting to Mac OS X from Windows Win32" استفاده کنند.

once4ever
شنبه 11 خرداد 1387, 19:50 عصر
خوب فکر کنم تفاوتها! یا بهتر بگم امکانات ودرمقابل اون محدودیتهایی که هر کدام در اختیار برنامه نویس میگذارند مشخص شد.
دوستان یک سوال
آیا برنامه نوشته شده با این دو نوع ویژوال سی قابل دیسورس شدن هست؟! یعنی به هر نحوی قسمتی از سورس از روی فایل exe یا dll قابل دیدن باشه (بجز رشته ها و عکسها)
ممنون سریع و کامل به سوالم جواب بدید

مهران موسوی
شنبه 11 خرداد 1387, 20:42 عصر
دوست عزيز فكر كنم بدونم از كجا اين سوال براتون به وجود اومده ... اون كه شما ديديد يكي از دوستان سورس كد برنامه ي شما رو در انجمن امنيت بهتون تحويل داد علتش استفاده از فريم ورك دات نت بود كه يكي از نقاط ضعف اون هست .. البته نميشه روش عيب گذاشت چون ميكروسافت هيچ تعهدي رو در رابطه با امنيت دات نت ارائه نكرده يا حداقل من چيزي نديدم ...

ولي در باب Win32 موضوع با دات نت فرق ميكنه . هيچ وقت امكان نداشته كه كدهاي ماشين رو مستقيما به سورس كد اصلي تبديل كرد .. حتي قطعه اي از اون رو .. البته ناگفته نماند كه با وجود ديباگر هاي قدرتمند امروزي به راحتي ميشه سورس زبان اسمبلي رو در اختيار داشت ... و با كمي دانش زبانهاي سطح پايين سورس كد اصلي رو پياده سازي كرد ...

ولي در كل من تا به حال ابزاري براي تبديل مستقيم كد به زبان اصلي كه كد باهاش نوشته شده نديدم ...

simul8or
یک شنبه 12 خرداد 1387, 00:45 صبح
خوب فکر کنم تفاوتها! یا بهتر بگم امکانات ودرمقابل اون محدودیتهایی که هر کدام در اختیار برنامه نویس میگذارند مشخص شد.
دوستان یک سوال
آیا برنامه نوشته شده با این دو نوع ویژوال سی قابل دیسورس شدن هست؟! یعنی به هر نحوی قسمتی از سورس از روی فایل exe یا dll قابل دیدن باشه (بجز رشته ها و عکسها)
ممنون سریع و کامل به سوالم جواب بدید
اصولا دست یابی به الگوریتمی که بر اساس آن بتوان file باینری را به کد اولیه تبدیل کرد غیر ممکن است. مخصوصا اگر برنامه توسط زبان ++C/Cنوشته شده باشد.
ولی برای برنامه های کوچک و ساده تا حدی این امکان وجود دارد، اما باز هم ممکن است نام متغییر ها بی معنی باشند(var1 , var2 ...) و یا هیچ کامنتی مشاهده نشود، حلقه for به جای حلقه while مورد استفاده قرار گیرد. و ... اما نتیجه ی بهتری برای زبانهای مدیریت شده .net در مقایسه با mfc یا win32 بدست خواهد آمد.
میزان صحت source بدست آمده تا حد زیادی بستگی به مقدار اطلاعات debugging موجود در فایل باینری دارد.
2 سایت زیر می تواند به شما کمک کند:
http://www.program-transformation.org/Transform/WebHome1
http://www.remotesoft.com/salamander/2

once4ever
یک شنبه 12 خرداد 1387, 08:53 صبح
.::Mehran::. دوست عزیز من 5سال پیش با ویژوال سی برنامه مینوشتم و همچنین به موضوعاتی که گفتید آگاهی داشتم.
فقط برای اطمینان کامل سوال کردم چون جدا از هر قفل یا هرچیز دیگر ، روشی که در پیاده سازی بعضی قسمتهای سیستم بکار میبرم نباید بطور واضح دیده شوند (که در دات نت هنوز بطور قطعی از سورس محافظت نمیشود) و دیدن کدهای اسمبلی یا مقادیر بعضی متغیرها مهم نیست.
سوال: آیا به هر روشی با هر زمانی میشود سورس MFC دید؟
ممنون

Nima_NF
یک شنبه 12 خرداد 1387, 13:15 عصر
تا زمانی که طرز کار کامپیوتر ها ، زبان ماشین ، کامپایلر ها و غیره برای همه مردم آشکار باشد مطمئنا می توان هر چند سطحی کار هایی کرد تا متوجه محتویات هر برنامه یا فایل باینری به صورت حداقل یک شبهه کد یا الگوریتم شد. (البته در صورت داشتن ابزار و دانش آن)
کسی که ادعا کند این کار اصلا شدنی نیست، مثل فردی هست که ادعا کند نرم افزارش اصلا قابل کرک شدن نیست که همیشه این گونه افراد با شکست بیشتری روبرو می شوند!

از جمله نرم افزار های این کار Hex-Rays Decompiler (http://www.hex-rays.com/decompiler.shtml) هست که با مکانیسم خود می تواند فایل های باینری را تحلیل کرده و آن را Disassemble کند و سپس آن را به شبه کدهای ++C/C دی کامپایل (Decompile) کند. البته نرم افزار گران قیمتی هست و مسلما به دانش بالا در زمینه تحلیل کدهای اسمبلی و C نیاز دارد.

اما فرقی که بین برنامه های دات نت با برنامه های سایر زبان ها مانند ++C وجود دارد در این است که در دات نت کد های شما به کد میانی مایکروسافت تبدیل می شود و لذا نحوه برگردان آن با توجه به روش های آشکار و ابزار های موجود، نسبت به سایر فایل های باینری کامپایل شده به زبان ماشین بسیار آسان تر است.

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

simul8or
دوشنبه 13 خرداد 1387, 10:57 صبح
کسی که ادعا کند این کار اصلا شدنی نیست، مثل فردی هست که ادعا کند نرم افزارش اصلا قابل کرک شدن نیست که همیشه این گونه افراد با شکست بیشتری روبرو می شوند!

به نظر شما مي توان به يك الگوريتم ثابت براي decompile كردن دست پيدا كرد؟؟ تا جايي كه من اطلاع دارم اين امكان وجود ندارد, مگر اينكه شركت سازنده كامپايلر, برنامه decompiler هم توليد كرده باشد.(براي مثال Java Virtual Machine )
مشخص است كه بدست آوردن كد اسمبلي و تجزيه تحليل آن براي دست يابي به source براي هر برنامه متفاوت است.
منظور من از جمله "اصولا دست یابی به الگوریتمی که بر اساس آن بتوان file باینری را به کد اولیه تبدیل کرد غیر ممکن است" , دست يابي به الگوريتمي ثابت است.

Nima_NF
دوشنبه 13 خرداد 1387, 15:01 عصر
به نظر شما مي توان به يك الگوريتم ثابت براي decompile كردن دست پيدا كرد؟؟مطمئنا خیر، راه ثابت و 100% کاملی برای کل برنامه وجود ندارد.

جمله قبلی خودم را دوباره تکرار می کنم:

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