June 2006 - Wine-devel - list.winehq.org

wine and serial port - again
by Pavel Troller 05 Jul '06

05 Jul '06

Hi! From time to time, complaints can be heard about functionality of the serial port implementation in wine. Just now I have one of examples of the serial communication problem. There is a very simple program, called ft or softjump, intended to dump or modify some particular addresses of an EEPROM of an amateur radio. It uses a serial port in non-canonical mode, writing always 5 binary chars into it and reading (also binary) reply. I've run this program under wine but there were problems - the program never dumped any data. The source is included in the program archive; it was about 30 minutes of work to convert it for Linux. After successfull compilation, I've run the resulting Linux program (pure Linux, not winelib) and it worked as expected. For the testing purposes, I've then compiled the original windows version using winegcc. I was able to run the program, but the results were identical to those with original windows binary (no data). The windows binary output shows this: patrol(a)arcus:~/ft817$ wine ft.exe ft.exe by Peter May, VK2JCG, vk2jcg(a)yahoo.com.au This program uses undocumented CAT commands to read or update the EEPROM in the Yaesu FT817 and FT897 Radios. The soft jumper settings are stored in location 4 and 5 of the EEPROM. Power the radio off and on to activate the new settings. If you do a reset of the radio, you will have to run this program again to rewrite the values The program assumes that the radio is connected to COM1: and the CAT rate is set to 38400 baud *** USE AT YOUR OWN RISK *** Serial port COM1: successfully reconfigured. Read current data from EEPROM gives : patrol(a)arcus:~/ft817$ Its Linux version works well: patrol(a)arcus:~/ft817/Source$ ft ft by Peter May, VK2JCG, vk2jcg(a)yahoo.com.au This program uses undocumented CAT commands to read or update the EEPROM in the Yaesu FT817 and FT897 Radios. The soft jumper settings are stored in location 4 and 5 of the EEPROM. Power the radio off and on to activate the new settings. If you do a reset of the radio, you will have to run this program again to rewrite the values. *** USE AT YOUR OWN RISK *** Linux version by Pavel Troller - OK1XPT, <patrol(a)sinus.cz> Serial port /dev/tts/0 successfully reconfigured. Read current data from EEPROM gives : DD BF patrol(a)arcus:~/ft817/Source$ Do you see ? The windows version doesn't output the actual EEPROM data. +file,+comm trace from wine looks like this: trace:file:CreateFileW L"COM1:" GENERIC_READ GENERIC_WRITE creation 3 attributes 0x0 trace:file:RtlDosPathNameToNtPathName_U (L"COM1:",0x7fb3fdd0,(nil),(nil)) trace:file:RtlGetFullPathName_U (L"COM1:" 520 0x7fb3fb44 (nil)) trace:file:get_dos_device L"COM1" -> "/dev/ttyS0" trace:file:CreateFileW returning 0x2c trace:comm:GetCommState handle 0x2c, ptr 0x7fb3fe70 trace:comm:COMM_DeviceIoControl 0x2c IOCTL_SERIAL_GET_BAUD_RATE (nil) 0 0x7fb3fe18 4 0x7fb3fdb0 trace:comm:COMM_DeviceIoControl 0x2c IOCTL_SERIAL_GET_LINE_CONTROL (nil) 0 0x7fb3fe1d 3 0x7fb3fdb0 trace:comm:COMM_DeviceIoControl 0x2c IOCTL_SERIAL_GET_HANDFLOW (nil) 0 0x7fb3fe00 16 0x7fb3fdb0 trace:comm:COMM_DeviceIoControl 0x2c IOCTL_SERIAL_GET_CHARS (nil) 0 0x7fb3fe12 6 0x7fb3fdb0 trace:comm:GetCommState OK trace:comm:dump_dcb bytesize=8 baudrate=38400 fParity=0 Parity=0 stopbits=2 trace:comm:dump_dcb ~IXON ~IXOFF trace:comm:dump_dcb fOutxCtsFlow=0 fRtsControl=0 trace:comm:dump_dcb fOutxDsrFlow=0 fDtrControl=1 trace:comm:dump_dcb ~CRTSCTS trace:comm:dump_dcb bytesize=8 baudrate=38400 fParity=0 Parity=0 stopbits=2 trace:comm:dump_dcb ~IXON ~IXOFF trace:comm:dump_dcb fOutxCtsFlow=0 fRtsControl=0 trace:comm:dump_dcb fOutxDsrFlow=0 fDtrControl=0 trace:comm:dump_dcb ~CRTSCTS trace:comm:COMM_DeviceIoControl 0x2c IOCTL_SERIAL_SET_BAUD_RATE 0x7fb3fe18 4 (nil) 0 0x7fb3fdb0 trace:comm:COMM_DeviceIoControl 0x2c IOCTL_SERIAL_SET_LINE_CONTROL 0x7fb3fe1d 3 (nil) 0 0x7fb3fdb0 trace:comm:COMM_DeviceIoControl 0x2c IOCTL_SERIAL_SET_HANDFLOW 0x7fb3fe00 16 (nil) 0 0x7fb3fdb0 trace:comm:COMM_DeviceIoControl 0x2c IOCTL_SERIAL_SET_CHARS 0x7fb3fe12 6 (nil) 0 0x7fb3fdb0 trace:comm:SetCommTimeouts (0x2c, 0x7fb3fe5c) trace:comm:COMM_DeviceIoControl 0x2c IOCTL_SERIAL_SET_TIMEOUTS 0x7fb3fe0c 20 (nil) 0 0x7fb3fdb0 trace:file:WriteFile 0x8 0x7fb3f9cc 48 0x7fb3fdd4 (nil) Serial port COM1: successfully reconfigured. trace:file:WriteFile 0x2c 0x7fb3fe54 5 0x7fb3fe4c (nil) trace:file:ReadFile 0x2c 0x7fb3fe8c 4 0x7fb3fe4c (nil) trace:file:WriteFile 0x8 0x7fb3f9b4 38 0x7fb3fdbc (nil) Read current data from EEPROM gives : trace:file:WriteFile 0x8 0x7fb3f9b8 2 0x7fb3fdc0 (nil) You can see the port configuration phase, as well 5 bytes being written and a read being attempted. However, resulting "count" variable (see source) is probably 0, because there is no output of values read. I don't know, whether it is due to wrong command being written to the radio, or failure to read its response. Original package can be downloaded freely for example here: http://www.817-onair.de/download.php?id=6&sid=c66545090cd6b5cbc2e1c06321ff9… My Linux variant is attached to this mail. Sorry for the lengthy mail, but I hope that it can really help to improve the serial communication support in wine. With regards, Pavel Troller

