Hi list,
I'm having trouble with my unicows.dll implementation. I can trace this problem down to forwarding entries not working, but I can't understand why.
I am attaching the diffs for my current unicows patch (not working though it is). I'm trying to run it with a program I wrote. This program is the plain "Hello world" Visual Studio 6 produces when you ask for a Win32 application, with two changes. I changed the link order according to the instructions for using MSLU (http://msdn.microsoft.com/msdnmag/issues/01/10/MSLU/default.aspx), so that the app will use unicows.dll on win98. The second is that I modified the LoadString and DrawText to specifically call LoadStringW and DrawTextW. The application is, otherwise, an ANSI application (only two Unicode functions called).
The resulting app works ok on Windows 2000 and on Windows 98 (the later only when unicows.dll is in the same directory as the application - as it should). When trying to run the app on Wine with os=nt4, or with os=win98 and the native unicows.dll in the same directory as the app, everything works. So far, so good.
Now comes the part things stop to work. First - I couldn't get my DLL overrides to take effect. I tried adding "UNICOWS.DLL"=b, but it wouldn't load my winelib dll over the standard one. I eventually created a symbolic link from a file called "unicows.dll" in the apps' dir to my unicows.dll.so file. That caused my dll to load.
The second had to do with the forwarding call. I generated (using a small perl script) the spec file for the DLL. It forwards all Unicode calls to the relevant Unicode call. Strangely, when the entries for LoadStringW and DrawTextW were pointing to the corresponding calls in user32, the program wouldn't run correctly. When I replaced them with explicit loading of user32.dll and GetProcAddress, everything works (that's the way it's currently in the diff). This suggests, to me, that the spec file is incorrectly set up. Can anyone please point me to my mistake?
Shachar
One more point. You can download the Windows program used to check this (source+exec) from http://shemesh.biz/wine.
Shachar Shemesh wrote:
The second had to do with the forwarding call. I generated (using a small perl script) the spec file for the DLL. It forwards all Unicode calls to the relevant Unicode call. Strangely, when the entries for LoadStringW and DrawTextW were pointing to the corresponding calls in user32, the program wouldn't run correctly. When I replaced them with explicit loading of user32.dll and GetProcAddress, everything works (that's the way it's currently in the diff). This suggests, to me, that the spec file is incorrectly set up. Can anyone please point me to my mistake?
Shachar
"Shachar Shemesh" wine-devel@shemesh.biz wrote:
I'm having trouble with my unicows.dll implementation. I can trace this problem down to forwarding entries not working, but I can't understand why.
Why do you need to add unicows.dll to Wine? That dll is not supposed to be a part of Windows, it's just an addtion provided by an application to circumvent the absence of the unicode APIs on win9x platform, and must be installed by that application.
Dmitry Timoshkov wrote:
"Shachar Shemesh" wine-devel@shemesh.biz wrote:
I'm having trouble with my unicows.dll implementation. I can trace this problem down to forwarding entries not working, but I can't understand why.
Why do you need to add unicows.dll to Wine? That dll is not supposed to be a part of Windows, it's just an addtion provided by an application to circumvent the absence of the unicode APIs on win9x platform, and must be installed by that application.
Because it has bad intereffect on Wine.
I'm not sure where, exactly. Things misbehave (sometimes) with this DLL present. You get Unicode data sent to ANSI functions and other strange stuff.
The thing about this DLL is that it is very easy to implement in Wine (so things will not misbehave). All you have to do is direct all calls to the real Unicode versions already in Wine. I'm just having problems with the fine details of the forwarding mechanism.
Shachar
"Shachar Shemesh" wine-devel@shemesh.biz wrote:
I'm not sure where, exactly. Things misbehave (sometimes) with this DLL present. You get Unicode data sent to ANSI functions and other strange stuff.
The thing about this DLL is that it is very easy to implement in Wine (so things will not misbehave). All you have to do is direct all calls to the real Unicode versions already in Wine. I'm just having problems with the fine details of the forwarding mechanism.
I'd suggest to find and fix the bug in Wine preventing unicows.dll to work. I admit that it might be harder to do than just a workaround you're trying to implement.
-
Dmitry Timoshkov -
Shachar Shemesh