May 2004 - Wine-Devel - list.winehq.org

Re: General serial communications issues

by Eric Pouech

James Courtier-Dutton a écrit : > I attach two logs taken with the command: - > WINEDEBUG=+comm wine ttermpro.exe WINEDEBUG="+comm,+file,+ntdll" would be more helpful. TIA.

May 31, 2004

Re: General serial communications issues

by James Courtier-Dutton

David Purucker wrote: > Hello, > > I have tried several terminal programs (Hyperterm and TeraTerm) under > several builds of > Wine including Wine-20040505 and they seem to have the same generic > problem. > > They all exhibit the same situation, DATA seems to go OUT, but never > seems to come IN. > Several other people have experienced the same thing, as seen in this > bug report: > http://bugs.winehq.org/show_bug.cgi?id=2115 > > By the way, TeraTerm does work fine in TCP/IP mode, so it's definitely a > serial problem. > It's freeware available here: > http://hp.vector.co.jp/authors/VA002416/teraterm.html > > It appears to be a fundamental problem in the serial/file code, which I > understand is now > under the ntdll tree. Obviously, I don't know much about it, but there > is definitely > something wrong. > > I was wondering if any developers were aware of this problem, as the > decreased general > usage of serial communications may have caused this to slip under the > carpet, so to speak. > > I look forward to hearing any ideas, work-arounds, or patches. > > Thanks > I can confirm this problem. My setup is this. PC -> Serial Cable -> Loopback plug. linux based kermit works correctly, and the loopback also loops RTS/CTS. I type a character, and the loopback plug returns it back to the PC. With the loopback plug removed, no character is returned. It I then use teraterm, teraterm manages to output characters to the cable (I see LEDs flashing on the loopback plug). But, no characters make it back to windows. I attach two logs taken with the command: - WINEDEBUG=+comm wine ttermpro.exe "no-loop.txt" is without a loopback plug. "loop.txt" is with a loopback plug. So, this is certainly a wine bug, and I hope the logs help someone fix this. Cheers James fixme:comm:SetupComm insize 8192 outsize 2048 unimplemented stub trace:comm:PurgeComm handle 0x68, flags f trace:comm:SetCommTimeouts (0x68,0x406cf558) trace:comm:SetCommState handle 0x68, ptr 0x406cf56c trace:comm:SetCommState bytesize 8 baudrate 9600 fParity 0 Parity 0 stopbits 1 trace:comm:SetCommState ~IXON ~IXOFF trace:comm:SetCommState fOutxCtsFlow 0 fRtsControl 1 trace:comm:SetCommState fOutxDsrFlow 0 fDtrControl1 trace:comm:SetCommMask handle 0x68, mask 0 trace:comm:SetCommMask handle 0x68, mask 1 trace:comm:WaitCommEvent (0x68 0x42320178 (nil) ) trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:COMM_WaitCommEventService iosb 0x4232010c trace:comm:WaitCommEvent (0x68 0x42320178 (nil) ) trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:COMM_WaitCommEventService iosb 0x4232010c trace:comm:WaitCommEvent (0x68 0x42320178 (nil) ) trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:COMM_WaitCommEventService iosb 0x4232010c trace:comm:WaitCommEvent (0x68 0x42320178 (nil) ) trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:COMM_WaitCommEventService iosb 0x4232010c trace:comm:WaitCommEvent (0x68 0x42320178 (nil) ) trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:COMM_WaitCommEventService iosb 0x4232010c trace:comm:WaitCommEvent (0x68 0x42320178 (nil) ) trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:COMM_WaitCommEventService iosb 0x4232010c trace:comm:WaitCommEvent (0x68 0x42320178 (nil) ) trace:comm:PurgeComm handle 0x68, flags f trace:comm:EscapeCommFunction handle 0x68, function=6 trace:comm:EscapeCommFunction CLRDTR trace:comm:SetCommMask handle 0x68, mask 0 fixme:comm:SetupComm insize 8192 outsize 2048 unimplemented stub trace:comm:PurgeComm handle 0x68, flags f trace:comm:SetCommTimeouts (0x68,0x406cf558) trace:comm:SetCommState handle 0x68, ptr 0x406cf56c trace:comm:SetCommState bytesize 8 baudrate 9600 fParity 0 Parity 0 stopbits 1 trace:comm:SetCommState ~IXON ~IXOFF trace:comm:SetCommState fOutxCtsFlow 0 fRtsControl 1 trace:comm:SetCommState fOutxDsrFlow 0 fDtrControl1 trace:comm:SetCommMask handle 0x68, mask 0 trace:comm:SetCommMask handle 0x68, mask 1 trace:comm:WaitCommEvent (0x68 0x42320178 (nil) ) trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:PurgeComm handle 0x68, flags f trace:comm:EscapeCommFunction handle 0x68, function=6 trace:comm:EscapeCommFunction CLRDTR trace:comm:SetCommMask handle 0x68, mask 0