2 1

wine-1.0 goal: fix all reported msi and ole bugs?
by Dan Kegel 04 Jul '06

04 Jul '06

I just looked, and there aren't *that* many msi and ole bugs reported in bugzilla. http://bugs.winehq.org/buglist.cgi?product=Wine&component=wine-ole&keywords… lists 37 ole bugs with downloadable demos http://bugs.winehq.org/buglist.cgi?product=Wine&component=wine-ole&bug_stat… lists 89 ole bugs total http://bugs.winehq.org/buglist.cgi?product=Wine&component=wine-msi&keywords… lists 35 msi bugs with downloadable demos http://bugs.winehq.org/buglist.cgi?product=Wine&component=wine-msi&bug_stat… lists 71 msi bugs total Would it be unreasonable to set a goal of having all msi and ole bugs fixed for wine-1.0 ?

4 4

re: msi: Fix some copy/paste bugs in the implementation of condition operators.
by Dan Kegel 03 Jul '06

03 Jul '06

Hans wrote: > [http://www.winehq.org/pipermail/wine-cvs/2006-June/023395.html] > Fix some copy/paste bugs in the implementation of condition operators. Congratulations on getting your patch into cvs! How far does this go towards fixing America's Army (http://bugs.winehq.org/show_bug.cgi?id=5139)? Also, are you still working on a conformance test for this, or did you stop once you found the obvious problem? - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

12 23

Call for volunteer: dwarf2 testing
by Eric Pouech 01 Jul '06

01 Jul '06

As you may have seen, there's now some support for the dwarf2 debug format (instead of stabs) in the Wine tree I'd like to get some feedback on the overall feedback on how it behaves. To do so, you need to reconfigure Wine with something like CFLAGS="$CFLAGS -gdwarf-2" ./configure and then make clean; make (so that all modules are recompiled with proper format) Normal debugging should be available with winedbg. If something goes wrong, please indicate: - console messages - error items - steps that led to it - version of gcc used TIA

3 4

WRT failed to Build
by Detlef Riekenberg 01 Jul '06

01 Jul '06

Hi. The cross-compiled WRT failed since 17. May. The native WRT failed even longer. And Ideas? -- By By ... ... Detlef

2 3

Wine 0.9.16 and ddraw issues
by Alexander Nicolaysen Sørnes 01 Jul '06

01 Jul '06

Greetings, I maintain several ddraw apps in the Application Database. While most of the problems introduced by Wine 0.9.16 have been fixed, some still remain. Command & Conquer and C&C: Red Alert When exiting the game, a messagebox displays: 'Unregonized Direct Draw result code: 1' A demo of Red Alert is available here: http://appdb.winehq.org/appview.php?versionId=4026 These two games, along with 'Warlords IIII: Darklords Rising' also have a strange SMP problem. In earlier Wine versions, these games would stop redrawing at some point. This also happens in Wine 0.9.16, but sometimes an error message is displayed instead, and then Wine receives a page fault. Emperor: Battle for Dune This game requires native d3drm.dll, which does not work anymore. Problems with this file was mentioned on this list a few days ago. Heroes of Might and Magic IV This game now displays a File menu when run in full-screen, which it is only supposed to do when run in a window. If I change the game's resolution, the menu disappears, but if I change it back to the resolution it had when it was started, the File menu is displayed again. Because of this menu, the game window is moved downwards, so the bottom part of the game is not displayed. Warcraft II Battle.net Edition The title screen is no longer displayed; it shows a black screen instead. This also happens with some of the campaign intro screens. The rest of the game seems to work as before. The new ddraw code fixes redrawing problems in at least a dozen games, and makes some of them faster, so it was a very good thing! :) Regards, Alexander N. Sørnes

3 4

DDRAW: Releasing attached surfaces
by Krzysztof Benkowski 01 Jul '06

01 Jul '06

Hello, In the latest version of wine (0.9.16) there is a regression which makes Dune 2000 crash. After some debugging i found that the problem lays in IDirectDrawSurfaceImpl_Release method. The game (Dune 2000) shows that the assumption that all attached surfaces should be destroyed regardless of their refcount is wrong. What causes the crash in few words: - first Dune 2000 creates a surface with a backbuffer - then it gets the backbuffer interface by GetAttachedSurface method (refcount for the backbuffer is incremented) - it releases the frontbuffer (the backbuffer is destroyed even though its refcount is higher than frontbuffer's) - creates new frontbuffer and an offscreen plain - when one starts a mission the game tries to use the old backbuffer (which is then destroyed) and causes a page fault So my fix is rather quick and thus i'm not quite sure if it's correct. That's because the game works with it but when it quits it leaves the backbuffer not released. I don't know if it's the game's fault or the fix has to be done some other way. I've done it this way: --- surface.c 26 Jun 2006 12:15:20 -0000 1.6 +++ surface.c 29 Jun 2006 14:09:59 -0000 @@ -377,7 +377,7 @@ IDirectDrawSurfaceImpl_Release(IDirectDr while( (surf = This->next_complex) ) { This->next_complex = surf->next_complex; /* Unchain it from the complex listing */ - IDirectDrawSurfaceImpl_Destroy(surf); /* Destroy it */ + IDirectDrawSurfaceImpl_Release(surf); /* Release it */ } If you (Stefan probably) need more info about the bug i can provide some logs Krzysiek

4 5

Re: riched20: corrected EM_GETLINE and wrong hWnd patches (combined into one)
by James Hawkins 30 Jun '06

30 Jun '06

On 6/30/06, Krzysztof Foltman <wdev(a)foltman.com> wrote: > ChangeLog: > * EM_GETLINE support (roughly based on code by Thomas Kho, although > there are important changes, for example, it works correctly in RichEdit > 1.0 emulation mode) (bug #4305) > * Workaround for wrong window handles (bug# 4452) > * EM_LINELENGTH handles paragraph ends properly (bug #5375) > > I'm sending it as one patch, just in case it gets rejected again - > trying to split the patch seems to give me some mysterious git problems. > I've just looked at this patch and the previous patch Thomas sent in, and saying that this is roughly based on his patch is putting it lightly. I see that you've added the 1.0 emulation change, but that doesn't warrant you putting your name on his patch. The correct way to go about this would be to wait till his patch gets accepted and then add your code in a new patch, or to make him aware of the problems in his implementation, so he can rewrite it or add the missing feature, but either way, he deserves credit for the code he wrote, and not just saying that your code was based off of his. -- James Hawkins

2 5

Gecko installer
by Jacek Caban 30 Jun '06

30 Jun '06

Hi. Please consider this mail as: Re: Built-in iexplore Re: acad 2004 licence file bug Re: Broken FC5 packages - stay clear. Last week Wine Gecko was mentioned a few times on this mailing list and I can see that there is no understanding of it. It's not really surprising as it's a big mess ATM. We can still use Mozilla ActiveX control (but that needs to be removed) or (xor) directly Gecko. Sometimes (if the app uses HTMLDocument directly, not via WebBrowser, like iexplore does) only the second option works. That has led me to do what I am planning to do later. I've just sent Wine Gecko installer. After it will be committed, a system similar to Mozilla ActiveX control download will have to be set up (that is upload the package to SourceForge and add a script that directs download of it). That will allow us to get rid of Mozilla ActiveX control. Thanks, Jacek

7 14

Re: winspool.drv: Write-strings warnings fix
by Detlef Riekenberg 30 Jun '06

30 Jun '06

Andrew Talbot wrote: > Changelog: > winspool.drv: Write-strings warnings fix. The touched parts should call the UNICODE-Functions instead of the ANSI-Functions. That's on my ToDo-List, but after the Port-Functions are fixed. Many tests for the affected Functions also needs to come before the touched Parts will be updated again. I'm ok with this Patch. -- By By ... ... Detlef

1 0