This mornings CVS of wine breaks Lotus Notes 5.0.11 This is the message I get from wine-dbg Unhandled exception: unimplemented function user32.dll.SendIMEMessageExA called in 32-bit code (0x40afb052). In 32-bit mode. 0x40afb052 (__wine_unimplemented+0x52 [user32.spec.c:42] in user32.dll.so): jmp0x40afb04c (__wine_unimplemented+0x4c [user32.spec.c:42] in user32.dll.so) 50 void __wine_stub_user32_dll_14(void) { __wine_unimplemented("BlockInput"); } Kevin
"Kevin" == Kevin DeKorte <kdekorte(a)yahoo.com> writes:
Kevin> This mornings CVS of wine breaks Lotus Notes 5.0.11 This is the Kevin> message I get from wine-dbg Kevin> Unhandled exception: unimplemented function Kevin> user32.dll.SendIMEMessageExA called in 32-bit code (0x40afb052). Kevin> In 32-bit mode. 0x40afb052 (__wine_unimplemented+0x52 Kevin> [user32.spec.c:42] in user32.dll.so): jmp0x40afb04c Kevin> (__wine_unimplemented+0x4c [user32.spec.c:42] in user32.dll.so) Kevin> 50 void __wine_stub_user32_dll_14(void) { Kevin> __wine_unimplemented("BlockInput"); } Are you sure you didn't change anything else? I doubt that wine itself will call the unimplemented function SendIMEMessageExA. So either your Notes setup/native dll setup changed or wine was fixed in some way that another codepath is taken now that calls SendIMEMessageExA. Perhaps try to find out where SendIMEMessageExA is called. depends.exe moght be of help/. Anyways: SendIMEMessageExA seems undocumented: Peace, another Win compatibility approach http://chiharu.hauN.org/peace has /* * Old IME API? */ EXTERN_C LRESULT WINAPI SendIMEMessageExA(HWND p1, LPARAM p2) { ADP("SendIMEMessageExA [not implemented]"); /* XXX */ return TRUE; } as stub implementation. Do you know how to integrate this in wine? If not, tell me to send you a patch for testing. It might however be that Notes _needs_ this function working or otherwise needed functions will not work. We have to see. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
Uwe, Nope did not change anything, and in fact I rolled back to Wine 5/1/2003 and Notes works again. Kevin On Monday 05 May 2003 11:27 am, Uwe Bonnes wrote:
"Kevin" == Kevin DeKorte <kdekorte(a)yahoo.com> writes:
Kevin> This mornings CVS of wine breaks Lotus Notes 5.0.11 This is the Kevin> message I get from wine-dbg
Kevin> Unhandled exception: unimplemented function Kevin> user32.dll.SendIMEMessageExA called in 32-bit code (0x40afb052). Kevin> In 32-bit mode. 0x40afb052 (__wine_unimplemented+0x52 Kevin> [user32.spec.c:42] in user32.dll.so): jmp0x40afb04c Kevin> (__wine_unimplemented+0x4c [user32.spec.c:42] in user32.dll.so) Kevin> 50 void __wine_stub_user32_dll_14(void) { Kevin> __wine_unimplemented("BlockInput"); }
Are you sure you didn't change anything else? I doubt that wine itself will call the unimplemented function SendIMEMessageExA. So either your Notes setup/native dll setup changed or wine was fixed in some way that another codepath is taken now that calls SendIMEMessageExA. Perhaps try to find out where SendIMEMessageExA is called. depends.exe moght be of help/.
Anyways: SendIMEMessageExA seems undocumented: Peace, another Win compatibility approach http://chiharu.hauN.org/peace
has /* * Old IME API? */ EXTERN_C LRESULT WINAPI SendIMEMessageExA(HWND p1, LPARAM p2) { ADP("SendIMEMessageExA [not implemented]"); /* XXX */ return TRUE; }
as stub implementation. Do you know how to integrate this in wine? If not, tell me to send you a patch for testing.
It might however be that Notes _needs_ this function working or otherwise needed functions will not work. We have to see.
Bye
"Kevin" == Kevin DeKorte <kdekorte(a)yahoo.com> writes:
Kevin> Uwe, Nope did not change anything, and in fact I rolled back to Kevin> Wine 5/1/2003 and Notes works again. Any chance that you try the approaches I mentioned? Kevin> On Monday 05 May 2003 11:27 am, Uwe Bonnes wrote: Kevin> ... Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
Uve, look at http://www.winehq.com/hypermail/wine-cvs/2003/05/0005.html. (03/05/02) This patch adds user32.dll.SendIMEMessageExA as a stub in user32.spec.
Any chance that you try the approaches I mentioned?
Kevin> On Monday 05 May 2003 11:27 am, Uwe Bonnes wrote: Kevin> ... Bye
===== Sylvain Petreolle (spetreolle at users dot sourceforge dot net) ICQ #170597259 No more War ! "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". For the Law of Oil and Fire, Im an European that lives in France. For all my Brothers and friends, Im a human living on Earth. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
"Sylvain" == Sylvain Petreolle <spetreolle(a)yahoo.fr> writes:
Sylvain> Uve, look at Sylvain> http://www.winehq.com/hypermail/wine-cvs/2003/05/0005.html. Sylvain> (03/05/02) This patch adds user32.dll.SendIMEMessageExA as a Sylvain> stub in user32.spec. Oh. Probably the function is called via GetProcAddress. If the function is not listed in our spec file, GetProcAdress will fail. If it is listed, GetProcAddress will succeed and when the prgram jumps to that address, a crash will happen. This makes me wonder if we should not return Failure toe GetProcAddress if a stub-only function is requested. Investigating... Bye PS: Uve->Uwe and please no 3 mails ( to the list, to me and to me as CC) -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
Im curious to see what adress GetProcAdress gets when asked for a stub.
Probably the function is called via GetProcAddress. If the function is not listed in our spec file, GetProcAdress will fail. If it is listed, GetProcAddress will succeed and when the prgram jumps to that address, a crash will happen.
Look at the recipients you sent your mail : De: "Uwe Bonnes" <bon(a)elektron.ikp.physik.tu-darmstadt.de> | Ce mail est un spam | Ajouter au carnet d'adresses À: "Kevin DeKorte" <kdekorte(a)yahoo.com> CC: "Uwe Bonnes" <bon(a)elektron.ikp.physik.tu-darmstadt.de>, "wine-devel(a)winehq.com" <wine-devel(a)winehq.com> It comes from you, is sent to wine-devel and to you. Hitting reply to all sent my reply to you (as sender) and you + wine-devel as CC.
PS: Uve->Uwe and please no 3 mails ( to the list, to me and to me as CC)
Argh silly me! Writing "Uve" after 7 years of german :) ===== Sylvain Petreolle (spetreolle at users dot sourceforge dot net) ICQ #170597259 No more War ! "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". For the Law of Oil and Fire, Im an European that lives in France. For all my Brothers and friends, Im a human living on Earth. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
"Sylvain" == Sylvain Petreolle <spetreolle(a)yahoo.fr> writes:
Sylvain> Im curious to see what adress GetProcAdress gets when asked for Sylvain> a stub. Wine happily returns a valid function adress, also obvious the same at least for different stubbed functions in the same dll. I searched for a way to return perhaps some flag in LdrGetProcedureAddress for that case, but I was not able to find something. I didn't find a way how LdrGetProcedureAddress could get that address and compare with the function address calculated for the requested function. Perhaps Eric or some other guru can... I propose that GetProcAddress evaluates that flag and should return 0 for stubs. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
On Tue, 6 May 2003, Uwe Bonnes wrote: [...]
I propose that GetProcAddress evaluates that flag and should return 0 for stubs.
This may fix this problem but may also cause a lot of others: cases where the application checks the value returned by GetProcAddress but doesn't actually call the function (or only calls it in some rarely used code path). I think it would be better to transform SendIMEMessageExA into a semi-stub. Hopefully that will be enough. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Linux: the choice of a GNU generation
Of course, its returning 0xdeadbeef :) --- Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> a écrit :
"Sylvain" == Sylvain Petreolle <spetreolle(a)yahoo.fr> writes:
Sylvain> Im curious to see what adress GetProcAdress gets when asked for Sylvain> a stub.
Wine happily returns a valid function adress, also obvious the same
===== Sylvain Petreolle (spetreolle at users dot sourceforge dot net) ICQ #170597259 No more War ! "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". For the Law of Oil and Fire, Im an European that lives in France. For all my Brothers and friends, Im a human living on Earth. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
"Sylvain" == Sylvain Petreolle <spetreolle(a)yahoo.fr> writes:
Sylvain> Of course, its returning 0xdeadbeef :) No longer. Wine sets up a special exception now to display more information when the function is accessed. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes:
Wine happily returns a valid function adress, also obvious the same at least for different stubbed functions in the same dll. I searched for a way to return perhaps some flag in LdrGetProcedureAddress for that case, but I was not able to find something. I didn't find a way how LdrGetProcedureAddress could get that address and compare with the function address calculated for the requested function.
Perhaps Eric or some other guru can...
I propose that GetProcAddress evaluates that flag and should return 0 for stubs.
There's no reason to do that; the whole point of declaring a stub is to provide a function address. If we don't want that function at all it should simply be commented out in the spec file. -- Alexandre Julliard julliard(a)winehq.com
"Alexandre" == Alexandre Julliard <julliard(a)winehq.com> writes:
Alexandre> Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: >> Wine happily returns a valid function adress, also obvious the same >> at least for different stubbed functions in the same dll. I searched >> for a way to return perhaps some flag in LdrGetProcedureAddress for >> that case, but I was not able to find something. I didn't find a way >> how LdrGetProcedureAddress could get that address and compare with >> the function address calculated for the requested function. >> >> Perhaps Eric or some other guru can... >> >> I propose that GetProcAddress evaluates that flag and should return 0 >> for stubs. Alexandre> There's no reason to do that; the whole point of declaring a Alexandre> stub is to provide a function address. If we don't want that Alexandre> function at all it should simply be commented out in the spec Alexandre> file. Andi, as your patches causes breackage, please revisit with Alexandre's rule applied. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
This is still broken in the 5/8/2003 release of WINE. Kevin On Monday 05 May 2003 10:40 am, Kevin DeKorte wrote:
This mornings CVS of wine breaks Lotus Notes 5.0.11
This is the message I get from wine-dbg
Unhandled exception: unimplemented function user32.dll.SendIMEMessageExA called in 32-bit code (0x40afb052). In 32-bit mode. 0x40afb052 (__wine_unimplemented+0x52 [user32.spec.c:42] in user32.dll.so): jmp0x40afb04c (__wine_unimplemented+0x4c [user32.spec.c:42] in user32.dll.so) 50 void __wine_stub_user32_dll_14(void) { __wine_unimplemented("BlockInput"); }
Kevin
what about sending a tiny stub implementation ? --- Kevin DeKorte <kdekorte(a)yahoo.com> a écrit :
This is still broken in the 5/8/2003 release of WINE.
Kevin
On Monday 05 May 2003 10:40 am, Kevin DeKorte wrote:
This mornings CVS of wine breaks Lotus Notes 5.0.11
This is the message I get from wine-dbg
Unhandled exception: unimplemented function user32.dll.SendIMEMessageExA called in 32-bit code (0x40afb052). In 32-bit mode. 0x40afb052 (__wine_unimplemented+0x52 [user32.spec.c:42] in user32.dll.so): jmp0x40afb04c (__wine_unimplemented+0x4c [user32.spec.c:42] in user32.dll.so) 50 void __wine_stub_user32_dll_14(void) { __wine_unimplemented("BlockInput"); }
Kevin
===== Sylvain Petreolle (spetreolle at users dot sourceforge dot net) ICQ #170597259 No more War ! "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". For the Law of Oil and Fire, Im an European that lives in France. For all my Brothers and friends, Im a human living on Earth. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
"Sylvain" == Sylvain Petreolle <spetreolle(a)yahoo.fr> writes:
Sylvain> what about sending a tiny stub implementation ? --- Kevin I think writing stub implementations for functions not available in all windows implementation and where the windows program only load them with GetProcAdrress and so can cope with the function not available is plain wrong. That way we tell the windows program the function _is_ available, so it will rely on the implementation, but then we provide no implementation... Andy, do you follow the problems resulting from your last contribution? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
participants (5)
-
Alexandre Julliard -
Francois Gouget -
Kevin DeKorte -
Sylvain Petreolle -
Uwe Bonnes