May 31, 2004

[REGRESSION] Photoshop 7.0 works before wine-cvs-20040130 16:??:?? CST (bug #2017)

by Luca Capello

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, as reported on bug #2017 [1], Adobe Photoshop 7.0 stops working after wine-20031212 (in the majority of cases). This happens on Debian unstable (where I am) as well as on other distro. As suggested by Tony Lambregts, I made a regression testing to find the patch that broke this. The problem is between cvs-20040130-165720 and cvs-20040130-165721. The 'cvs -d ...' command gives me updates for only 3 files: ===== U dlls/kernel/Makefile.in U dlls/kernel/actctx.c U dlls/kernel/kernel32.spec ===== so I think the problem should be in these files, am I right? If it's so, well, the patch that broke Photoshop 7.0 working is the following [2] - - Jon Griffiths <jon_p_griffiths(a)yahoo.com> Add stubs for the Activation Context API (XP+). Please fix this problem, now that you know the cause. Thx, bye, Gismo / Luca [1] http://bugs.winehq.org/show_bug.cgi?id=2017 [2] http://www.winehq.org/hypermail/wine-cvs/2004/01/0394.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iD8DBQFAu1FuVAp7Xm10JmkRAgWIAJ90THCdqfIu6/uLGyurqrLfNNWEkACeIAze ALi4ZeOtMTEEDp8ETWu4G4c= =/pZb -----END PGP SIGNATURE-----

May 31, 2004

Wine bug with delphi Menus

by Robert van Herk

Hi people, I think I discovered a wine bug. In a delphi program, changing the visibility of a menuitem (TMenuItem) causes the whole menu of that form to stop working, when the program is run under Wine. Behind the screens, the setVisible of a menu item calls MenuChanged. This seems to put the menu in such a state that, in wine, all menu components stop doing anything. I've written a small application (455 kb EXE) to show what goes wrong. Would anybody be interested to help me in solving this bug? Would a message trace from Winsight (for example) be of any help? Greetings, Robert

May 31, 2004

Re: General serial communications issues

by Eric Pouech

Raul Dias a écrit : > I am not a serial expert, but I don't understand what can change in the > serial communication to work with one printer and not work with another > (that use to work). > For me serial is TX, RX and a few control pins and that's it. there's lot of stuff in between the physical interface and the application code (linux TTY driver, Linux serial code, Windows libs...), and also several ways to call the Windows API. > Does anyone knows what really changed in the serial code? the way overlapped operations (aka asynchronous read/write) are handled. However, it's hard to tell what's broken from the information you gave. It may also well be that your issues are not linked to the issues reported by others A+

May 31, 2004

Current Wine CVS status

by Dmitry Timoshkov

Hello all (mostly Alexandre :-)), running today's ~/wine/wine under an old RH 6.2 install I get the following: Usage: ld.so [OPTION]... EXECUTABLE-FILE [ARGS-FOR-PROGRAM...] You have invoked `ld.so', the helper program for shared library executables. This program usually lives in the file `/lib/ld.so', and special directives in executable files using ELF shared libraries tell the system's program loader to load the helper program from this file. This helper program loads the shared libraries needed by the program executable, prepares the program to run, and runs it. You may invoke this helper program directly from the command line to load and run an ELF executable file; this is like executing that file itself, but always uses this helper program from the file you specified, instead of the helper program file specified in the executable file you run. This is mostly of use for maintainers to test new versions of this helper program; chances are you did not intend to run this program. --list list all dependencies and how they are resolved --verify verify that given object really is a dynamically linked object we get handle --library-path PATH use given PATH instead of content of the environment variable LD_LIBRARY_PATH --inhibit-rpath LIST ignore RPATH information in object names in LIST -- Dmitry.

May 31, 2004

Re: General serial communications issues

by Raul Dias

Hi, I have problems with wine serial code since 2000/2001. I think this might be related to your problem. In my situation, I have a bunch of stores that runs linux. Their sales sistem is remote application that can be run thru ssh/telnet/... Unfortunally they are required to use expensive serial fiscal printers that does not work with linux. The solution was to use netterm, a freeware term program, that given special escape sequences, it will handle it to a proprietary dll that them comunicates to the printer driver. Everything worked fine until the serial rewrite somewhere between 2000 and 2001. One strange thing is that some new printers (different brand) now works fine with wine, while the older printer does not. I can only get them to work with wine 20001026. So you probably should try that out if you have a chance. One problem is that this is a really old version of wine, which makes it really difficult to compile under a new distro with gcc 3.x, new glibc and probably kernel 2.6. I am not a serial expert, but I don't understand what can change in the serial communication to work with one printer and not work with another (that use to work). For me serial is TX, RX and a few control pins and that's it. Does anyone knows what really changed in the serial code? Should the new code works like the old one or is there fundamental differences that makes this incompatible? Could this be a API problem and not a problem in the way serial is handled? I have the same application with both wines. Old 20001026 (in a old distro) for the old printer and recent builds (in fresh distro) for the new printer in different machines. Is there any debugging code I can generate to help solve or find where the problem lies? I really would like to help solve this issue, however I have little win32 knowledge. []'s Raul Dias On Mon, 2004-05-24 at 14:06, David Purucker wrote: > Hello, > > I have tried several terminal programs (Hyperterm and TeraTerm) under > several builds of > Wine including Wine-20040505 and they seem to have the same generic problem. > > They all exhibit the same situation, DATA seems to go OUT, but never seems > to come IN. > Several other people have experienced the same thing, as seen in this bug > report: > http://bugs.winehq.org/show_bug.cgi?id=2115 > > By the way, TeraTerm does work fine in TCP/IP mode, so it's definitely a > serial problem. > It's freeware available here: > http://hp.vector.co.jp/authors/VA002416/teraterm.html > > It appears to be a fundamental problem in the serial/file code, which I > understand is now > under the ntdll tree. Obviously, I don't know much about it, but there is > definitely > something wrong. > > I was wondering if any developers were aware of this problem, as the > decreased general > usage of serial communications may have caused this to slip under the > carpet, so to speak. > > I look forward to hearing any ideas, work-arounds, or patches. > > Thanks > > _________________________________________________________________ > Stop worrying about overloading your inbox - get MSN Hotmail Extra Storage! > http://join.msn.click-url.com/go/onm00200362ave/direct/01/ >

May 31, 2004

Re: Making a system DLL unavailable (problem with COMMCTRL)

by Samuel Audet

Hi! Mike Hearn wrote: > Try "commctrl"="native" Hum... I must have been tired the other day, because Wine actually never provides a built-in commctrl.dll, which is OK. Ok, so the only big problem seems to be that OWL50.DLL can't display its emulated controls. Yes, the native commctrl.dll from Windows 98 kind of works. The dialog window size is incorrect. Any hint as to where I should start looking in the code or the debugger? Thank you! bye

May 31, 2004

segfault fault at startup

by Florian Goth

H! I have the same Problem. I get a segfault, when I do "wine myapp" and when I do "wine-pthread" I'm using a SuSE System ( ~ 9.0 ) with kernel 2.6.6 and gcc 3.4.0 this is the gdb output: (gdb) set follow-fork-mode child (gdb) r Starting program: /usr/local/bin/wine [New Thread 16384 (LWP 5206)] [New Thread 32769 (LWP 5209)] [New Thread 16386 (LWP 5210)] Cannot find user-level thread for LWP 5206: generic error (gdb) this is some of the last strace output I get: t_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM IO], [RTMIN], 8) = 0 writev(4, [{"$\0\0\0002\0\0\0\0\0\0\0\0\0\0\200\0\0\0\0\1\0\0\0\1\0"..., 64}, {"/home/sifff/.wine/dosdevices/c:/"..., 50}], 2) = 114 read(5, "\0\0\0\0\0\0\0\0000\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0 rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM IO], [RTMIN], 8) = 0 write(4, "G\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0A\0\0\0\5\0\17\0"..., 64) = 64 read(5, "\0\0\0\0\0\0\0\0004\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0 rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM IO], [RTMIN], 8) = 0 write(4, "I\0\0\0\0\0\0\0\0\0\0\0004\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 read(5, "\0\0\0\0\0\0\0\0\0\0\0\0\0000M\0A\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0 rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM IO], [RTMIN], 8) = 0 write(4, "&\0\0\0\0\0\0\0\0\0\0\0004\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 read(5, "\0\0\0\0\0\0\0\0\377\377\377\377\1\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0 recvmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{"4\0\0\0", 4}], msg_controllen=16, msg_control=0xbfffab68, , msg_flags=0}, 0) = 4 fcntl64(9, F_SETFD, FD_CLOEXEC) = 0 rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM IO], [RTMIN], 8) = 0 write(4, "\26\0\0\0\0\0\0\0\0\0\0\0004\0\0\0\0\0\0\0\0\0\0\0\t\0"..., 64) = 64 read(5, "\0\0\0\0\0\0\0\0\0\0\0\0\t\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0 dup(9) = 10 rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM IO], [RTMIN], 8) = 0 write(4, "&\0\0\0\0\0\0\0\0\0\0\0004\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 read(5, "\0\0\0\0\0\0\0\0\t\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0 dup(9) = 11 fstat64(11, {st_mode=S_IFREG|0755, st_size=5054496, ...}) = 0 fstatfs(11, {f_type="MSDOS_SUPER_MAGIC", f_bsize=4096, f_blocks=358741, f_bfree=57991, f_files=0, f_ffree=0, f_namelen=260}) = 0 close(11) = 0 mmap2(NULL, 5124096, PROT_READ, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40860000 munmap(0x40d33000, 65536) = 0 mmap2(0x40860000, 5058560, PROT_READ, MAP_PRIVATE|MAP_FIXED, 10, 0) = 0x40860000 rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM IO], [RTMIN], 8) = 0 write(4, "\27\0\0\0\0\0\0\0\0\0\0\0\377\377\377\3774\0\0\0\377\377"..., 64) = 64 read(5, "\0\0\0\0\0\0\0\0008\0\0\0\377\377\377\377\0\0\0\0\0\0\0"..., 64) = 64 rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0 close(10) = 0 rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM IO], [RTMIN], 8) = 0 write(4, "\25\0\0\0\0\0\0\0\0\0\0\0004\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 read(5, "\0\0\0\0\0\0\0\0\t\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0 close(9) = 0 getpid() = 5154 open("/tmp/reg14220000.tmp", O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE, 0666) = 9 fcntl64(9, F_GETFL) = 0x8001 (flags O_WRONLY|O_LARGEFILE) fstat64(9, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 mmap2(NULL, 131072, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40d33000 _llseek(9, 0, [0], SEEK_CUR) = 0 brk(0) = 0x7800a000 brk(0x7800b000) = 0x7800b000 write(9, "WINE REGISTRY Version 2\n[MIME\\\\D"..., 131072) = 131072 write(9, "trolSet\\\\Control\\\\DeviceClasses\\"..., 131072) = 131072 write(9, "&PID_0095&INST_0\"\n\"RefCount\"=dwo"..., 131072) = 131072 write(9, "ixer f\\xfcr Aureon 5.1 Fun\"\n\n[Sy"..., 131072) = 131072 write(9, "0,00,00,00,00,00,00,00,00,00,00,"..., 131072) = 131072 write(9, "stem\\\\CurrentControlSet\\\\Service"..., 131072) = 131072 brk(0) = 0x7800b000 brk(0x7800c000) = 0x7800c000 brk(0) = 0x7800c000 brk(0x7800d000) = 0x7800d000 brk(0) = 0x7800d000 brk(0x7800e000) = 0x7800e000 brk(0) = 0x7800e000 brk(0x7800f000) = 0x7800f000 brk(0) = 0x7800f000 brk(0x78010000) = 0x78010000 --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV +++ Thanks, Flo

May 31, 2004

Re: Making a system DLL unavailable (problem with COMMCTRL)

by Samuel Audet

Hello, Eric Pouech wrote: > one of the things you could try (but that's risky) is to compile wine > twice. First time with standard option, second time with disabling > compilation of 16 bit part. Then use the commctrl DLL from the second > compilation in the first compilation. But you need to do everything by > hand. > The best solution anyhow is to understand why Wine's commctrl in 16 bit > fails and fix it. Thanks for the tip! I have tried something else since then. I modified OWL50.DLL to look for COMMCTRL.DLL in say CRAPPY00.DLL, and that made the DLL unavailable all right, but it still didn't work correctly. I get the same "no dialog" dialog window that is either huge, or tiny, depending on other options, and with 100% CPU usage. My guess is, OWL50.DLL correctly detects that Wine's COMMCTRL.DLL is a stub and starts using its emulated controls, but fails to display them... Anybody has some debugging experience with Wine to give me hint as to where I should start looking why OWL50.DLL can't display its emulated controls on Wine? Thank you later!

May 31, 2004