نگرانی برنامه‌نویسان در مقابل ویندوز 8 و آینده

[Felony]

http://www.narenji.ir/sites/default/files/articleimage/1015/11/log.png?1316410290

اینترفیس مترو به ویندوز آمده و خیلی ها منتظر عرضه نسخه بعدی ویندوز هستند. تصور سیستم عاملی یکپارچه که روی تمام تبلت ها نصب خواهد شد و از این پس کاربران خواهند توانست که از برنامه های حرفه ای و کاربردی ویندوز روی تبلت نیز بهره مند شوند. اما صبر کنید! داستان خیلی فراتر از این هاست. در پس پرده شاید چیز هایی به جز انتظارات شما در حال برآورده شدن هستند. از طرفی تغییر پیش آمده در ویندوز 8 بسیار بزرگ است و از طرفی دیگر این تغییر بزرگ دارد برنامه نویسان را تهديد می کند. اما داستان چیست؟ در ادامه مطلب به آن پی خواهید برد.


حدود 10 سال پبش زمانی كه مایكروسافت فریم ورک «دات نت» را معرفی كرد، امید داشت كه این Framework زمانی بر روی تمام پلتفرمهای دنیا جای خود را باز كند. اما متاسفانه به نتیجه دلخواه نرسید. برای لینوكس پروژه سورس‌باز Mono شكل گرفت. بر روی Symbian نوكیا، بستر دات نت توسط RedFiveLabs فراهم شد. حتی خود مایكروسافت بر روی میكروكنترلر هم .Net كوچكی طراحی كرد كه آنرا میكرو دات نت نامید و موارد بسیار دیگر، اما نهایتا هیچكدام به اندازه لازم توانایی پیدا نكردند.


در هر صورت مایكروسافت تصمیم جدی گرفته بود تا به این هدف دست یابد، بنابراین چند سال پیش یك پروژه به مراتب عظیمتر بنا كرد تحت نام "ژوپیتر". هدف از این پروژه، گسترش سیستم عامل ویندوز بر روی تمامی پلتفرمهاست، یعنی كامپیوترهای شخصی، تبلت‌ها، گوشی‌های موبایل و ... البته مایكروسافت با تجربه قبلی می‌دانست كه اینبار بهتر است از استاندارهای مورد پذیرش كاربران جهت نیل به اهداف خود استفاده نماید.


بنابراین از بین تمامی گزینه ها، پرمخاطبترین آن یعنی HTML را انتخاب كرد، HTML5 آنقدر توسعه پیدا نموده كه مایكروسافت بتواند مستقیما در سیستم عامل جدید خود یعنی ویندوز 8 استفاده كند. با توجه به استفاده روز افزون HTML5 در سایر پلتفرمها، پروژه ژوپیتر ظاهرا بسیار سریع به هدفش خواهد رسید.


اما از چند روز پیش كه كنفرانسی چهار روزه در كالیفرنیا جهت معرفی ویندوز 8 برگذار شده، جامعه برنامه نویسان و توسعه دهندگان ویندوز دچار نگرانی شده است. اولین تغییر در این محصول جدید، نمای جدید آن به نام "مترو" می‌باشد كه دارای ظاهری دل‌فریب و مشتری پسند جهت آغاز حركت به دنیای لمسی می‌باشد ولی در پس آن ابهامات بسیاری است، كه دلواپسی برنامه‌نویسان را به همراه دارد. مایكروسافت در اینترنت اكسپلورر 10 اجازه نصب پلاگین نمیدهد، این بدان معنی است كه دیگر خبری از Flash نخواهد بود و متاسفانه بدتر از آن اینكه برای Silverlight هم مجالی نمانده! در عوض مایكروسافت HTML5 را جایگزین كرده است.


هم اكنون در بسیاری از سایتهای مربوط به تكنولوژی Silverlight درگیری و بحث و اعتراض به پا شده، مایكروسافت هم یا سكوت میكند و یا با جمله "ما پشتیبانی خواهیم كرد" شعله این آتش‌ را فرو می‌نشاند! هرچند كه باز از جای دیگر زبانه میكشد... حتی خبرها حاكی از آنست كه در خود مایكروسافت هم گروه‌های توسعه در جنگ و درگیری هستند! چیزی كه در نگاه به فیلمهای مربوط به كنفرانس مشهود است، حركت آرام آرام مایكروسافت به سمت حذف تدریجی بسیاری از تكنولوژیهای فعلی و جایگزین نمودن معادل جدید آن می‌باشد و به قول خود مایكروسافت دگرگونی عظیمی در راه است.


http://www.narenji.ir/sites/default/files/images/u5/win8round/windows8platform.jpg

اگر به سایت www.buildwindows.com مراجعه نمایید، در فیلم اول مربوط به روز اول، دقیقه 36، تصویری (تصویر بالا) نمایش داده میشود كه بیانگر ایجاد یك سیستم عامل كاملا متفاوت با قبل می‌باشد. توجه به این نكته مهم است كه در حال حاضر ویندوز 8 از كلیه تكنولوژیها و ابزارات قدیمی ویندوز (تحت عنوان Desktop Apps) پشتیبانی میكند ولی موضوعی كه برنامه نویسان را نگران كرده، هدف اصلی مایكروسافت جهت قطع كامل ابزار های قدیم و جایگزینی با امكانات جدید است!


