January 2003 - Wine-Bugs - list.winehq.org

[Bug 1245] - msvcrt.__crtLCMapStringA unimplemented

by wine-bugs＠winehq.com

http://bugs.winehq.com/show_bug.cgi?id=1245 marcus(a)jet.franken.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW everconfirmed|0 |1 Summary|Garmin Mapsource crashes |msvcrt.__crtLCMapStringA |after msvcrt.mblen() call |unimplemented ------- Additional Comments From marcus(a)jet.franken.de 2003-01-31 01:47 ------- correct. can you try the attached patch please and see if it fixes the problem>? DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://bugs.winehq.com/show_bug.cgi?id=1245>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.

Jan. 31, 2003

[Bug 1245] - Garmin Mapsource crashes after msvcrt.mblen() call

by wine-bugs＠winehq.com

http://bugs.winehq.com/show_bug.cgi?id=1245 ------- Additional Comments From keldon(a)ont.com 2003-01-31 01:22 ------- I did as you asked, and there's nothing new before the RaiseException, but immediately afterwards I get this: trace:seh:EXC_RtlRaiseException code=80000100 flags=1 addr=0x780e54cb trace:seh:EXC_RtlRaiseException info[0]=407d6c80 trace:seh:EXC_RtlRaiseException info[1]=407d6dd3 trace:seh:EXC_RtlRaiseException stub=__crtLCMapStringA trace:seh:EXC_CallHandler calling handler at 0x709512 code=80000100 flags=1 I suppose this "__crtLCMapStringA" isn't implemented? DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://bugs.winehq.com/show_bug.cgi?id=1245>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.

Jan. 31, 2003

[Bug 1245] - Garmin Mapsource crashes after msvcrt.mblen() call

by wine-bugs＠winehq.com

http://bugs.winehq.com/show_bug.cgi?id=1245 ------- Additional Comments From marcus(a)jet.franken.de 2003-01-31 01:17 ------- can you run with -debugmsg +seh,+relay and check the output before the RaiseException? I think it is running up to an unimplemented function or similar. DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://bugs.winehq.com/show_bug.cgi?id=1245>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.

Jan. 31, 2003

[Bug 1245] - Garmin Mapsource crashes after msvcrt.mblen() call

by wine-bugs＠winehq.com

http://bugs.winehq.com/show_bug.cgi?id=1245 ------- Additional Comments From keldon(a)ont.com 2003-01-30 23:34 ------- I forgot to mention that when I run with a native msvcrt, it gets far past this point (it crashes later, but I'll worry about that some other time). DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://bugs.winehq.com/show_bug.cgi?id=1245>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.

Jan. 31, 2003

[Bug 1245] New: - Garmin Mapsource crashes after msvcrt.mblen() call

by wine-bugs＠winehq.com

