A bit about the 'Single World Wide Binary'

by Michael S. Kaplan, published on 2006/05/01 03:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2006/05/01/587340.aspx


I had an old friend/colleague and semi-regular reader of the blog who asked me this weekend how I could have possibly done over 1000 posts before seriously even mentioning the SWWB (Single World Wide Binary) model this last Friday.

Just lucky, I told her. :-)

In truth, it is a term that I hate. Like i18N, the spoken form of the nickname is simply way too long. And as a feature name it seems to lie on its face, talking about single anything when referring to an operating system that probably contains more files in it than the population of the largest city in Idaho.

But the concept is one that I like, so perhaps my distate for the name is something I will just have to get over....

The idea behind SWWB is best thought of at the level of a simple application, such as Notepad, the single most known app in all of Windows.

The principle is simple -- let there be one core version of all of the basic code, used worldwide. What is added later is all of the localized resources, in separate, pluggable modules.

Some people like to call it the Language Neutral model instead of SWWB, though nobody seems to have come up with a short name using it though. It describes the same concept -- the idea that the core code will not contain language-specific elements that are added later in individual markets. This makes a sharp contrast to the older "throw code over the fence" model, where developers in Japan or wherever would modify the project for their market. The Language Neutral model has many advantages to it, such as:

And so on.

Which is not to say Windows started this way. In fact, it is fair to say that it is a project whose roots are firmly planted in the "throw code over the fence" model.

I shudder to think about how much money has been spent to finally (in Vista) be approaching SWWB -- enough to make a CFO shudder and want to go back in time to fire whatever CFO didn't push for SWWB back when things were first getting started.

This is really why issues like the language SKU-specific nature of DEFAULT_GUI_FONT bother me as much as they do. Because by violating the principles of a Language Neutral core, they force people who are testing functionality to have to look at other language SKUs.

And even worse, the exact nature of the functionality differences between language SKUs is much more difficult to describe and/or document.

I guess we need a list for Vista -- "language natural except for ___________", where the blank would be filled in with the list of items like this?

Of course, other complications arise, though they will be the subject of future posts. :-)

 

This post brought to you by "" (U+0f4f, a.k.a. TIBTAN LETTER TA)


# Rosyna on 1 May 2006 3:40 AM:

Mac OS X achieves this by using a "package" format for applications and loadable plugins/frameworks. A package is just a folder with an extension in most cases that is treated as a single file but the GUI. It's also nice because the localizable resources or plain text files. So any "fan" of a product can create a localized version and send the resources for inclusion in future versions. Many smaller software companies (like Unsanity) use this to their advantage.

# Rosyna on 1 May 2006 3:43 AM:

Good lord, that contained a lot of typos.. but the GUI==by the GUI. or plain==are plain.

# Gabe on 2 May 2006 4:28 AM:

Unfortunately, localizing involves a whole lot more work than just translating some text. Changing text may require changes to the layout of controls or dialog boxes.

Some localizations may require specifying the correct fonts (particularly for Far East languages). Some may require different icons (some icons contain text or things that don't make sense in all cultures, like Excel's "$" icon to set the currency style on a cell), and some controls or buttons may not belong in every localization. Some may require minor algorithmic changes (like if you have a clever piece of code to generate numbers like 1st, 2nd, 3rd, and just put 'th' after 4-20, then 21st, 22nd, 23rd, etc.; this algorithm is specific to English). Some may require major algorithmic changes, like allowing people to work in other calendars and date systems.

Some localizations may require major changes to the structure of your program, to allow for things like right-to-left text (like Hebrew and Arabic) or top-to-bottom text (like Chinese and Japanese).  Some features just can't be localized, as the English concept of a spell checker doesn't make sense in Chinese for example.

# Adam on 3 May 2006 9:18 AM:

Yup, that's pretty confusing.

When I first read "Single World Wide Binary", I thought you'd figured out how to write some kind of binary polyglot[0] that would run on multiple OSs and system architectures. e.g. Win32/x86, MacOSX/PPC, MacOSX/x86, .NET, Sparc, etc...

(In fact, if you got a single, couple-of-hundred-byte, machine code polyglot that could run on multiple arches and then jump to arbitrary locations in the file based on which arch it was actually running on, you'd be mostly there. The rest of the file could then basically be an uncompressed zip (tar file) with separate code for each arch. Hmm.....)

"Language Neutral" is a *much* better description.

"World Wide Binary" is very reminiscent of "World Wide Web". For some of us, "World Wide" means more than being geographically neutral; it also means being *device* neutral. Win32/x86 is not the only platform out there.


[0] http://www.nyx.net/~gthompso/poly/polyglot.htm
(Particularly http://www.nyx.net/~gthompso/poly/polyglot.txt)

Please consider a donation to keep this archive running, maintained and free of advertising.
Donate €20 or more to receive an offline copy of the whole archive including all images.

go to newer or older post, or back to index or month or day