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