فصل 6

آيا ويژوال بيسيک ANSI است يا يونيکد؟

همانطور که در همان فصل اول "آغاز کار" اشاره کردم، اين سوال که آيا ويژوال بيسيک ANSI است يا يونيکد، سوالی گمراه‌کننده بيش نيست. تنها پاسخی که می‌توان به اين سوال داد "هم بلی و هم خير" است، به عبارتی ديگر، پاسخ بستگی به منظور پرسشگر دارد. شايد رجوع به تاريخچه اين بحث و بررسی عميق‌تر گذشته آن به اين سوال معنای کافی بخشيده و پاسخ "بستگی دارد" را حداقل کمی قانع‌کننده جلوه دهد.

ANSI = ~يونيکد = MBCS

يک تعريف مهم قبلاً مورد بحث قرار گرفت: در اينجا منظور من از يونيکد همان مفهوم UCS-2/UTF-16 ميکروسافت است. مورد ديگری که قبلاً ذکر نکردم مسئله رشته کاراکترهای غيريونيکد است. اگرچه اين رشته‌کاراکترها معمولاً تحت عنوان چندبايتی (که شامل کليه برگهای اطلاعات كاراكتر (code page) ديگر من‌جمله برگهای اطلاعات کاراکتر DBCS که از دو بايت و UTF-8 که از 1 الی 5 بايت استفاده می‌کنند و غيره، می‌باشد) شناخته می‌شوند، ولی بسياری از افراد نيز اين رشته‌کاراکترها را به عنوان ANSI می‌شناسند. دليل اين موضوع عمدتاً در گذشته ريشه داشته، ولی عامل جديدی نيز جهت اين اشتباه وجود دارد: کليه APIهای چندبايتی ويندوز با حرف A شروع می‌شوند و A حرف اختصاری واژه ANSI است. به عنوان مثال می‌توان به FindWindow API اشاره کردکه برای يک کلاس پنجره، يک بلوک پنجره يا هر دو مورد مذکور ورودی به شکل رشته کاراکتر دريافت می‌کند. FindWindowA API در تمام سيستم‌های عامل 32 بيتی ويندوز وجود داشته و پارامتر ورودی آن با برگ اطلاعات کاراکتر پيش‌فرض سيستم قابل نمايش است. FindWindowW API تنها در ويندوز NT و ويندوز 2000 وجود داشته و پارامتر ورودی آن در قالب رشته کاراکترهای يونيکد است.

من شخصاً ترجيج می‌دادم که APIهای سری A را APIهای ~Unicode (يعنی APIهای "غيريونيکد") بخوانند، ولی کاراکتر ~ در شناسه‌ها به عنوان يک کاراکتر معتبر قابل استفاده نيست. چنين عنوانی دست کم سبب سردرگمی خواهد بود!

مسئله بکارگيری و فراخوانی APIهای يونيکد در برابر بکارگيری و فراخوانی APIهای غيريونيکد را در ادامه اين فصل مورد بحث قرار داده و در فصل 7 "درک موانع ناشی از برگهای اطلاعات کاراکتر" و فصل 8 "بکارگيری فرم‌ها و فرمت‌های ويژوال بيسيک" بطور مشروح بررسی خواهيم نمود.

تاريخچه مختصر يونيکد و محصولات ميکروسافت

در اينجا قصد بررسی مفصل موضوع يونيکد يا استاندارد 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 اين بود که وجود جداول برگهای اطلاعات كاراكتر جهت تسهيل تبديل رشته‌کاراکترها بين سيستم يونيکد و برگ اطلاعات کاراکتر مورد نظر، واجب می‌نمود. پشتيبانی از يک زبان در حالی که اکثر نرم‌اقزارها از يونيکد برای عمليات داخلی خود استفاده نمی‌کردند، به معنای پشتيبانی از برگ اطلاعات کاراکتر مربوطه نيز بود.

ويندوز 95

