Re:sucks to be a guy named Torvalds right now...
on
Linux Kernel Bugs
·
· Score: 1
We released updated kernels yesterday:
A 2.4 kernel [redhat.com], for Red Hat Linux 7.1
A 2.2 kernel [redhat.com], for Red Hat Linux 6.2 and 7
It would have been nice if you also updated the list of 6.2 Security Advisories. At the moment (1:15 PM Pacific) the latest updated on there is the Netscape one back from April 10. It would have saved me (and probably many others) time poking around this morning trying to guess if it was updated for this exploit or not.
Oops. Don't think I specifically addressed these points:
Finally, just because COM objects only accept BSTRs doesn't make them Unicode...
Well... COM/ActiveX _is_ the API. As long as that is used, it doesn't matter what's on the back-end... VB, Java, C, C++... And the API is purely Unicode. So COM is Unicode. Implementations might do things differently on the back end, but that doesn't change the programming contract.
their coclass implementation can still be ANSI (probably translating all incoming and outgoing strings).
And if that were the case, sticking with the approach you suggest would make the problem worse. For every single time you'd call into COM, you'd first convert your ANSI [using Microsoft's questionable terminology] data to Unicode and make a new BSTR. Then you'd feed it through COM. Then the back-end would reverse that transformation and process data in ANSI. It would then have to convert from ANSI back to Unicode to make a new BSTR to pass back to you. Then you'd convert that BSTR from Unicode back into ANSI for further processing on your side. Whew!
On the other hand, your data was kept in Unicode, then your program would cut in half all the conversions on your data per call into COM. And if you happened to call something that did implement it's code in Unicode (like any of the components from Office), then you'd end up with zero conversions per COM call.
If you go with 100% Unicode under Windows, every system call will have to be intercepted, and translated if you're on Win9x.
That's right. Of course, you can go ANSI like most Windows apps, and when it runs on NT, 2K and XP every single API call will get the data translated... So you'd be hit by that problem on one of the two platforms.
However, ever since Office 97, this is exactly what Microsoft has been doing with it's entire office suite. And it's been well worth it for them
The person in charge of all Office development gave a good presentation on all this at the 13th Unicode conference. So... if it's good enough for Microsoft's flagship product...
You say build two different binaries, one for Win9x, and one for NT... how do you propose doing that without using the TCHAR.H stuff? Maintain two separate sets of code?
You missed my point. I was saying that if you use #define UNICODE and TCHAR, then you will need to build two separate binaries. And quadruple your testing, QA, etc.
My point is that because separate binaries is just not a good idea, one should avoid TCHAR, et al.
The TCHAR stuff isn't just for legacy Win3.1 people, it also for all Win9x OSes too.
Well... kinda. It's for MFC. Besides, if you aren't building two different binaries, then you're just typing in a bunch of unneeded NOOPs. If you are only ever building a Win9X/ME version of a program, and never need to compile a NT build, then you have no need for TCHAR at all.
Finally, just because COM objects only accept BSTRs doesn't make them Unicode... their coclass implementation can still be ANSI (probably translating all incoming and outgoing strings).
Well, it could be. But then again, it might not. And so you'd need to convert your string data in Win9x programs at some point. You could choose to do it when you get input from an old-school Win32 API call, or you could choose to do it before feeding into the new-school COM/ActiveX call. The more programs get to COM/ActiveX/whatever, the more you'll be translating.
So, given that it has to occur somewhere, doing it before it gets into your program is more and more of a good thing. (Remember, however, that I pointed out that MFC is a different thing, but I don't think MFC is all that great either).
There's another aspect to "going Unicode" that should be brought up, and it has a strong bearing on the business case for doing so.
It's not just for 'going international' ("We're not going to be selling in Europe, so don't bother"), or even for multilingual ("We don't care if the Spanish-speaking market in the US is big, stick to English"). It's also for cross-platform support.
Western versions of MS Windows uses CodePage 1252, which is close enough to Latin-1 for most marketing types. However, Macs use (suprise, suprise) MacRoman, and the upper half of the character set is wildly differnt. Go Unicode, and any servers or applications can easily support Windows, Linux, Unix and Macintosh data. And especially with Mac OS X being how it is, suddenly you have an extra market in the US to sell into.
You first have to examine carfully the chracter set your current application can deal with. Is it ASCII? Or just the printable range? Or do most routines treat everything as sequences of 8-bit characters? Is the null character permitted in data? And so on.
This is a key point. Is the person sure that their data is all ASCII? Often people confuse "ASCII" with "8-bit text" and get burned. Most common is calling data "ASCII" when it's really "Latin-1" or "Windows CodePage 1252". Others thinking of similar problems should be careful about getting terms correct. Remember, if the data has any values outside of the 0 through 127 range (more than 7-bit, more than 128 values), then it's not "ASCII".
Also, if you can represent languages other than US English, Latin, Hawaiian and Swahili, then chances are good that you have something other than "ASCII" data.
Just in case any of this work is being done on Microsoft Windows, you should avoid "#define UNICODE", TCHAR, and _T(). These are mainly legacy tricks used to help Windows 3.1 developers cross-compile their code for NT. Microsoft themselves doesn't use them, and insted goes with pure Unicode through the app. Even COM in Win32 since the first release of Windows 95 is all Unicode (BSTRs).
Of course, this would preclude you from using MFC, but then again, many think that avoiding it is a good thing (again, Microsoft is among those who avoid using it). But aside from other benefits, you'd end up with not needing to build two separate binaries: one for Windows NT/2K and one for Win9X.
Oh, and one other thing. If you are doing any portable code, remember that the Microsoft documentation lies and that wchar_t is not always 16-bit like they say. In fact, the spec recomends that it be 32-bit, and most other platforms (Linux included) define it thus.
IBM's ICU is a good place to look. It's based on research originally from Taligent. The transliteration and message formatting capabilities might be of special interest, and the site might be a good jumping-off point.
The International Components for Unicode(ICU) is a C and C++ library that provides robust and full-featured Unicode support on a wide variety of platforms. The library provides:
When I mentioned that you would not program a complex model (i'm thinking along the line of the chick from Final Fantasy, or even just the SIGGRAPH teakettle, anything more complex than several boxes and triangles and quads) using code I was bringing up the use of tools. You would not use a sharpened stone to cut something if you had a knife lying around. You would not use a stone to drive a nail when there is a hammer, would you? Of course not.
Well, for a Female, I might use 3DS or some other tool. For the Utah teapot, however, I could whip it out more quickly in code. Same for just about anything archetectural or mechanical. Even some biological things I can code things quite well. Anything that has interconnecting parts is also quite easy. It's amazing how well tentacles can be modeled and animated in code. My point is that for many things, coding is the hammer, and WYSIWYG is the stone.
You can do anything with command line that you can do with GUI. BUT, with CLI or line by line programming you can't design other GUIs as nicely. You can still do it, piece of cake... but to make a really good GUI with standard programming, takes a LOT of time and a LOT of effort.
Well, since you use "You", I can answer directly that you are incorrect. I personally can whip out Java GUI apps much more quickly and with much better functionality than with using a GUI tool to do so. For many other people it's the same. Especially with Java and it's layout managers, your GUI is much more that "stick a button this big over here". It's quite easy to program a UI that will scale up to the needed component sizes, even if you change the language on the fly (or just on startup). On the other hand, internationalization is a pain in VB and such.
With a tool like Visual Basic(ugh! VB sucks!) your GUIs and forms are easy to design and manipulate. You can make the same forms and GUIs with C++ or Java but it will take you longer, it's much harder to do complex things and lots of times your design will LOOK awkward.
Again, for me I personally can make professionall looking UI's quite quickly in Java with pure code. Plus my code is smaller, faster, and has fewer bugs. And as far as complex, when was the last time you had a UI change from English to French or Japanese with no problems at all?
You wouldn't make a complex 3d model of anything programming polygons... you could.
Actually.... I could. Depending on the subject matter, for many 3D models I can get something nicer done more quickly by 'coding' it directly in POV-Ray script. This of course depends on the subject matter, but just because one person finds one way faster doesn't mean that another person won't be faster a different way. Just sometimes I'd go with 3DS or Strata, other's I'd just code by hand. And sometimes I'd write a custom C program to make the model. It just all depends.
And just in case it's a factor, I've programmed multimedia products before for many platforms, and have done 3D artist work for Interplay.
This is probably a major question to get answered first. For example, Emacs with JDE for doing Java work has just about everything VJ++ has (except for a WYSIWYG UI editor that only creates layouts for the proprietary MS Windows only classes). It has menus, integrated debugging, tags support, speedbar...
So, what is this person pushing as a "GUI" tool? One specifically, or many?
Also, given what Emacs does and looks like (except for those pretty buttons on the toolbars), does it count as a CLI tool or as a GUI tool? The line is often blurred, but I know of many people who in discussions vehemently deny that Emacs is an IDE of any form.
But what you are speaking of is more 'graphic design' than 'user interface'. There's a lot more to it than just pretty pixels, and that functionality is what she mentions.
When I'm playing a game, I want to be immersed in a virtual world. When I'm writing, or designing graphics for a Web site, or pounding out code, or looking for information on some obscure subject, I want a clean, simple interface that makes it as easy as possible for me to get, create, or manipulate my data. And that's it.
I'd have to disagree and say that the basic principle is the same. When I'm playing a game (Myth II for example), I want to focus on paying attention to the health of my units, where I want to get them to go, and not have to worry about the mechanics of actually achieving it. When I'm writing a document, I want to focus on my train of thought, what I'm trying to say, etc. and not have to worry about the mechanics of using the word processor. Different paradigm, but same UI goal.
I would say that many games I've played seem to have gotten this down well. Perhaps it's because of the focus where they know that no player is going to actually bother reading the manual, and the developers need to keep in mind the needs of a novice user just sitting down at the program for the first time.
The game 'tutorial' intro level and the wavy green lines in Word: both good steps along this path.
Well, I thought it was an OK interview, just a little light. And the main gist of her UI comments were more towards feature presentation and interaction, not graphic design and artwork (as other posters have taken it).
Beauty and the Beast, Titan AE, I can think of a lot more scenes but I can't remember what shows they were from.
Suprisingly enough, The Rugrats Movie was one of these. I was quite suprised at how well it was integrated. Of course, having done some 3D work for an early game, I keep an eye on this kind of thing.
WTF? Did everyone forget that there have already been MANY people who've spent more time than this in space?
And that's exactly where the article mentions the information comes from. Those cosmonauts exhibited signs of osteoporosis (Or rather, loss ten times faster than osteoporosis). Combine that with a year of almost 1/3-g between 6 month stints of zero-g, and that on the average the bones of women are less dense than the men to begin with and you end up with an issue that must be considered.
Also, at the moment Valeri Polyakov's record of 14 months in space still stands. Not that much more than 12 months, and he definitely didn't have that extra year of low-g in between.
last i checked, mars had gravity... then again, I haven't been there in a while...
Yes... but if you read the story you might notice that it mentions a mission with one year of zero-g. That's pretty much 6 months out and then 6 months back.
Read the story. Among other things, a two-year Mars mission including one year of zero-g (6 months there and 6 months back... that back part is also important) would be enough to cause permanent tooth loss.
And the story also mentions those same people you cite.
In Castillian Spanish, 'ch' and 'll' are characters that require two glyphs to print. However, for alphabetization purposes, 'ch' and 'll' are distinct characters
Well, in general this is what should occur. If it does not, then it is because the national standards for those languages had already been treating them as two separate characters, with two encoding points.
For compatibility with pre-existing standards, there are characters that are equivalently represented either as sequences of code points or as a single code point called a composite character. For example, the i with 2 dots in naïve could be presented either as i + diaeresis (0069 0308) or as the composite character i + diaeresis (00EF).
That's were Unicode bends from pure idealism to practical matters. They'd preffer to have one char, but if Spain is already using two characters for 'ch', then the Unicode consortium would obey their practice.
simple-minded comparison routines that compare character codes report erroneous comparison values because they doesn't realize that 'cg'
Of course, the same goes for any Unicode sorting. No Unicode sorting can be assumed to work based just on the character values. That's why all software libraries that allow for sorting Unicode have functions for the programmer to use, based on the language/locale in effect.
Sorry, but this is simply not true. Sort order is not handled by embedded encodings; the ONLY way to handle it is to go to Unicode.
Sorry, but that is simply not true. Unicode does nothing really to help sort-order. US-ASCII English is about the only thing that can use Unicode ordering for sorting. Any other language needs to go through some other mechanism to achieve ording. In your example that would be either an explicit Chinese ordering routine or an explicit Japanese ording routine. But those could take EUC, for example, instead of Unicode.
So, calling Unicode "the ONLY way" to handle sorting is just incorrect.
Think, I could have a Kanji followed by Arabic letters in Unicode, but when is that useful? hardly ever.
Well, it turns out that your view is not shared by the extensive research Microsoft for one has undertaken. They did a lot of research in this field since more than 40% of their Office revenue came from overseas. One interesting thing they found is that people who did use more than one language tended to actually mix two or three main languages per document.
All this is part of why Microsoft for some time had been changing Office internally and had made it all Unicode internally by Office 97.
If there is a need for multiple languages, it is always possible to use "<>" tags, right? Multiple character encodings will always exist, so for each text character encodings must be specified somehow anyway.
Yes, multiple languages but not necesarily multiple encodings. In fact many programs have problems with multiple encodings in one document. I know as a software engineer that doing so is one nightmare I'd like to avoid at all costs.
And on windows one does not have to specify text encodings at all. Since Windows 3.1 their fonts have used Unicode mapping tables internally. And COM (and thus ActiveX) on Windows is pure Unicode for all it's strings. So there is no need to change away for COM work or display.
1. Unicode fonts on X suck. 2. Netscape on X blows up trying to read a page with Unicode fonts. 3. Netscape on Windows does the same.
Then don't use them. I've been reading Japanese and Chinese on the net for years (or rather 'viewing', since I'm not fluent in the languages themselves). You don't need to have Unicode fonts, just install Chinese fonts for Chinese pages, Japanese fonts for japanese pages, and have something inteligent to build them up.
Java has used the idea of composite fonts since the get-go. Netscape also does 'Psuedo Fonts'. I forget about MSIE, since I don't use it much as all. In fact, I'm sitting here now in Netscape under X and instead of a 'suck'y Unicode font, Unicode encoded characters are getting displayed by a NSPseudoFont.
3. Netscape on Windows does the same
You should look more into details of your problem. Here's a possibly shocking bit of news for ya: Since Windows 3.1, Windows fonts have used and preferred Unicode mapping. So it's extremely unlikely that a font being Unicode in and of itself is causing Netscape any problems on Windows.
Slashdot Mirror
It would have been nice if you also updated the list of 6.2 Security Advisories. At the moment (1:15 PM Pacific) the latest updated on there is the Netscape one back from April 10. It would have saved me (and probably many others) time poking around this morning trying to guess if it was updated for this exploit or not.
Oops. Don't think I specifically addressed these points:
Well... COM/ActiveX _is_ the API. As long as that is used, it doesn't matter what's on the back-end... VB, Java, C, C++... And the API is purely Unicode. So COM is Unicode. Implementations might do things differently on the back end, but that doesn't change the programming contract.
And if that were the case, sticking with the approach you suggest would make the problem worse. For every single time you'd call into COM, you'd first convert your ANSI [using Microsoft's questionable terminology] data to Unicode and make a new BSTR. Then you'd feed it through COM. Then the back-end would reverse that transformation and process data in ANSI. It would then have to convert from ANSI back to Unicode to make a new BSTR to pass back to you. Then you'd convert that BSTR from Unicode back into ANSI for further processing on your side. Whew!
On the other hand, your data was kept in Unicode, then your program would cut in half all the conversions on your data per call into COM. And if you happened to call something that did implement it's code in Unicode (like any of the components from Office), then you'd end up with zero conversions per COM call.
That's right. Of course, you can go ANSI like most Windows apps, and when it runs on NT, 2K and XP every single API call will get the data translated... So you'd be hit by that problem on one of the two platforms.
However, ever since Office 97, this is exactly what Microsoft has been doing with it's entire office suite. And it's been well worth it for them The person in charge of all Office development gave a good presentation on all this at the 13th Unicode conference. So... if it's good enough for Microsoft's flagship product...
You missed my point. I was saying that if you use #define UNICODE and TCHAR, then you will need to build two separate binaries. And quadruple your testing, QA, etc.
My point is that because separate binaries is just not a good idea, one should avoid TCHAR, et al.
Well... kinda. It's for MFC. Besides, if you aren't building two different binaries, then you're just typing in a bunch of unneeded NOOPs. If you are only ever building a Win9X/ME version of a program, and never need to compile a NT build, then you have no need for TCHAR at all. Well, it could be. But then again, it might not. And so you'd need to convert your string data in Win9x programs at some point. You could choose to do it when you get input from an old-school Win32 API call, or you could choose to do it before feeding into the new-school COM/ActiveX call. The more programs get to COM/ActiveX/whatever, the more you'll be translating.So, given that it has to occur somewhere, doing it before it gets into your program is more and more of a good thing. (Remember, however, that I pointed out that MFC is a different thing, but I don't think MFC is all that great either).
There's another aspect to "going Unicode" that should be brought up, and it has a strong bearing on the business case for doing so.
It's not just for 'going international' ("We're not going to be selling in Europe, so don't bother"), or even for multilingual ("We don't care if the Spanish-speaking market in the US is big, stick to English"). It's also for cross-platform support.
Western versions of MS Windows uses CodePage 1252, which is close enough to Latin-1 for most marketing types. However, Macs use (suprise, suprise) MacRoman, and the upper half of the character set is wildly differnt. Go Unicode, and any servers or applications can easily support Windows, Linux, Unix and Macintosh data. And especially with Mac OS X being how it is, suddenly you have an extra market in the US to sell into.
This is a key point. Is the person sure that their data is all ASCII? Often people confuse "ASCII" with "8-bit text" and get burned. Most common is calling data "ASCII" when it's really "Latin-1" or "Windows CodePage 1252". Others thinking of similar problems should be careful about getting terms correct. Remember, if the data has any values outside of the 0 through 127 range (more than 7-bit, more than 128 values), then it's not "ASCII".
Also, if you can represent languages other than US English, Latin, Hawaiian and Swahili, then chances are good that you have something other than "ASCII" data.
Just in case any of this work is being done on Microsoft Windows, you should avoid "#define UNICODE", TCHAR, and _T(). These are mainly legacy tricks used to help Windows 3.1 developers cross-compile their code for NT. Microsoft themselves doesn't use them, and insted goes with pure Unicode through the app. Even COM in Win32 since the first release of Windows 95 is all Unicode (BSTRs).
Of course, this would preclude you from using MFC, but then again, many think that avoiding it is a good thing (again, Microsoft is among those who avoid using it). But aside from other benefits, you'd end up with not needing to build two separate binaries: one for Windows NT/2K and one for Win9X.
Oh, and one other thing. If you are doing any portable code, remember that the Microsoft documentation lies and that wchar_t is not always 16-bit like they say. In fact, the spec recomends that it be 32-bit, and most other platforms (Linux included) define it thus.
Well, for a Female, I might use 3DS or some other tool. For the Utah teapot, however, I could whip it out more quickly in code. Same for just about anything archetectural or mechanical. Even some biological things I can code things quite well. Anything that has interconnecting parts is also quite easy. It's amazing how well tentacles can be modeled and animated in code. My point is that for many things, coding is the hammer, and WYSIWYG is the stone.
Well, since you use "You", I can answer directly that you are incorrect. I personally can whip out Java GUI apps much more quickly and with much better functionality than with using a GUI tool to do so. For many other people it's the same. Especially with Java and it's layout managers, your GUI is much more that "stick a button this big over here". It's quite easy to program a UI that will scale up to the needed component sizes, even if you change the language on the fly (or just on startup). On the other hand, internationalization is a pain in VB and such.
Again, for me I personally can make professionall looking UI's quite quickly in Java with pure code. Plus my code is smaller, faster, and has fewer bugs. And as far as complex, when was the last time you had a UI change from English to French or Japanese with no problems at all?
Actually.... I could. Depending on the subject matter, for many 3D models I can get something nicer done more quickly by 'coding' it directly in POV-Ray script. This of course depends on the subject matter, but just because one person finds one way faster doesn't mean that another person won't be faster a different way. Just sometimes I'd go with 3DS or Strata, other's I'd just code by hand. And sometimes I'd write a custom C program to make the model. It just all depends.
And just in case it's a factor, I've programmed multimedia products before for many platforms, and have done 3D artist work for Interplay.
This is probably a major question to get answered first. For example, Emacs with JDE for doing Java work has just about everything VJ++ has (except for a WYSIWYG UI editor that only creates layouts for the proprietary MS Windows only classes). It has menus, integrated debugging, tags support, speedbar...
So, what is this person pushing as a "GUI" tool? One specifically, or many?
Also, given what Emacs does and looks like (except for those pretty buttons on the toolbars), does it count as a CLI tool or as a GUI tool? The line is often blurred, but I know of many people who in discussions vehemently deny that Emacs is an IDE of any form.
But what you are speaking of is more 'graphic design' than 'user interface'. There's a lot more to it than just pretty pixels, and that functionality is what she mentions.
Good post, but...
I'd have to disagree and say that the basic principle is the same. When I'm playing a game (Myth II for example), I want to focus on paying attention to the health of my units, where I want to get them to go, and not have to worry about the mechanics of actually achieving it. When I'm writing a document, I want to focus on my train of thought, what I'm trying to say, etc. and not have to worry about the mechanics of using the word processor. Different paradigm, but same UI goal.
I would say that many games I've played seem to have gotten this down well. Perhaps it's because of the focus where they know that no player is going to actually bother reading the manual, and the developers need to keep in mind the needs of a novice user just sitting down at the program for the first time.
The game 'tutorial' intro level and the wavy green lines in Word: both good steps along this path.
Well, I thought it was an OK interview, just a little light. And the main gist of her UI comments were more towards feature presentation and interaction, not graphic design and artwork (as other posters have taken it).
Suprisingly enough, The Rugrats Movie was one of these. I was quite suprised at how well it was integrated. Of course, having done some 3D work for an early game, I keep an eye on this kind of thing.
And that's exactly where the article mentions the information comes from. Those cosmonauts exhibited signs of osteoporosis (Or rather, loss ten times faster than osteoporosis). Combine that with a year of almost 1/3-g between 6 month stints of zero-g, and that on the average the bones of women are less dense than the men to begin with and you end up with an issue that must be considered.
Also, at the moment Valeri Polyakov's record of 14 months in space still stands. Not that much more than 12 months, and he definitely didn't have that extra year of low-g in between.
Good one. But seriously, as opposed to the bone loss:
Yes... but if you read the story you might notice that it mentions a mission with one year of zero-g. That's pretty much 6 months out and then 6 months back.
And the story also mentions those same people you cite.
I'm now hit with that 'compression filter' problem.... how to get the info out there seems to be the question.... Ah. good. this ramble fixed it.
Yes, Microsoft bought Bungie, but the Myth franchise made it to the escape pods.
Well, in general this is what should occur. If it does not, then it is because the national standards for those languages had already been treating them as two separate characters, with two encoding points.
http://www.unicode.org/unicode/standard/where/
Says:
That's were Unicode bends from pure idealism to practical matters. They'd preffer to have one char, but if Spain is already using two characters for 'ch', then the Unicode consortium would obey their practice.
Of course, the same goes for any Unicode sorting. No Unicode sorting can be assumed to work based just on the character values. That's why all software libraries that allow for sorting Unicode have functions for the programmer to use, based on the language/locale in effect.
Well... close. But for Asian languages it might only increase it by 150%, not 200% (i.e. 3 bytes per character instead of 2).
:-)
Sorry, but that is simply not true. Unicode does nothing really to help sort-order. US-ASCII English is about the only thing that can use Unicode ordering for sorting. Any other language needs to go through some other mechanism to achieve ording. In your example that would be either an explicit Chinese ordering routine or an explicit Japanese ording routine. But those could take EUC, for example, instead of Unicode.
So, calling Unicode "the ONLY way" to handle sorting is just incorrect.
Well, it turns out that your view is not shared by the extensive research Microsoft for one has undertaken. They did a lot of research in this field since more than 40% of their Office revenue came from overseas. One interesting thing they found is that people who did use more than one language tended to actually mix two or three main languages per document.
All this is part of why Microsoft for some time had been changing Office internally and had made it all Unicode internally by Office 97.
Yes, multiple languages but not necesarily multiple encodings. In fact many programs have problems with multiple encodings in one document. I know as a software engineer that doing so is one nightmare I'd like to avoid at all costs.
And on windows one does not have to specify text encodings at all. Since Windows 3.1 their fonts have used Unicode mapping tables internally. And COM (and thus ActiveX) on Windows is pure Unicode for all it's strings. So there is no need to change away for COM work or display.
Then don't use them. I've been reading Japanese and Chinese on the net for years (or rather 'viewing', since I'm not fluent in the languages themselves). You don't need to have Unicode fonts, just install Chinese fonts for Chinese pages, Japanese fonts for japanese pages, and have something inteligent to build them up.
Java has used the idea of composite fonts since the get-go. Netscape also does 'Psuedo Fonts'. I forget about MSIE, since I don't use it much as all. In fact, I'm sitting here now in Netscape under X and instead of a 'suck'y Unicode font, Unicode encoded characters are getting displayed by a NSPseudoFont.
You should look more into details of your problem. Here's a possibly shocking bit of news for ya: Since Windows 3.1, Windows fonts have used and preferred Unicode mapping. So it's extremely unlikely that a font being Unicode in and of itself is causing Netscape any problems on Windows.