A common problem encountered occurs when some update packages or uninstall programs rename or delete either of the OLE libraries (OLEACC.DLL, OLEDLG.DLL), which are dependencies of UNICOWS.DLL.[5] This results in some applications, such as OpenOffice.org, showing an error with the message "Application cannot start because one of the required libraries cannot be found." This occurs even if UNICOWS.DLL is installed in the system, as it cannot start without its dependencies (see also DLL hell).
MSLU was designed to be a translation layer for Windows NT-based Unicode APIs on Windows 9x. The layer, however, is not a complete rewrite of Windows 9x, nor is it some type of Windows NT emulator for the Windows 9x platform. It does not provide support for Unicode-only scripts like Devanagari or Georgian, or for any of the new supplementary characters that have been added to Unicode (specifically UTF-16) as surrogate pairs. It also cannot provide extended international support beyond the platform that it runs on, since it is relying on the operating system for any particular international functionality that developers may want to provide. For example, MSLU does not provide updated versions of the cp_*nls files that contain support for code pages, nor does it add support on Windows 95 for GetLocalInfo LCTypes for which the operating system has no specific information. Instead, developers should consider MSLU as one part of a whole package of international or Unicode-focused components provided by Microsoft. These components include RichEdit, which provides rich text support and can also be used for more comprehensive support with plain text. Windows common controls provide a standard way to implement many commonly used interface components. Uniscribe allows the support and rendering of complex scripts (writing systems that need additional processing prior to display, such as Arabic, Devanagari, and Thai). GDI+ extends Uniscribe to provide easier developer integration and more consistent rendering for mixed scripts. MLang provides many features such as character encoding, string conversion, and font linking support, and the Text Services Framework (TSF) provides a common framework for text input and natural language technologies. Since all of these components have a Unicode solution, MSLU does not attempt to provide overlapping functionality. With the use of these other components, you can go a step beyond MSLU's support for Unicode and handle multilingual input, processing, and rendering, so that applications can go beyond the codepage-based support provided by Windows 9x. For more information on these other technologies, what versions to use, and how to implement and deploy them, go to the MSDN Online homepage.
Microsoft Layer For Unicode Unicowsdll Cannot Be Found
Let's examine these steps and the reasons for them, one at a time. Perform step 1 to determine that the OS version of the API is not found. This is critical, since the OS version of the call will usually fail, or at best not use the appropriate MSLU behavior. Technically, you can remove libraries from the list that you are not using, but it is important to realize that other LIB files (like those for MFC or ATL) use APIs, and you do not want them to pick up APIs from anything other than unicows.lib. It is therefore safer to include all of them. Step 2 should require no explanation. Step 3 will allow MSLU to find the APIs it needs (after all, it often needs to call the OS after it has done its work to convert strings). It will also allow all of the other APIs that MSLU does not wrap to be found by your application. As in step 1, you can remove libraries from this list if you do not use them, but it is safer to include them all, unless you are sure that neither you nor any of your dependent libraries will ever need them. Experienced developers who feel comfortable with the internals of the linker can devise other ways to proceed here; there are many options. These three steps represent the best practices. If you follow them exactly and never try to insert any LIB files in between them, then the MSLU integration will work properly. If linking is not implemented properly, some APIs will fail and some will succeed, resulting in a very unstable situation in which your application will not work properly. Thus, it is exceptionally important to implement these steps correctly. Of course, it is not necessarily easy to diagnose the exact problem. Many tools can be used to determine what functions are imported from each DLL. For example, you can use DumpBin (DUMPBIN.EXE) with the /IMPORTS flag set, or Dependency Walker (DEPENDS.EXE). The problem for MSLU is that neither method recognizes the custom loader, so the result of integrating MSLU will be that all Unicode APIs will appear to have vanished from the list of functions. This does, however, make an interesting way to determine if you have integrated MSLU properly. The trick is to ensure that none of the layer-provided APIs show up. It is not a perfect solution, but it is relatively easy to spot the difference.
The memory for step 1 is usually allocated on the stack, since that is both faster and easier. Cleanup is automatic when the function returns. In order to provide maximum safety, the function does a quick probe to make sure that there is enough memory available on the stack (thus attempting to avoid stack overflow exceptions). The actual cost of this probe is just an extra 12 CPU instructions, so it is very inexpensive; however, if the probe fails and MSLU has to clean up the stack, this obviously will take a bit longer to complete. The very first build of unicows.dll was an automatically generated version that simply performed these three steps. From the beginning, however, it was clear that a lot more work needed to be done, since there were many exceptions to this simple plan. The first exception relates to the times that CP_ACP (the system default code page) is not the code page used to do the conversion. The OS is often expecting that the strings will not be based on the default system code page, but rather on some other code page, corresponding to a locale parameter, the character set of a device context, or the file system settings (as represented by the AreFileApisANSI API). MSLU's careful adherence to the way the OS handles these cases allows it to provide a limited form of support for non-CP_ACP applications (basically, any time the OS supports it, MSLU supports it, too). An example of this is GetLocaleInfo, which converts string parameters using the code page corresponding to the default system code page of the locale parameter. MSLU handles a large number of exceptions. In fact, from over 400 APIs in this category, only a little more than half of them can be described so simply; the rest of the exception cases require some further special handling. Some of these exception cases relate to enumeration functions such as EnumDateFormats, which often do not take string parameters, but instead return them to a user-provided callback function. Other APIs provide specific bug fixes or behavior to emulate the Windows NT platform, which had been provided by one or more of those other 32 layers. An example of this is GetWindowTextLength, whose "A" version never promises to give an exact length on DBCS systems, but whose "W" version does. Other APIs cannot be wrapped at all. The IsBadStringPtr API is a good example, since its job is to test whether the passed-in parameter is a valid string. Converting to call the "A" version will just test the string that MSLU created. If the memory was bad, MSLU would crash trying to convert it, so obviously conversion is not needed or wanted. Yet other APIs needed a lot of extra work in order to properly function. For example, a lot of work had to go into making sure that a call to our CreateWindowExW would create a "faux-Unicode" window. This would be a window that is seen as a Unicode window by MSLU, even though the operating system is quite certain it is not a Unicode window. Every time the "W" APIs were reexamined during the development process, we found more exceptions, resulting in almost 200 cases that defied simple classification. As a result, a great deal of thought went into each API by the time MSLU was ready to ship. You could almost say that every API had a story!Unicode functionality Nothing is ever simple, and it quickly became clear that there were quite a few APIs relating to Unicode support that do not have a suffix. For example, IsWindowUnicode is an API that a caller would reasonably expect to return TRUE if MSLU's CreateWindowExW created the window. Not all examples were quite this straightforward. The DDE functions have parameters that specify CP_WINUNICODE or CP_WINANSI and expect string parameters to match whatever that parameter is. MSLU had to wrap functions such as these in order to do the things that a Unicode application would expect them to do.APIs that enhance user messaging support Although there are only a few functions that relate to user messaging that do not have a "W" suffix, it was important for MSLU to wrap them. This provides a consistent user messaging story for "mixed" applications that expect to work properly with both Unicode and ANSI windows and window procedures. In order to handle this, we had to wrap many functions such as CallWindowProcA and SetWindowLongA to provide that consistency. This particular category of APIs did force us to skirt that line of "no new functionality" a few times, but it seemed important to provide at least the same level of support for the "A" and "W" mix of these functions as Windows NT does, in order to allow applications to work properly.APIs that fix bugs other layers have addressed Of course, this category ended up being one of the most controversial ones, since it clearly provides new functionality, which is contrary to one of the core design criteria of MSLU. However, if you keep in mind that one of the other design goals of MSLU was to become a layer that internal groups at Microsoft would use for their Unicode support, it was important to pick up their bug fixes (otherwise they would have no real impetus to consider the change). The most well-known of these API fixes are the many bugs that exist in GDI functions on Windows 9x, which were vigorously addressed by Microsoft Office in the Office 95 days. These became so well-known that many external developers noticed (and used) the functions in mso97.dll and mso9.dll with names like MsoExtTextOutW and MsoGetCharWidthW. Since there was already code written for the vast majority of these cases, it made sense to pick up a few APIs in this category. The changes were already well-tested and would be needed in order to promote adoption of MSLU within Microsoft. 2ff7e9595c
留言