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.
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.
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.
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.
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.
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.
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.
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@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.
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.