Title: RE: MS Windows and Unicode 4.0 ?

A few corrections to your version of history below +++

Chris Pratley

Group Program Manager,

Microsoft Word, Publisher, OneNote

_____________________________________________
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Philippe Verdy
Sent: December 2, 2003 5:03 AM
To: Michael (michka) Kaplan
Cc: [EMAIL PROTECTED]icode.Org
Subject: RE: MS Windows and Unicode 4.0 ?

Michael (michka) Kaplan writes:

> I know I'll end up regretting this....

Why do you regret it? I know that you work for Microsoft, but I don't think you can imply things that Microsoft has not claimed to have done in its systems.

> From: "Philippe Verdy" <[EMAIL PROTECTED]>

>

> > That far? So why isn't there correct support of UTF-16 on Windows

> > 95OSR2, 98, 98SE and ME (notably for their FAT32 filesystem)? I can

> > understand it for Windows 95 and 95OSR1 as they were designed before,

> > and may be also for the 95OSR2 version despite it was published in

> > late 1997, one year after UTF-16 was published.

>

> If you have programmed on Win9x for any length of time then you know the

> answer to this and it is simply a straw man to ask why such support was

> not done. Its the fundamental nature of what that system does and it

> would require a rewrite to support Unicode -- in fact, it did require a

> rewrite (called NT).

NT4 predates Windows 95, and offered a whole set of Unicode APIs.

You can't say that NT is a rewrite of Windows 95, as it is simply the reverse:

Windows 95 was built to integrate the Win32 Unicode APIs of NT, and ease the compatibility of programs written for NT4 environment. That's why it contains the MultiByteToWideChar() and WideCharToMultiByte() functions which are used to convert between Unicode (in fact only UTF-16 in Windows 95) and other SBCS or DBCS encodings (in fact only the OEMCP and ANSICP codepages for the localized version of the system in  Windows 95).

+++Win95 was created to be a successor to Win3.1 and to support Win32 APIs. It was not created with a purpose of supporting *Unicode* (Wide) Win32 APIs that NT supported. Win 3.x and Win9x are code-page based internally, and by definition, Unicode support would be limited to what could be converted to a code page.

+++The few Unicode APIs that exist in Win9x are there because certain individuals inside Microsoft insisted that they be put in, notably a few people in Windows and the Word team, who knew that if the OS shipped with zero Unicode support, it would be really hard to build any kind of Unicode app in the future. The seven APIs that did get implemented (even in their original buggy state) were enough to make it reasonable for Office97 core apps to become full Unicode apps internally.

+++You are correct that NT was not a rewrite of Win9x. It was instead a rewrite of the whole family of Windows that was based on DOS. Thats why the project was called OS/2 initially, then abandoned and redone as NT more or less as you describe. MichKas phrasing was a shorthand for this whole process. NT was a rewrite of Windows (of course, that is unfair to NT rewrite implies it was redone to the same specs. In fact NT was entirely different and only later was support for the Win 3.x (later 9x) GUI and Win32 APIs grafted on. The Win32 APIs themselves did a kind of roundtrip through NT. They started life as Win16 on Win 3.x (and before), then went to NT where they became Win32 because NT was 32 bit and implemented internally as Unicode, which prompted the NT team to simply provide direct (and faster) access as W APIs (there were few people at that time who would consider building this imaginary thing called a Unicode app so the W APIs were sort of academic, for completeness. Then they were back-ported to Win3.x using the Win32s library/thunking layer, and finally implemented natively in Win9x, but without the W versions in large part since these were still considered by most to be an academic thing. There was even a version of Office for NT 3.1/3.5x that was based on Office 4.3 (Word 6, Excel 5, etc.) but was 32 bit, non-Unicode, and ran natively on NT. This later became the basis for Office95, which was the 32 bit Office that was released with Win95 still not Unicode. Finally Office97, which was started at the same time as Office95 but continued for almost three years, shipped the first set of Unicode apps designed for NT but which could run using a shim on Win9x, using its very limited W API support, which if you remember was jammed in near the end of the Win9x project by the aforementioned Unicode enthusiasts inside Microsoft.

Of course the kernel of Windows 95 is basically the same as Windows for Workgroup 3.11, including for its drivers (but Windows 95 innovated in its new Plug&Play architecture with simpler drivers, a technology that was later retrofitted in Windows 2000, or integrated after full debugging as I'm quite sure that it was developped to be later compatible and integrable in the NT kernel).

The FAT32 filesystem (or more precisely the support of UTF-16 encoded LFN) was also new in Windows 95: it should have integrated approximately the same file naming conventions as in NT4, without needing the integration of the NTFS filesystem in Windows 95. Full support for FAT32 was later integrated in Windows 2000.

If you want to say that NT is a rewrite, you must speak about NT 3.0 which was rewritten from the Windows 3.1+MSDOS 6 base (in parallel with Windows for WorkGroup 3.11 which was, despite its minor version number, a really _major_ evolution from Windows 3.1 and has been _much_ more innovative than Windows 95 for the kernel part as WfW already integrated support for multiple VMs), and to integrate kernel features found in Unix, MVS and VMS systems. The origin of NT is a split from the development project of OS/2 initiated by IBM and initially written jointly between IBM and Microsoft.

Microsoft had to rewrite all in NT when he decided to exit the OS/2 joint project, to leave the legacy dependance with IBM in the MSDOS kernel system (adapted to multitasking in OS/2 using the VM concept which was possible starting with the Intel 80286 processor, and experimented in some "enhanced multitasking DOS" systems).

The kernel support of "wide chars" (even if it was still not named Unicode) was already a developement target in OS/2, and it's quite normal that it was also integrated in NT when "wide chars" became synonymous of UCS-2 in Windows NT kernel.


__________________________________________________________________

<< ella for Spam Control >> has removed Spam messages and set aside Newsletters for me

You can use it too - and it's FREE!  http://www.ellaforspam.com

Reply via email to