خلق ويندوز 95 تحت اصولی متفاوت صورت گرفت: از بسياری از جوانب ويندوز 95 بسط سيستم اصلی 16 بيتی ويندوز 3.x بود (همين مسئله در مورد اکثر نرم‌افزارها، حتی آنهايی که تحت ويندوز NT نوشته شده‌اند، صدق می‌کند). در ابتدا پشتيبانی کامل از APIهای 32 بيتی ويندوز همانند ويندوز NT مورد نظر بود، ولی در اکثر موارد فراخوانی نسخه‌های W توابع API با يکی از دو پيغام خطای ERROR_CALL_NOT_IMPLEMENTED يا E_NOTIMPLپاسخ داده می‌شود. تعداد محدودی از توابع API 32 بيتی به منظور پشتيبانی از هر دو سيستم يونيکد و ANSI تحت ويندوز 95 و 98 طراحی شده‌اند که فهرست آنان در جدول 6.1 آمده است.

جدول 6.1 آن دسته از توابع 32 بيتی ويندوز که در تمامی شرايط محيطی از يونيکد پشتيبانی می‌کنند

تابع API

عملکرد آن

EnumResourceLanguages

تعداد زبانهايی را که توسط منبع مورد نظر در واحد نرم‌افزاری مورد نظر پشتيبانی ميشوند، محاسبه ميکند

EnumResourceNames

تعداد کل منابعی را که از نوعی خاص بوده و در واحد نرم‌افزاری مورد نظر وجود دارند، محاسبه ميکند

EnumResourceTypes

انواع منابع موجود در واحد نرم‌افزاری مورد نظر را محاسبه ميکند

ExtTextOut

يک رشته کاراکتر را در محل مورد نظر ثبت می‌کند. امکان استفاده از پارامترهای بيشتری نسبت به پارامترهای TextOut در اين تابع وجود دارد.

FindResource

منبع دارای نام و عنوان مورد نظر را پيدا ميکند.

FindResourceEx

منبع دارای نام و عنوان مورد نظر را با ذکر زبان مربوطه پيدا ميکند.

GetCharWidth

عرض کاراکترهای مشخص شده را برميگرداند

GetCommandLine

رشته کاراکتر خط فرمان برای مرحله فعلی اجرايی برنامه را برميگرداند

GetTextExtentPoint

عرض و ارتفاع رشته کاراکتر متنی داده شده را محاسبه مينمايد (برای سازگاری با نسخه‌های قبلی ارائه شده، استفاده از GetTextExtentPoint32 توصيه ميشود)

GetTextExtentPoint32

عرض و ارتفاع رشته کاراکتر متنی داده شده را محاسبه مينمايد

lstrlen

طول رشته کاراکتری را که با کاراکتر null خاتمه مييابد، برميگرداند

MessageBox

يک پنجره پيغام بوجود آورده، نمايش داده، و اجرا مينمايد.

MessageBoxEx

يک پنجره پيغام بوجود آورده، نمايش داده، اجرا مينمايد، و به کاربر اجازه ميدهد زبان مورد نظرش را برای کليدهای پيش‌ساخته تعريف نمايد

MultiByteToWideChar

با توجه به برگ اطلاعات کاراکتر مشخص شده جهت تبديل، يک رشته کاراکتر چندبايتی را به رشته کاراکتر يونيکد تبديل ميکند

TextOut

يک رشته کاراکتر را در محل مورد نظر ثبت می‌کند

WideCharToMultiByte

با توجه به برگ اطلاعات کاراکتر مشخص شده جهت تبديل، يک رشته کاراکتر يونيکد را به رشته کاراکتر چندبايتی تبديل ميکند


واضح است که نوشتن يک برنامه يونيکد تحت ويندوز 95 يا 98 با توجه به چنين ابزار پراکنده‌ای بسيار مشکل است. وليکن در ابتدا فرض بر اين بود که پس از نوشتن برنامه، به سادگی با کمپايل آن به عنوان يک برنامه يونيکد تحت ويندوز NT، هدف حاصل ميشود. نياز به پشتيبانی از برنامه‌های يونيکد تحت ويندوز 98/95 بعداً روشن شد.

يک استثنای بزرگ برای کل اين بحث وجود دارد و آن COM 32 بيتی است.

مدلسازی اشياء زيرمجموعه (COM) در دنيای 32 بيتی

