Unicode Across Windows

1
UnicodeAcrossWindows

• Michael S. KaplanTrigeminal Software, Inc.
• Cathy A. WissinkMicrosoft

2
Why Unicode in your application?

• World wide EXE
• Decrease localization costs
• Superior multilingual support
• Better integration with the NT platform
• Support for new languages on Windows 2000,
  Windows XP, and beyond

3
Why not Unicode in your apps?(note that none of
these are true any more some were never true!)

• One code page at a time is enough, right?
• Every major language has at least one version of
  Windows which supports it
• Visual Studio does not support Unicode
• There is no support for Unicode when you are on
  Win95/98/ME

4
The old workarounds

• Build two versions of the application
• Multiple code bases or build types to maintain
• Larger downloads/setups
• Harder to isolate problems in code
• Always do ANSI applications
• No multilingual support
• Poorer performance on NT platforms
• No support for Unicode only languages
• Create your own layer (based on the 4/99 MSJ
  article from Microsoft)
• http//www.microsoft.com/msj/0499/multilangUnicode
  /multilangunicode.htm
• A lot of work required!

5
Bumps in the road

• Microsoft assumed that the migration to NT would
  happen more quickly and that ISVs would make that
  happen
• Developers needed to support the consumer
  applications
• Microsoft did not have a consistent Unicode story
  for all platforms (and needed one)
• Something had to give....

6

• The Microsoft Layer for Unicode on Windows
  95/98/ME Systems

7
What is MSLU?

• The MICROSOFT Layer for Unicode on Windows
  95/98/ME Systems
• file name UnicoWS.dll
• Allows you to write a single Unicode application
  for all platforms

8
Design goals for MSLU

• Cannot slow down Unicode applications on
  WinNT/Win2K/WinXP
• When possible, provide a consistent, identical
  Unicode subset of the Win32 API across all
  platforms
• Based on the Millennium API set
• Supports Win95/98 also
• Allow developers to take advantage of the new
  languages on Windows 2000 and Windows XP without
  abandoning older platforms

9
Other design goals

• As small as possible
• Dll is 160kb
• Has over 440 API wrappers
• Has more than 40 "stub" wrappers
• Frugal with resources
• No registration required
• No dependencies
• No special file location requirement
• No inherent "DLL hell" issues
• Cannot be put in the system directory!

10
Performance

• No slowdown at all on WinNT/2K/XP
• No extra DLL load
• Native APIs called directly
• Minimal slowdown on Win95/98/ME
• Need time to convert strings to ANSI
• For functions with out params, need to convert
  strings to Unicode

11
MSLU's custom loader

• No Virginia, you cannot do a true static link
• Your application statically links to the loader
• The loader works in a similar way to the
  /DELAYLOAD functionality in VC
• Should work with other C compilers, too
• Supports the ability to override any API but get
  all the benefits of the loader!
• No fear of failure
• DLL not present
• Low memory scenarios

12
Agenda

• What is Unicode?
• Why Unicode in your application?
• Introducing the MS Layer for Unicode
• Integration of the layer
• Covered APIs and functionality
• What the layer is not
• What about Visual Studio.Net?
• Where to get MSLU

13
Integration of the layer

• Just add UnicoWS.lib to the link list, and you
  are done!
• 1) Add it after static libraries like the CRT
• 2) Add it before all of the libraries that it
  uses (such as kernel32.lib and shell32.lib)
• Making sense of the rules
• The linker resolves references Left to Right
• When it reaches the end, it wraps around
• uafxcw.lib libcmt.lib unicows.lib kernel32.lib
  gdi32.lib user32.lib oleaut32.lib oledlg.lib
  shell32.lib comdlg32.lib advapi32.lib winspool.lib

14
How the DLL is loaded

• Setting an override
• Add a function that you use to load the DLL
• "Set the hook" by adding this line
• extern "C" HMODULE (__stdcall _PfnLoadUnicows)
  (void) LoadUnicows
• Good place to handle failure
• Default behavior LoadLibrary!
• Fallback to the shared location if you must (not
  preferred at all)
• When all else fails, fail APIs gracefully!

15
Overriding individual APIs

• Add your function (using the same signature as
  the Win32 header files define)
• "Set the hook" with this line of code
• extern "C" FARPROC Unicows_ltapigtW
  (FARPROC)ltyour functiongt
• Overriding "stubbed out" APIs
• The new PSDK will have notes for every API --
  including any special issues, when needed

16
Detecting when APIs are wrapped properly

• Current technologies do not support MSLU
• Dependency Walker (DEPENDS.EXE)
• DUMPBIN.EXE /IMPORTS
• Using these methods anyway to determine what is
  linked and what is not

17
Loading your own "unicows.dll"

• How LoadLibrary works for loaded DLLs
• If DLL of the same name is already loaded,
  LoadLibrary uses that DLL
• How to stay independent of others
• Rename unicows.dll
• Use the loader override to load the DLL

18
Integration samples

• Taking a few samples from the PSDK
• Showing off a customer integration or two

19
Agenda

• What is Unicode?
• Why Unicode in your application?
• Introducing the MS Layer for Unicode
• Integration of the layer
• Covered APIs and functionality
• What the layer is not
• What about Visual Studio.Net?
• Where to get MSLU

