The Peters continued: > > What, not even a product whose only functions are to convert between > > Unicode encoding forms? > > OK; I guess I misunderstood the question you were asking. I see now that > it's "Can a given product correctly perform all of its functions > (whatever those might be) for all characters in a given version of > Unicode?" Sure, there will be combinations of products and versions of > Unicode for which that will be true. Character Map is probably one such > example. > > But if the product is an OS, I'm pretty sure there will not be any.
And I think this illustrates one of the difficulties that plagues such questions in the software industry today. What is "a product"? And what is "a system"? These notions used to be much simpler when computers used to all be discrete, OS's were much smaller and more primitive, and software applications were either small and single-function, or were massive, custom-developed applications for mainframes. Nowadays, everything is massive, multi-tiered, distributed, and interdependent. "Product" definitions are often constructed by marketing teams playing component legos, rather than being based on some kind of standalone executable piece of software. In these contexts, what constitutes "Unicode support" can get lost in the forest. Conceptually, it is a little like asking the question, "Does the Internet support Unicode, Version X.X?" As Peter [C] has indicated, if you properly narrow down your concept of what a "product" is and what "support" for Unicode it has, in some meaningful subset of what support might mean, then you can get to a well-formed question that might have an unambiguous yes/no answer. Whether an *answerable* question of this sort is then actually interesting for the person who was inquiring in the first place, is itself another question. For example, I develop a Unicode library that I am *positive* has full Unicode support for all characters for all versions of Unicode (and all future versions) for its basic string copy and length operations. But I doubt that answer will be of much real interest. When you move on to more meaningful questions such as does it support default casing for all Unicode characters, then I have to start hedging the answer carefully with which particular version of Unicode, which particular version of the library, and which date. And applications which build on the library have such dependencies built in, without it necessarily being obvious to all the developers using the library and certainly not to the end users of the distributed software that might be visible to them. --Ken