سيستم COM در هر دو سيستم عامل ابتکار جالبی به خرج داد: اين سيستم فقط از يونيکد پشتيبانی می‌کند، و ANSI را طرد کرده است. اگر به نوعی نتوانيد به زبان يونيکد تکلم کنيد (حتی اگر شده فقط با بکارگيری توابع MultiByteToWideChar و WideCharToMultiByte جهت تبديل)، قادر به برقراری ارتباط با COM نخواهيد بود. با توجه به اينکه حتی عمليات پايه و اوليه پوسته ويندوز 32 بيتی نيز نياز به يونيکد دارند، تمامی نرم‌افزارها بايد حداقل کمی با يونيکد کار کنند. رشته کاراکترهای COM 32 بيتی (OLESTRها و BSTRها) هميشه به يونيکد هستند. البته اکثر نرم‌افزارها با بکارگيری توابع تبديل و استفاده از برگ اطلاعات کاراکتر پيش‌فرض سيستم (CP_ACP)، يعنی تنها برگ اطلاعات کاراکتری که پشتيبانی از آن تضمين شده است، با حداقل شرايط ممکن از آن پشتيبانی می‌کنند.

ويندوز 98

تنها تغيير درونی اين نسخه از ويندوز اضافه شدن چند تابع API به فهرست توابعی که از هر دو سيستم ANSI و يونيکد پشتيبانی ميکردند, بود (فهرست اين توابع در جدول 6.2 آمده است).

جدول 6.2 فهرست توابع جديدی که در ويندوز 98 از يونيکد پشتيبانی ميکنند

تابع API

عملکرد آن

lstrcat

يک رشته کاراکتر را به ديگری پيوست می‌دهد

lstrcpy

يک رشته کاراکتر را به حافظه بافر کپی می‌کند


ولی تعداد واسط‌های اضافه شده زياد بود. به عنوان مثال می‌توان از دنباله‌های جديد پوسته و پيشرفت يکپارچگی مرورگرها نام برد. اينها همگی واسط‌های COM بوده و نتيجتاً تنها از يونيکد پشتيبانی می‌کنند.

نسخه هزاره ويندوز (ويندوز Me)

ويندوز Me نقش زيادی در اين معادله ايفا نکرد. بنا بر اظهارات ميکروسافت، اين نسخه از ويندوز آخرين نسخه‌ای خواهد بود که با اصول برنامه‌نويسی Win9x ارائه می‌شود. ولی ضمن رعايت انصاف بايد گفت که شرکت ميکروسافت از زمان عرضه نسخه OSR2 ويندوز 95 تاکنون همين حرف را تکرار کرده است. اصل مطالبی که در رابطه با ويندوز 95 و 98 ذکر کردم، در مورد ويندوز Me نيز صادق می‌باشد.

دو دسته از توابع جديدی که در نسخه هزاره ويندوز از يونيکد پشتيبانی می‌کنند، توابع API مربوط به Input Method Manager (IMM) که در فصل 8 بيشتر مورد بررسی قرار خواهم داد، و توابع API مربوط به Geographical Information Management (Geo) می‌باشند. توابع Geo در بسياری از اجزای ويندوز Me به منظور ارتباط اطلاعات منطقه‌ای به يک موقعيت جغرافيايی مورد استفاده قرار می‌گيرند.

بانکهای اطلاعاتی

خود بانکهای اطلاعاتی اعم از SQL Server، جت، فاکس‌پرو يا بانکهای اطلاعاتی ديگر، در ابتدا فاصله خود را از دنيای يونيکد حفظ کردند و دنيای محلی را که در آن يک برگ اطلاعات کاراکتر واحد کافی بود، ترجيح دادند. اگرچه جت و SQL Server هردو در بسياری از موارد توان اجرای عمليات مربوط به رشته کاراکترها (String normalization) را داشتند (جهت کسب اطلاعات بيشتری در اين زمينه به فصل 12 رجوع کنيد)، اما اين عمليات تنها با هدف افزايش قابليت صورت گرفته و جهت پشتيبانی از برگهای اطلاعات کاراکتر متعدد در يک فايل واحد نبود. هردو محصول يک پله فراتر از طرح «برگ اطلاعات کاراکتر پيش‌فرض» سيستم عامل قرار داشتند. انتخاب صريح و موردی هر برگ اطلاعات کاراکتر واحدی که توسط سيستم عامل پشتيبانی ميشد، در هر دو محصول مقدور بود، ولی هنوز به استفاده از يک برگ اطلاعات کاراکتر واحد محدود بوديد.