http://bugs.winehq.com/show_bug.cgi?id=1245 Summary: Garmin Mapsource crashes after msvcrt.mblen() call Product: Wine Version: CVS Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wine-misc AssignedTo: wine-bugs(a)winehq.com ReportedBy: keldon(a)ont.com Garmin's Mapsource 4.11 application crashes soon after startup. A +relay trace: 080e58d0:Call msvcrt._mbstrlen(403e3011 "India 0") ret=00402f9b 080e58d0:Ret msvcrt._mbstrlen() retval=00000007 ret=00402f9b 080e58d0:Call msvcrt._mbstrlen(403e3041 "India IA") ret=00402fb3 080e58d0:Ret msvcrt._mbstrlen() retval=00000008 ret=00402fb3 080e58d0:Call msvcrt.mblen(00000000,00000000) ret=00402fee 080e58d0:Ret msvcrt.mblen() retval=00000000 ret=00402fee 080e58d0:Call msvcrt.mblen(00000000,00000000) ret=00402ff4 080e58d0:Ret msvcrt.mblen() retval=00000000 ret=00402ff4 080e58d0:Call msvcrt.mblen(403e3011,00000007) ret=00403031 080e58d0:Ret msvcrt.mblen() retval=00000001 ret=00403031 080e58d0:Call msvcrt.mblen(403e3041,00000008) ret=0040303f 080e58d0:Ret msvcrt.mblen() retval=00000001 ret=0040303f 080e58d0:Call kernel32.InterlockedIncrement(407e17a4) ret=780e53cc 080e58d0:Ret kernel32.InterlockedIncrement() retval=00000001 ret=780e53cc 080e58d0:Call kernel32.InterlockedDecrement(407e17a4) ret=780e5415 080e58d0:Ret kernel32.InterlockedDecrement() retval=00000000 ret=780e5415 (there are several more increment and decrement calls here) 080e58d0:Call msvcrt.mblen(403e3012,00000006) ret=00403031 080e58d0:Ret msvcrt.mblen() retval=00000001 ret=00403031 080e58d0:Call msvcrt.mblen(403e3042,00000007) ret=0040303f 080e58d0:Ret msvcrt.mblen() retval=00000001 ret=0040303f 080e58d0:Call kernel32.InterlockedIncrement(407e17a4) ret=780e53cc 080e58d0:Ret kernel32.InterlockedIncrement() retval=00000001 ret=780e53cc 080e58d0:Call ntdll.RtlRaiseException(406c2a08) ret=407bb058 fs=008f eax=780e54cb ebx=407e0b74 ecx=406c2ab0 edx=407e1562 esi=406c2a08 edi=00000000 ebp=406c2a60 esp=406c2a08 ds=002b es=002b gs=0000 flags=00000216 DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://bugs.winehq.com/show_bug.cgi?id=1245>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.

Jan. 31, 2003

[Bug 1244] New: - Failure to communicate with serial device

by wine-bugs＠winehq.com

http://bugs.winehq.com/show_bug.cgi?id=1244 Summary: Failure to communicate with serial device Product: Wine Version: CVS Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wine-files AssignedTo: wine-bugs(a)winehq.com ReportedBy: keldon(a)ont.com I'm trying to run Garmin's "UPDATER.EXE", which is supposed to load a new firmware image into a GPS device. Communication is done over a serial port. If I run the program without any debugmsg flags, it fails immediately, complaining that it can't find the GPS. However, if I run with: --debugmsg +comm,+file,+serial then it gets a bit further. The first thing it does is get the model number and current firmware version from the device. But it soon fails again before beginning the upload. Here's an annotated debug log: trace:comm:COMM_Init COM1 = /dev/ttyS0 trace:comm:COMM_Init LPT1 = /dev/lp0 trace:comm:COMM_Init COM2 = /dev/ttyS1 trace:comm:COMM_Init COM3 = /dev/ttyS2 trace:comm:COMM_Init COM4 = /dev/ttyS3 trace:file:CreateFileW L"COM2" GENERIC_READ GENERIC_WRITE OPEN_EXISTING attributes 0x0 trace:file:CreateFileW opening device L"COM2" trace:file:DOSFS_CreateCommPort L"COM2" c0000000 0 trace:file:CreateFileW returning 0x4c trace:comm:GetCommState handle 0x4c, ptr 0x41222858 trace:comm:GetCommState OK trace:comm:GetCommState bytesize 8 baudrate 9600 fParity 0 Parity 0 stopbits 1 trace:comm:GetCommState ~IXON ~IXOFF trace:comm:GetCommState ~CRTSCTS trace:comm:SetCommState handle 0x4c, ptr 0x41222858 trace:comm:SetCommState bytesize 8 baudrate 9600 fParity 0 Parity 0 stopbits 1 trace:comm:SetCommState ~IXON ~IXOFF trace:comm:GetCommTimeouts (0x4c,0x41222844) trace:comm:SetCommTimeouts (0x4c,0x41222844) fixme:comm:SetupComm insize 4096 outsize 4096 unimplemented stub trace:comm:PurgeComm handle 0x4c, flags f trace:comm:ClearCommError handle 0x4c cbInQue = 0 cbOutQue = 0 trace:file:WriteFile 0x4c 0x40f01851 6 0x41222670 (nil) trace:comm:ClearCommError handle 0x4c cbInQue = 0 cbOutQue = 0 (this line is repeated many times, presumably while it waits for input) trace:comm:ClearCommError handle 0x4c cbInQue = 8 cbOutQue = 0 trace:file:ReadFile 0x4c 0x41222a70 8 0x41222530 (nil) trace:file:FILE_TimeoutRead 0x4c 0x41222a70 8 0x41222530 trace:file:FILE_ReadFileEx file 0x4c to buf 0x41222a70 num 8 0x41222488 func (nil) trace:file:GetOverlappedResult (0x4c 0x41222488 0x41222530 1) trace:file:GetOverlappedResult waiting on 0x41222488 trace:file:FILE_AsyncReadService 0x41222488 0x41222a70 trace:file:FILE_AsyncReadService read 8 more bytes 8/8 so far trace:file:GetOverlappedResult wait on 0x41222488 returned 192 trace:file:GetOverlappedResult waiting on 0x41222488 trace:file:GetOverlappedResult wait on 0x41222488 returned 0 It then continues to do this several times, reading 8 or 16 bytes at a time from the serial port. There is then one more write/read exchange, then this: trace:file:WriteFile 0x4c 0x40f01851 8 0x4122256c (nil) trace:comm:ClearCommError handle 0x4c cbInQue = 0 cbOutQue = 0 trace:file:WriteFile 0x4c 0x40f01851 8 0x41222670 (nil) trace:comm:ClearCommError handle 0x4c cbInQue = 0 cbOutQue = 0 This last line then repeats about 10,000 times before the program times out and gives up on hearing anything. I'm guessing that since it works slightly better with debugging enabled, that there is a race condition at work here. Maybe the last packet never actually got written to the serial port, or a response came and Wine lost it. DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://bugs.winehq.com/show_bug.cgi?id=1244>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.

