Keep off the grass

by Michael S. Kaplan, published on 2006/02/22 16:20 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2006/02/22/537269.aspx

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:

http://groups.google.com/group/microsoft.public.platformsdk.mslayerforunicode/browse_thread/thread/97e1f5b8fe16617d/246a7f1e2e2cc65a?q=vmware&rnum=2#246a7f1e2e2cc65a

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.

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:

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

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

# Mihai on 23 Feb 2006 4:40 AM:

Yuhong Bao on 21 Sep 2010 5:24 PM:

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