Bug introduced in ws2_32.dll.so in version 0.9.39
Hello, I have an application done in delphi that send and receive streams to a TCP server using indy. This applications is working fine since older versions of wine (0.9.5). After version 0.9.39 (up to last 0.9.41) the checksum of the stream is wrong when received in server side. The problem only happens with streams above 64KB (approximately). I debug the application but it's very dificult to detect the problem, the streams are very big to analyze them. If I replace "ws2_32.dll.so" with the one from 0.9.38 the problem is solved. Can I help in any way to solve it? I would like to posit in bugzilla but I think that I don't have sufficient information. Regards Christian c_pradelli(a)yahoo.com
On 7/20/07, Christian Pradelli <c_pradelli(a)yahoo.com> wrote:
Can I help in any way to solve it?
Its going to take a bit of debugging on your part. You can try to use git bisect and work through each patch from ws2_32 in 38 to 39 and see if you can isolate which one causes the problem. Thanks Steven -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
On 7/20/07, Christian Pradelli <c_pradelli(a)yahoo.com> wrote:
Hello,
I have an application done in delphi that send and receive streams to a TCP server using indy. This applications is working fine since older versions of wine (0.9.5). After version 0.9.39 (up to last 0.9.41) the checksum of the stream is wrong when received in server side. The problem only happens with streams above 64KB (approximately). I debug the application but it's very dificult to detect the problem, the streams are very big to analyze them.
If I replace "ws2_32.dll.so" with the one from 0.9.38 the problem is solved.
Can I help in any way to solve it? I would like to posit in bugzilla but I think that I don't have sufficient information.
It was fixed (http://bugs.winehq.org/show_bug.cgi?id=8771) so use the latest GIT. Should we maybe provide updates for previous wine versions in the case of serious regressions like this one?
Regards Christian c_pradelli(a)yahoo.com
Damjan
It was fixed (http://bugs.winehq.org/show_bug.cgi?id=8771) so use the latest GIT. Thank you, I will test it asap.
Should we maybe provide updates for previous wine versions in the case of serious regressions like this one?
I think that yes. This kind of bugs are very difficult to detect, so may be some people upgrade to a newer version because some graphical fix and they don't know that they are using a version with a dangerous bug that can corrupt data. Doing this it will be easy to test and find the optimal version to run a software.
Am Montag, 23. Juli 2007 18:09 schrieb Christian Pradelli:
Should we maybe provide updates for previous wine versions in the case of serious regressions like this one?
I think that yes. This kind of bugs are very difficult to detect, so may be some people upgrade to a newer version because some graphical fix and they don't know that they are using a version with a dangerous bug that can corrupt data. Doing this it will be easy to test and find the optimal version to run a software. No, it will not really help. Those updates for previous wine versions can contain regressions too.
Remember, Wine is still beta software. Releases are snapshots. Unless we have a declared stable release there is no point in providing unstable updates for old unstable releases. Of course anyone is free to maintain a few older wine versions, for the reasons stating above, and he is welcome to do so. However, I don't think we should spoil any existing resources on that.
Remember, Wine is still beta software. Releases are snapshots. Unless we have a declared stable release there is no point in providing unstable updates for old unstable releases.
Of course anyone is free to maintain a few older wine versions, for the reasons stating above, and he is welcome to do so. However, I don't think we should spoil any existing resources on that.
I agree with you about fixing older snapshots. Somebody is this forum says that is possible that wine never comes to be finished. If you think for a moment, also MSWindows never was finished, always has bugs to fix, but developers learned to live with them and fix the applications to works with that bugs. I did several changes to my application to be compatible with wine, but if every time a new snapshot is released something is broken I can't support my application to be "compatible with Wine". May be we can vote to chose the best working snapshot as manteined where only critical bugfixes can be applied, so linux distributions can use it as supported and software developers can use it too as reference to release they software as "compatible with Wine". Also you can tell your customers to download "maintained version of wine" from winehq.org and be shure that your application will work. This maintained snapshot could be released every 6 month with a good regretion tests. Of course you will say that Codeweavers already do that, but due to the price it's limited to expensive commercial applications, not for the small or simple ones that costs less than crossoveroffice. Regards Christian
Christian Pradelli wrote:
Remember, Wine is still beta software. Releases are snapshots. Unless we have a declared stable release there is no point in providing unstable updates for old unstable releases.
Of course anyone is free to maintain a few older wine versions, for the reasons stating above, and he is welcome to do so. However, I don't think we should spoil any existing resources on that.
I agree with you about fixing older snapshots. Somebody is this forum says that is possible that wine never comes to be finished. If you think for a moment, also MSWindows never was finished, always has bugs to fix, but developers learned to live with them and fix the applications to works with that bugs. I did several changes to my application to be compatible with wine, but if every time a new snapshot is released something is broken I can't support my That's the wrong approach. You shouldn't _need_ to make your application compatible to Wine. If your up runs into Wine bugs please fix Wine itself or at least open bug reports. Wine will make the efforts to be bug compatible to Windows _if_ real life applications depend on that behavior. But Wine won't be compatible to its own bugs.
application to be "compatible with Wine". May be we can vote to chose the best working snapshot as manteined where only critical bugfixes can be applied, so linux distributions can use it as supported and software developers can use it too as reference to release they software as "compatible with Wine". Also you can tell your customers to download "maintained version of wine" from winehq.org and be shure that your application will work. This maintained snapshot could be released every 6 month with a good regretion tests. Something like that is the plan for Wine-1.0.
Of course you will say that Codeweavers already do that, but due to the price it's limited to expensive commercial applications, not for the small or simple ones that costs less than crossoveroffice.
bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 -------------------------------------------------------------------- Reg. Adresse: Red Hat GmbH, Hauptstätter Strasse 58, 70178 Stuttgart Handelsregister: Amtsgericht Stuttgart HRB 153243 Geschäftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Werner Knoblich
participants (6)
-
Christian Pradelli -
Damjan Jovanovic -
Michael Stefaniuc -
Stefan Dösinger -
Steven Edwards -
Vitaliy Margolen