هنوز بسیار سخت میتوان پیش‌بینی نمود و یا قضاوت كرد. اما با توجه به كنفرانس مذكور و اهداف پروژه ژوپیتر باید پذیرفت كه مایكروسافت قصد دارد ویندوز را كاملا دگرگون كند، بنابراین طبق اطلاعات موجود اینطور گفته میشود كه قرار است به زودی Silverlight و WPF حذف شوند و در ادمه آن .NET (دات نت) نیز حذف خواهد شد! حتی جالبتر آنكه بدانید كدنویسی محلی (Native) برای Win32 هم كه توسط Visual C++ انجام می‌گرفت متحول شده و بزودی WinC++ جایگزین آن میشود. نكته اینجاست كه این تنها یك تغییر نام نیست، بلكه هدف اصلی "تغییر كامل API ویندوز" می‌باشد، و در آینده HTML5 و یك فریم ورک جدید به نام WinRT (مخفف Windows Runtime) جایگزین چارچوب فعلی خواهد شد. البته Syntax زبانهای ویژه مایكروسافت (C# و VB) حفظ گشته و برای توسعه در API جدید استفاده خواهند شد (این هم مثلا دلگرمی برای برنامه‌نویسان)!


در سال 95 كه مایكروسافت ویندوز 95 را جایگزین Dos نمود، این موضوع را در نظر داشت كه باید تا مدتها از داس پشتیبانی كند، بنابراین گزینه MS Dos Prompt مدتهاست در منوی Start ویندوز وجود دارد. اما بهتر است بدانید كه هر بار ویندوز جدیدی ارائه شده برخی از امكانات این شبیه ساز داس كاسته شده است، به عنوان مثال در ویندوز 7 امكان Fullscreen از آن حذف گردیده و عملا بسیاری از نرم‌افزارهای قدیمی تحت داس (مانند بازی‌ها) قادر به اجرا نمی‌باشند. البته این موضوع اهمیت چندانی ندارد. چون دیگر نیازی به آن نرم‌افزارها احساس نمی‌شود. در رابطه با ویندوز هم برنامه همین است. مایكروسافت نمیتواند و نباید یكمرتبه پشتیبانی ویندوز از API قدیم را حذف كند. ولی به مرور با ورود ویندوزهای جدید به بازار باید چارچوب سیستم عامل جدید بنا شده و حمایت از محیط قدیمی كمرنگ‌تر گردد.


بنابراین در آینده نرم‌افزارهای كنونی دیگر قابل اجرا بر روی ویندوز نخواهد بود و همه آنها باید مجددا برای ویندوز جدید بازنویسی شوند. (همانند كوچ كردن از Dos به ویندوز) كاری كه همین الان خود مایكروسافت شروع كرده و در حال بازنویسی مجموعه آفیس برای ویندوز 8 است. البته متذكر میشویم كه ویندوز 8 همه را پشتیبانی میكند ولی برای ویندوز بعدی اطمینانی نیست! اغلب برنامه‌نویسان معترض، شاكی از آنند كه چرا مایكروسافت با علم به پروژه "ژوپیتر" از چند سال پیش، حالا تصمیم به خبر رسانی گرفته و چه لزومی داشت برخی تكنولوژیها مانند Silverlight را معرفی و در ابتدای راه نابود كند!؟ برخی از معترضان سوال دارند كه با وجود چنین اهدافی چرا در حال توسعه نسخه 5 سیلورلایت هستید؟ تكلیف سرمایه‌های از دست رفته بابت این دسته تكنولوژیها چه خواهد بود؟! سرانجام نرم‌افزارهای حرفه‌ایی و پیچیده چه خواهد شد؟ فوتوشاپ، 3D Max، اتوكد و سایر نرم‌افزارهای مهندسی و حتی خود VisualStudio چطور تغییر خواهند كرد؟ از چه زمانی این دگرگونی و انتقال، قطعی و كامل خواهد شد؟


http://www.narenji.ir/sites/default/files/images/u5/win8round/2.jpg

مشابه این رویداد در سیستم عامل موبایل " ویندوز فون " در حال وقوع است، همچنانكه تصمیم اصلی مایكروسافت همین بوده كه كامپیوتر، تبلت و موبایل یكپارچه شوند، بنابراین در نسخه های بعدی ویندوز فون هم HTML5 جایگزین سیلورلایت خواهد بود و همچنین طبق سخنان مسئولین مایكروسافت XNA هم حذف شده و توابع DirectX از طریق همان WinRT در دسترس قرار میگیرد! (این موضوع در فیلم دوم كنفرانس به نمایش درآمده و حتی نمونه كدی هم جهت خلق بازی سه بعدی نوشته میشود). XNA فریم ورکی بود برای سازندگان بازی که از دایرکت ایکس بهره میبرده و علاوه بر در اختیار گذاشتن ابزار های مناسب بازی نویسی، امکان اجرای بازی های نوشته شده، روی پلتفرم های مختلف مانند: ایکس باکس، پی سی و ... را فراهم می کرد. شاید نوكیا هم برای همین منتظر مانده و هنوز اولین گوشی مجهز به ویندوز فون را معرفی نكرده، چون منتظر این كوچ عظیم و خروج ویندوز فون اصلیست!


برخی معتقدند اگر در این اوضاع پرآشوب رقیبان مایكروسافت از جمله اپل (یا حتی گوگل!) به خود تكانی داده و بازار كامپیوترهای شخصی را با سیستم عاملی مناسب اشباع كنند، دیگر مجالی برای مایكروسافت باقی نخواهد ماند! اگر تولیدكننده ایی مجبور باشد برای توسعه و بازنویسی نرم‌افزارهایش بر روی بستر جدید ویندوز سرمایه‌گذاری كند، چرا این سرمایه را صرف بازنویسی و انتقال كامل به سیستم عاملی دیگر معطوف ننماید؟! قطعا تمامی شركتهای بزرگ نرم‌افزارهای ویندوزی، این روزها به همین موضوع فكر میكنند.


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

منبع : نارنجی (http://www.narenji.ir)

[Saman Hashemi]

:ناراحت::ناراحت::افسرده:

[AMIBCT]

مایکروسافت شاید بخواهد و بتواند SilverLight را حذف کند

ولی عددی نیست که بخواهد جلوی فلش بایستد
IE پشتیبانی نکند این IE است که شکست می‌خورد نه Flash

[Aferir]

من که مشکی نمی بینم. یک ابزار با یک ابزار دیگر جایگزین شده، همین. الگوریتم ، شی گرایی ، patterns و غیره که عوض نشده است .
حتی اگه اینها عوض شوند( که حتما عوض می شند) باز هم که مشکلی نیست.
من یک برنامه نویسم نه یک کد نویس.
هیج وقت به ابزار وابسته نشوید.

[مهدی کرامتی]

بنابراین طبق اطلاعات موجود اینطور گفته میشود كه قرار است به زودی Silverlight و WPF حذف شوند و در ادمه آن .NET (دات نت) نیز حذف خواهد شد!چنین چیزی صحیح به نظر نمی رسد، چرا که برنامه های مبتنی بر مترو که با #C نوشته می شوند بر اساس WPF و XAML هستند.


بنابراین در آینده نرم‌افزارهای كنونی دیگر قابل اجرا بر روی ویندوز نخواهد بود و همه آنها باید مجددا برای ویندوز جدید بازنویسی شوند.این صحیح نیست. برنامه هایی که در قدیم برای Windows 95 نوشت شده بودند هنوز بر روی ویندوز 7 کار می کنند، حتی اگر نیازی در این برنامه ها وجود داشته باشد که مربوط به ویندوز فوق باشد خود ویندوز 7 آنها را در حالت Compatibility Mode اجرا می کند. از این قضیه می توان نتیجه گرفت که این روند همچنان جریان خواهد داشت.

از طرف دیگر، مایکروسافت در ابتدا با عرضه سیستم عامل ویندوز Phone سعی کرد روند جدیدی برای ایجاد برنامه های کاربردی ایجاد کند، اما پس از مشاهده کندی این روند تصمیم گرفت ویندوز 8 را سازگار با ویندوزهای قبلی مانند 7 کند. به این ترتیب شما می توانید برنامه هایی که از قبل برای ویندوز موجود بودند (مانند Photoshop و ...) را بدون مشکل روی گستره وسیعی از دستگاه ها شامل PC ، Tablet و Phone اجرا کنید! این برای مایکروسافت یک برگ برنده فوق العاده محسوب می شود، چرا باید چنین برگ برنده ای را دور بیاندازد؟


مایكروسافت در اینترنت اكسپلورر 10 اجازه نصب پلاگین نمیدهد، این بدان معنی است كه دیگر خبری از Flash نخواهد بود و متاسفانه بدتر از آن اینكه برای Silverlight هم مجالی نمانده! در عوض مایكروسافت HTML5 را جایگزین كرده است.
صحیح نیست. من امروز سایت برنامه نویس را با ویندوز 8 باز کردم، در ابتدا فلش های بالای سایت را نشناخت. چند دقیقه بعد Installer فلش بالا آمد (به نظر نمی آمد دانلود شده باشد، چون خیلی سریع نصب شد) و فلش پلیر نصب شد، دوباره که سایت برنامه نویس را باز کردم فلش هم در بالای صفحات قابل مشاهده بود (تصویر زیر را ببینید)


75538


سیلورلایت هم توسط خود Browser نصب شد!



75539


با توجه به این موارد، نگرانی های ذکر شده در تاپیک اول بی مورد به نظر می رسد.

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

[sgb110]

من یک برنامه نویسم نه یک کد نویس.


ولی این هم درست نیست که مایکروسافت ما رو به ویژوالش معتاد کنه بعد بگه من هر سازی زدم شما برنامه نویس ها باید باهاش برقصید

[مهدی کرامتی]

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

در مورد ویندوز 7 هم همین طور بود. برنامه های قبلی بدون مشکل بر روی ویندوز 7 کار می کردند، اما اگر شما می خواستید از امکانات جدید معرفی شده برای رابط کاربری ویندوز 7 (مانند نمایش درصد پیشرفت عملیات بر روی آیکون برنامه در TaskBar و ...) استفاده کنید مجبور بودید Windows 7 SDK که یک Class Library برای ویندوز 7 داشت و به راحتی قابل استفاده بود را به کار بگیرید.

Windows Application، WPF Application و ... هنوز بر روی ویندوز 8 قابل برنامه نویسی و استفاده است، تکنولوژی های جدیدتر هم اضافه شده اند.

پس، نگران نباشید!

[Sundown]

هنر مایکروسافت همیشه همین بوده که محصولات جدیدش محصولات قدیمیش رو تمام و کمال پشتیبانی میکنند.

حق با دوستمون جناب DelphiAssistant هست هیچ نگرانی وجود ندارد. در کل این تغییرات را مثبت میبینم

[ricky22]

خالی از لطف نیست
خلاصه‌اي كوتاه در مورد WinRT (http://www.dotnettips.info/2011/09/winrt.html)

[amir_saniyan]

من کاملا مطمين هستم که اگر برنامه‌ای فقط با کمی دقت در داس نسخه 1.0 نوشته شده باشه، همین الان روی ویندوز 8 کار می‌کنه.
تمام اعتبار مایکروسافت هم همین پشتیبانی از محصولات قدیمیه.
شما کافیه یک سر به پوشه C:\Windows\System32 بزنید تا ببنید چقدر برنامه ریز و درشت وجود داره که هنوز مایکروسافت به خاطر پشتیبانی اون‌ها رو حذف نکرده (نمونه‌اش dialer.exe).
به هر حال سابقه مایکروسافت نشون داده همانطور که ابداعات جدیدی می‌کنه و در کنارش ابداعات دیگران رو توسعه می‌ده (مثل C# که از جاوا ایده گرفت)، شکست رو هم خوب قبول می‌کنه (نمونه‌اش J++ , J#).
اما باید قبول کرد که تقریبا هر 10 سال یکبار تمام اطلاعات یک متخصص در حوزه فناوری کامپیوتر متحول می‌شه و یک فرد کاملا جدید با اطلاعات کاملا متفاوتی خواهد شد. اگر کسی نمی‌تونه این سرعت سریع رو تحمل کنه و حال و حوصله به روز کردن خودش رو نداره، می‌تونه بره سراغ رشته‌هایی مثل مکانیک که هر چند صد سال یکبار یک فردی مثل نیوتون و انیشتین یک تکونیش می‌دن :D
در هر حال کسی که همراه زمان جلو بره و خودش رو به روز کنه نباید نگران این مسایل باشه :)
موفق باشید

[ARC]

اگر قرار باشه دانت حذف بشه پس چه بلایی سر برنامه های وب میاد؟ منظور از این حذف، حذف از سیستم برنامه نویسی ویندوز هست و یا نه کلا دات نت رو تعطیل کنن؟
یه سوال دیگه در این سیستم مترو که دات نتی نیست پس زبان هایی مثل C# و VB.net چه جوری کار میکنن؟
البته من که فکر نمی کنم همچین اتفاقی بیفته اونم زمانی که دات نت این قدر پیشرفت کرده و موفق شده.

[A B C D]

خالی از لطف نیست
خلاصه‌اي كوتاه در مورد WinRT (http://www.dotnettips.info/2011/09/winrt.html)
منبعی که معرفی کردید گفته:

WinRT درحقيقت محصور كننده‌ي (Wrapper) همان Win32 API سابق است (در پشت صحنه همان dll هاي سابق ويندوز را بارگذاري و استفاده مي‌كند) جهت تطابق با نيازهاي دهه اخير و سال‌هاي پيش رو.
اما مقالهء ویکیپدیا (http://en.wikipedia.org/wiki/WinRT) خلافش رو میگه:

WinRT is a native (http://en.wikipedia.org/wiki/Native) runtime system that is implemented directly on the Windows NT (http://en.wikipedia.org/wiki/Windows_NT)-kernel and thus not based on previous platforms, like the Win32 (http://en.wikipedia.org/wiki/Win32) API (http://en.wikipedia.org/wiki/API).

ترجمه:
WinRT یک سیستم runtime است که مستقیما بر روی هستهء ویندوز NT پیاده سازی شده است و بنابراین بر پایه پلتفرمهای قبلی مانند Win32 (http://en.wikipedia.org/wiki/Win32) API (http://en.wikipedia.org/wiki/API) نیست.

[anubis_ir]

ويكي پديا در اين مورد زياد معتبر نيست. ديباگ كنيد سيستم رو تا ببينيد چه چيزي را بارگذاري مي‌كند. يك نفر اينكار رو كرده و گزارش نوشته براش:
WinRT and .NET in Windows 8 (http://blogs.microsoft.co.il/blogs/sasha/archive/2011/09/15/winrt-and-net-in-windows-8.aspx)


Next, a C++ Metro application will still load Win32 DLLs such as kernel32 and ntdll. Moreover, the WinRT APIs call into the Win32 DLLs – so they are not a replacement but rather a wrapper, an API flavor, on top of Win32.

[anubis_ir]

جالب است كه اين سايت نارنجي (ماخذ تاپيك جاري)، يك روز تبليغ كفش زنانه مي‌كند يك روز تبليغ فروش لپ تاپ، يك روز در مورد سرنوشت فناوري‌ها اظهار نظر مي‌كند! جريان چيست؟ :لبخندساده:

[A B C D]

اگر قرار باشه دانت حذف بشه پس چه بلایی سر برنامه های وب میاد؟ منظور از این حذف، حذف از سیستم برنامه نویسی ویندوز هست و یا نه کلا دات نت رو تعطیل کنن؟

در مقالهء ویکیپدیا آمده:

The .NET Framework (http://en.wikipedia.org/wiki/.NET_Framework) and the Common Language Runtime (http://en.wikipedia.org/wiki/Common_Language_Runtime) (CLR) is integrated into the WinRT as a subplatform.

یعنی گفته دات نت بعنوان یک زیرپلتفرم در داخل WinRT مجتمع شده.
حالا اینکه دقیقا یعنی چی نمیدونم، ولی بنظر میرسه محوریت خودش رو تاحدی از دست داده. حداقل دیگه اونطور مثل سابق نیست که آیندهء برنامه نویسی Native با سی++ در ویندوز دچار ابهام و رکود شدیدی بنظر میامد.
اما بهرحال فکر میکنم بازم برنامه نویسی در دات نت بجای استفادهء مستقیم از WinRT در سی++ مزایای مهمی داشته باشه. چون بهرحال در WinRT و سی++ بازم دارید سطح پایینتر کار میکنید، هرچند WinRT اکستنشن هایی رو به سی++ اضافه کرده و ظاهرا سطحش رو بالاتر برده و اینطور که برمیاد شباهت هایی هرچند ظاهری (مثلا طبقه بندی و نامگذاری کلاسهای مختلفش) با دات نت داره.
در دات نت با سی شارپ کار میکنید و کلا محیط سطح بالاتر هست و بنابراین فکر نمیکنم دات نت به این زودی و راحتی احتمال منسوخ شدن داشته باشه، اما شاید محدودهء فراگیری اون محدودتر از چیزی بشه که در ابتدا بنظر میامد.


یه سوال دیگه در این سیستم مترو که دات نتی نیست پس زبان هایی مثل C# و VB.net چه جوری کار میکنن؟
البته من که فکر نمی کنم همچین اتفاقی بیفته اونم زمانی که دات نت این قدر پیشرفت کرده و موفق شده.اصلا مترو (http://en.wikipedia.org/wiki/Metro_%28design_language%29) چیه؟
اونطور که بنده از مقالهء ویکیپدیا متوجه شدم، فقط یک استاندارد و فریمورک رابط کاربری باید باشه که اساسا بر روی متن و محتوا بنا شده و از اجزای گرافیکی صرف تاحد امکان پرهیز کرده. *
بنابراین مترو خودش چیزی جز یک استاندارد و اینترفیس کاربری جدید نیست.
مترو مگر بر WinRT بنا نشده؟
بنابراین سوال شما تبدیل میشه به اینکه «در این سیستم WinRT که دات نتی نیست پس زبان هایی مثل C# و VB.net چه جوری کار میکنن؟»
جواب این سوال هم متادیتایی هست که کدهای Native در WinRT دارن و این متادیتا از نوع متادیتای دات نت است. بنابراین تونستن قابلیت استفادهء مستقیم از کتابخانه های WinRT رو در دات نت ایجاد کنن. یعنی دیگه لازم نیست از کتابخانه های Interop دات نت و سینتاکس سطح پایین و وصله و پینه ای برای استفاده از کتابخانه های Native استفاده کنید؛ میتونید کتابخانه های Native از نوع WinRT رو طوری در محیط دات نت استفاده کنید که انگار کتابخانه های مدیریت شدهء دات نت هستن. البته چون این کتابخانه ها درواقع مدیریت شده نیستن بنابراین بنظرم در بعد عملیاتی و در نتیجه تمهیدات برنامه نویسی، تفاوت هایی میان اونها و کتابخانه های مدیریت شده وجود خواهد داشت.

*: راستی شاید شما هم با بنده هم عقیده باشید که خیلی از رابطهای کاربری متمرکز بر گرافیک و آیکون و تصویر، در عمل بحد قابل توجهی ناکارا هستن و جز یک جلوهء نمایشی سطحی چیز زیادی از امکان دریافت سریع اطلاعات بقدر کافی کامل و دقیق و بدون ابهام و کمک به کارایی عملی در اونها دیده نمیشه. مثلا خیلی وقتا این آیکونها هیچ کمکی به من نمیکنن و اساسا از متن (حالا یا بصورت Caption و یا بصورت Tooltip و غیره) برای پیدا کردن یا مطمئن شدن از عملیات یک گزینه استفاده میکنم؛ فقط بعضی آیکونهای خیلی متداول و واضح و استاندرد (مثل آیکونهای Open و Save و اینها) هستن که براحتی و سرعت و اطمینان کافی قابل تشخیص هستن.
بنظرم طراحان میکروسافت هم به همین نتیجه رسیدن که مترو رو بوجود آوردن.

[A B C D]

ويكي پديا در اين مورد زياد معتبر نيست. ديباگ كنيد سيستم رو تا ببينيد چه چيزي را بارگذاري مي‌كند. يك نفر اينكار رو كرده و گزارش نوشته براش:
WinRT and .NET in Windows 8 (http://blogs.microsoft.co.il/blogs/sasha/archive/2011/09/15/winrt-and-net-in-windows-8.aspx)


Next, a C++ Metro application will still load Win32 DLLs such as kernel32 and ntdll. Moreover, the WinRT APIs call into the Win32 DLLs – so they are not a replacement but rather a wrapper, an API flavor, on top of Win32.

این منبع هم خیلی کامل و دقیق و مطمئن نیست.
اینطور که از گفته های طرف در همون ابتدا برمیاد خودش عضو تیمی که روی هر بخشی از این داستان کار بکنه یا اطلاع موثق از ساختار اون داشته باشه نیست.
وبلاگهای میکروسافت هم که رسمی نیستن و دیدگاه شخصی افراد رو منعکس میکنن و لزوما نظارت و اصلاحی بر اشتباهات اونا وجود نداره.
اینم که یک اپلیکیشن هنوز Win32 رو لود و استفاده بکنه بازم دلیل کامل و قاطعی بر این مسئله نیست که WinRT خودش بصورت پایه ای و کامل بر روی Win32 استواره. شاید WinRT هنوز کامل نیست یا بعضی کارایی ها رو پوشش نمیده و در اون موارد از Win32 استفاده میشه و شاید بصورت موقتی بعضی کارایی های WinRT رو با استفاده از کتابخانه های Win32 پیاده سازی کردن.

بنده نفهمیدم طرف چطور یه دفه از حدس و گمان و چنتا تست خیلی کلی و سطح بالا به این اطمینان رسیده که ادعا میکنه WinRT یک wrapper بر روی Win32 هست، درحالیکه دلیل کافی برای این مطلب ذکر نکرده و نه حتی یک منبع موثق و از گفتار خودش هم در ابتدا برمیاد که در این زمینه کاره ای نبوده و نیست:

From a brief analysis of the Windows 8 Developer Preview, Visual Studio 11 Developer Preview, and whatever bits of information delivered at the conference sessions, I think I have a pretty decent mental picture of what’s going on.

[anubis_ir]

* دات نت داخل WinRT مجتمع نشده، يك سطح بالاتر است. به تصاوير اين مطلب مراجعه كنيد:
http://dougseven.com/2011/09/15/a-bad-picture-is-worth-a-thousand-long-discussions/
اين تصوير هست (http://www.mediafire.com/?ym0la6bal2nvg1u) اگر فيلتر شده.
* سطح پايين‌تر در سي++ اينجا معنا ندارد چون sandbox و محدوديت‌هاي امنيتي اعمال شده روي WinRT اين اجازه را نمي‌دهد.
* در مورد رد نظرات اين شخص هم فقط يك كار مي‌شود انجام داد. سيستم را ديباگ كنيد و گزارش موارد load شده را منتشر كنيد. براي اين مورد هم لازم نيست تخصص آنچناني داشته باشيد. انواع و اقسام ديباگرهاي native codes موجود هستند خوشبختانه و كمبودي از اين لحاظ نيست.

[A B C D]

این رو ببینید: http://msdn.microsoft.com/en-us/library/windows/apps/br205757%28v=VS.85%29.aspx
درش آمده:

Metro style apps can use a subset of the Win32 and COM API. This subset of APIs was chosen to support key scenarios for Metro style apps that were not already covered by the Windows Runtime, HTML/CSS, or other supported languages or standards. The Windows App Certification Kit ensures that your app uses only this subset of the Win32 and COM API.

ترجمه:
اپلیکیشن های مترو میتوانند یک زیرمجموعه از Win32 and COM API را استفاده کنند. این زیرمجموعه از API برای پشتیبانی سناریوهای کلیدی ای که پیشتر بوسیلهء Windows Runtime، ا HTML/CSS یا دیگر زبانها یا استانداردهای ساپورت شده پوشش داده نمیشدند انتخاب شده بود. Windows App Certification Kit اطمینان میدهد که اپلیکیشن شما فقط این زیرمجموعه از Win32 and COM API را استفاده میکند.

بنظرم بقدر کافی واضح باشه. یعنی لود شدن Win32 رو در یک اپلیکیشن مترو میشه به همین علت دونست که در این متن آمده. این متن میگه بعضی از چیزها سابقا در مجموعهء فناوریهای WinRT پوشش داده نشده بودند (احتمالا الان پوشش داده شدن) که به همین علت امکان استفاده از یک زیرمجموعه از Win32 و COM رو در اپلیکیشن های مترو قرار دادن.

خلاصه میگم اینقدر سطحی و زود نباید قضاوت کرد. منبع باید موثق باشه. تست هم باید تست اصولی و کامل و دقیق باشه، نه اینکه تا دیدیم یه اپلیکیشن بر مبنای WinRT کتابخانه های Win32 رو لود و استفاده کرد بگیم WinRT یک Wrapper بر روی Win32 است!

[anubis_ir]

نه. دو مفهوم را با هم تركيب نكنيد. يكي مفهوم دسترسي محدود شده به Win32 API است كه همين مطلب فوق به آن اشاره دارد. مثلا مسيج باكس Win32 API در اينجا قابل استفاده نيست، به علاوه كليه مسايل امنيتي Sandbox آن. يك مورد ديگر هم پايه اصلي خود WinRT است.

[A B C D]

* دات نت داخل WinRT مجتمع نشده، يك سطح بالاتر است. به تصاوير اين مطلب مراجعه كنيد:
http://dougseven.com/2011/09/15/a-ba...g-discussions/ (http://dougseven.com/2011/09/15/a-bad-picture-is-worth-a-thousand-long-discussions/)
اين تصوير هست (http://www.mediafire.com/?ym0la6bal2nvg1u) اگر فيلتر شده.
بله اینطور که از تصویر مشخص است از نظر پیاده سازی یک سطح بالاتر است و بر اساس WinRT پیاده سازی شده است.
اما شاید آن جمله از نظر بعضی مفاهیم دیگر بیان شده است.
ضمنا در منبع دیگری (http://www.winsupersite.com/blog/supersite-blog-39/windows8/winrt-replacing-win32-140605) که خواندم به دیاگرام میکروسافت اشاره شده بود:

Microsoft has an unfortunately inaccurate high-level diagram showing the relation between WinRT and the environments its replacing (which are shown as IE, Win32, and .NET)

اگر این همان دیاگرام باشد، که به احتمال زیاد همینطور است، این منبع اعتقاد دارد که یک دیاگرام نادقیق است. حالا علتش را از خودش باید پرسید.


* سطح پايين‌تر در سي++ اينجا معنا ندارد چون sandbox و محدوديت‌هاي امنيتي اعمال شده روي WinRT اين اجازه را نمي‌دهد.

منظورم از سطح پایینتر برنامه نویسی سطح پایین، مثلا برنامه نویسی سیستمی نبود.
منظورم پایین بودن سطح خود زبان بود. یک کتابخانه و حتی WinRT با چند اکستنشن در خود زبان سطح یک زبانی مثل سی++ را برابر با زبانی مثل سی شارپ نمیکند. همچنان سطح برنامه نویسی با سی شارپ بالاتر خواهد بود، چون سی شارپ اساسا سطح بالاتر طراحی شده و ساختارها و سینتاکس سطح بالاتری دارد.
وگرنه شما با سی++ هم میتوانید برنامه های سطح بالا و اپلیکیشن بنویسید، اما مسلما سطح برنامه نویسی در سی++ از سطح برنامه نویسی در سی شارپ پایینتر است. هرچند احتمالا WinRT این مسئله را بحد قابل توجهی کم رنگ تر میکند.

[anubis_ir]

در مورد پايه اصلي خود WinRT اين توضيحات ضروري است:
از لحاظ فني WinRT يك سطح بالاتر از Win32 API قرار مي‌گيرد خصوصا User32 آن. زمانيكه يك Metro app اجرا مي‌شود، WinRT يك پنجره هميشه on-top تمام صفحه Win32-based را درست مي‌كند. يك سطح DirectX را به آن اضافه كرده و سپس همه چيز را روي آن ترسيم مي‌كند. به اين ترتيب مي‌توان اطمينان حاصل كرد كه برنامه‌هاي مترو به كمك DirectX از امكانات شتاب دهنده‌هاي سخت افزاري استفاده مي‌كنند. خلاصه اين Win32 جايي نرفته. فقط ايزوله سازي در موردش صورت گرفته تا دوستان و رفقا خيالشون راحت باشه كه نمي‌تونند از Sandbox آن خارج شوند.

[A B C D]

نه. دو مفهوم را با هم تركيب نكنيد. يكي مفهوم دسترسي محدود شده به Win32 API است كه همين مطلب فوق به آن اشاره دارد. مثلا مسيج باكس Win32 API در اينجا قابل استفاده نيست، به علاوه كليه مسايل امنيتي Sandbox آن. يك مورد ديگر هم پايه اصلي خود WinRT است.
قربونت همون دیاگرامی که خودت رفرنس دادی داره میگه که WinRT بر مبنای Win32 نیست. غیر از اینه؟

دسترسی محدود شده هم خب که چی؟ بله دسترسی به یک زیرمجموعه از Win32 هست، ولی بهرحال به اون امکاناتی که دسترسی هست Win32 است و بنابراین بصورت استاندارد لود و استفاده میشه و فکر نمیکنم دیباگر در این زمینه تفاوتی با برنامه های عادی Win32 تشخیص بده. حداقل در تست ها دلیلی بر اثبات این مدعا ذکر نشده.
اون مطلبی هم که درمورد App Certification Kit بیان شده نشون میده که برای اطمینان از اینکه برنامه فقط اون مجموعهء محدود رو استفاده کرده نیاز به ابزار و فرایند خاصی هست. یعنی ظاهرا میشه این محدودیت رو دور زد و یه چیزی تضمین شده نیست. اونطور که در منابع نوشته این محدودیت بسادگی با استفاده از ماکروها یا دستورهای پیش پردازنده در فایلهای هدر SDK مربوطه انجام شده. یعنی یه چیزی نیست که تحت نظارت و کنترل مستقیم WinRT باشه. WinRT خودشه که تحت محدودیت های امنیتی مطمئن و در sandbox اجرا میشه، نه اون چیزهایی که در همون برنامه با استفاده از Win32 انجام میشن.

[A B C D]

در مورد پايه اصلي خود WinRT اين توضيحات ضروري است:
از لحاظ فني WinRT يك سطح بالاتر از Win32 API قرار مي‌گيرد خصوصا User32 آن. زمانيكه يك Metro app اجرا مي‌شود، WinRT يك پنجره هميشه on-top تمام صفحه Win32-based را درست مي‌كند. يك سطح DirectX را به آن اضافه كرده و سپس همه چيز را روي آن ترسيم مي‌كند. به اين ترتيب مي‌توان اطمينان حاصل كرد كه برنامه‌هاي مترو به كمك DirectX از امكانات شتاب دهنده‌هاي سخت افزاري استفاده مي‌كنند. خلاصه اين Win32 جايي نرفته. فقط ايزوله سازي در موردش صورت گرفته تا دوستان و رفقا خيالشون راحت باشه كه نمي‌تونند از Sandbox آن خارج شوند.
شما همینطوری داری روی مطلبی پافشاری میکنی، درحالیکه منبع و دلیل مطمئنی براش نمیاری.
حتی همون دیاگرامی که خودت درج کردی خلاف این رو نشون میده. کجاش WinRT روی Win32 هست بگو ما هم ببینیم. اون دیاگرام مدل سیستم عاملهای قبلی بر مبنای Win32 رو با مدل جدید WinRT کنار هم قرار داده و مقایسه میکنه.

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

[anubis_ir]

*اين نمودار در اين مورد ماخذ خوبي نيست! چون بر اساس اين نمودار IE هم دارد روي كرنل اجرا مي‌شود، CLR دات نت هم به همين صورت.
*ضمنا اين WinRT يك ران تايم است كه Sandbox را اجرا مي‌كند تا مسايل را كنترل كند. لطفا مباحث را با هم تركيب نكنيد. اين Sandbox همين الان در ويندوز فون و سيلورلايت موجود است. ران تايم سيلورلايت است كه دارد اين Sandbox را پديد مي‌آورد.
* اون مورد ايجاد پنجره win32 معتبر است. لايه دايركت ايكس روي آن هم به همين صورت.

[anubis_ir]

در مورد ماخذ بهتر و معتبرتر از مدير پروژه مونو رو من الان سراغ ندارم
http://tirania.org/blog/archive/2011/Sep-15.html

WinRT wraps both the new UI system as well as old Win32 APIs and it happens that this implementation is based on top of COM

[A B C D]

يكي مفهوم دسترسي محدود شده به Win32 API است كه همين مطلب فوق به آن اشاره دارد. مثلا مسيج باكس Win32 API در اينجا قابل استفاده نيست، به علاوه كليه مسايل امنيتي Sandbox آن.

For example, the MessageBox function is not available for Metro-style apps, and its declaration is protected in the header file as follows: #pragma region Desktop Family
#if WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP)
WINUSERAPI int WINAPI MessageBoxA(…);

شما به محافظت توسط دستورات پیش پردازنده در فایلهای هدر میگی امنیت و Sandbox ؟
منبعش هم البته همونی که قبلا معرفی شد و بنظر بنده حرفاش معتبر نیست: http://blogs.microsoft.co.il/blogs/sasha/archive/2011/09/15/winrt-and-net-in-windows-8.aspx
اما حداقل در این یک مورد از یه کد و منبع خارجی معتبر سندی ارائه کرده.

من نمیگم این منبع حتما درست میگه یا مطمئنم هیچ Sandbox ای درمورد Win32 درکار نیست، اما منبع و دلیلی برای ادعاهای شما پیدا ندیدم و بلکه چیزی که از دیاگرام ارائه شده و مطالب دیگه برمیاد بیشتر باعث برداشت خلاف ادعاهای شما میشن.
تا حالا چه سند و دلیل معتبری برای این ادعا ارائه شد که WinRT بر روی Win32 بنا شده؟ دیاگرام میکروسافت خلاف این رو میگه. منابع دیگه هم خلاف این رو میگن. فقط مقالهء ویکیپدیا هم نبود. اینم که دیباگر نشون بده Win32 لود و اجرا میشه به خودی خودش هیچ چیزی رو ثابت نمیکنه (و یک دلیل احتمالیش رو با منبع معتبر براتون گذاشتم)، حتی اگر یه بخشی از WinRT هم یه کارایی با Win32 بکنه دلیل نمیشه نتیجه بگیریم WinRT با استفاده از Win32 کار کنه. همونطور که بعنوان نمونه دیدید، موقتا و بعلت کمبودهایی که بوده اجازهء استفاده از بخشهایی از Win32 رو هم دادن.

نباید اینقدر سطحی و عجولانه و غیراصولی نتیجه گیری کرد. مگر به این سادگیه؟ اونم وقتی منابع دارن خلافش رو میگن و برای موارد استثناء هم توجیه کافی وجود داره.

[anubis_ir]

* قسمتي از آن بله. اين‌ها تزئيني كه نيست. اينجا مشخص ميشه كه كتابخانه‌هاي جديد به چه چيزهايي دسترسي دارند يا نه.
* پنجره ايجاد شده جهت اجراي برنامه‌هاي مترو يك پنجره win32 با لايه دايركت ايكس است
* در مورد نحوه عملكرد اين sandbox به مطلب زير مراجعه كنيد:
Access to user resources using the Windows Runtime
http://msdn.microsoft.com/en-us/library/windows/apps/hh464936%28v=VS.85%29.aspx

[A B C D]

در مورد ماخذ بهتر و معتبرتر از مدير پروژه مونو رو من الان سراغ ندارم
http://tirania.org/blog/archive/2011/Sep-15.html

WinRT wraps both the new UI system as well as old Win32 APIs and it happens that this implementation is based on top of COM

بنظر بنده مفهوم این گفته هم میتواند بصورت های مختلف برداشت شود.
WinRT میتواند دسترسی به Win32 را هم ظاهرا از طریق محیط خودش مهیا کند. شاید منظور این بوده. نه اینکه خود WinRT هم بر مبنای Win32 بنا شده است. و شاید هم منظور طرف درواقع همان برنامه ها و محیطی بوده که قبلا هم معلوم شد میتوان در آن حداقل از بخشی از Win32 هم استفاده کرد.
اینکه ما جمله ها را چطور تفسیر کنیم خب گذشته از میزان دقت ما، به اینکه آن جملات تا چه حد در موضوع مورد بحث دقت و بدون ابهام بودن را رعایت کرده باشند هم بستگی دارد.
حالا شما یه گوگل میزنی برای WinRT و Wrap و Win32 و یه چیزایی پیدا میکنی. اما یه جستجو هم بزن برای خلاف این و بنظرم طبیعی هست که مواردی هم برای آن پیدا میکنید.

بعدشم اگر میخواید مطمئن بشید فکر نمیکنم زیاد سخت باشه. باید از یه منبع معتبر و موثق (تا حد امکان) تحقیق کنیم. شده از خود میکروسافت، اگر نشد در یکی از فرومهای رسمی یا معروفش. معمولا هیچکس نمیتونه بهتر از خودشون مطلع باشه و توضیح بده و اثبات کنه. قبول دارید؟
شما که خودتون واردتر هستید احتمالا یه فروم رسمی رو سراغ دارید معرفی کنید.

[vcldeveloper]

تمام اعتبار مایکروسافت هم همین پشتیبانی از محصولات قدیمیه.
شما کافیه یک سر به پوشه C:\Windows\System32 بزنید تا ببنید چقدر برنامه ریز و درشت وجود داره که هنوز مایکروسافت به خاطر پشتیبانی اون‌ها رو حذف نکرده (نمونه‌اش dialer.exe).
به هر حال سابقه مایکروسافت نشون داده همانطور که ابداعات جدیدی می‌کنه و در کنارش ابداعات دیگران رو توسعه می‌ده (مثل C# که از جاوا ایده گرفت)، شکست رو هم خوب قبول می‌کنه (نمونه‌اش J++ , J#).
البته این بیشتر به backward compatibility در محصولات برای کاربر نهایی صدق میکنه. در حوزه backward compatibility برای ابزارهای توسعه نرم افزار، مایکروسافت همچین خوش سابقه هم نیست!


در مورد ویندوز 7 هم همین طور بود. برنامه های قبلی بدون مشکل بر روی ویندوز 7 کار می کردند، اما اگر شما می خواستید از امکانات جدید معرفی شده برای رابط کاربری ویندوز 7 (مانند نمایش درصد پیشرفت عملیات بر روی آیکون برنامه در TaskBar و ...) استفاده کنید مجبور بودید Windows 7 SDK که یک Class Library برای ویندوز 7 داشت و به راحتی قابل استفاده بود را به کار بگیرید.
این بار خیلی تفاوت کرده؛ اون چیزی که در ویندوز 7 بود، هنوز همان Win32 بود، فقط یکسری توابع جدید برای بعضی کارهای محدود اضافه شده بودند. البته به جز Direct2D که در ویندوز 7 معرفی شد، ولی استفاده چندانی ازش نشد، تا اینکه در ویندوز 8 رابط گرافیکی Metro بر روی آن سوار شد. WinRT رو نمیشه گفت یک افزونه برای Win32. تحولی که ایجاد میکنه، بسیار گسترده تر از اضافه کردن تعدادی تابع به Win32 هست.


از طرف دیگر، مایکروسافت در ابتدا با عرضه سیستم عامل ویندوز Phone سعی کرد روند جدیدی برای ایجاد برنامه های کاربردی ایجاد کند، اما پس از مشاهده کندی این روند تصمیم گرفت ویندوز 8 را سازگار با ویندوزهای قبلی مانند 7 کند. به این ترتیب شما می توانید برنامه هایی که از قبل برای ویندوز موجود بودند (مانند Photoshop و ...) را بدون مشکل روی گستره وسیعی از دستگاه ها شامل PC ، Tablet و Phone اجرا کنید! این برای مایکروسافت یک برگ برنده فوق العاده محسوب می شود، چرا باید چنین برگ برنده ای را دور بیاندازد؟
من همچین برداشتی از چیزهایی که از کنفرانس Build دیدم و شنیدم ندارم؛ تصور نمی کنم در نسخه های مبتنی بر ARM ویندوز شما بتونید با چیزی غیر از WinRT برنامه بنویسید. قبلا هم اعلام شده که در ویندوز های مبتنی بر ARM نباید انتظار Backward compatibility داشت. از طرف دیگه، عمده تبلت های موجود در بازار و تبلت های موجود در آینده نزدیک، مبتنی بر ARM خواهند بود، پس نباید انتظار داشت که برنامه های فعلی ویندوز به این راحتی برای تبلت ها کامپایل و آماده اجرا بشند. این مسئله منطقی هم هست، مایکروسافت نمیتونه اجازه بده که برنامه هایی که به طور ویژه برای محیط های Touch بهینه نشدند، و شکل و ظاهر برنامه های Legacy ویندوز رو دارند، روی تبلت سر و کله شان پیدا بشه؛ چون این باعث تخریب تجربه کاربر نهایی با این تبلت ها میشه. این تجربه کاربر نهایی و حسی که از کار کردن با نرم افزارهای تبلت بهش القاء میشه، همون برگ برنده اپل در iOS بوده. پس من انتظار دارم برنامه های موجود برای PC همچنان روی PC های دارای ویندوز 8 قابل اجرا باشند، اما روی تبلت های دارای ویندوز 8، فقط برنامه های مبتنی بر WinRT با رابط کاربری Metro قابل اجرا شدن باشند.


برخی معتقدند اگر در این اوضاع پرآشوب رقیبان مایكروسافت از جمله اپل (یا حتی گوگل!) به خود تكانی داده و بازار كامپیوترهای شخصی را با سیستم عاملی مناسب اشباع كنند، دیگر مجالی برای مایكروسافت باقی نخواهد ماند! اگر تولیدكننده ایی مجبور باشد برای توسعه و بازنویسی نرم‌افزارهایش بر روی بستر جدید ویندوز سرمایه‌گذاری كند، چرا این سرمایه را صرف بازنویسی و انتقال كامل به سیستم عاملی دیگر معطوف ننماید؟! قطعا تمامی شركتهای بزرگ نرم‌افزارهای ویندوزی، این روزها به همین موضوع فكر میكنند.
اتفاقا شرکت هایی مثل اپل و گوگل از جمله مبلغین پایان عصر PC ها هستند. حوزه PC حوزه ایی هست که این شرکت ها در آن سهم چندانی ندارند، و آینده آن هم با تردیدهایی مواجه شده. اصلا همین تردیدها باعث شده که مایکروسافت هم از حوزه سنتی خودش کمی فاصل بگیره، و همه تخم مرغ هاش رو در یک سبد نذاره. اون وقت چندان منطقی نیست که تصور کنیم با این کار مایکروسافت، اون شرکت ها به دنبال کسب بازار مایکروسافت از PC باشند. اگر همچین بازار گرمی موجود بود، مایکروسافت ازش فاصله نمی گرفت. نکته بعدی هم اینکه، بر فرض که بازار PC پر رنق بشه، مایکروسافت با سیاست فعلی خودش چیزی از دست نداده، چون برنامه های فعلی همچنان به خوبی و بدون نیاز به تغییر خاصی، روی PC های دارای ویندوز 8 کار خواهند کرد. مسئله اصلی برای کسانی هستند که بخوان نرم افزار خودشان را برای تبلت ها هم آماده کنند.


به هر حال، نظر شخصی من این هست که هر چند یک تغییر استراتژی در مایکروسافت رخ داده، اوضاع مایکروسافت و برنامه نویسی برای پلت فرم های نرم افزار بد نشده، بلکه بهتر هم شده. تکنولوژی های پایه ایی که مایکروسافت در این مدت آنها را گسترش داده، همچنان زنده خواهند ماند، شاید بعضی از آنها مثل Silverlight نقش شان کمرنگ بشه، یا تغییر جهت هایی در آنها حاصل بشه، ولی دات نت، دات نت خواهد ماند، و زبان های برنامه نویسی مایکروسافتی سر جای خودشان خواهند ماند. محیط های برنامه نویسی تولید کننده Native Code (مثل ویژوال سی پلاس پلاس) که در چند سال اخیر با تبلیغات گسترده مایکروسافت برای دات نت روی پلت فرم ویندوز، تا حدودی به حاشیه رانده شده بودند، دوباره مورد توجه ویژه مایکروسافت قرار خواهند گرفت. البته Win32 هم بالاخره بازنشسته خواهد شد؛ کاری که قرار بود با عرضه دات نت انجام بشه، ولی انجام نشد، شاید الان با توجه ویژه مایکروسافت به توسعه نرم افزارهای Native Code، در WinRT، بالاخره Win32 بازنشسته بشه.

[مهران رسا]

آقای کشاورز به نظر شما مایکروسافت ترتیبی میده تا WinRT هم مثل NET Framework. بر روی نسخه های قبلی ویندوز قابل پیاده سازی باشه؟ اصلاً از نظر منطقی امکان پذیر هست؟ من اطلاعات زیادی در مورد WinRT ندارم.

[vcldeveloper]

آقای کشاورز به نظر شما مایکروسافت ترتیبی میده تا WinRT هم مثل NET Framework. بر روی نسخه های قبلی ویندوز قابل پیاده سازی باشه؟
اطلاعی ندارم. نسخه های قبلی ویندوز امکان اجرا بر روی سی پی یو های ARM را ندارند، اما شاید با توجه به استقبال گسترده از ویندوز 7 توسط کاربران، و وجود برخی پیش نیاز هایی WinRT روی این سیستم عامل، مثل Direct2D، مایکروسافت بخش هایی از WinRT را برای این سیستم عامل هم آماده کنه، تا با توجه به وجود تعداد بالایی از ویندوز 7، برنامه نویسان مجبور نشوند برای پشتیبانی از ویندوز 7 و ویندوز 8، کدهایشان را دو بار تحت دو API متفاوت بنویسند. البته اگر همچین اتفاقی بیافته، میشه تصور کرد فقط بخش هایی از WinRT به ویندوز 7 راه پیدا کنند، نه همه آن.

[محمد باقری نسب]

جناب DelphiAssistant ، شما باید سایتتون رو توی IE 10 باز کنید نه IE 9 و خواهید دید که هیچ ActiveX ی بارگذاری نخواهد شد! نه فلش و نه سیلورلایت و نه هیچ ActiveX دیگری.

http://www.geek.com/wp-content/uploads/2011/09/win8_screenshot_IE10_web.jpg

[مهدی کرامتی]

ورژنی از IE که به طور پیش فرض همراه با ویندوز 8 نصب می شود IE 10 است. تصاویری که ضمیمه کردم مربوط به IE 10 بود نه 9.

[amir-yeketaz]

فکر میکنم اینجا رو هم ببینین جالب خواهد بود
http://www.persiadevelopers.com/news/window8-vs2011-dotnet4-5-preview.aspx

[joker]

یه برنامه نوشتم سه مدل درایور مختلف مجبور شدم با اینستالش بدم یکی مخصوص xp-2003 یکی مخصوص ویندزو سون 32 بیتی و یکی مخصوص 64 بیتی ها.
هرکدوم هم ماشالا باید یه قلقی بکار میبردم تا درایورنصب میشده ، از وقتی بیلی نیت کرده بره دنبال خوشگذرونی و تفریحات سالم دیگه میکروسافت روز به روز داره بیشتر گند میزنه تو اعصاب.

[Mehdi Naderi]

من این پست ها رو خوندم اما در یک مورد برام ابهام پیش اومده

من چند جا خوندم که رابط کاربری ویندوز 8 بر پایه سیلورلایت است
درسته ؟

[مهران رسا]

من چند جا خوندم که رابط کاربری ویندوز 8 بر پایه سیلورلایت است
درسته ؟
خیر. در تصویر زیر قسمت Metro Style Apps رو مشاهده بفرمایید :
http://blog.ecofic.com/wp-content/uploads/2011/09/api1.png

[A.Karimi]

واقعاً جای تعجب دارد!

به جای اینکه خوشحال باشیم که مغزمان از کارکردن با تکنولوژی‌های تکراری یخ نمی‌زند و با چنین پلتفرم جزابی می‌توانیم به سادگی برنامه‌نویسی کنیم، من نمی‌دانم اینهمه نق و غر برای چیست ؟

از خوشحالی در پوست خودم نمی‌گنجم و بی صبرانه منتظر نوشتن کدهای جدید بر روی WinRT هستم. مثل روز روشن است که در حال گذر به مرحله جدیدی از سیستم عامل ویندوز هستیم و این خیلی لذت بخش است. و مطمئناً همانطور که تا کنون زبان‌های خانواده C حرف اول را می‌زدند از این به بعد هم خواهند زد. فقط ممکن است در کلیات قضیه تفاوتهایی به وجود بیاید که کاملاً قابل درک است! هیچ شرکتی دوست ندارد با بدتر کردن پلتفرم خود طرفدارانش را از دست بدهد! مایکروسافت هم به همچنین.

خوب است برخی از دوستان که درباره نابودی dotNet و امثال آن صحبت کردند بدانند که علم سیستم عامل بیشتر به سمت سیستم‌عامل‌های Managed یا Language-based می‌رود. اکنون دانشجویان سیستم‌عامل دانشگاه‌های برتر جهان به جای نوشتن کد با زبان C و Assembly، افزونه‌هایی با زبان #Sign که هم خانواده زبان #C است برای سیستم‌عامل Singularity می‌نویسند. سیستم‌عامل‌های آینده بیشتر به این سمت و سو خواهند رفت. با اینکه خودم طرفدار پر و پا قرص زبانهای سطح پایین هستم و سالها از برنامه نویسی با آنها لذت بردم اما باید گفت که قرار نیست تا اخر دنیا با زبان Assembly و ++C کد زد.

در هر صورت ممکن است Xaml و Html5 با هم ادغام شوند و یا مبدلی برای این دو ساخته شود که مثلا شما با Xaml کد بزنید و خروجی Html5 دریافت کنید اما کلیت کار تغییر نخواهد کرد.

در هر صورت اوضاع بسیار بسیار بهتر از آن است که برخی نگران آن هستند!

[A B C D]

منکه به خوندن و یاد گرفتن عادت دارم. و اینو فهمیدم که این رشته یعنی همین. درسته گسترده و پیچیده هست و تغییرات زیاد و سریع داره و اینا واسه آدم دردسره، اما عوضش از نظر قدرت و آزادی ای هم که به تک تک افراد بدون هیچ امکانات اولیه و سرمایهء خاصی میده، در مقایسه با بیشتر رشته های دیگه و اصولا در کل تاریخ بشر استثناییه.

فقط امیدوارم فناوریهای این رشته هر روز به سمت آزادتر و استانداردتر شدن پیش برن. چون این به نفع همه هست.
آزادی بخاطر اینه که آدم بتونه هرچی رو میخواد بفهمه و انجام بده (دانستن و توانستن) - بدون اینکه محدودیتی براش باشه؛ بستگی به میزان خورگی و تلاش خودش داره که بتونه تا کجا پیش بره.
استانداردهای باز و جهانی هم برای اینن که حتی یه خورهء عاقل هم از انجام کارهای بیهوده و تکراری خوشش نمیاد، بلکه دوست داره هرچه بیشتر چیزهای مفید و کاربردی جدید یاد بگیره، نه اینکه با ناسازگاری ها و صرف تنوع و کثرت الکی سر و کله بزنه.

[Mehdi Naderi]

سایت هایی که با سیلورلایت طراحی شده با دانلود افزونه سیلورلایت و نصب آن در بخش Desktop در اینترنت اکسپلورر 10 مشابه با ویندوز 7 اجرا میگردد

[hjran abdpor]

با سلام.یه سوال کوجولو داشتم ، ایا WinRt جای Win32 را میگره یا نه ؟
میشه توشح بدین هسته WinRT چی هست ؟

[iranpcl]

سلام
اینکه به نظر نمیاد مایکروسافت بتونه دانت فریمورک رو حذف کنه یه فکر غلط هست
چرا که تجربه ویندوز vista هنوز قابل فراموشی نیست
ویندوزی که هر لایسنسش با قیمتی بیشتر از قیمت یه کامپیوتر معمولی فروخته شد و همونطور ناقص رها شد اینکه ایران و کشورهایی که عضو انجمن بین المللی رعایت کنندگان قوانین کپی رایت نیستن رفع این چنین تجرباتی برامون آسونه
اگر قراره ویندوز 8 از ابزارالات ویندوز 7 به پایین رو پشتیبانی کنه ناچاری مایکروسافت رو به این کار نشون میده ولی گفته شده ویندوز 8 نرم افزار های نوشته شده وین 7 رو پشتیبانی میکنه! این یعنی تضمینی برای نرم افزار های سایر سیستم عامل های ویندوز وجود نداره!!! و این یعنی ویندوز بعدی مشخص نیست چند مرده حلاج باشه یا اصلا... !
هرچند میشه حدس زد که چقدر این شرکت تلاش برای بالا بودن این پشتیبانی با سیستم عامل جدیدش میکنه!
شاید برنامه های نوشته شده برمبنای سیلورلایت و فلش و ... تو ویندوز 8 به خوبی کار کنند ولی این به معنی ویندوزی جدید با پشتیبانی wpf یا سیلورلایت و ... شاید نباشه چرا که از اشاره های متنی برای پشتیبانی نرم افزار های وین 7 "نرم افزار های ویندوز7 به خوبی در سیستم عامل جدید اجرا خواهند شد" میشه حدس زد که یک لایه از وین 7 برای اجرای کار برنامه های نوشته شده براش گذاشته شده
وقتی یه شرکت نرم افزاری برنامه ای رو مینویسه درواقع روی ان نرم افزار سرمایه گذاری چند ساله یا چند ده ساله و یا برای شرکت های بزگ جند صد ساله میکنه و دو مورد اول برای اشخاص حقیقی برنامه نویس(یعنی ما ها هم) صادقه
البته وین8 تا جانشین ویندوز های فعلی بشه......... چرا که هنوز XP سرویس پک دوش هم خیلی جاها استفاده میشه و اونم تو کشوری که شکر خدا قوانین بین المللی کپی رایت نداره وگرنه که الان کمتر کسی وین 7 داشت چه برسه به بحث روی وین 8 که هنوز نسخه نهاییش عرضه نشده و این یعنی فرصت برای تغییر
اینکه سیلور لایت، wpf ، دات نت و ... حذف شه یعنی مایکروسافت داره یه تکون دسته جمعی میده و چیزی هم براش جز پیشرفت مهم نیست، این نیت مایکروسافت میتونه تو ویندوز بعدیش چند برابر لرزه بیشتری داشته باشه!!!!!! اونقدری که فرصت چندانی برای تغییر نباشه

[مهران رسا]

با سلام.یه سوال کوجولو داشتم ، ایا WinRt جای Win32 را میگره یا نه ؟
میشه توشح بدین هسته WinRT چی هست ؟
What is WinRT (http://blog.ecofic.com/?p=839&cpage=1#comment-2100)

[hjran abdpor]

دوستعزیز وبلاگت باز نشد اگه میشه یه ذره توضیح بدن البته خلاصه دریک خط.

[morrning]

ولی این هم درست نیست که مایکروسافت ما رو به ویژوالش معتاد کنه بعد بگه من هر سازی زدم شما برنامه نویس ها باید باهاش برقصید

یه تجربه شخصی که من حدود 6 سال پیش گرفتم و هنوزم به این تصمیم افتخار میکنم این بود رابطم با ابزار های توسعه ماکروسافت قطع کردم برای طرحی وب رفتم دنبال php و برای دسکتاپ هم رفتم دنبال جاوا .اوایل خیلی سخت بود به خصوص اینکه برنامه های یک پارچه که هم رو وب باشن هم دسکتاپ اجراشون خیلی مشکل بود ولی با مدتی مطالعه و تمرین و به خصوص php-gtk خیلی از مشکلاتم حل شد.

به دلیل همین تحولات غیر منتظره ماکروسافت هم که مدیر عاملشون صبح از خوب بلند میشه تصمیم میگیره نصف تولیدات شرکتشون رو عوض کنه چند سالی هست که تولیدات شرکتمون رو با تمرکز بر سکوی لینوکس دست مشتری میدیم . به هر حال خوبی تولیدات متن باز اینه که روند تغییرات با شیب متعادلی پیش میره مثل گذر از php4 > php5 و لازم نیست اطلاعات قبلیت رو دور بریزی بلکه فقط آپدیتشون میکنی ولی توی ماکروسافت از این خبرا نیست vb6 به vb.net رو در نظر بگیرید .یه شبه حدود 1000تا تابع و کلاس به نسخه جدید اضافه شد و از اون طرف 1000 تا رو حذف کردن.

این نظر شخصی منه که همیشه به دلیل این تغییرات وسیع و تبلیغات بی حد و حساب روی این تغییرات ماکروسافت همیشه پول خوبی به جیب زده و در عوض شرکت ها و سازمان ها همیشه باید برای آموزش کارمنداشون ضرر های زیادی رو متحمل میشن. فرض کنید یه شرکت متوسط توی کشوری مثل هند که 400 تا برنامه نویس داشته باشه که با دات نت کار میکنن یهو باید چه هزینه ای بده که همه برنامه نویساش رو با ویندوز 8 با این همه دنگ و فنگاش کوچ بده, ویندوزی که این طور که در این خبر اومده قراره بدون دات نت و سیلورلایت باشه

[ARC]

فعلا که چیزی درست مشخص نیست پس بهتره صبر کنیم تا مشخص و بشه و هر چی به ذهنمون رسید رو نگیم...
در مورد تغییرات هم دنیای کامپیوتر به قول برخی از دوستان پیشرفت و تغییراتش سریع هست ولی متاسفانه ما ایرانی ها همیشه دنبال راحتی هستیم و میخوایم مثلا با یادگیری یک زبان تا آخر عمر همه نیاز هامون رو پوشش بدیم و حتی حاضر نیستم در در نسخه های بعدی همون زبان هم تغییر کلی به وحود بیاد که نیاز باشه 2 تا کتاب بخونیم و میخوایم با 2 تا صفحه وب یا یه PDF 50 صفحه کار رو تموم کنیم. اگر دنبال تغییر نیستین خوب رشته هایی مثل میکانیک رو انتخاب کنید که هر مثلا 100 سالی یکی بیاد یه تغییر بده.
البته میتونه در حوزه های متن باز کار کنه که تغییراتش کمتره.
باید بگم تا جایی که اطلاع دارم این تغییرات حاصل 1 پروژه است که 10 سال پیش شروع شده (قابل توجه کسانی که فکر میکنن مدیر های مایکروسافت یه شبه تصمیم گرفتن!!!)

[vcldeveloper]

در مورد تغییرات هم دنیای کامپیوتر به قول برخی از دوستان پیشرفت و تغییراتش سریع هست ولی متاسفانه ما ایرانی ها همیشه دنبال راحتی هستیم و میخوایم مثلا با یادگیری یک زبان تا آخر عمر همه نیاز هامون رو پوشش بدیم و حتی حاضر نیستم در در نسخه های بعدی همون زبان هم تغییر کلی به وحود بیاد که نیاز باشه 2 تا کتاب بخونیم و میخوایم با 2 تا صفحه وب یا یه PDF 50 صفحه کار رو تموم کنیم. اگر دنبال تغییر نیستین خوب رشته هایی مثل میکانیک رو انتخاب کنید که هر مثلا 100 سالی یکی بیاد یه تغییر بده.
:متفکر: چه ربطی به ایرانی بودن داشت؟! جنابعالی اگر سری به مطالب سایت ها، انجمن ها، و وبلاگ های مربوط به برنامه نویسی برای سکوی ویندوز؛ در بازه زمانی بعد از معرفی ویندوز 8 تا اتمام کنفرانس Build مایکروسافت بزنید، حجم گسترده ایی از نگرانی ها، ابراز یاس و نا امیدی ها، حدس و گمان ها، و سایر واکنش ها را خواهید دید. اونها هم ریشه ایرانی داشتند؟!!

[betisa]

به نظر من به جای اظهار نظر های مبهم در مورد حرف های دیگران و چیزی که مایکروسافت به عنوان نو آوری در سیستم عامل جدیدش معرفی کرده خیلی راحت میشه با سیستم عامل جدید کار کرد و نتیجه رو دید. بیشترین نگرانی که ابراز شده مربوط به زبان های Native هست چون بیشتر اون ها با Api سیستم عامل کار می کنند. به نظر من در مورد .net و زبان های مربوط به اون نگرانی خاصی نیست چرا که مایکرو سافت ابزار های توسعه .net را در نسخه developer این ویندوز قرار داده که نشون دهنده پشتیبانی کامل این سیتم عامل از .net و کتاب خانه های مربوط به اون هست. و در مورد رابط کاربری metro هم باید گفت که این رابط استاندارد جدید در طراحی برنامه ها رو داره پایه گزاری میکنه و اگر ما به تاریخ مراجعه کنیم این مسئله مارو یاد ویندوز تا نسخه 3 میندازه که هر دو محیط (ویندوز و داس) رو در کنار هم برای کاربران فراهم کرده بود و این باعث اقبال بیشتر کاربران از این سیستم عامل در برابر رقیبانش شد نه تجربه بد کاربران در محط گرافیکی. به نظر من مایکرو سافت با این عمل به شرکت های توسعه نرم افزار این قابلیت رو میده تا زمان گزار از نرم افزار های صرفا pc رو با آرامش بیشتر به سمت tablet طی کنند و این یکی از خصوصیات شرکتی مثل مایکرو سافت (این کاملا نظر شخصی منه و هر کسی میتونه باهاش مخالف باشه!:لبخندساده:) و در ضمن مایکروسافت با این کار دو رقیب عمده خودش که android و ios باشه رو در مسئله تعداد application های موجود برای سیستم عامل که یکی از بزرگترین مسائل در زمینه رقابت بین سیستم عامل هاست رو کنار میگزاره و همچنین در مسئله راحتی توسعه هم این قابلیت رو داره. پس با یک نگاه منطقی و دقیق میبینم که مایکرو سافت در حقیقت قدم بسیار بزرگی رو در زمینه تحول سیستم های عامل برداشته. و این تحول منطبق با قدم های قبلیش و هماهنگ با توسعه تکنولوژی های نرم افزاری و سخت افزاری که خودش یکی از سردم دارانش هست برداشته.

نتیجه کلی:

1- درمورد زبان های native چون این زبان ها در برنامه نویسی برای سیستم عامل وابسته به API های سیستم عامل هستند ناگزیر به تغییر با آن هستند. و این یکی از مسائلی هست که باعث جهت گیری مایکروسافت به سمت .net شد.

2- در مورد زبان ها و تکنولوژی های مربوط به .net: اگر مایکروسافت قصد حذف کردن .net و خانواده تکنولوژی های مربوط به اون رو داشت در نسخه developer هیچ وقت visual studio .net 11 رو قرار نمی داد.

3- در مورد محیط کاربری metro هم همین بس که این محیط برای استفاده در touche device ها طراحی شده و برای استاندارد سازی محیط های کاربری جدید برای این نوع خاص دستگاه ها نه محدود کردن کاربران این دستگاه ها به این نوع از محیط کاربری ( که صد البته چون برای touche طراحی شده بسیار کاربردی تر و راحت تر خواهد بود).

[ARC]

:متفکر: چه ربطی به ایرانی بودن داشت؟! جنابعالی اگر سری به مطالب سایت ها، انجمن ها، و وبلاگ های مربوط به برنامه نویسی برای سکوی ویندوز؛ در بازه زمانی بعد از معرفی ویندوز 8 تا اتمام کنفرانس Build مایکروسافت بزنید، حجم گسترده ایی از نگرانی ها، ابراز یاس و نا امیدی ها، حدس و گمان ها، و سایر واکنش ها را خواهید دید. اونها هم ریشه ایرانی داشتند؟!!

جناب کشاورز عزیز بنده قصد بی احترامی به کسی رو نداشتم من خودم هم یک ایرانی هستم پس اگر چیزی بگم شامل خود من هم میشه. بنده چیزی رو که روزانه دارم میبینم میگم خیلی از ما هایی که اسم خودمون رو میزاریم برنامه نویس گاهی حتی اطلاع درستی از زبانی که روش کار میکنیم هم نداریم، نه بلدیم اصولی کد بنویسیم، نه حاضریم یکم تحقیق کنیم و 2 تا کتاب بیشتر بخونیم من نمی خوام بگم من همه این کارو انجام میدم یا نه فیلسوفی هستم توی کامپیوتر شاید از همه دوستان این انجمن هم بی سواد تر باشم ولی سعیم رو میکنم که درست کار کنم و چیزایی رو که نمیدونم یاد بگیرم و با اومدن یک تکنولوژی جدید فکر نمی کنم که آسمون به زمین امده و ... ولی خیلی ببخشید خیلی از ما هایی که اسم خودمون رو گذاشتیم برنامه نویس تا کد بلد میشیم یا 1-2 تا کتاب میخونیم دیگه فکر میکنیم تموم شد حالا دیگه شدیم یه برنامه نویس حرفه ای و دو روز بعد اگه مثلا یه تغییری به وجود امد میگیم این کار اشتباه هست و ... چرا ؟!! چون ما فقط بلد بودیم در حد همون 2 تا کتاب کد بزنیم و حاضر هم نیستیم به هیچ عنوان چیزی یاد بگیریم. شاید خارج از ایران هم همین طور باشه (که من مطمئن نیستم) ولی به همین مهندس های کامپوتری که هر ساله از دانشگاه فارغ التحصیل میشن نگاه کنید چند درصدش بلده 1 برنامه درست حسابی بنویشه یا یک شبکه رو مدیریت کنه.

[mazdadoost]

تایید میشه.دو نوع IE10 در وین ۸ هست.یکی برای مترو یکی برای دسکتاپ معمولی.


سایت هایی که با سیلورلایت طراحی شده با دانلود افزونه سیلورلایت و نصب آن در بخش Desktop در اینترنت اکسپلورر 10 مشابه با ویندوز 7 اجرا میگردد

[Dariuosh]

سلام
مایکروسافت به غیر از ویندوز 8 و ویژوال استودیو 11 ، اکسپرشن بلند 5ام تو این پکیجش داده
به نظرم عمده دلیلش برا ارتباط بیشتر با زمل (XAML)ه ، زمل ام یعنی دبلیو پی افو سیلورلایت .
IE10 ایی که تو 8 داده(PP3) ، دوتا فیس داره ، یکی برا دنیای کنوونی ویندوز ،یکیم برا دنیای تاچش یا هموون مترو
به نظره شما منطقیه که یهو مایکروسافت بگه از این به بعد هر کی بخواد با تاچ بره اینترنت فقط میتونه جاهایی بره که HTML5 هست ولا غیر ؛ این یعنی مثلا یوتیوب خاستی بری از این ور چیزی ایدت نمیشه ، از اوون ور باید بری
خودشونم که گفتن این کار برا ایجاد یه تجربه جدید برا برنامه نویس هاس ، این ورژن حتی بتا هم نیست

بعدشم دات نت داد که برنامه نویس درگیر یه عالمه هیاهو نشه دیگه ، حالا بیاد ورش داره که چی ؟ دات نت 4.5 هم که تو کاره ،تو 8 .

[FastCode]

به جای اینکه خوشحال باشیم که مغزمان از کارکردن با تکنولوژی‌های تکراری یخ نمی‌زند و با چنین پلتفرم جزابی می‌توانیم به سادگی برنامه‌نویسی کنیم، من نمی‌دانم اینهمه نق و غر برای چیست ؟اونهایی که میخوان مغزشون یخ نزنه, میتونن و با محیطهای دیگه تحت ویندوز مثل Qt و wx و java و صد تا چیز دیگه کار کنن و میکنن.اونهایی که با API ویندوز کار میکنند(مثل خود من) مجبور هستند که این کار رو بکنند.
وگرنه API ویندوز در مقابل موارد فوق اصلاً چیز خوشایندی نیست.

[L u k e]

به نظر شما با آومدن این ویندوز جاوا و زبان های دیگه باید نسخه جدیدی واسه ویندوز 8 ارئه کنند یا نه ؟

[مهران رسا]

WinRT و برنامه نویسی سرور



Most WinRT APIs are only usable inside Metro style apps. ASP.Net or any server programming for that matter, is done in the context of a desktop application. Thus a large amount of WinRT is not usable there. If you look at the WinRT reference, you will see that most of what is present is aimed at consumer apps, not server applications.

Microsoft has not said what will happen in the future, but for Windows 8/Server 8 WinRT is not aimed at server development.

[A.Karimi]

اونهایی که میخوان مغزشون یخ نزنه, میتونن و با محیطهای دیگه تحت ویندوز مثل Qt و wx و java و صد تا چیز دیگه کار کنن و میکنن.اونهایی که با API ویندوز کار میکنند(مثل خود من) مجبور هستند که این کار رو بکنند.
وگرنه API ویندوز در مقابل موارد فوق اصلاً چیز خوشایندی نیست.

بنده با وجود اینکه بر روی سکوهای مایکروسافت کار می‌کنم از زمانی که Red Hat فقط Linux متن باز داشت با Linux نیز کار کرده‌ام. برای من در اکثر اوقات در کنار ویندوز، Linux نیز نصب است و حداقل در Linux برنامه نویسی کرده‌ام. خوب است بدانید که از آن زمان (متن باز بودن Red Hat) تا کنون Qt، wx و Java چه تغییراتی کرده‌اند (فارق از اینکه در ویندوز توسعه بدهید یا در Linux). زمانی مغز ما یخ می‌زند که فقط در یک مسیر ثابت حرکت کنیم. البته این حرف فقط از منظر برنامه‌نویسی قابل بررسی است.

در حال حاظر متاسفانه یا خوشبختانه دو رقیب اصلی وجود دارند Java و dotNet که بر همه آشکار است، قدرت و انعطاف زبان #C بسیار بسیار بیشتر از زبان Java است حالا از امکاناتی مثل LINQ، WCF، WPF و بچه‌های WPF و ... بگذریم. ساختار پلتفرم dotNet در زمینه وب کوچکتر از چیزهایی امثال J2EE است چون J2EE با هدف Application Server ایجاد شده ولی dotNet هدفی دیگر داشته! از نظر راحتی کاربر هم؛ بیشتر کاربران نهایی (Power Users) وقتی می‌شنوند یک برنامه با Java نوشته شده پشتشان می‌لرزد! (انصافاً برنامه‌های بسیار خوبی مثل Eclipse هم وجود دارد اما...)

در مورد ++C هم بهتر می‌دانید که در وادی دیگری قابل بررسی است.

بنده به شخصه اگر انتخاب بهتری از تکنولوژیهای زنده مایکروسافت وجود داشته باشد با کمال میل دوست دارم وارد آن وادی شوم.

[FastCode]

بنده با وجود اینکه بر روی سکوهای مایکروسافت کار می‌کنم از زمانی که Red Hat فقط Linux متن باز داشت با Linux نیز کار کرده‌ام. برای من در اکثر اوقات در کنار ویندوز، Linux نیز نصب است و حداقل در Linux برنامه نویسی کرده‌ام. خوب است بدانید که از آن زمان (متن باز بودن Red Hat) تا کنون Qt، wx و Java چه تغییراتی کرده‌اند (فارق از اینکه در ویندوز توسعه بدهید یا در Linux). زمانی مغز ما یخ می‌زند که فقط در یک مسیر ثابت حرکت کنیم. البته این حرف فقط از منظر برنامه‌نویسی قابل بررسی است.

در حال حاظر متاسفانه یا خوشبختانه دو رقیب اصلی وجود دارند Java و dotNet که بر همه آشکار است، قدرت و انعطاف زبان #C بسیار بسیار بیشتر از زبان Java است حالا از امکاناتی مثل LINQ، WCF، WPF و بچه‌های WPF و ... بگذریم. ساختار پلتفرم dotNet در زمینه وب کوچکتر از چیزهایی امثال J2EE است چون J2EE با هدف Application Server ایجاد شده ولی dotNet هدفی دیگر داشته! از نظر راحتی کاربر هم؛ بیشتر کاربران نهایی (Power Users) وقتی می‌شنوند یک برنامه با Java نوشته شده پشتشان می‌لرزد! (انصافاً برنامه‌های بسیار خوبی مثل Eclipse هم وجود دارد اما...)

در مورد ++C هم بهتر می‌دانید که در وادی دیگری قابل بررسی است.

بنده به شخصه اگر انتخاب بهتری از تکنولوژیهای زنده مایکروسافت وجود داشته باشد با کمال میل دوست دارم وارد آن وادی شوم.
بنده شخصاً مدت زیادی نیست با Qt آشنا شدم و وافعاً راضی هستم.
البته از داتنت سختتره.ولی محدودیتهایی رو که در داتنت دارم در Qt ندارم.
به عنوان مثال همین آخری, توی یک سری گزارش نیاز به SSE داشتم که توی داتنت به هیچ عنوان قابل پیاده سازی نیست. ولی با یک بنچمارک ساده فهمیدم که چون SSE ندارم سرعتم زیر یک درصده.
یا مثلاً استفاده از shared memory با semaphore که پیاده سازیش توی C# رو من هنوز بعد از ۵ سال نفهمیدم.
توی این چیزها dotnet هرگز به پای C++ نمیرسه.

در مواردی که اشاره کردید مثل WPF و WCF و .... از نظر تئوری هم C++ نمیتونه حرفی برای گفتن داشته باشه.

[A.Karimi]

بنده شخصاً مدت زیادی نیست با Qt آشنا شدم و وافعاً راضی هستم.
البته از داتنت سختتره.ولی محدودیتهایی رو که در داتنت دارم در Qt ندارم.
به عنوان مثال همین آخری, توی یک سری گزارش نیاز به SSE داشتم که توی داتنت به هیچ عنوان قابل پیاده سازی نیست. ولی با یک بنچمارک ساده فهمیدم که چون SSE ندارم سرعتم زیر یک درصده.
یا مثلاً استفاده از shared memory با semaphore که پیاده سازیش توی C# رو من هنوز بعد از ۵ سال نفهمیدم.
توی این چیزها dotnet هرگز به پای C++ نمیرسه.

در مواردی که اشاره کردید مثل WPF و WCF و .... از نظر تئوری هم C++ نمیتونه حرفی برای گفتن داشته باشه.

البته عقیده من بر این است که dotNet برای پروژه های تجاری و حتی سیستم‌عاملهای آینده مناسب تر است اما به هیچ عنوان دلیل بر بد بودن یک زبان یا تکنولوژی دیگر نخواهد بود و چنین عقیده‌ای ندارم. این مورد درباره Qt که یک کتابخانه بسیار عالی برای ++C است هم صادق است. اگر شما بخواهید با ++C برنامه بنویسید مسلماً Qt اگر بهترین نباشد به نظر من یکی از بهترین گزینه‌هاست.

اما بحث این پست بر سر تغییرات تکنولوژی بود که باز هم تاکید می‌کنم Qt نسبت به چند سال قبل مثلاً زمان dotNet 2.0 چه تغییری کرده؟ و dotNet چه تغییری؟ این تغییرات به نظر بنده باعث سرزندگی است!

در مورد Shared Memoery و Semaphore که اشاره کردید و در کل درخصوص برنامه نویسی غیر همزمان (Asynchronous Programming) اگر کار با ++C را در این زمینه «جهنم» تصور کنید کار با #C را می‌توانید «بهشت» تصور کنید. و البته در dotNet نسخه 5 این مورد فوق العاده و فوق العاده ساده‌تر و شیرین‌تر شده بدون اینکه از قدرت کار کاسته شود. به طوری که برنامه‌نویسی Async ظاهری شبیه Sync خواهد داشت و مفهومی به نام Callback دیگر وجود نخواهد داشت. اگر این موارد برای شما مهم هستند حتماً مطالعه‌ای بر روی C# 5.0 و دستورات کلیدی async و await داشته باشید. و البته سمافور هم دیگر مانند دهه‌ی 70 میلادی نیست و با استفاده در دستور lock در زبان #C به راحتی می‌توانید عملیات مورد نظرتان را انجام دهید. هرچند سمافور به همان شکل سنتی هم در dotNet قابل دسترس است.

[AlgorithmX]

بنابراین طبق اطلاعات موجود اینطور گفته میشود كه قرار است به زودی Silverlight و WPF حذف شوند و در ادمه آن .NET (دات نت) نیز حذف خواهد شد! =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=

Windows Application، WPF Application و ... هنوز بر روی ویندوز 8 قابل برنامه نویسی و استفاده است، تکنولوژی های جدیدتر هم اضافه شده اند.کاملا درسته!
حذف WPF, Silverlight و .. عملی غیر ممکن از سوی مایکروسافته! چون این تکنولوژی ها این قدر قدرتمند و قابل رشد هستند که اگه هم اتفاقی قرارباشه رخ بده اضافه کردن امکان جدیدی از جمله طراحی رابط کاربری برای مترو به این تکنولوژی هاست، نه حذف آنها!!
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=
واسه این تکنولوژی و این دگرگونی ها هم نسخه جدید ویژوال استدیو رو داره عرضه میکنه! که دوستان لینکش رو گذاشته بودن!
خبری از نسخه جدید ویژوال استدیو و امکانات جدید!! (http://www.persiadevelopers.com/news/window8-vs2011-dotnet4-5-preview.aspx)

[FastCode]

البته عقیده من بر این است که dotNet برای پروژه های تجاری و حتی سیستم‌عاملهای آینده مناسب تر است اما به هیچ عنوان دلیل بر بد بودن یک زبان یا تکنولوژی دیگر نخواهد بود و چنین عقیده‌ای ندارم. این مورد درباره Qt که یک کتابخانه بسیار عالی برای ++C است هم صادق است. اگر شما بخواهید با ++C برنامه بنویسید مسلماً Qt اگر بهترین نباشد به نظر من یکی از بهترین گزینه‌هاست.

اما بحث این پست بر سر تغییرات تکنولوژی بود که باز هم تاکید می‌کنم Qt نسبت به چند سال قبل مثلاً زمان dotNet 2.0 چه تغییری کرده؟ و dotNet چه تغییری؟ این تغییرات به نظر بنده باعث سرزندگی است!

در مورد Shared Memoery و Semaphore که اشاره کردید و در کل درخصوص برنامه نویسی غیر همزمان (Asynchronous Programming) اگر کار با ++C را در این زمینه «جهنم» تصور کنید کار با #C را می‌توانید «بهشت» تصور کنید. و البته در dotNet نسخه 5 این مورد فوق العاده و فوق العاده ساده‌تر و شیرین‌تر شده بدون اینکه از قدرت کار کاسته شود. به طوری که برنامه‌نویسی Async ظاهری شبیه Sync خواهد داشت و مفهومی به نام Callback دیگر وجود نخواهد داشت. اگر این موارد برای شما مهم هستند حتماً مطالعه‌ای بر روی C# 5.0 و دستورات کلیدی async و await داشته باشید. و البته سمافور هم دیگر مانند دهه‌ی 70 میلادی نیست و با استفاده در دستور lock در زبان #C به راحتی می‌توانید عملیات مورد نظرتان را انجام دهید. هرچند سمافور به همان شکل سنتی هم در dotNet قابل دسترس است.
حیف نمیتونم نمیونه کد بزارم که بفهمید lock یک ابداع احمقانه بیشتر نیست.(اگر بزارم انقدر پیچیدست که نمیفهمید/فقط توضیح میدم.)
فرض کنید دو تا لیست داریم که در شرایطی از تغییرات اولی دومی هم تغییر میکنه ولی در زمانی که دومی داره تغییر میکنه اولی دیگه قرار نیست تغییر کنه و اگر اولی باز بشه ممکنه طوری تغییر بکنه که دومی نخواد تغییر بکنه.
این جزء مواردیه که نمیشه با lock پیاده سازی کرد.

از این موارد در C++ زیاده.
مثل ترکیب for و switch

[A.Karimi]

حیف نمیتونم نمیونه کد بزارم که بفهمید lock یک ابداع احمقانه بیشتر نیست.(اگر بزارم انقدر پیچیدست که نمیفهمید/فقط توضیح میدم.)
فرض کنید دو تا لیست داریم که در شرایطی از تغییرات اولی دومی هم تغییر میکنه ولی در زمانی که دومی داره تغییر میکنه اولی دیگه قرار نیست تغییر کنه و اگر اولی باز بشه ممکنه طوری تغییر بکنه که دومی نخواد تغییر بکنه.
این جزء مواردیه که نمیشه با lock پیاده سازی کرد.

از این موارد در C++ زیاده.
مثل ترکیب for و switch

هر موردی که با سمافور قابل حل باشد با بلاک lock نیز قابل حل است. مضاف بر اینکه عرض کردم در دات نت شما به سمافور ها دسترسی دارید. تا جایی که من متوجه شدم این مسئله‌ای که مطرح کردید با بلاک lock قابل حل است. فقط شما باید شی مناسبی را جهت دادن به این دستور انتخاب کنید. شما چه شیی را به بلاک lock میدادید که با مشکل مواجه می‌شدید؟

چرا نمی‌توانید نمونه کد ارسال کنید؟ خیلی مشتاق شدم که این مساله را با C# حل کنم. هر چند که از موضوع بحث این تاپیک خارج شدیم. اگر موضوع نفهمیدن ماست، نگران فهمیدن ما نباشید نمونه کد را بفرستید.

پیشنهاد می‌کنم یک تاپیک جدید برای این موضوع ایجاد کنید تا با زبانهای مختلف این مساله حل شود. نتیجه خیلی جالب خواهد بود.

[vcldeveloper]

حیف نمیتونم نمیونه کد بزارم که بفهمید lock یک ابداع احمقانه بیشتر نیست.(اگر بزارم انقدر پیچیدست که نمیفهمید/فقط توضیح میدم.)
فرض کنید دو تا لیست داریم که در شرایطی از تغییرات اولی دومی هم تغییر میکنه ولی در زمانی که دومی داره تغییر میکنه اولی دیگه قرار نیست تغییر کنه و اگر اولی باز بشه ممکنه طوری تغییر بکنه که دومی نخواد تغییر بکنه.
این جزء مواردیه که نمیشه با lock پیاده سازی کرد.

مکانیزم lock در دات نت با استفاده از monitors پیاده سازی شده، و هر چیزی که بشه با Semaphores پیاده سازی کرد رو میشه با monitors هم پیاده سازی کرد، پس ادعایی که کردی از نظر فنی فاقد ارزش هست. علاوه بر اون، synchronization primitives مثل semaphores، critical sections, events و غیره توسط سیستم عامل پیاده سازی میشند و در اختیار برنامه ها قرار می گیرند. زبان های برنامه نویسی می تونند بر اساس آنها ساختارهای سطح بالاتری (مثل monitors) ایجاد کنند. این synchronization primitives در اختیار هر زبان برنامه نویسی که بتونه با API سیستم عامل تعامل برقرار کنه، هستند؛ پس تصورت مبنی بر اینکه semaphore یا هر کدام از سایر synchronization primitives ها مختص یک زبان برنامه نویسی خاص (مثل ++C) هستند، یا در فلان ابزار برنامه نویسی لزوما نباید در دسترس باشند، هم اشتباه هست.

[FastCode]

خب بزارید یه جور دیگه توضیح بدم که از نظر فنی درست بشه!!!!
lock obj1
lock obj2
unlock obj1
unlock obj2
الان این رو یکی با C#‎ حل کنه.میخوام بخندم.


بهترین روش برای این کار استفاده از جاواست.

[A.Karimi]

خب بزارید یه جور دیگه توضیح بدم که از نظر فنی درست بشه!!!!
lock obj1
lock obj2
unlock obj1
unlock obj2
الان این رو یکی با C#‎ حل کنه.میخوام بخندم.


بهترین روش برای این کار استفاده از جاواست.

دوست عزیز lock و unlock کردن یک object جزو عملیات سیستمی است! شما با این چهار خط توضیحات فنی دادید؟ obj1 و obj2 چه ارتباطی با هم دارند؟ این دو از نوع static هستند یا dynamic؟ چهار خطی که اشارده کردید در چه contextی قرار دارند؟ هرکدام از عملیاتها چقدر زمانبر هستند (چون شما می‌توانید کل عملیات را داخل یک بلاک synchronize شده قرار داده و به راحتی انجام دهید)؟

لطفاً به جای مطرح کردن موضوع به این شکل، مسئله را شفاف مطرح کنید. شک نکنید که با همه زبانهای برنامه نویسی می‌توان آنرا حل کرد! نه فقط #C بلکه همه زبان‌های مدرن که قابلیت ارتباط با سیستم عامل را داشته باشند (از جمله جاوا و ...) و یا به صورت توکار از مفاهیم synchronization پشتیبانی کنند می‌توانند این مسائل را حل کنند.

لطفاً مساله را واضح و روشن مطرح کنید تا کدهای ساده و روشن زبانهای مختلفی چون #C را مشاهده کنید. و البته باز هم پیشنهاد می‌کند در یک تاپیک جدا گانه مطرح کنید و در اینجا لینک بدهید تا موضوع این تاپیک حفظ شود.
توجه داشته باشید که بحث ما کل کل بر سر زبانها نیست و من به شخصه دوست دارم مسائل مشکل synchronization را حل کنم. بنده خالق هیچ یک از این تکنولوژی‌ها نیستم و دلیلی بر دفاع از جان گذشته از آنها نمی‌بینم. علاقه من و امثال من به برنامه‌نویسی است و همانطور که از ++C به #C مهاجرت کردیم در صورت لزوم از #C هم به یک زبان بهتر مهاجرت خواهیم کرد (بدون ناراحتی).

با تشکر.

[vcldeveloper]

الان این رو یکی با C#‎‎ حل کنه.میخوام بخندم.
الان به نظر خودت اون چهار خطی که نوشتی، صورت یک مسئله هست؟!


بهترین روش برای این کار استفاده از جاواست.
جان هر کس که دوست داری، اینقدر اظهار نظرهای الکی و غیر فنی نکن! جاوا از نظر مکانیزم های lock و Synchronization چیز بخصوصی بهت نمیده که در #C یا خیلی از سایر زبان های امروزی موجود نباشه. این چیزهایی که اینجا مطرح میکنی، مسائلی نیست که به یک زبان برنامه نویسی بخصوص برای حل شدن نیاز داشته باشه، و همانطور که در پست قبلی هم گفتم، ربطی به زبان برنامه نویسی نداره.

[Dariuosh]

سلام
مایکروسافت به غیر از ویندوز 8 و ویژوال استودیو 11 ، اکسپرشن بلند 5ام تو این پکیجش داده
به نظرم عمده دلیلش برا ارتباط بیشتر با زمل (XAML)ه ، زمل ام یعنی دبلیو پی افو سیلورلایت .
.
نظرم کاملاً اشتباه بوود چون اکسپرشن بلند 5 تو این پکیج برا طراحی برنامه های مترو فرم هستش ،همشم HTML5 , CSS
Expression Blend for HTML (http://blogs.msdn.com/b/somasegar/archive/2011/09/13/expression-blend-for-html.aspx)

[محمد باقری نسب]

دوستان همه مطمئن باشید که شرایط بسیار بهتر از اینچه که هم اکنون در دنیای IT شاهد آن هستیم خواهد شد.

[iranpcl]

دوستان همه مطمئن باشید که شرایط بسیار بهتر از اینچه که هم اکنون در دنیای IT شاهد آن هستیم خواهد شد.
صد در صد
ولی باید یکم به تگ و توگ مایکروسافت برقصیم

[AlgorithmX]

با این دگرگونی و انقلابی که مایکروسافت راه انداخته، آیا ممکنه ایقدر امنیت محصولاتش (ویندوز، ویژوال استدیو و ..) اینقدر بالا رفته باشه که امکان کرک شدنشون به -0- برسه!! (حالا صفر هم نه، خیلی سخت بشه!!)؟ یعنی نیم بیشتر ما مجبور به خرید محصولاتش بشیم؟!!

[iranpcl]

اینکه سخت تر بشه نمیدونم ولی هیچ وقت 0 نمیشه چرا که اصلا ساختار سخت افزاری pc اینطوره
مثالا: برای اجرای هر اپلیکیشنی باید اپلیکیشن تو رم لود شه!!!!!!!!!!!
پ.ن: میشه با ابزار هایی محتوای رم و دامپ کرد

[A B C D]

احتمالا با فناوری TC میشه به چنین هدفی رسید یا حداقل خیلی نزدیکتر شد. یعنی طوری که مهندسی معکوس و در نتیجه کرک کردن برنامه ها که نیاز به مهندسی معکوس داره، غیرممکن یا بسیار بسیار دشوارتر بشه.
این تاپیک رو ملاحظه کنید: پالادیوم - NGSCB (http://barnamenevis.org/showthread.php?274040-%D9%BE%D8%A7%D9%84%D8%A7%D8%AF%DB%8C%D9%88%D9%85-NGSCB&highlight=ngscb)

یکی از خواص این فناوری که گفته ببینید چیه:

بنابراین برای هرکسی، منجمله مالک رایانه، بسیار دشوار خواهد بود تا یک برنامهء قابل اعتماد را فریب دهد تا خارج از حافظهء پنهان شده اجرا شود. این از روی دیگر موجب میشود تا مهندسی معکوس یک برنامهء قابل اعتماد بینهایت دشوار شود.--------------------------


با این دگرگونی و انقلابی که مایکروسافت راه انداخته، آیا ممکنه ایقدر امنیت محصولاتش (ویندوز، ویژوال استدیو و ..) اینقدر بالا رفته باشه که امکان کرک شدنشون به -0- برسه!! (حالا صفر هم نه، خیلی سخت بشه!!)؟ یعنی نیم بیشتر ما مجبور به خرید محصولاتش بشیم؟!! این دگرگونی ها بنظرم ارتباط خاصی به کرک و اینها ندارن. بلکه پیشرفت در بالا بردن سطح برنامه نویسی هستن. حتی میشه گفت خیلی از فناوریهای جدید در برابر مهندسی معکوس و کرک شدن ضعیف تر هستن. بطور مثال چون این برنامه ها حتی پس از کامپایل دارای ساختارهای سطح بالاتر و متادیتای زیادی هستن. یا مثلا دات نت که اساسا خیلی راحتتر قابل مهندسی معکوس و کرک شدن هست.
در طراحی فناوریهای امروزی موضوع مهندسی معکوس و کرک رو چندان درنظر نمیگیرن. چون حداقل در مراحل اولیه این مسائل اهمیت و اولویت بالایی ندارن و هزینه هاشون توجیه شده نیست و درواقع فرایند طراحی و مشکلات فنی رو بیش از حد گسترده و پیچیده میکنن و اصلا در خیلی موارد نمیشه از بیشتر شدن امکان مهندسی معکوس و کرک جلوگیری کرد مگر اینکه از یکسری امکانات و ساختارهای سطح بالای مهم یا حتی اساسی صرفنظر بشه.
اینکه برنامه های exe قدیمی رو خیلی سخت تر میشه مهندسی معکوس و کرک کرد بخاطر اینه که با امکانات و زبان برنامه نویسی سطح پایین تری نوشته میشن و در نهایت به کد اجرایی خیلی بدوی تری کامپایل میشن که متادیتای خیلی کمی داره و خیلی کمتر با ساختارها و الگوهای خودکار و سطح بالا تولید شده یا به کتابخانه های سطح بالا و سرویسهای خارجی سطح بالا پیوند خورده.
هرچی سطح برنامه نویسی بالاتر میره، مهندسی معکوس و کرک برنامه ها ساده تر میشه و راه کامل و راحت و کم هزینه ای هم برای جلوگیری از این امر وجود نداره. یعنی این راه حداقل چیزی نیست که بتونه در سطح نرم افزاری (به تنهایی) باشه.
چیزی که بدیهی هست اینه که باوجود اینها، بالا بردن سطح برنامه نویسی اونقدری مزایا داره که کمتر کسی ترجیح میده بخاطر سخت تر شدن کرک و مهندسی معکوس بیاد از فناوریهای برنامه نویسی سطح بالا صرفنظر کنه. در خیلی جاها و موارد اصلا این مسائل چندان مهم نیستن. و در کشورهای دیگر هم میشه گفت بخاطر اعمال حقوق انحصار فکری (کپی رایت و غیره) از طریق قانون، نیاز به راههای فنی خیلی کمتر هست و از موارد محدودی که سوء استفاده صورت میگیره صرفنظر میشه و بهرحال بقدر کافی از فروش و انحصار قانونی خودشون درآمد دارن.

اما همونطور که در بالا مطرح کردم فناوریهای مثل TC اساسا قدرت زیادی در این وادی (جلوگیری از مهندسی معکوس و کرک) دارن و بنظرم میشه با اون حتی برنامه های دات نت رو هم در برابر مهندسی معکوس و کرک تا حد زیادی ایمن تر کرد (یا شاید هم کاملا). اما فناوری TC هنوز به اون شکل پیاده سازی و دارای کاربرد کامل و گسترده نشده و خیلی ها باهاش مخالف هستن و اون رو خطرناک میدونن؛ چون معتقد هستن ازش بیشتر سوء استفاده خواهد شد و درکل سایدافکت های منفی بیشتری خواهد داشت تا اینکه مفید باشه. چون امکان کنترل انحصاری برنامه نویسان رو بر رایانه ها افزایش میده و کاربران تاحد زیادی قدرت کنترل خودشون رو بر رایانهء خودشون از دست میدن. این مسئله ممکنه برای همه کس حتی برنامه نویسان پیش بیاد و نامطلوب باشه. مثلا ممکنه میکروسافت ویژگی نامطلوبی رو بخاطر منفعت خودش در سیستم عامل و برنامه هاش بذاره که باوجود فناوری TC ما به هیچ وجه قادر به از بین بردن اون نباشیم، اما الان این امکان رو داریم و میتونیم تقریبا همه چیز رو حالا سخت یا آسون دستکاری کنیم و تغییر بدیم و شاید به همین خاطر شرکتهای بزرگ تولیدکنندهء نرم افزار ویژگیهای ناخوشایند و پنهان خیلی کمتری رو در محصولات خودشون قرار میدن، اما وقتی قدرت اونها بواسطهء TC افزایش پیدا کنه ممکنه از این قدرت برای تحمیل خواسته های خودشون به ما استفاده کنن.
ریچارد استالمن حرف جالبی میزنه که میگه با این فناوری رایانه های ما بجای اینکه از ما اطاعت کنن از دیگران اطاعت میکنن و ممکنه بر علیه خودمون استفاده بشن.
مشکل پایمال شدن حقوق انحصار فکری و بعضی مسائل امنیتی یه چیزه، که TC میتونه به اون کمک کنه، و مشکل سوء استفادهء طبیعی و قابل پیشبینی از TC چیز دیگه ای که بنظر خیلی ها بیشتر و مهمتره.

بهرصورت بنظر نمیرسه براحتی دست از پیاده سازی چنین چیزی برداشته بشه چون کاربردهای قابل توجهی داره و برای خیلی ها هم منافع مهمی درش هست.
بطور مثال ارتش آمریکا اجازهء خرید رایانه هایی رو که امکانات سخت افزاری لازم برای TC رو نداشته باشن نمیده. هرچند این امکان هنوز بصورت کامل در نرم افزارها پیاده سازی نشده و مورد استفاده نیست، اما احتمالا پیشبینی آیندهء نزدیک رو میکنن که از این فناوری برای تامین امنیت بیشتر رایانه های مورد استفاده در مراکز نظامی استفاده کنن.

[iranpcl]

آیا wpf قراره از روی vs2012 هم حذف شه؟؟؟
کسی اطلاعی داره؟

[Amir Oveisi]

این دو صفحه رو کامل بخونید لطفا، پاسخ خیلی از سوالاتتون رو می گیرید:
http://arstechnica.com/microsoft/news/2011/06/windows-8-for-software-developers-the-longhorn-dream-reborn.ars
http://arstechnica.com/microsoft/news/2011/06/windows-8-for-software-developers-the-longhorn-dream-reborn.ars/2

[iranpcl]

این دو صفحه رو کامل بخونید لطفا، پاسخ خیلی از سوالاتتون رو می گیرید:
http://arstechnica.com/microsoft/news/2011/06/windows-8-for-software-developers-the-longhorn-dream-reborn.ars
http://arstechnica.com/microsoft/news/2011/06/windows-8-for-software-developers-the-longhorn-dream-reborn.ars/2
ممنون ولی فیلترند

[FastCode]

سلام.
فکر میکنم توی این چند روزی که آفلاین بودم بحث عوض شده.

خب اگر میشد با C#‎ نوشت که اینطوری نمینوشتم.
یه نمونه آماده کردم.نمیدونم کامپایل میشه یا نه.

static class TheSimpleCode
{
public static void Main()
{
object obj1 = new object();
object obj2 = new object();
lock(obj1)
{
lock(obj2)
{

//change these two lines in some way to
//release obj1 before releasing obj2
}//line 1
}//line 2
}
}

static class Example_MoreRealistic
{
public static void Main()
{
syncRoot = new object ();
MyList = new Tuple<object,List<int>>[100000];
System.Threading.Thread[] Threads = new Thread[100];
for(int ThreadCounter = 0;ThreadCounter != 100;ThreadCounter++)
{
Threads[ThreadCounter] = new Thread(myProcedure);
Threads[ThreadCounter].Start();
}
for(int ThreadCounter = 0;ThreadCounter != 100;ThreadCounter++)
{
Threads[ThreadCounter].Join();
}
Console.WriteLine("Done.");
}
static object syncRoot;
static Tuple<object, List<int>>[] MyList;
static void myProcedure()
{
Random R = new Random();
for(int OuterLoopCounter = 0 ;OuterLoopCounter != 100000;OuterLoopCounter++)
{
int sum = 0;
lock(syncRoot)
{
List<int> Ints = null;
object obj2 = null;
if(MyList[OuterLoopCounter] == null)
{
obj2 = new object();//the same obj2 in example 1
Ints = new List<int>();
MyList[OuterLoopCounter] = new Tuple<object,List<int>> (obj2, Ints);
//look at next comment (4 lines down)
}
else
{
obj2 = MyList[OuterLoopCounter].Item1;
Ints = MyList[OuterLoopCounter].Item2;
//If the thing was possible, i could lock obj2 right here and unlock syncRoot, but i simply can't.
}
lock(obj2)//Instead i lock obj2 here, without unlocking syncRoot; because i can't.
{
for(int n = 0 ;n !=100;n++) // note:this loop is worth releasing and locking syncRoot.
{
int Next = R.Next(65536);
sum += Next;
Ints.Add(Next);
}
if(sum > 3276800)//Half the times
{
MyList[OuterLoopCounter].Item2.Clear();
}
}
}
}
}
}

[mehdi.mousavi]

سلام. فکر میکنم توی این چند روزی که آفلاین بودم بحث عوض شده. خب اگر میشد با C#‎ نوشت که اینطوری نمینوشتم. یه نمونه آماده کردم.نمیدونم کامپایل میشه یا نه.

سلام.
lock در حقیقت متود Exit کلاس Monitor رو در finally block قرار میده تا مطمئن بشیم که Lock آزاد شده. فقط همین!
در نتیجه، در این کدی که اشاره کردید:


object obj1 = new object();
object obj2 = new object();

lock (obj1)
{
lock (obj2)
{
//change these two lines in some way to
//release obj1 before releasing obj2
}
}


کافیه تا بدین شکل عمل کنیم:


object obj1 = new object();
object obj2 = new object();

Monitor.Enter(obj1);
Monitor.Enter(obj2);

Monitor.Exit(obj1);
Monitor.Exit(obj2);


تا به هدفمون برسیم. اینجا، طبق خواسته شما، با Enter وارد ناحیه بحرانی اول میشیم (و سپس ناحیه بحرانی دوم). در نهایت، اول lock ای که روی obj1 گذاشته شده رو آزاد می کنیم (به بیان دیگه از ناحیه بحرانی اول خارج میشیم، در حالیکه obj2 هنوز Lock هستش) و سپس lock دوم رو آزاد می کنیم... طبیعتا باید حواسمون به Exception های احتمالی ای که ممکنه این بین رخ بده نیز باشه...

موفق باشید.

[FastCode]

سلام.
lock در حقیقت متود Exit کلاس Monitor رو در finally block قرار میده تا مطمئن بشیم که Lock آزاد شده. فقط همین!
در نتیجه، در این کدی که اشاره کردید:


object obj1 = new object();
object obj2 = new object();

lock (obj1)
{
lock (obj2)
{
//change these two lines in some way to
//release obj1 before releasing obj2
}
}


کافیه تا بدین شکل عمل کنیم:


object obj1 = new object();
object obj2 = new object();

Monitor.Enter(obj1);
Monitor.Enter(obj2);

Monitor.Exit(obj1);
Monitor.Exit(obj2);


تا به هدفمون برسیم. اینجا، طبق خواسته شما، با Enter وارد ناحیه بحرانی اول میشیم (و سپس ناحیه بحرانی دوم). در نهایت، اول lock ای که روی obj1 گذاشته شده رو آزاد می کنیم (به بیان دیگه از ناحیه بحرانی اول خارج میشیم، در حالیکه obj2 هنوز Lock هستش) و سپس lock دوم رو آزاد می کنیم... طبیعتا باید حواسمون به Exception های احتمالی ای که ممکنه این بین رخ بده نیز باشه...

موفق باشید.
سلام.
ممنون, دقیقاً دنبال همین بودم.
البته به این نتیجه هم رسیدیم که lock اینجا کارایی نداره.

از همه عذر میخوام که باعث شدم موضوع تاپیک منحرف بشه.

[A.Karimi]

سلام.
فکر میکنم توی این چند روزی که آفلاین بودم بحث عوض شده.

خب اگر میشد با C#‎‎‎ نوشت که اینطوری نمینوشتم.
یه نمونه آماده کردم.نمیدونم کامپایل میشه یا نه.

static class TheSimpleCode
{
public static void Main()
{
object obj1 = new object();
object obj2 = new object();
lock(obj1)
{
lock(obj2)
{

//change these two lines in some way to
//release obj1 before releasing obj2
}//line 1
}//line 2
}
}



من حدس می‌زنم شما با شی Monitor در dotNet آشنا نباشید. نیازی نیست حتماً از lock استفاده کنید. lock تضمین می‌کند که اگر در بلاک به هر دلیلی اجرای برنامه به جای دیگری پرش کرد (مثلا به علت Exception و...) در این صورت حتماً Monitor.Exit فراخوانی شود.

در واقع کد زیر:


lock (obj)
{
...
}


معادل کد زیر است:


System.Threading.Monitor.Enter(x);
try {
...
}
finally {
System.Threading.Monitor.Exit(x);
}


منبع : http://msdn.microsoft.com/en-us/library/aa664735(v=vs.71).aspx

در این صورت چیزی که شما دنبال آن هستید شبیه کد زیر خواهد بود:


object obj1 = new object();
object obj2 = new object();

System.Threading.Monitor.Enter(obj1);
System.Threading.Monitor.Enter(obj2);
...
System.Threading.Monitor.Exit(obj1);
System.Threading.Monitor.Exit(obj2);


همانطور که ملاحظه می‌کنید طبق کامنت شما خط 1 و 2 جابجا شدند. این باید همان چیزی باشد که شما به دنبال آن هستید.

برای اطلاعات بیشتر و همچنین آگاهی از بقیه امکانات: http://msdn.microsoft.com/en-us/library/system.threading.monitor.aspx

مقایسه درباره همزمان سازی در Java و #C (این مقایسه در رابطه با ویژگی‌های زبان است):
1. http://www.javacamp.org/javavscsharp/sync.html
2. http://en.csharp-online.net/CSharp_FAQ%3A_What_is_the_difference_between_CShar p_lock_and_Java_synchronized
و ...

اگر علاقه بیشتری به مقایسه این دو زبان دارید، در این خصوص به لینک زیر مراجعه بفرمایید:
http://en.wikipedia.org/wiki/Comparison_of_C_Sharp_and_Java

توضیح اینکه با احترام به برنامه‌نویسان جاوا در این مقایسه قدرت و زیبایی زبان #C کاملاً مشخص است. لطفاً جدول مقایسه ویژگی‌های زبان و همچنین مقایسه قطعه کدهای هر دو زبان را ملاحظه کنید.
در کل هدف بنده این بود که بدانید از نظر امکانات همزمان سازی تقریباً فرقی بین #C و Java وجود ندارد. با این تفاوت که در dotNet 4.5 امکانات Multi-threading بسیار ساده‌تر و قوی‌تر شده است.

و البته این مورد به این تاپیک بی ربط نیست؛ اگر زبان #C اکنون اینقدر پویا و کامل است علتش همین سیاست‌های مایکروسافت بوده که در آن، «تغییر» جایگاه ویژه‌ای دارد. همانطور که ما در مهندسی نرم‌افزار در سالهای اخیر آموختیم چابکی و تغییر پذیری جزوء مهمترین فاکتورهای موفقیت در پروژه‌های امروزه است.

-- ویرایش --
قبل از ارسال پست صفحه تاپیک را بروز رسانی نکرده و پاسخی که قبلاً این مورد داده شده بود را ندیدم. اما به دلیل رفرنس‌هایی که دادم و همچنین مقایسه بین #C و Java و ... این پست را حذف نمی‌کنم.
متشکرم.

[vcldeveloper]

توضیح اینکه با احترام به برنامه‌نویسان جاوا در این مقایسه قدرت و زیبایی زبان #C کاملاً مشخص است. لطفاً جدول مقایسه ویژگی‌های زبان و همچنین مقایسه قطعه کدهای هر دو زبان را ملاحظه کنید.
در کل هدف بنده این بود که بدانید از نظر امکانات همزمان سازی تقریباً فرقی بین #C و Java وجود ندارد. با این تفاوت که در dotNet 4.5 امکانات Multi-threading بسیار ساده‌تر و قوی‌تر شده است.
مکانیزم های lock در #C و synchronized در جاوا هر دو از Monitors استفاده می کنند، و از این لحاظ #C برتری خاصی نسبت به جاوا نداره. از نظر کتابخانه های مربوط به Parallel Computing، فرق جاوا با #C در این هست که برای #C به جز شرکت مایکروسافت، بازیگر بخصوصی وجود نداره، و مایکروسافت خودش این ابزارها رو معمولا تهیه میکنه، ولی در جاوا بازیگران گسترده تر هستند، و معمولا برنامه نویس باید از بین چند انتخاب موجود بهترین گزینه برای کار خودش را انتخاب کنه.



و البته این مورد به این تاپیک بی ربط نیست؛ اگر زبان #C اکنون اینقدر پویا و کامل است علتش همین سیاست‌های مایکروسافت بوده که در آن، «تغییر» جایگاه ویژه‌ای دارد. همانطور که ما در مهندسی نرم‌افزار در سالهای اخیر آموختیم چابکی و تغییر پذیری جزوء مهمترین فاکتورهای موفقیت در پروژه‌های امروزه است.
خیلی بحث تغییرات مکرر مایکروسافت در جهتگیری هاش در حوزه توسعه نرم افزار درش دخیل نیست. جاوا حداقل یک دهه قبل از #C عرضه شده، و طراح #C هم قبل از اینکه به کار روی #C مشغول بشه، روی کامپایلر جاوا مایکروسافت و ماشین مجازی اختصاصی آن کار میکرده، پس طبیعی هست که بعد از این همه سال و اون همه تجربه طراح #C در حوزه جاوا، نقاط ضعف و قوت جاوا برای وی و تیمش عیان بوده باشند. در #C سعی شده که از نقاط قوت جاوا بهره برداری بشه، و از نقاط ضعفش پرهیز بشه. پس این برتری ها یا روان تر بودن که در #C مطرح می کنید، لزوما به خاطر تغییر پذیری در مایکروسافت نبوده. البته این بحث درباره برتری یک زبان بر زبان دیگه نیست، بلکه درباره علت وجود برخی نقاط قوت و ضعف در یک زبان نسبت به یک زبان دیگه هست.

[A.Karimi]

مکانیزم های lock در #C و synchronized در جاوا هر دو از Monitors استفاده می کنند، و از این لحاظ #C برتری خاصی نسبت به جاوا نداره. از نظر کتابخانه های مربوط به Parallel Computing، فرق جاوا با #C در این هست که برای #C به جز شرکت مایکروسافت، بازیگر بخصوصی وجود نداره، و مایکروسافت خودش این ابزارها رو معمولا تهیه میکنه، ولی در جاوا بازیگران گسترده تر هستند، و معمولا برنامه نویس باید از بین چند انتخاب موجود بهترین گزینه برای کار خودش را انتخاب کنه.


قدرت یک زبان فقط به توانایی انجام یک یا چند کار نیست. بلکه از خوانایی تا سرعت کد نویسی و Performance اجرا در آن اهمیت دارد. همانطور که ملاحظه می‌کنید در جداول مقایسه‌ای بین #C و Java موارد متفاوتی از نظر زبانی بررسی شده است. این مورد فقط درباره Synchronization نیست. در مورد کتابخانه‌های موجود برای Java حق با شماست کما اینکه بنده معتقد هستم متاسفانه برنامه‌نویسان تنبل در وادی محصولات مایکروسافت بیشترند و معمولاً دنبال محصولات و روشهای از پیش آماده هستند که بر روی اجتماع دات نت کمی اثر گذاشته‌اند. اما نباید طرفداران ALT.NET که انصافاً بسیار فعال هستند را نا دیده بگیرید. پروژه‌هایی مثل NHibernate و iTextSharp شاید در ابتدا یک ترجمه از روی نسخه Javaی آنها بودند ولی اکنون و در آینده حرفی برای گفتن خواهند داشت. در هر صورت این انتخاب شماست که از ابزارهای Community استفاده کنید و یا از ابزارهای معمولاً توکار مایکروسافت. و یا حتی خودتان برای خوتان ابزار بسازید.



خیلی بحث تغییرات مکرر مایکروسافت در جهتگیری هاش در حوزه توسعه نرم افزار درش دخیل نیست. جاوا حداقل یک دهه قبل از #C عرضه شده، و طراح #C هم قبل از اینکه به کار روی #C مشغول بشه، روی کامپایلر جاوا مایکروسافت و ماشین مجازی اختصاصی آن کار میکرده، پس طبیعی هست که بعد از این همه سال و اون همه تجربه طراح #C در حوزه جاوا، نقاط ضعف و قوت جاوا برای وی و تیمش عیان بوده باشند. در #C سعی شده که از نقاط قوت جاوا بهره برداری بشه، و از نقاط ضعفش پرهیز بشه. پس این برتری ها یا روان تر بودن که در #C مطرح می کنید، لزوما به خاطر تغییر پذیری در مایکروسافت نبوده. البته این بحث درباره برتری یک زبان بر زبان دیگه نیست، بلکه درباره علت وجود برخی نقاط قوت و ضعف در یک زبان نسبت به یک زبان دیگه هست.


در همان لینکی که درخصوص تفاوت Java و #C ارائه شد به کرات به محافظه کار بودن طراحان و نگهدارندگان زبان Java اشاره شده است که البته یک مثال از شرکتهای اینچنینی است. البته که گروه طراحان #C مخصوصاً Anders Hejlsberg به جز مطالعه جاوا، Object Pascal و ... را هم مطالعه کرده و یا در طراحی آنها فعال بوده‌اند و بعد از رفع ایرادات اقدام به طراحی زبان جدید کرده‌اند. بله بنده این موارد را قبول دارم اما شدیداً بر این موضوع تاکید دارم که چابکی و تغییرات ناگهانی یکی از مهمترین دلایل زنده بودن شرکت بزرگی مثل مایکروسافت است و مقایسه این دو زبان به عنوان تشبیهی برای دو شرکت که یکی محافظه کارتر و دیگری خطرپذیرتر است بیان شد.

همانطور که عرض کردم در علم مهندسی نرم‌افزار امروز «چابکی»، «تکرار»، «تغییر» و از این قبیل اهمیتی بیش از پیش دارد. مایکروسافت عادت دارد محصولات جدید را با شتاب ارائه کند و البته مشاهده باگها و موردهای اینچنی در اینگونه محصولاتش عادت همه ما شده شاید به نظر ما برنامه نویسان خوش نیاید، اما به نظر می‌رسد که این روش ارائه محصول بهتر، کم هزینه‌تر و در زمان کمتری به جواب می‌رسد و تغییر سیاستها راحتتر است.
کسانی که دوست ندارند در برخی از پیچ و خم های اجباری سیاست‌های کسب کار نرم‌افزار گرفتار شوند و تحمیل‌های اینجنینی را بچشند، می‌توانند به جای استفاده از تکنولوژی‌های Cutting Edge از تکنولوژی‌های مسن‌تر با خیال آسوده‌تر استفاده کنند و مدتی را تا مشخص شدن اوضاع صبر کنند. اما به نظر من در دنیای امروز این کار پر خطرتر است!

[vcldeveloper]

بله بنده این موارد را قبول دارم اما شدیداً بر این موضوع تاکید دارم که چابکی و تغییرات ناگهانی یکی از مهمترین دلایل زنده بودن شرکت بزرگی مثل مایکروسافت است و مقایسه این دو زبان به عنوان تشبیهی برای دو شرکت که یکی محافظه کارتر و دیگری خطرپذیرتر است بیان شد.
برخلاف شما، من مایکروسافت رو یک شرکت چابک و ریسک پذیر نمیدونم، اتفاقا در اکثر مواقع مایکروسافت بسیار محافظه کار و کند هست. همین مسئله رو می تونید در سیاستگذاری های کلی این شرکت و حرکت بسیار کندش به سمت موبایل و تبلت (فقط یکی از موارد ببینید). به طوری که الان ارزش سهام شرکت مثل اپل که رقیب دیرینه این شرکت بود، و مدت ها بود بازارش به واسطه فروش PC و ویندوز محدود شده بود، الان در حد ارزش سهام شرکت های نفتی هست. همین عدم ریسک پذیری و کند بودن مایکروسافت در مواجه اش با گوگل هم کاملا مشهود بود. مایکروسافت اگر دیر بجنبه، تبدیل میشه به IBM دهه اواخر دهه 90 میلادی.

درباره تغییرات در زبان های برنامه نویسی، وضع جاوا با #C خیلی فرق میکنه؛ جاوا سابقه اش از #C خیلی بیشتره و استفاده از آن هم به نسبت #C بسیار گسترده تر هست. از طرف دیگه، هر چند شرکت Oracle (و قبل از آن Sun)، وظیفه اصلی توسعه جاوا را برعهده دارند، ولی وجود چندین شرکت تکنولوژی بزرگ مثل IBM که سرمایه گزاری های عظیمی در جاوا کردند هم در سیاستگذاری های جاوا دخیل هست. همچنین، Oracle برخلاف مایکروسافت به تنهایی مالک هیچ سیستم عامل با کاربرد گسترده ایی نیست (فقط سولاریس). مایکروسافت مالک پر کاربرد ترین سیستم عامل دنیا ست. خودش هم تنها توسعه دهنده #C هست، و تغییرات در زبان #C هم اثر گزاری به گستردگی اثر گزاری یک تغییر در جاوا نداره؛ در نتیجه مایکروسافت دستش بسیار باز تر هست. اگر مایکروسافت تغییری را اعمال کنه، شما به عنوان برنامه نویس ناچار به قبول آن تغییر هستید، چون ریش و قیچی دست مایکروسافت هست، میگه این پلت فرم من هست، پر استفاده ترین سیستم عامل جهان هم هست، اگر میخواید براش برنامه بنویسید و ازش پول در بیارید، راهش همینه که من میگم! دوست نداری، به سلامت! این هست که برنامه نویسان مایکروسافتی همیشه باید دنبال مایکروسافت بدوند. نمونه جالبش همین خبر چند هفته اخیر درباره پشتیانی از ODBC در نسخه های آینده SQL Server هست؛ سالیان سال هست که مایکروسافت داره گلو خودش رو پاره میکنه که ODBC یک تکنولوژی منسوخ شده است، سرعتش پایینه، امکانات نداره، و برنامه نویسان باید ازش دوری کنند، و به OLE DB رو بیارند. اما جدیدا نظر مایکروسافت تغییر کرده، میگه نسخه آینده SQL Server آخرین نسخه ایی خواهد بود که از OLE DB پشتیبانی میکنه، و بعد از این SQL Server فقط از ODBC پشتیبانی خواهد کرد! همه چیز دست خودشه، شما وزنه خاصی ندارید. همین مسئله رو در سایر تغییرات مایکروسافتی هم می بینیم، یک روز می گفت اصلا Native Code رو دیگه فراموش کنید، فقط دات نت، اصلا ویستا که بیاد، ما دات نت رو در ویندوز یکپارچه می کنیم. بعدا معلوم شد که یکپارچکی دات نت فقط در حد نصب دات نت فریم ورک به صورت پیش فرض روی ویندوز هست. الان هم که برای ویندوز 8 دوباره داره برای Native Code بازار گرمی میکنه. COM هم همینطور؛ COM قرار بود همه چیز رو کن فیکون کنه، دیدن اینقدر پیچیده هست که همه به نوعی سعی دارند ازش فرار کنند، گفتن دات نت که بیاد، عصر COM تموم میشه. دات نت هم اومد، خبری نشد. الان هم که در ویندوز 8 رابط گرافیکی Metro مبتنی بر COM بنا شده. در هر حال مایکروسافت در حوزه سیستم عامل خودش فعالیت میکنه و به شدت هم در این زمینه انحصار طلبانه رفتار میکنه، پس این اعمال تغییرات در #C یا سایر تکنولوژی های مایکروسافتی رو نمیشه چندان به چابک بودن و ریسک پذیر بودن این شرکت مرتبط دونست. از مایکروسافت انحصار طلب تر میخواید، اپل! اپل به زور زبان برنامه نویسی عهد عتیق خودش (Objective-C) رو به خورد برنامه نویس ها میده، اجازه نصب برنامه روی آیفن یا آیپد خودتون رو بدون دریافت مجوز از این شرکت بهتون نمیده، کل نرم افزارهای ارسالی برای فروشگاه اپل را بررسی میکنه، و در صورتی که با سیاست های این شرکت تعارض داشته باشند، از API های تایید نشده این شرکت استفاده کرده باشند، یا مستقیما با بعضی محصولات اپل در رقابت باشند، اونها رو حذف میکنه. در آخر هم میگه، همینه که هست؛ آیفن پر فروش ترین موبایل دنیا، آیپد هم پر فروش ترین تبلت دنیا ست. دوست دارید ازش پول در بیارید، این روش من هست، اگر خوشتون نمیاد، به سلامت! البته مایکروسافت هم احتمالا با عرضه ویندوز مارکت در ویندوز 8، به تدریج به همین سمت حرکت خواهد کرد.

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

[A B C D]

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

الگوی انتشار محصولات در مراحل اولیه و نابالغ دقیقا الگوی شناخته شدهء مورد استفاده در دنیای نرم افزار آزاد و بازمتن هست که بیشترین تطابق رو با خواص و روش توسعهء متداول بازمتن داره.
ولی این روش مسلما میتونه مزایای قابل توجهی برای شرکتهای تجاری مثل میکروسافت و محصولات انحصاری هم داشته باشه.
و بنده فکر میکنم میکروسافت تاحد زیادی از الگو و تجربیات و تحلیل های اثبات شده در دنیای بازمتن الهام گرفته و سعی میکنه از قدرت و کارایی این روش و مشارکت کامیونیتی به نفع خودش بهره برداری کنه. البته روش میکروسافت مسلما محتاطانه تر و محدودتره، اما نسبت به گذشته تغییر و اصلاحات و انعطاف بیشتری در میکروسافت دیده میشه.
این قضیه و تغییرات و ایجاد یک نزدیکی و تاحدی هایبرید الگوی انحصاری کلاسیک و بازمتن رو میشه در قضیهء Community Promise license (http://en.wikipedia.org/wiki/Microsoft_Open_Specification_Promise) هم که بنظرم حداقل درمورد چنین محصولات بزرگ و مهم و پایه ای در میکروسافت بی سابقه بوده هم مشاهده کرد. میدونید که این تعهد میکروسافت بود برای اینکه پیاده سازیهای آزاد دات نت توسط دیگران رو اجازه بده. هرچند در این مورد مشکل و ابهاماتی وجود داشته و داره و بهرحال میکروسافت بزرگترین شرکت تجاری انحصارگر بوده که در عین حال دشمن قدیمی و رسمی نرم افزار آزاد و بازمتن محسوب میشه، بخاطر همین نمیشه به نیت و سیاست ها و تصمیم های آیندهء اون در باب دوستی با دنیای نرم افزار آزاد و بازمتن مطمئن بود و حتی میشه شک کرد که از ابتدا قصد حقه و سیاست تخریب و انحراف کامیونیتی و دستاوردها و استقلال دنیای نرم افزار آزاد و بازمتن در کار بوده.

[A.Karimi]

برخلاف شما، من مایکروسافت رو یک شرکت چابک و ریسک پذیر نمیدونم، اتفاقا در اکثر مواقع مایکروسافت بسیار محافظه کار و کند هست. همین مسئله رو می تونید در سیاستگذاری های کلی این شرکت و حرکت بسیار کندش به سمت موبایل و تبلت (فقط یکی از موارد ببینید). به طوری که الان ارزش سهام شرکت مثل اپل که رقیب دیرینه این شرکت بود، و مدت ها بود بازارش به واسطه فروش PC و ویندوز محدود شده بود، الان در حد ارزش سهام شرکت های نفتی هست. همین عدم ریسک پذیری و کند بودن مایکروسافت در مواجه اش با گوگل هم کاملا مشهود بود. مایکروسافت اگر دیر بجنبه، تبدیل میشه به IBM دهه اواخر دهه 90 میلادی.


مایکروسافت همانطور که در پست قبل گفتید برای مثال برای ایجاد زبان #C به مطالعه همه چیز پرداخت. همین مورد در زمینه EF هم صدق می‌کند. اما باید بدانیم که R&D چیز دیگری است و تغییر پذیزی چیز دیگر! به نظر من مایکروسافت به خوبی از نتایج R&D استفاده و اعمال تغییر می‌کند. در مورد بازار موبایل هم نباید عجله کرد! کما اینکه نه تنها در مورد نرم‌افزارهای موبایل نباید عجله کرد بلکه در مورد کاربردپذیزی و کلاً آینده ابزارهای موبایل در حال گذر هستیم و باید کمی منتظر بود.

درباره اپل حق با شماست! اپل برنده شد! مایکروسافت هم خدا نیست که شکست نخورد! اما محافظه کار بودن مایکروسافت در زمینه‌هایی است که مورد بحث ما نیست.



جاوا سابقه اش از #C خیلی بیشتره و استفاده از آن هم به نسبت #C بسیار گسترده تر هست. از طرف دیگه، هر چند شرکت Oracle (و قبل از آن Sun)، وظیفه اصلی توسعه جاوا را برعهده دارند، ولی وجود چندین شرکت تکنولوژی بزرگ مثل IBM که سرمایه گزاری های عظیمی در جاوا کردند هم در سیاستگذاری های جاوا دخیل هست.


گستردگی استفاده از جاوا نسبت به #C یک صحبت نسبی است. هیچیک از نمودارها و آمارهایی که ارائه می‌شود جامع و کامل نیست. معمولاً آمارها از نمونه‌هایی جمع‌آوری شده که در نتیجه تاثیر مستقیم داشته. البته در مورد #C هم به همچنین، پس بنده نسبت به گستردگی استفاده از جاوا (که از گوشه و کنار در مورد رکود آن می‌شنوم) اظهار نظر نمی‌کنم.
اما در مورد استفاده از جاوا در نرم‌افزارهای بزرگ این مورد را همه می‌دانیم که پلتفرم J2EE بزرگتر از ASP.NET در حال حاظر است و طبیعی است که از استفاده از آن در برخی پروژه‌های خاص استقبال شود. مضاف بر اینکه Java یک زبان مشترک (Lingua franca) برای دانشگاهیان (خارج از ایران) نیز می‌باشد.



اگر مایکروسافت تغییری را اعمال کنه، شما به عنوان برنامه نویس ناچار به قبول آن تغییر هستید، چون ریش و قیچی دست مایکروسافت هست، میگه این پلت فرم من هست، پر استفاده ترین سیستم عامل جهان هم هست، اگر میخواید براش برنامه بنویسید و ازش پول در بیارید، راهش همینه که من میگم! دوست نداری، به سلامت!


تا امروز که این مورد به هیچ عنوان صادق نبوده! مسئله اینجاست که مایکروسافت ساده‌ترین روش‌ها را در اختیار برنامه‌نویس قرار می‌دهد و این را همه می‌دانیم که مهمترین رمز موفقیت مایکروسافت سادگی ابزارهای آن است. برنامه‌نویسان هم معتاد این سادگی شده و گوش به فرمان مایکروسافت می‌شوند. تا امروز همیشه شما می‌توانستید با هر زبان و هر پلتفرمی که دوست داشتید بر روی Windows به توسعه نرم‌افزار بپردازید. در حال حاظر Widnows کم محدودیت ترین سیستم‌عامل دنیا جهت توسعه نرم‌افزار است (عدم محدودیت را با باز بودن اشتباه نگیرید!) این ناشی از تنبلی خود ما برنامه‌نویسان است.
برای مثال: شما می‌توانید از NHibernate استفاده کنید. ولی بیشتر افراد به سمت Entity Framework می‌روند. چون امکاناتی مانند RIA بر روی EF ساده‌تر و سر راست‌ تر کار می‌کند اما باز هم شما می‌توانید با کمی تغییر از NHibernate حتی در RIA هم استفاده کنید.
آیا تصور می‌کنید در مورد Java چنین موضوعی صادق نیست؟ تعدد پیاده‌سازی‌ها دلیل بر کامل بودن همه آنها نیست. اگر در هر زمینه از صنعت نرم‌افزار برای جاوا 10 پیاده‌سازی مهم وجود داشته باشد معمولاً دوتا یا کمتر از دوتای آنها به طور کامل قابل اتکا و استفاده تجاری واقعی هستند. اوراکل، Red Hat و بقیه نیز پیشنهادات خود را برای فیلدهای کاری مختلف بر روی جاوا دارند اما همانطور که بحث ما از ابتدا این بود، اینها بسیار محافظه کارانه تر عمل می‌کنند.



نمونه جالبش همین خبر چند هفته اخیر درباره پشتیانی از ODBC در نسخه های آینده SQL Server هست؛ سالیان سال هست که مایکروسافت داره گلو خودش رو پاره میکنه که ODBC یک تکنولوژی منسوخ شده است، سرعتش پایینه، امکانات نداره، و برنامه نویسان باید ازش دوری کنند، و به OLE DB رو بیارند. اما جدیدا نظر مایکروسافت تغییر کرده، میگه نسخه آینده SQL Server آخرین نسخه ایی خواهد بود که از OLE DB پشتیبانی میکنه، و بعد از این SQL Server فقط از ODBC پشتیبانی خواهد کرد!


OLEDB مشخصاً به این جهت معرفی شد تا کار با بانک‌های ارتباطی غیر Relational (مثل ODBMS ها) را نیز مانند RDBMS ها پشتیبانی کند. اما OLEDB استاندارد خود مایکروسافت بوده و یک استاندارد باز نبوده. چون امروزه محاسبات ابری جایگاه ویژ‌ه‌ای دارند مایکروسافت مجبور است از استانداردهای بازتری استفاده کند. ODBC از ابتدا توسط تمام نسخه‌های SQL پشتیبانی می‌شد و اکنون نیز در حال پشتیبانی است. مطلبی مبنی بر اینکه مایکروسافت برنامه‌نویسان را به دوری از ODBC فراخوانی کرده باشد ندیده‌ام! (اگر اشتباه می‌کنم لطفاً اصلاح بفرمایید) البته همیشه صحبت این بوده است که اگر شما نیاز به ارتباطات بین پلتفرمی دارید راه حل شما ODBC است نه OLEDB اکنون هم صحبت همین است. درکل اکنون کدام نرم‌افزار است که در انتخاب بین ODBC و OLEDB در شک باشد؟ امروزه برای کار با SQL در دات نت از نام فضای System.Data.SqlClient استفاده می‌شود.



در هر حال مایکروسافت در حوزه سیستم عامل خودش فعالیت میکنه و به شدت هم در این زمینه انحصار طلبانه رفتار میکنه، پس این اعمال تغییرات در #C یا سایر تکنولوژی های مایکروسافتی رو نمیشه چندان به چابک بودن و ریسک پذیر بودن این شرکت مرتبط دونست.


با همه این بحث‌ها متوجه نشدم چرا نباید اعمال تغییرات در تکنولوژی‌های یک شرکت را به چابک بودن آن ربط داد؟ مگر چابک بودن یک شرکت نرم‌افزاری با معیاری بجز تکنولوژی‌های آن سنجیده می‌شود؟ و یا آیا رفتار انحصار طلبانه ربطی به چابک بودن دارد؟

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

[A.Karimi]

الگوی انتشار محصولات در مراحل اولیه و نابالغ دقیقا الگوی شناخته شدهء مورد استفاده در دنیای نرم افزار آزاد و بازمتن هست که بیشترین تطابق رو با خواص و روش توسعهء متداول بازمتن داره.
ولی این روش مسلما میتونه مزایای قابل توجهی برای شرکتهای تجاری مثل میکروسافت و محصولات انحصاری هم داشته باشه.
و بنده فکر میکنم میکروسافت تاحد زیادی از الگو و تجربیات و تحلیل های اثبات شده در دنیای بازمتن الهام گرفته و سعی میکنه از قدرت و کارایی این روش و مشارکت کامیونیتی به نفع خودش بهره برداری کنه. البته روش میکروسافت مسلما محتاطانه تر و محدودتره، اما نسبت به گذشته تغییر و اصلاحات و انعطاف بیشتری در میکروسافت دیده میشه.
این قضیه و تغییرات و ایجاد یک نزدیکی و تاحدی هایبرید الگوی انحصاری کلاسیک و بازمتن رو میشه در قضیهء Community Promise license (http://en.wikipedia.org/wiki/Microsoft_Open_Specification_Promise) هم که بنظرم حداقل درمورد چنین محصولات بزرگ و مهم و پایه ای در میکروسافت بی سابقه بوده هم مشاهده کرد. میدونید که این تعهد میکروسافت بود برای اینکه پیاده سازیهای آزاد دات نت توسط دیگران رو اجازه بده. هرچند در این مورد مشکل و ابهاماتی وجود داشته و داره و بهرحال میکروسافت بزرگترین شرکت تجاری انحصارگر بوده که در عین حال دشمن قدیمی و رسمی نرم افزار آزاد و بازمتن محسوب میشه، بخاطر همین نمیشه به نیت و سیاست ها و تصمیم های آیندهء اون در باب دوستی با دنیای نرم افزار آزاد و بازمتن مطمئن بود و حتی میشه شک کرد که از ابتدا قصد حقه و سیاست تخریب و انحراف کامیونیتی و دستاوردها و استقلال دنیای نرم افزار آزاد و بازمتن در کار بوده.

بحث من علم مهندسی نرم‌افزار و متدهای نوین توسعه نرم‌افزار مانند Agile و ... بود. با اینکه انتشار محصولات به صورت Alpha یا Beta و یا ... قبل از شکوفایی دنیای متن باز وجود داشت اما من در صحبت‌هایم مخالفتی با الگو برداری از این جنبش نداشتم و ندارم! و البته بحث ما ربطی به دنیای متن باز و دوستی یا دشمنی مایکروسافت با آن و ... نداشت !؟

[A B C D]

بحث من علم مهندسی نرم‌افزار و متدهای نوین توسعه نرم‌افزار مانند Agile و ... بود.
بهرصورت من فکر میکنم غیر از این قضیه میکروسافت داره حداقل تاحدودی طبق الگوی بازمتن هم عمل میکنه و از اون الگو گرفته. یعنی بجای اینکه یک چیزی و ساختار و سیاستی رو صرفا تحت نظر خودش در داخل بصورت کامل طراحی و پیاده سازی کنه و بعد با یک نسخه از ویندوز بعنوان فرضا محیط اصلی برنامه نویسی بده بیرون، سعی میکنه دینامیک تر باشه و از کامیونیتی هم فیدبک و کمک و پیشنهاد بگیره (هرچند در ظاهر این رو علنا بیان نکنه) و جای برگشت و تغییر و هماهنگی سریع با فناوریهای رقیب رو هم برای خودش حفظ بکنه.
بخاطر همین بود که دات نت که مثلا قرار بود محیط اصلی اپلیکیشن نویسی ویندوز باشه الان داره جزیی از یک محیط چند زبانی/فناوری/فریمورک میشه تا اینکه بگیم تنها محیط عمدهء اپلیکیشن نویسی روی ویندوز.

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

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


انتشار محصولات به صورت Alpha یا Beta و یا ... قبل از شکوفایی دنیای متن باز وجود داشتشاید وجود داشته، اما گستردهء فواید و بهره برداری این الگو در نرم افزارهایی که کاملا انحصاری باشن خیلی محدودتر از نرم افزارهای بازمتن است.
در دنیای بازمتن این روش اساسا نیروی مضاعفی برای هدایت آگاهانه و دموکراتیک و توسعهء مشترک نرم افزار و کاهش هزینه ها و بالا رفتن کیفیت ایجاد میکنه. یعنی مثلا نیازی نیست شما یه برنامه رو کامل کنید، حتی در یک درجهء بدوی هم میشه منتشرش کرد و بعد اگر ارزشش رو داشته باشه خیلی ها ممکنه روش کار کنن و اون رو تکمیل کنن، اونم بصورت کاملا عینی در جریان استفادهء عملی و با فیدبک و انعطاف کامل از جانب جامعهء برنامه نویسان و کاربران.
درحالیکه اگر نرم افزار انحصاری بود حتی ممکن بود هیچوقت به اون درجه نرسه و حتی منتشر هم نشه (بخاطر کمبود منابع و انگیزه و غیره).


اما من در صحبت‌هایم مخالفتی با الگو برداری از این جنبش نداشتم و ندارم! و البته بحث ما ربطی به دنیای متن باز و دوستی یا دشمنی مایکروسافت با آن و ... نداشت !؟ فقط خواستم مطلب کامل باشه و بازهم تاکید کنم که میکروسافت در این زمینه خیلی ناقص و غیرقابل اعتماده و به هیچ وجه نمیشه سیاست های اون رو بقدر کافی باز و سازگار/دوست با دنیای بازمتن دونست.

[vcldeveloper]

اگر شما می‌خواهید بگویید که مایکروسافت آنقدرها هم چابک نیست باید توجه بفرمایید که بحث ما بر سر شرکت‌های موجود در جهان است نه ایده‌آل ها که هنوز وجود ندارند. بحث بنده این است که در بین امکانات موجود و شرکت‌های موجود، مایکروسافت از همه پویاتر است و این پویایی بر خلاف اعتراض برنامه‌نویسان در دنیای امروز چیز بدی نیست.
من کندی مایکروسافت رو حداقل در دو عرصه اقبال نرم افزارهای مبتنی بر وب (رقابت با گوگل)، و اقبال دنیای موبایل و تبلت (رقابت با اپل) با شرکت های فعلی که رقبای عمده مایکروسافت محسوب میشند، مقایسه کردم، نه با ایده آل ها! کافیه یک نگاهی به ارزش سهام همین دو رقیب مایکروسافت و بخصوص رشد تصاعدی آنها در چند سال اخیر بیاندازید، تا ببینید مایکروسافت چقدر دیر به فکر فرو افتاد که تغییر رویه بده. الان اپل در دنیای تکنولوژی کشور آمریکا پر سود ترین شرکت محسوب میشه، و ارزش این شرکت با ارزش شرکت نفتی ExxonMobil، بزرگترین شرکت نفتی جهان رقابت میکنه! مایکروسافت سال ها ست که در هماهنگ سازی زیر مجموعه های مختلف شرکت با هم در راستای استراتژی های شرکت مشکل داره.



مایکروسافت همانطور که در پست قبل گفتید برای مثال برای ایجاد زبان #C به مطالعه همه چیز پرداخت. همین مورد در زمینه EF هم صدق می‌کند. اما باید بدانیم که R&D چیز دیگری است و تغییر پذیزی چیز دیگر! به نظر من مایکروسافت به خوبی از نتایج R&D استفاده و اعمال تغییر می‌کند.
همه شرکت های معروف تکنولوژیکی سرمایه گسترده ایی روی R&D می کنند و از آن بهره می برند. اگر معیار چابکی استفاده گسترده از نتایج آزمایش ها و پژوهش های لابراتوارهای R&D، و به بازار کشاندن این دستاورد ها باشه؛ رقیب مایکروسافت، یعنی گوگل، بسیار بیشتر از مایکروسافت بر این امر اهتمام داره، و مایکروسافت در مقایسه با آن، شرکتی کند و کم تحرک محسوب میشه.


مطلبی مبنی بر اینکه مایکروسافت برنامه‌نویسان را به دوری از ODBC فراخوانی کرده باشد ندیده‌ام! (اگر اشتباه می‌کنم لطفاً اصلاح بفرمایید)
رجوع کنید به مطالب مربوط به دهه 90 میلادی، زمانی که مایکروسافت به شدت در حال تبلیغ OLE DB بود، و همچین به ناپدید شدن تدریجی اپلت مدیریت ODBC در نسخه های اخیر ویندوز (ویستا و ویندوز 7). در اینکه ODBC یک استاندارد باز، با استفاده گسترده، و مورد قبول عام بوده و هست، بحثی نیست. بحث سر اینه که مایکروسافت بالاخره به این نتیجه رسید، و همانطوری که تا دیروز کاربرانش را به سمت OLE DB سوق می داد و از مزایای آن سخن می گفت، الان همین کار را برای ODBC انجام میده، و البته در پست قبلی به چند مثال دیگه مثل دات نت، و COM هم اشاره کردم. مایکروسافت در اینگونه تغییر جهت گیری ها، ید طولایی داره.


با همه این بحث‌ها متوجه نشدم چرا نباید اعمال تغییرات در تکنولوژی‌های یک شرکت را به چابک بودن آن ربط داد؟ مگر چابک بودن یک شرکت نرم‌افزاری با معیاری بجز تکنولوژی‌های آن سنجیده می‌شود؟ و یا آیا رفتار انحصار طلبانه ربطی به چابک بودن دارد؟
البته مسئله شرکت مایکروسافت فراتر از بحث توسعه #C هست. تیم #C به نسبت کل شرکت مایکروسافت، فوق العاده کوچک و محدود هست. شرکت مایکروسافت در چند سال اخیر هیچ نوع آوری قابل توجهی به بازار عرضه نکرده، و در بازار بیشتر دنباله روی جهت گیری های بازار بوده، تا اینکه خودش جهت گیری ها را شکل بده. در واقع در این چند ساله مایکروسافت فقط تلاش کرده که از دور رقابت خارج نشه. رویکرد مایکروسافت به اهمیت دادن به نرم افزارهای مبتنی بر وب و Cloud computing، و رویکرد مایکروسافت به بازار موبایل، به عنوان تکنولوژی های پیشروی امروزی در دنیای IT، رویکردی منفعلانه بوده، برای شکست نخوردن در برابر حریفان بوده. ارائه سرویس آنلاین آفیس، توجه ویژه به موتور جستجوی بینگ، ارائه سرویس های Cloud، تصمیم برای شکست اتحاد معروف وینتل (ویندوز + اینتل) و قبول ارائه سیستم عامل برای سی پی یو های ARM، توجه ویژه به بازار فعلی تبلت، و شریک شدن با نوکیا (شرکتی که در عرصه موبایل سرنوشتی مشابه مایکروسافت پیدا کرد)، به منظور خروج از بحران در حوزه موبایل؛ همگی نمونه ایی از رفتارهای مایکروسافت برای عقب نماندن از قافله بازار بوده، نه حاصل دور اندیشی یا سیاست گزاری های صحیح مایکروسافت. به همچین شرکتی نمیشه گفت شرکت چابک! اینکه بحث انحصار مایکروسافت را مطرح کردم، به این منظور بود که بگم، اگر هم جایی ما مایکروسافت را حرکت به سمت تکنولوژی های جدید پیشگام می بینیم، یکی از عوامل مهم اش انحصار مایکروسافت در آن حوزه ها بود. در واقع مایکروسافت در این چند سال اخیر در هر حوزه ایی که انحصار نداشت، از رقبای خودش عقب افتاد. در دنیای دات نت هم عملا همه رقبا را با سیاست گزاری های خودش از دور خارج کرد. قبلا هم درباره این موضوع توضیح دادم که در سطح دات نت هر چند دست همه برای ارائه تکنولوژی باز هست، ولی زمین بازی به نحوی چیده شده که هیچکس به جز مایکروسافت از آن پیروز بیرون نمیاد، و همه چیز دست مایکروسافت هست. الان مایکروسافت بخواد یک تغییر در زبان #C بده، یا یک افزونه به دات نت اضافه کنه، CLR دات نت که دسته خودش هست (حالا پروژه هایی مثل MONO بماند که گستردگی استفاده ازشان اصلا قابل مقایسه با CLR پیاده سازی شده توسط مایکروسافت نیست). پلت فرم ویندوز هم که دست خودش هست. ماشین تبلیغاتی مایکروسافت هم که معرف حضور همه هست؛ قبل از ارائه هر دست آورد حتی تکراری، چنان بمباران رسانه ایی میکنه، و اونقدر مقاله و کتاب در وصف اون تغییر و مزایای اون منتشر میکنه، که خیلی وقت ها بعضی کاربران تصور می کنند که مایکروسافت خودش مبدع و خالق اون دست آورد بوده! یادم هست مدت ها خیلی ها تصور می کردند که مثلا Web Services رو مایکروسافت خلق کرده! یا MVC رو مایکروسافت کاشته که الان بر سر زبون ها افتاده! خب با این تفاسیر، این مدل تغییرات در همچین شرایطی کار ساده ایی هست، و نمیشه به صرف دیدن این مدل تغییرات، مایکروسافت رو شرکتی چابک نامید. حقیقتش من تا به حال از هیچکس، حتی کسانی که مرتبا اخبار مایکروسافت را دنبال می کنند، و درباره آن مطلب می نویسند؛ نشنیده بودم که در این چند سال اخیر، مایکروسافت را شرکتی چابک خطاب کنند، بلکه بالعکس، مایکروسافت رو شرکتی بزرگ با بخش های متعدد که در بسیاری از مواقع از احوال هم بی خبرند و حتی گاها با هم به رقابت مشغول اند، می دیدند.

البته ذکر این نکته هم ضروری هست که این بحث ها بر سر چابکی شرکت مایکروسافت هست، نه بر سر مزایای #C یا مثبت بودن برخی از تصمیمات مایکروسافت، مثل رویکرد به ODBC یا تصمیم گیری های اخیرش درباره ویندوز 8. در واقع من مایکروسافت را شرکت چابکی نمی شناسم، اما #C را یک زبان برنامه نویسی خوب و روان میدونم، و امکانات و قابلیت های جدیدش را دوست دارم. رویکرد جدید مایکروسافت در عرضه ویندوز 8، اقبال مجددش به Native Code، و قبول این مسئله که باید به طور جدی وارد عرصه موبایل شود را هم بسیار مثبت میدونم؛ یعنی مایکروسافت حداقل این تدبیر را دارد که وقتی در عرصه ایی شکست خورد یا عقب افتاد، یا اشتباه کرد، برای عقب نماندن از قافله هم که شده، تصمیم گیری درستی برای بقا در بازار و ادامه رقابت انجام بده.

[A.Karimi]

@علی کشاورز -

مبلغ سهام مایکروسافت و ... برای من به عنوان یک توسعه دهنده اهمیتی ندارد (متوجه اهمیت غیر مستقیم آن هستم) و بحث من در مورد آن نیست! بنده به خوبی می‌دانم که مایکروسافت در چه زمینه‌هایی از قافله عقب است! بلکه بحث ما بر سر ابزارهای توسعه محیطهای برنامه‌نویسی و پلتفرمهای برنامه نویسی بود. نه موفقیت یا عدم موفقیت مایکروسافت در دو زمینه که نام بردید.

شاید نام چابک نام اشتباهی برای توصیف این خصوصیت مایکروسافت باشد. اما مسئله اینجاست که مایکروسافت به راحتی تغییرات اساسی در محصولات توسعه‌دهندگان و برنامه‌نویسان خود می‌دهد که خودتان در متن بارها به آن اشاره کردید. در مورد اپل هم که در مورد انحصار طلبی‌اش توضیح دادید که کاملاً موافقم. در مورد گوگل هم نو آوری آن بیشتر در سمت کاربران نهایی است. حتی برای Android از Java استفاده کردند و یک نو آوری متحولانه نداشتند (در مورد سبک توسعه UI این سیستم عامل اگر نو آوری نمی‌کردند قضیه امکانپذیر نمی‌شد که البته آنهم به نظرم یک تغییر اساسی نبود)! در Androd شما هنوز برای ایجاد یک event ساده باید چند خط کد بزنید! در مورد بقیه سرویسهای گوگل از منظر برنامه‌نویسی نیز شاید فقط یک سری API بسیار خوب باشد! مایکروسافت هر چه باشد حداقل در زمینه ابزارهای برنامه سازی و توسعه بلند پروازانه تر از شرکتهای رقیبش کار می‌کند (با توجه به اندازه‌اش و با توجه به مشکلاتی که دارد).

مجدداً اشاره می‌کنم که بحث ما بر سر این است که برنامه نویسان از تغییرات مایکروسافت ناراحت هستند! و بنده این تغییرات را مثبت می‌دانم.

در هر صورت من هم دوست ندارم خودم را گول بزنم! بنده به عنوان یک توسعه دهنده در حال حاظر ابزارها و پلتفرم مایکروسافت را بهترین می‌دانم. در اویل دهه‌ی 90 و حتی کمی بعد از آن مایکروسافت هیچ حرفی برای گفتن در این زمینه نداشت در حالی که بورلند پیشرو بود. اما همه چیز تغییر کرد. اکنون نیز ممکن است شرایط تغییر کند. هر چند که بخشی از کار ما پیشبنی آینده تکنولوژی است و من آینده کار بر روی پلتفرم مایکروسافت را روشن میدانم، اما در صورتی که لازم باشد باید به راحتی به وادی بهتر کوچک کنیم.

از اینکه در بحث شرکت کردید متشکرم.

[danial_rtw]

این همه دوستان حرف زدن و بحث کردن و نظر دادن ما آخرش نفهمیدیم باید چیکار کنیم خواهشن یکی به من بگه من #C که دارم میخونم ادامه بدم یا نه ، در ضمن دارم جاوا هم کار میکنم تو جفتشون مبتدی هستم لطفا راهنمایی بفرمایید چی کار کنم؟

[Amir Oveisi]

این همه دوستان حرف زدن و بحث کردن و نظر دادن ما آخرش نفهمیدیم باید چیکار کنیم خواهشن یکی به من بگه من #C که دارم میخونم ادامه بدم یا نه ، در ضمن دارم جاوا هم کار میکنم تو جفتشون مبتدی هستم لطفا راهنمایی بفرمایید چی کار کنم؟

ادامه بدید :)

[Dariuosh]

Designing Metro style apps that are touch-optimized (http://channel9.msdn.com/events/BUILD/BUILD2011/APP-391T)
و یه عالمه دیگه (http://channel9.msdn.com/Events/BUILD/BUILD2011?t=metro%2Bstyle%2Bapps)