by Michael S. Kaplan, published on 2006/12/27 03:01 -08:00, original URI: http://blogs.msdn.com/michkap/archive/2006/12/27/1368334.aspx
It was over a year ago that Jeff D. asked in the Suggestion Box:
Michael,
What I'd be interested in reading (assuming you haven't already given us one) is a primer on how to go about converting a non-Unicode app to Unicode compliance... for those of us who are starting to "see the light", as it were.
Cheers,
~Jeff D.
P.S.
Forgive me if you've already written an article like this and I simply haven't found it yet.
First, let me say that I hope Jeff is still around and that he wasn't holding his breath waiting for me to answer. :-)
Although I left the question "on the books" for all this time, I was hesitant to post about it because it really seems like a more a tutorial that one might expect and less of a blog topic.
But I kind of thought that the next time I had to take a purely non-Unicode app and convert it to Unicode that it would be cool to perhaps try to start an answer to Jeff's question by covering what was involved, and what I did to minimize the amount of work while maximizing the productivity.
The last app that I had in mind for this idea that I had to do this with (long before Jeff posted his question) was converting the Windows build tool kbdtool.exe to the kbdutool.exe that MSKLC ships and uses. I specifically decided not to write about the kbdtool --> kbdutool conversion though, for a few reasons. First of all, the source for kbdtool.exe doesn't ship in the SDK, so no one could really see the project I did the work on, and second of all, the work was long done and it is easy to forget lots of details that long after the fact.
Plus I didn't want to just do something that wasn't related to what I'm doing.
And finally, I decided if I was ever going to do it I wanted it to be something that might be generally useful for others, too.
Tall order? Definitely.
And then earlier today, a project that fit my criteria pretty much fell in my lap!
In response to a bug that was reported earlier today:
BUG Title: MSKLC 1.4: The bootstrapper, setup.exe, is not Unicode?
Repro Steps:
- Launch MSKLC 1.4
- Customize any key so we can build a keyboard layout
- Point the working directory to a path that contains Unicode only chars like a Hindi char
- Build the keyboard layout
- Launch the created setup.exe
Result: Setup was unable to find the msi package or patch.
Suddenly I had a project to convert -- the SETUP.EXE Bootstrap sample from the Platform SDK that Heath Stewart mentioned a while back!
As a bonus, perhaps one day the Windows Installer folks might want to pick it up and include in the SDK. :-)
Now I realized there are many ways to do this kind of thing in a blog.
I decided to take the approach of a multiple posts that anyone could follow along with if they have the project on their machine.
This is a nice small project (~3500 lines of code or thereabouts) that I can use to show how I approached the idea.
It also has some other cool aspects I'll be able to point out as I go along (and also a few aspects that don't apply here that I will be able to point out as well!).
The actual amount of time it took me for this project gong from A to Zed to a compiling Unicode version that works was two hours and three minutes. But this series will take a bit longer as do it again and take the time to comment on what I am doing each day.
Hopefully everyone will find this a fun and/or useful way to spend some time over the next week or so....
Each day, the sponsoring character will be a random character not found in any Windows code page that would be suitable for step #3 in the repro steps of the bug, given earlier. :-)
This post brought to you by क (U+0915, a.k.a. DEVANAGARI LETTER KA)
# Dean Harding on Wednesday, December 27, 2006 6:03 PM:
> As a bonus, perhaps one day the Windows Installer folks might want
> to pick it up and include in the SDK.
One can only dream! Lets get them to support Unicode in MSI files, first :-)
# Michael S. Kaplan on Wednesday, December 27, 2006 6:45 PM:
Well, getting them to pick up a finished code sample is a whole lot easier than getting them to write a whole new feature into an existing code base....
But that team could use the same principles to do try to the conversion! :-)
# Dean Harding on Wednesday, December 27, 2006 9:40 PM:
Perhaps you could include support for MSLU in the sample, to show them how you can still be living in the 21st century, while at the same time, still supporting Windows 9X?
referenced by
2007/04/14 Rhymes with Amharic (a.k.a. How about a little breakfast embed, dear?)
2007/01/24 Thank Bob that there are no time machines!
2007/01/17 Ungarbling the comments
2007/01/05 Converting a project to Unicode: Part 9 (The project's postpartum postmortem)
2007/01/04 Converting a project to Unicode: Part 8 (Fitting MSLU into the mix)
2007/01/03 Converting a Project to Unicode: Part 7 (What does it mean to fit things to a 'T', anyway?)
2007/01/02 Converting a Project to Unicode: Part 6 (Upon the road not traveled)
2007/01/01 Converting a Project to Unicode: Part 5 (Are we there yet? Well, not *just* yet)
2006/12/31 Converting a Project to Unicode: Part 4 (It's /Delightful, it's /Delicious, it's /DUnicode!)
2006/12/30 Converting a project to Unicode: Part 3 (Can I quote you on that?)
2006/12/28 Converting a project to Unicode: Part 1 (Business before pleasure)