وليکن نسخه‌های اخيرتر جت و SQL Server از يونيکد به عنوان يک فرمت محلی پشتيبانی می‌نمايند: در بانک اطلاعات جت، همه چيز به سيستم يونيکد منتقل شد، ولی در SQL Server انتخاب بين ANSI و يونيکد امکان‌پذير بود. بانکهای اطلاعاتی ديگر (همچون فاکس‌پرو) در سطح بانک اطلاعاتی از يونيکد به عنوان يک فرمت محلی پشتيبانی نمی‌کنند.

توابع دسترسی به اطلاعات

اکثر توابع دسترسی به اطلاعات (ADO، OLE DB، DAO، و RDO) بر خلاف خود بانکهای اطلاعاتی اجزای COM بوده و نتيجتاً فقط از يونيکد پشتيبانی می‌کنند. بنابراين داده‌ها در حاليکه بانک اطلاعاتی پايه آنها از يونيکد پشتيبانی نمی‌کند، چگونه می‌توانند به زبان يونيکد مورد استفاده قرار بگيرند؟ جواب اين سوال به زبان ساده اين است که داده‌ها مرتب از يونيکد و به يونيکد تبديل می‌شوند، که برای اين کار از برگ اطلاعات کاراکتر پيش‌فرض سيستم، و يا در مورد فاکس‌پرو، جت و SQL Server، از برگ اطلاعات کاراکتر انتخابی خود استفاده می‌نمايند. واضح است که در چنين سيستمی احتمال بروز خطاهای ناشی از تبديل اطلاعات افزايش می‌يابد.

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

Microsoft Office

نويسنده مشهور ويژوال بيسيک، بروس مک‌کنی، گفته بود: "روزی فرمتهای يونيکد برای فايلهای اطلاعات وجود خواهد داشت، ولی شايد به عمر ما قد ندهد!". عجب اشتباهی می‌کرد! طی سه نسخه اول Office 32 بيتی، تمام برنامه‌های اصلی آن (Word، Excel، Access، و PowerPoint) به فرمت‌های يونيکد فايل و اجرايی‌های يونيکد تغيير سيستم داده‌اند. حتی در دنيای فايلهای متنی (که معمولاً در فرمت ANSI ذخيره می‌شوند)، پيش‌بينی‌هايی صورت گرفته که برگ اطلاعات کاراکتر فايل مربوطه با محدوديتی روبرو نباشد.

به عنوان مثال در نگارش اين کتاب، ويرايش و صفحه‌بندی آن توسط ناشر، از برنامه Word 2000 استفاده شده است. چرا؟ چون در بسياری از موارد می‌خواستم از متون چندزبانه استفاده کنم. نمی‌خواستم ناشر از QuarkXpress که در صنعت نشر و چاپ برنامه بسيار مشهوری است، استفاده کند، چراکه اين برنامه همان محدودتهای بسياری از برنامه‌های ديگر را که مورد بحث قرار دادم، دارا می‌باشد. سالها در مقاله‌هايی که نوشته‌ام با چنين محدوديتهای نرم‌افزاری روبرو بوده‌ام (و برنامه‌های Quark برای اکثر ناشرين به عنوان انتخاب اول شناخته شده است)، اما در اين کتاب برايم مهم بود که برنامه بکار رفته از تمام زبانها بصورت برابر پشتيبانی کند. با استفاده از نسخه 2000 Word قادرم که متنی هندی مانند "आप यहाँ पर क्यों आना चाहते हैं ?" يا متنی تايلندی چون "ทำไมคุณถึงต้องเข้ามาชมเว็บไซต์นี้?" در اين کتاب وارد کنم، بدون اينکه نيازی به گرفتن تصويرهای خاص از صفحه برای هر قطعه از متن داشته باشم. در فصل 10 تحت عنوان "استفاده از منابع ترجمه شده با Satellite DLLs" اين بحث را پيشتر خواهم برد.

