تاریخچه مختصر یونیکد و محصولات میکروسافت
در اینجا قصد بررسی مفصل موضوع یونیکد یا استاندارد ISO-10646 که اکنون یونیکد در پی اجرای مو به موی آن است را نداریم. هدف ما از این بحث، بررسی تاریخچه این مفاهیم جهت شرح موقعیت فعلی ویژوال بیسیک و سایر محصولات میکروسافت نسبت به یونیکد و همچنین شناسایی مسیر حرکت آنان نسبت به این سیستم است. این بحث اکثر مقاطع بحرانی این تاریخچه را پوشش داده وبیشتر بر اساس کاربرد مرتب‌سازی شده تا بر اساس زمان. از کجا شروع کنیم؟ البته که از اول شروع خواهیم کرد...
ویندوز 16 بیتی (ویندوز 3.0، 3.1، و 3.1x)
ویندوز در ایالات متحده آمریکا توسط شرکت آمریکایی میکروسافت برنامه‌نویسی شد. در آن زمان واژه یونیکد هنوز شناخته شده نبود و طبیعتاً هیچ یک از سیستم‌های عامل 16 بیتی ویندوز توان تکلم به زبان یونیکد را ندارند. برخی مسئولین آینده‌بین میکروسافت که به بازارهای بین‌المللی و خصوصاً بازارهایی چون ژاپن می‌اندیشیدند سبب شدند میکروسافت فراتر از برگ اطلاعاتی 1252 فکر کرده و به برگهای اطلاعاتی ژاپن و دیگر زبانهای آسیایی بیاندیشد. اگرچه هزینه جهانی‌سازی و ترجمه نرم‌افزار واضح نبود اما نیازهای بازار ژاپن به حدی شفاف بود که میکروسافت با هدف ترجمه نرم‌افزار در این بازار قدم نهاد.
ولیکن ترجمه نرم‌افزار در این مرحله به شکلی بسیار بدوی صورت می‌گرفت. برنامه‌نویسان آمریکایی "کدهای برنامه‌های خود را به آن طرف دیوار" برای برنامه‌نویسان ژاپنی پرتاب می‌کردند و برنامه‌نویسان ژاپنی تغییرات لازم را اعمال و صحت تغییرات صورت گرفته را آزمایش می‌کردند. متاسفانه این برنامه‌نویسان و مهندسین آزمایش نرم‌افزار در کار خود به اندازه هم‌ردیفان اولیه خویش اشتباه داشته و نسخ نرم‌افزاری حاصل ابرمجموعه‌هایی قادر به پشتیبانی از کلیه زبانها نبوده، بلکه نرم‌افزارهایی خاص بودند که همان اشکالات را در کار کردن با داده‌های زبان نسخه اصلی پیدا می‌کردند.
و بدین ترتیب ترجمه نرم‌افزار پدید آمد، اما جهانی‌سازی هنوز مفهومی نسبتاً ناشناخته بود. از آنجا که نسخ ترجمه شده به هر زبان با داده‌های همان زبان کار کرده و نیازی به تبادل اطلاعات بین چند برگ اطلاعات کاراکتر مختلف نبود، مشکلات عمده‌ای برای کسی ایجاد نمیشد.
مدلسازی اشیاء زیرمجموعه (COM) در دنیای 16 بیتی
سیستم COM نیز به دلایلی مشابه، درک چندان بهتری از یونیکد پیدا نکرد. در واقع باید گفت که این سیستم (Component Object Model) اهمیت ویژه زبان/تنظیمات محلی در نرم‌افزارها را اصلاً نپذیرفت. ادامه کار این سیستم با این فرض که ادامه کار با همین برگ اطلاعاتی پیش‌فرض فعلی سیستم کافی است، صورت گرفت.
ویژوال بیسیک در دنیای 16 بیتی
نسخ اولیه ویژوال بیسیک با همان قوانین و معیارهای نرم‌افزارهای 16 بیتی دیگر کار کردند ولی تا زمان عرضه نسخه 3.0 ویژوال بیسیک، ضرورت وجود دیدگاه جدیدی نسبت به نرم‌افزار جهت کاهش هزینه‌ها و افزایش کیفیت محصولات عرضه شده در سایر کشورها روشن شده بود. ولیکن ویژوال بیسیک همواره وابستگی شدیدی به محیط نرم‌افزاری و سیستم عامل داشته و بدون تغییر جهت پی و زیربنا، تغییر جهت ساختمان ممکن نیست. نتیجتاً نسخه 3.0 ویژوال بیسیک به شکل قبلی خود ماند در حالیکه مردم به آینده، یعنی تکنولوژی جدید میکرسافت که همان Windows New Technology یا به اختصار ویندوز NT بود، چشم اندوختند.
ویندوز NT
دومین سیستم عامل دیوید کاتلر (سیستم عامل اول برای Digital طراحی شده بود) با دیدی آینده‌نگر طراحی شده بود، و جنبه مهم آن برای ما پشتیبانی کامل ویندوز NT از یونیکد است. در کلیه مراحل برنامه‌نویسی این سیستم عامل، یک هسته (Kernel) یونیکد و پشتیبانی از یونیکد مهمترین روش دسترسی به سیستم عامل قرار داده شده‌اند. این طرح با انتقاد مواجه شد، چراکه از دید اکثر افراد در آن زمان که کامپیوترها با کمبود حافظه RAM و فضای هارد دیسک روبرو بودند، چنین طرحی مشکل‌ساز بود، اما آقای کاتلر واقعاً دوراندیشانه عمل کرده بود. "یونیکد" انتخابی او UCS-2 یعنی همان استاندارد جهانی تحت پوشش ISO-16046 بود که تمام کاراکترها را به شکل دو بایتی تعریف میکرد. تنظیمات محلی انگلیسی آمریکایی هنوز از نظر "موقعیت" برتری داشت، چراکه در 127 کاراکتر اول جای گرفته بود، اما دیگر مزیت سابق خود نسبت به زبانهای آسیایی یعنی اشغال فضای کمتر را از دست داده بود.
در عین حال واقعیت نیز امکان بکارگیری سیستم عاملی را که از "روش قدیمی” اجرای برنامه‌ها پشتیبانی نکند، محال جلوه می‌داد. بنابراین امکان سازگاری با نسخ قدیمی پشتیبانی از ANSI را واجب می‌ساخت، بدین ترتیب تمام برنامه‌های موجود نیز قابل اجرا بودند (در اکثر موارد). بدین ترتیب تمامی APIهای 32 بیتی که رشته کاراکتر دریافت می‌کردند، در دو نسخه ارائه شدند: یک نسخه A برای سیستم‌های کاراکترهای چندبایتی مانند انگلیسی، هلندی و ژاپنی، و یک نسخه W که از یونیکد استفاده کند. به هنگام کمپایل، با روشن یا خاموش کردن پارامتر یونیکد، استفاده از دسته API مورد نظر مقدور می‌گشت. به عنوان مثال، این پارامتر تعیین میکرد که فراخوانی GetWindowLong در برنامه C یا C++ شما از بین GetWindowLongA و GetWindowLongW کدامیک را اجرا نماید. همواره میتوانستید بطور خاص و بر حسب مورد مشخص کنید کدامیک مورد نظرتان است، اما این شیوه توصیه نمیشد. در تئوری، فقط با تغییر یک پارامتر میتوانستید روزی برنامه خود را سازگار با سیستم یونیکد بنمایید!
و اما چرا چنین چیزی مطلوب بود؟ اولاً توان یک برنامه اجرایی که در سراسر جهان قابل اجرا باشد، واضح است (حتی خود ویندوز NT نیز هنوز از چنین خصوصیتی برخوردار نبود، چراکه بسیاری از برنامه‌های داخلی آن هنوز به اندازه هسته کرنل ویندوز پرقابلیت نبودند - وضع به حدی فجیع بود که همانطور که می‌بینید هسته کرنل ویندوز را پرقابلیت دانسته‌ایم!). ثانیاً اینکه هرگاه مستقیماً با یونیکد کار می‌کردید، عملیات مورد نظرتان سریعتر انجام میشد چراکه در چنین حالتی نیازی به عملیات تبدیلی بین دو سیستم ANSI و یونیکد نبود. مردم به سرعت پی بردند که ادعای راهنماهای SDK صحیح بوده و توابع MultiByteToWideChar و WideCharToMultiByte به راستی میتوانستند سبب کندی اجرا برنامه‌ها بشوند.
البته یکی از خصوصیات نهفته MultiByteToWideChar و WideCharToMultiByte این بود که وجود جداول برگهای اطلاعات کاراکتر جهت تسهیل تبدیل رشته‌کاراکترها بین سیستم یونیکد و برگ اطلاعات کاراکتر مورد نظر، واجب می‌نمود. پشتیبانی از یک زبان در حالی که اکثر نرم‌اقزارها از یونیکد برای عملیات داخلی خود استفاده نمی‌کردند، به معنای پشتیبانی از برگ اطلاعات کاراکتر مربوطه نیز بود.
شامل 12 صفحه word
دانلود تحقیق مایکروسافت