Jan. 31, 2003

[Bug 1234] - WINE 20030115: Misc Tribes 1 errors; DINPUT, OPENGL

by wine-bugs＠winehq.com

http://bugs.winehq.com/show_bug.cgi?id=1234 ------- Additional Comments From LogicDonut(a)msn.com 2003-01-30 20:51 ------- Created an attachment (id=375) Debug log from: wine --debugmsg +relay,+dinput Tribes.exe DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://bugs.winehq.com/show_bug.cgi?id=1234>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.

Jan. 31, 2003

[Bug 1189] - Error in window creation, Wine 20021124

by wine-bugs＠winehq.com

http://bugs.winehq.com/show_bug.cgi?id=1189 ------- Additional Comments From michal.seliga(a)visicom.sk 2003-01-29 11:49 ------- There is the same problem in many application (new modal windows are created behind main window), including many installers. I workarounded it with setting wine to not use managed mode in wine.conf. Now everything works well. I tried wine 20030115 so maybe that could lead to something.... (bug in managed mode?) DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://bugs.winehq.com/show_bug.cgi?id=1189>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.

Jan. 29, 2003

[Bug 550] - DLL Separation: gdi32 from ntdll (DOSFS_GetFullName)

by wine-bugs＠winehq.com

http://bugs.winehq.com/show_bug.cgi?id=550 dpaun(a)rogers.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED ------- Additional Comments From dpaun(a)rogers.com 2003-01-28 17:19 ------- This function does not seem to be used by gdi32 anymore: [dimi(a)dimi wine.src]$ grep -l DOSFS_GetFullName `find -name "*.c"` ./dlls/ntdll/file.c ./files/directory.c ./files/dos_fs.c ./files/drive.c ./files/file.c ./files/profile.c ./misc/registry.c ./msdos/dosconf.c ./msdos/int21.c ./scheduler/process.c Time to close this bugger. DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://bugs.winehq.com/show_bug.cgi?id=550>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.

Jan. 28, 2003

[Bug 540] - DLL Separation: x11drv from user32 (clipboard)

by wine-bugs＠winehq.com

http://bugs.winehq.com/show_bug.cgi?id=540 ------- Additional Comments From hughes2002(a)btinternet.com 2003-01-28 15:07 ------- The attached patch should clean up CLIPBOARD_EmptyCache, CLIPBOARD_GetFormatName and CLIPBOARD_IsPresent. The others will be much harder to get rid of, as they rely on internal parts of the Wine clipboard implementation which aren't accessed (and possibly don't exist) under Win32. DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://bugs.winehq.com/show_bug.cgi?id=540>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.

Jan. 28, 2003