اگر فرد کنجکاوی هستيد، می‌توانيد با مراجعه به جدول 6.3 به معنای متون هندی و تايلندی فوق و همچنين معادل اين عبارات به زبانهای ديگری (حتی شايد زبان خودتان!) پی ببريد. اين عبارات برای زبانهای متعددی که در سايت وب trigeminal.com بکار رفته، ترجمه شده‌اند.

جدول 6.3 اينجا رو، تصوير (bitmap) نيست! بيان يک جمله به اشکال متعدد (نمايش توان بالای ناشرم!)

زبان

جمله

هندی

आप यहाँ पर क्यों आना चाहते हैं?

تايلندی

ทำไมคุณถึงต้องเข้ามาชมเว็บไซต์นี้?

بلغاری

или защо Ви трябва да идвате тук?

انگليسی

That is, why would you want to be here?

چينی سادهشده

即你来这儿的目的?

چينی سنتی

即你為什麼要來這裡?

ترکی

örneğin; Neden bu sitede olmayı isteyeceginiz gibi?

آلمانی

d.h. warum lohnt es sich, hier zu sein?

فرانسوی

i.e., pour quelles raisons dé sirez-vous explorer ce site?

يونانی

δηλαδή, γιατί θέλετε να είστε εδώ;

عبری

כלוםר למה בכלל תרצה להיות כאן?

هلندی

d.w.z., waarom wilt u hier zijn?

ژاپنی

すなわち、あなたに必要なもの

سوئدی

m.a.o. vad gör du här?

پرتغالی

porque é que tu queres estar aqui?

روسی

возможно это то, что Вам надо

اسپانيايی

ejemplo, ¿Porqué deseas estar aquí?

ايتاليايی

in altre parole, perché potreste voler visitare queste pagine?

رومانی

cu alte cuvinte, de ce sunteti aici?

تاميلی

ஏன்நீ இஙுகு வரவேண்டு?


ويندوز 2000

ويندوز 2000 که قبل از ورود به بازار با نام NT5 مشهور بود، راه ويندوز NT3.1، 3.51، و 4.0 را ادامه داد. البته ويندوز 2000 پوسته ويندوز 98 را نيز بکار گرفت و به بسياری از مسائل و مشکلات کاربری پاسخ گفت. اما از ديدگاه مسئله جهانی‌سازی، به مدل جهانی برنامه‌های اجرايی نزديکتر شد: رفع اشکالات برنامه‌نويسی (bug) ديگر برای زبانهای مختلف به شکل مجزا ارائه نميشد! ويندوز 2000 با پشتيبانی از سيستم MUI (واسط کاربر چندزبانه) جايگاه خود را بعنوان يک سيستم عامل جهانی تثبيت کرد.

متاسفانه بعضی از نرم‌افزارها (که Internet Information Server نمونه‌ای بارز از آنهاست) در مرحله ANSI متوقف مانده‌اند، ولی به اين نرم‌افزارها نيز خاطرنشان شده است که بايد در چه جهتی پيش بروند: يونيکد.

ويندوز CE

و اما کوچکترين سيستم عامل نيز از مدلی ديگر استفاده کرد: ويندوز CE از يک جهت به COM بيش از هرچيز شبيه است و اين شباهت از آن بابت است که ويندوز CE در سطح توابع API فقط از يونيکد پشتيبانی می‌کند. وليکن از آنجا که تعداد نرم‌افزارهايی که از يونيکد خالص پشتيبانی می‌کنند محدود است، وچون دستگاه‌های کوچک فضای محدودی جهت ذخيره جداول تبديل برگهای اطلاعات کاراکتر در اختيار دارند، نرم‌افزارهای ويندوز CE در عمل در تعداد برگهای اطلاعات کاراکتری که می‌توانند مورد استفاده قرار بدهند با محدوديت روبرو هستند. وليکن واضح است که اين قدم، قدمی در جهت صحيح می‌باشد.

ويژوال بيسيک در دنيای 32 بيتی

و بالاخره به مهمترين ابزار RAD در چارچوب اين کتاب رسيديم: نسخه‌های 32 بيتی ويژوال بيسيک! مسائل بسياری بحث پشتيبانی از يونيکد در ويژوال بيسيک را تحت‌الشعاع قرار می‌دهند: