Keep off the grass

by Michael S. Kaplan, published on 2006/02/22 16:20 -05:00, original URI:

Well, at the very least keep MSLU apps out of the VMWare shared folders? :-)

The other day, Brian asked in the microsoft.public.platformsdk.mslayerforunicode newsgroup:

I have a strange situation, seemingly involving MSLU on VMWare.

First, let me say that I have a fully unicode enabled program, using MSLU to run on 95, 98, and NT.  It works well on all platforms, including Japanese, Chinese, and Korean 98, ME, and all versions of 2k and XP.  I can display unicode characters in titles, menus, dialogs, and everywhere else needed, so I believe my application is built and linked correctly.

Now, with that said, here is my problem...

I am running a Windows XP VM as a guest OS in VMWare 5.5, with XP also as the host OS.  My app runs fine if I run it from the desktop or a local folder in VMWare, but if I run my app from a shared folder in VMWare, I get garbled strings.  It took me a while, but I've traced this down to MSLU.  It seems that when running under a shared folder, my LoadUnicowsProc() function is called, the unicows.dll is loaded, and from then on, MSLU is trying to translate strings, with disasterous results.  Symptoms range from garbage in strings to truncated window titles similer to one reported in this post:

My understanding is that Unicows  DLL should never have to be loaded on XP.  I wonder what the difference is here?  I use VMWare all the time, with excellent results even on Win95, 98, ME.  Without the source to the MSLU Loader, it's a bit difficult to figure out why it would be trying to load the DLL in this situation.

Does anyone (MichKa)  have even Pseudo-code for what the loader is looking for before loading the DLL?  I imagine it's at least calling GetVersion() or GetVersionEx(), both of which seem to be returning the proper values.

The problem goes away when I do the following:

  1. Copy the exe from the shared folder to the local machine.
  2. Simply remove Unicows.lib from the link list and recompile

I've even replicated the problem in a scaled-down program containing only a WinMain.  Let me know if you're interested in seeing it.

Any suggestions would be appreciated.

My response was of course grounded in Tester's Axiom #1, and said:

VMWare compatibility testing is not a scenario we ever covered, so of course there could be bugs (and it appears there are?).

The workaround -- keep apps out of the shared folder....

Brian did then respond back with more information, including info from the VMWare folks:

That would be fine, as my program is normally installed under "program files", except that the same problem occurs when a document is opened (by double-clicking in explorer) from the shared folder.  The application, because of it's association with the document extension, starts up but its working directory is the shared folder and the problem still exists.

So, now the workaround is: don't put programs or documents in the shared folder.  So, what's the shared folder for anyway!!

I brought this up here because it is unclear to me which piece is broken.  There's obviously an undesirable interaction between VMWare and MSLU, and considering the popularity of both, it seems someone would be interested in fixing this.  I just don't know who.  I'm not sure how interested Microsoft would be to work with VMWare on a resolution.  Looking at the VMWare forums, there are loads of similar issues, with symptoms in other apps that are identical to my own problems (running programs, opening documents).  However, nowhere did I see anyone else track it down to an interaction with MSLU.

I opened the same issue with VMWare and got this response:

Dear Brian,

We are currently tracking this issue in Vmware Bug # 60617. I have added your comments to the bug and we will be in touch with you if we need any additional information. Unfortunately there is no current workaround or fix for this issue except to avoid using the shared folder as a working directory. You will be notified if there are any updates or workarounds for this issue.

Anyway, I just thought I'd bring it up.  I know MSLU does some tricky stuff behind the scenes.  Obviously, something it is doing is giving VMWare fits.

Now we actually went through a few iterations on methods to do this detection, which happens in both unicows.lib (the MSLU loader, used by C/C++ applications) and unicows.dll (MSLU, used directly by applications like VB that cannot use the loader).

(In this case, Brian is using an MSLU loader override, which means he is using unicows.lib. Getting the latest version of the .LIB may be helpful here, but of course knowing which version of the .LIB is being used is also a good idea)

There is no compatibility issue where a mismatch between .LIB version and .DLL version could cause problems, other than if one of the bugs that caused us to change methods came up, but that is kind of expected, I think. There is a benfit to using the latest version, as usual.

We also has the benefit of being produced by the Windows team within the Windows source tree, which gave us a lot of chances to see all of the good and bad ways that people tried to do this very thing in their own programs, both inside the Windows source and from many reports of applications inside and outside of MS....

Anyway, some more detail about MSLU....

A long time ago, MSLU used GetVersion to do its version checking. However, the ability added to XP that allows you to run an application as if it were a different version was able to raise a pretty huge set of problems.

So it became important to look for a way to detect the version that was not quite so subject to being changed by the whim of someone intentionally asking the OS to lie about its own version.

After all, only MSLU should be allowed to lie for MSLU apps, right? :-)

At this point, the Microsoft Layer for Unicode is itself in maintenance mode. So there is not a high chance that the .DLL will be able to be modified to fix such a problem. There is a bit more flexibility on the .LIB file, but more info would be needed from VMWare to be able to consider proceeding in such a direction....


This post brought to you by "±" (U+00b1, a.k.a. PLUS-MINUS SIGN)

# Mihai on 23 Feb 2006 2:30 AM:

<<After all, only MSLU should be allowed to lie for MSLU apps, right?>>

No! The user should always be the final master!

If an application developed with MSLU by a company that died 1 year ago refuses to work on Vista (or Win XP SP3 :-), I should have the power to lie.

And, in general, I hate any software that thinks it knows better than me.

# Ben Cooke on 23 Feb 2006 3:34 AM:

Serifs and Italics at a small size == ick! I had to zoom to 200% to read it!

# Michael S. Kaplan on 23 Feb 2006 3:57 AM:

Hi Mihai --

Sorry, but MSLU has to have the final say here -- because running it under NT and pretending to be 9x, it is impossible to make things work. Running that way *is* suicide for a process, and suicide is simply not a scenario we have ever supported with MSLU....

# Mihai on 23 Feb 2006 4:40 AM:

An application committing suicide if you lie to her :-)
This is a funny thought :-)

(PS: "her" is not a mistake. In most Latin languages "application" is feminin :-)

Yuhong Bao on 21 Sep 2010 5:24 PM:

Lying as a NT version will not be a problem, only lying as a 9x version will cause problems.

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