20
Covered APIs and functionality - 1

• Wraps almost every "W" Win32 API
• The few that are not wrapped are ones that
  already support Unicode, such as the IME APIs
• Stubs you can override are present for APIs not
  explicitly supported
• Wraps several non "W" APIs when needed for
  Unicode support
• Unicode support (e.g., IsWindowUnicode)
• Consistent user messaging (e.g., CallWindowProcA)
• Common, known issues (e.g., ExtTextOutW)

21
Covered APIs and functionality - 2

• User messaging support
• Similar to NT's user messaging support for ANSI
  applications
• Threadsafe
• Can handle multithreaded applications properly

22
Covered APIs and functionality - 3(Playing well
with the other children)

• Works properly with the Unicode versions of MFC,
  ATL, and the CRT in both VS 6.0 and VS 7.0
• Interoperability with other MSLU clients
• in process
• out of process
• Interoperability with non-Unicode applications

23
Agenda

• What is Unicode?
• Why Unicode in your application?
• Introducing the MS Layer for Unicode
• Integration of the layer
• Covered APIs and functionality
• What the layer is not
• What about Visual Studio.Net?
• Where to get MSLU

24
What the layer is not

• Not a rewrite of the Win9x platform
• No NT-specific functionality added
• No "Unicode-only" language support
• No supplementary character support
• No new international support
• No new functionality added, at all
• Not an "NT emulator" for Windows 95!
• Not a layer over components that are still
  shipping new versions

25
Other components, other solutions

• RichEdit
• 2.0 Unicode support
• 3.0 Bidirectional support
• 4.0 Supplementary character support
• Windows Common Controls (comctl32.dll)
• 5.80 full Unicode support
• Uniscribe/GDI
• MLang
• Common Language Runtime (CLR)
• System.Globalization namespace
• System.Text namespace's encoding support

26
Agenda

• What is Unicode?
• Why Unicode in your application?
• Introducing the MS Layer for Unicode
• Integration of the layer
• Covered APIs and functionality
• What the layer is not
• What about Visual Studio.Net?
• Where to get MSLU

27
What about Visual Studio.Net?

• VS.NET should include the newest Platform SDK
  unicows.lib is in there!
• CLR languages like VB.NET, C, and MC have
  their own delayload solution
• PInvoke does not support calling different
  libraries on different platforms
• Do not call MSLU on NT platforms!
• You will have the same runtime issue with PInvoke
  in your MC code

28
C.NET syntax

• using System
• using System.Text
• using System.Runtime.InteropServices
• public class SystemAPI
• DllImport("kernel32")
• private static extern uint GetVersion()
• DllImport("kernel32", EntryPoint"GetSystemDi
  rectoryW", CharSetCharSet.Unicode)
• private static extern uint OsGetSystemDirector
  yW(StringBuilder lpBuf, uint uSize)
• DllImport("unicows.dll", EntryPoint"GetSyste
  mDirectoryW", CharSetCharSet.Unicode)
• private static extern uint MsluGetSystemDirect
  oryW(StringBuilder lpBuf, uint uSize)
• public static uint GetSystemDirectory(StringBu
  ilder lpBuf, uint uSize)
• if(GetVersion() lt 0x80000000)
• return(OsGetSystemDirectoryW(lpBuf,
  uSize))
• else

29
VB.NET syntax

• Imports System
• Imports System.Text
• Imports System.Runtime.InteropServices
• Public Class SystemAPI
• Declare Function GetVersion Lib "kernel32" ()
  As Integer
• Declare Unicode Function OsGetSystemDirectoryW
  Lib "kernel32" Alias "GetSystemDirectoryW" _
• (ByVal lpBuf As StringBuilder, ByVal uSize
  As Integer) As Integer
• Declare Unicode Function MsluGetSystemDirector
  yW Lib "unicows.dll" Alias "GetSystemDirectoryW"
  _
• (ByVal lpBuf As StringBuilder, ByVal uSize
  As Integer) As Integer
• Public Function GetSystemDirectory(ByVal
  lpBuf As StringBuilder, ByVal uSize As Integer)
  As Integer
• If (GetVersion() gt H80000000) Then
• GetSystemDirectory
  OsGetSystemDirectoryW(lpBuf, uSize)
• Else
• GetSystemDirectory
  MsluGetSystemDirectoryW(lpBuf, uSize)
• End If
• End Function

30
Agenda

• What is Unicode?
• Why Unicode in your application?
• Introducing the MS Layer for Unicode
• Integration of the layer
• Covered APIs and functionality
• What the layer is not
• What about Visual Studio.Net?
• Where to get MSLU

31
Where to get MSLU

• the .LIB ships in the Platform SDK!
• http//www.microsoft.com/msdownload/platformsdk/se
  tuplauncher.asp
• The DLL is a redistributable component
• http//www.microsoft.com/msdownload/platformsdk/se
  tuplauncher.asp
• (it will be somewhere up there, not sure where
  yet!)

32
Questions?
33
Don't Forget Your Evals!

• The Microsoft Layer for Unicode on Windows
  95/98/ME Systems