Text item:
Mark,
You are correct in saying that secondary apps need to be in Unicode. But as a
developer of such secondary apps on Win95/WinNT, I find it frustrating that the
sdk forces you to go to either MBCS or UNICODE at compile time. That means you
need two exes to support each platform completely and lose Microsoft Windows
logo(requires one exe for both platforms), or use MBCS on both and Unicode is
out the door, which is the solution I had to implement for the Intel LANDesk
management products. But then, I am back to square one, codepage encoded data.
As a secondary solution, I tried to only implement the inventory database in
Unicode and transfer between 95/NT console and managed clients in Unicode, but
Microsoft will not provide conversion apis for older platforms, nor will Novell
support 3.x NLM Unicode conversion apis, and when they do provide APIs, they do
not work well with each other. So one has to redo their work and deal with the
conversion differences and its impact on the OS when other products use OS
specific conversions to interact with your product or you with theirs. And it
is not like you can find vendors offering api conversions spaning whole platform
sets easily. Only Oracle does it within their products. I don't know that they
offer an off-the-shelf sdk for developers to use as a standalone api outside of
their database products though. Oracle is sending Michael Kung (and Jianping
Yang) to give a presentation at the 10th Unicode conference in Germany
concerning this very subject. Should be interesting.
Is it that difficult to put those tables and apis in with the sdk? If the source
was also present, it would guarantee conformity with their plaftform Unicode
implementation, and allow real-life software to work with Unicode across
platforms.
The irony is that some of these companies will spend millions of dollars
developing and trying to convince software developers and users alike to use
their internet browsers and tools, sometimes free of charge, but they won't part
with something as insignificant as a Unicode api set that would make software
development across platforms using Unicode an easier goal to reach.
While it is not the purpose of this consortium to dictate/require/request
companies to support Unicode for set platforms, I believe it should promote
further compatibility and consistency in this area by producing a Unicode API
definition with enough implementation detail to facilitate round-trip
conversions across diverse implementations. In particular, the area of default
choice should be strengthened.
Compiler companies could then at least synch up on api naming, parameter types,
and be more compatible with each other. The Unicode Standard 2.0 chapter 5 is a
good start, but more is needed. I am sure, lots of discussions have already
occurred, and, should that be my luck, something may already be in the works.
Boy, this was a mouthful :).
-Grard
Gerard_Cattin@ccm.ut.intel.com
Internationalization Architect,
LANDesk Products, Intel Corporation
p.s. This view is not representative of Intel, just mine.
______________________________ Reply Separator _________________________________
Subject: Re: Should I laugh or cry?
Author: unicode@Unicode.ORG at SMTPGATE
Date: 12/17/96 11:59 AM
unicode@Unicode.ORG wrote:
>
> I've just received this from a colleague ...
>
> Misha
>
> ---
>
> >Misha
> >
> >fyi - it's a shame Brussels' software evidently does not support
> >Unicode. I don't know if you have heard, but a European Commissioner is
> >going to sit at a terminal today(?) to answer questions on line via the
> >Internet. Questions can be in any language except Greek because "the
> >Internet software can not support it".
> >
> >Phil
In the next 6 months we should see:
- the next generation of browers (Internet Explorer 4.0 & Navigator 4.0)
being Unicode-enabled (UTF-8). (They have both committed to this.)
- Java 1.1 having much more support for Unicode.
Given that, the problem you describe should be gone within the next
year. The concrete steps that I think we can all take to help further
this process are to evangealize secondary products to be
Unicode-enabled:
- the web authoring tools (PageMill, HomePage, FrontPage,...).
- the web search engines (Lycos, Excite, AltaVista, WebCrawler,
HotBot...).
...
I can't see that the current situation is cause for crying!
Mark
Text item: External Message Header
The following mail header is for administrative use
and may be ignored unless there are problems.
***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.
To: unicode@Unicode.ORG
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0
Subject: Re: Should I laugh or cry?
Errors-To: uni-bounce@Unicode.ORG
Reply-To: Mark Davis <mark_davis@taligent.com>
Message-Id: <9612171959.AA00933@Unicode.ORG>
Date: Tue, 17 Dec 96 11:59:49 -0800
Received: by Unicode.ORG (NX5.67c/NX3.0M)
id AA00933; Tue, 17 Dec 96 11:59:49 -0800
Received: from Unicode.ORG (unicode.org [192.195.185.2]) by ormail.intel.com (8.
8.4/8.7.3) with SMTP id MAA04809 for <gerard_cattin@ccm.ut.intel.com>; Tue, 17 D
ec 1996 12:03:24 -0800 (PST)
From: unicode@Unicode.ORG
Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by relay.jf.i
ntel.com (8.8.2/8.7.3) with ESMTP id MAA22855 for <gerard_cattin@ccm.ut.intel.co
m>; Tue, 17 Dec 1996 12:41:03 -0800 (PST)
Return-Path: unicode@Unicode.ORG
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:33 EDT