http://bugs.winehq.org/show_bug.cgi?id=2591
btucker@mpc-data.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Wine FreeBSD |Wine FreeBSD Stuck in | |ReadProcessMemory
------- Additional Comments From btucker@mpc-data.co.uk 2004-03-12 05:55 ------- Running Freebsd 4.10, Wine 20040505 or 20040408 both patched for FreeBSD and built fron the ports collection. I find that console mode win32 exes run ok. Any GUI executables such as notepad.exe (from a XP pro sp2 installation) get stuck in the win32 api call 'kernel32.ReadProcessMemory'. Interestingly, the windows GUI version of vim, called gvim.exe version 62 did not suffer the same problem. Running XFree86 4.3.0.1. I have attacked the wine trace and ktrace. I am supprised that I have found no mention of this problem in the bug lists as it affects all windows exes (gvim excluded) that I tried (word, excell etc) I am trying to run a propriety windows GUI scripting system for X platform driver testing. It runs on Linux but FreeBSD has become an unexpected show stopper. Any help gratefully received.
Ben.
P.S. Running under linux, our test system loads dlls several times i.e. it does LoadLibrary on the same dll more than one time. We have found that where the dll in question is a wine wrapper '.dll.so', the first load library succeeds but subsiquent loads fail. Wine picks up the .dll.so from the linker paths the first time but that records it's path incorrectly. This problem only ocures when a path the the win .dll is included in the LoadLibrary call.