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@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@arcus:~/ft817$
Its Linux version works well:
patrol@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@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
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
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
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
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
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
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
