Wine and serial port AGAIN

[Pavel Troller]

Hi!
  As a technician, I need often to use some form of serial port communication.
  My recent experience is with a program for programming TYT radios from China.
They supply a simple windows app, which allows to program all the features of
the radio, which cannot be accomplished using the radio keyboard only.
  The program works perfectly in wine, with one exception - a physical comms
with the radio. It complains that it doesn't receive a response from the radio,
while the radio crashes - it stops working, when a programming attempt is made,
and has to be power-cycled.
  The radio is connected using a USB cable, which contains just a regular 
PL-2303 USB to serial converter, which is perfectly supported in Linux. 
Port assignment for wine is also done, proof of which is, that the radio 
crashes upon the programming request. The data volume to be programmed is
small, just a few hundreds of bytes. It's really stupid that I can prepare my
data in the program only, and then I need to ask my colleague with real windows
to perform a programming job :-(.
  The program can be freely downloaded from the TYT pages:
  http://www.tyt888.com/WebEditor/UploadFile/201096144939483.rar
  but a real radio is needed to debug the comms problem. I've captured the
console output with WINEDEBUG=+comm, which is attached. It contains a log of
three consecutive attempts to program the radio. I'm ready to do more debugging,
but I don't know, how to proceed now.
  With regards, Pavel.
fixme:ole:OleLoadPictureEx 
(0x9c2d6c,1086,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=0,y=0,f=0,0x32fa80), 
partially implemented.
fixme:ole:OleLoadPictureEx 
(0x9c2d6c,0,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=16,y=16,f=0,0x13e7d8), 
partially implemented.
fixme:ole:OleLoadPictureEx 
(0x9c2d6c,0,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=16,y=16,f=0,0x13e850), 
partially implemented.
fixme:ole:OleLoadPictureEx 
(0x9c2d6c,0,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=16,y=16,f=0,0x13eb68), 
partially implemented.
fixme:ole:OleLoadPictureEx 
(0x9c2d6c,0,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=16,y=16,f=0,0x13ebe0), 
partially implemented.
fixme:ole:OleLoadPictureEx 
(0x9c2d6c,0,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=16,y=16,f=0,0x13ec58), 
partially implemented.
fixme:ole:OleLoadPictureEx 
(0x9c2d6c,0,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=16,y=16,f=0,0x13ecd0), 
partially implemented.
fixme:ole:OleLoadPictureEx 
(0x9c2d6c,0,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=16,y=16,f=0,0x13ed48), 
partially implemented.
fixme:ole:OleLoadPictureEx 
(0x9c2d6c,0,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=16,y=16,f=0,0x13edc0), 
partially implemented.
fixme:ole:OleLoadPictureEx 
(0x9c2d6c,0,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=16,y=16,f=0,0x13ee38), 
partially implemented.
fixme:ole:OleLoadPictureEx 
(0x9c2d6c,0,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=16,y=16,f=0,0x13eeb0), 
partially implemented.
fixme:ole:OleLoadPictureEx 
(0x9c2d6c,0,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=16,y=16,f=0,0x13ef28), 
partially implemented.
fixme:ole:OleLoadPictureEx 
(0x9c2d6c,0,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=16,y=16,f=0,0x13efa0), 
partially implemented.
fixme:ole:OleLoadPictureEx 
(0x9c2d6c,0,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=16,y=16,f=0,0x13f018), 
partially implemented.
fixme:ole:OleLoadPictureEx 
(0x9c2d6c,0,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=16,y=16,f=0,0x13f090), 
partially implemented.
fixme:ole:OleLoadPictureEx 
(0x9cfc9c,5774,1,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=0,y=0,f=0,0x32f63c), 
partially implemented.
fixme:ole:OleLoadPictureEx 
(0x9cfc9c,5774,1,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=0,y=0,f=0,0x32f63c), 
partially implemented.
fixme:ole:OleLoadPictureEx 
(0x9cfc9c,5774,1,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=0,y=0,f=0,0x32f63c), 
partially implemented.
fixme:ole:OleLoadPictureEx 
(0x9cfc9c,5774,1,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=0,y=0,f=0,0x32f63c), 
partially implemented.
fixme:ole:OleLoadPictureEx 
(0x9cfc9c,5774,1,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=0,y=0,f=0,0x32f63c), 
partially implemented.
fixme:ole:OLEPictureImpl_SaveAsFile (0x12e580)->(0x181088, 0, (nil)), hacked 
stub.
trace:comm:SetCommMask handle 0x78, mask 1fd
trace:comm:io_control 0x78 IOCTL_SERIAL_SET_WAIT_MASK 0x32f3d4 4 (nil) 0 
0x32f374
trace:comm:io_control 0x78 IOCTL_SERIAL_SET_QUEUE_SIZE 0x32f3b4 8 (nil) 0 
0x32f370
fixme:comm:set_queue_size insize 1024 outsize 512 unimplemented stub
trace:comm:io_control 0x78 IOCTL_SERIAL_PURGE 0x32f3d4 4 (nil) 0 0x32f374
trace:comm:SetCommTimeouts (0x78, 0x32f40c)
trace:comm:io_control 0x78 IOCTL_SERIAL_SET_TIMEOUTS 0x32f3a8 20 (nil) 0 
0x32f364
trace:comm:GetCommState handle 0x78, ptr 0x32f418
trace:comm:io_control 0x78 IOCTL_SERIAL_GET_BAUD_RATE (nil) 0 0x32f3e8 4 
0x32f378
trace:comm:io_control 0x78 IOCTL_SERIAL_GET_LINE_CONTROL (nil) 0 0x32f3ed 3 
0x32f378
trace:comm:io_control 0x78 IOCTL_SERIAL_GET_HANDFLOW (nil) 0 0x32f3cc 16 
0x32f378
trace:comm:io_control 0x78 IOCTL_SERIAL_GE

Re: [PATCH 5/7] mshtml: Added IHTMLScriptElement::get_scr implementation.

[Marvin]

Hi,

While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=7657

Your paranoid android.


=== W7PRO (32 bit dom) ===
Failure running script in VM: The specified guest user must be logged in 
interactively to perform this operation

socks & wine, patching wininet to use winsock

[Gabriele Greco]

I'm trying to make programs that need a socks proxy to work on wine.

They work with freecaps or similar winsock patches as long as they don't use
wininet or other indirect winsocks APIs to make their stuff, if they use
wininet those patches could not work since wininet bypasses winsocks and use
linux sockets directly.

In the head of the wininet.dll sources there is this comment:

/* FIXME!!
 *This should use winsock - To use winsock the functions will have to
change a bit
 *as they are designed for unix sockets.
 *SSL stuff should use crypt32.dll
 */

I tried to change netconnection.c to use winsock functions WSAConnect,
WSASend & WSARecv since WS_send, WS_recv and WS_connect are not exposed by
ws2_32 instead of direct linux socket functions (connect/send/recv), but I
had no way to check the problems with unix sockets vs inet sockets cause the
library crashes wine before hitting anything related with my CODE patches.

It crashes simply because I've added in Makefile.in ws2_32 module IMPORTS,
doing so what I've observed is that standard linux sockets calls are
"wrapped" and points now to NULL (because ws2_32 is not loaded?).

In this specific case "getaddrinfo" is NULL and HTTP_ResolveName crashes
when calling it.

Anyone can suggest me the correct approach to implement this? I have to load
manually ws2_32 in the wininet initialization?

-- 
Bye,
 Gabry

Re: [PATCH 1/5] server: Handle more inotify mask values

[Alexandre Julliard]

Piotr Caban  writes:

> -static int inode_check_dir( struct inode *parent, const char *name )
> -{
> -char *path;
> -unsigned int filter;
> -struct inode *inode;
> -struct stat st;
> -int wd = -1, r = -1;
> -
> -path = inode_get_path( parent, strlen(name) );
> -if (!path)
> -return r;
> -
> -strcat( path, name );
> -
> -r = stat( path, &st );
> -if (r < 0) goto end;
> -
> -if (!S_ISDIR(st.st_mode))
> -{
> -r = 0;
> -goto end;
> -}
> -
> -r = 1;
> -
> -filter = filter_from_inode( parent, 1 );
> -if (!filter)
> -goto end;
> -
> -inode = inode_add( parent, st.st_dev, st.st_ino, name );
> -if (!inode || inode->wd != -1)
> -goto end;
> -
> -wd = inotify_add_dir( path, filter );
> -if (wd != -1)
> -inode_set_wd( inode, wd );
> -else
> -free_inode( inode );
> -
> -end:
> -free( path );
> -return r;
> -}

You can't remove all this, you still need to add a watch for newly
created directories.

-- 
Alexandre Julliard
julli...@winehq.org