[mindpirate]

Painkiller Jane, on Apr 16 2004, 01:23 AM, said:

haven't seen you mentioning if wine/cxoffice emule works on your setup for longer times (30+ hours).

I've just now passed the 30-continuous-hours mark with eMule under CrossOver. No crashes or weird behavior. 12 files downloaded this session, mostly multi-megabyte in size. Uploading the entire time at ~30Kbps to anywhere from 2 to 9 clients.

I'll keep it going as long as I can.

[Painkiller Jane]

good for you.
i dunno if you mentioned it before but i'd like to know which distribution you use.
i'm thinking of setting up a second box with the distrib that you use to check if that works better for me. if so i gonna switch distribs on the 'trouble' box.

cheers,

-pkj

[mindpirate]

Here's the rundown on my main box:

OS:
SuSE 9.0 Professional w/all current updates and patches
* Kernel 2.4.21-202-athlon
* KDE 3.1.4-46
* XFree86 4.3.0.1-46

Hardware:
Athlon XP 2400+ @ 2GHz
2x512 MB Corsair DDR400 PC3200 RAM (dual-channel enabled)
Abit NF7-S rev. 2.0 w/ nVidia nForce2 Ultra400 chipset
ATI Radeon 9000 Pro
2xATA133 Maxtor drives (20GB,60GB)

Software:
CodeWeavers CrossOver Office 2.1-14, from the SuSE Wine Rack CD-ROM

Let me know if I left anything important out.

[Painkiller Jane]

hrm, your OS specs are pretty much the same as mine.
but your cxoffice seems to have a few more patch levels.
gonna try a more recent version sometime soon.

-pkj

[Painkiller Jane]

i've installed clean suse 9.0 + updates and patches on the other box.
installed cxoffice 2.1.0. ran emule. same crash as on the first box.
expanding an item (file) in the transfer list to see it's sources crashes cxoffice.

getting the cxoffice 2.1-14 now...

-pkj

[Painkiller Jane]

emule 0.42e works fine with cxoffice 2.1-14.
no crash when expanding sources anymore.
crashes when quitting emule, though, but hey, minor problem.
preparing for a long time test to see if i still get these WSA bla bla errors.
just need to finish some downloads 1st.

cheers,

pkj

[mindpirate]

Painkiller Jane, on Apr 20 2004, 05:41 PM, said:

emule 0.42e works fine with cxoffice 2.1-14.
no crash when expanding sources anymore.
crashes when quitting emule, though, but hey, minor problem.

Well I suppose we could pull that revision of CrossOver from the CodeWeavers CVS and compare it with the current Wine sources to see what tweaks haven't "crossed over" from XO to Wine yet, then narrow the results down to those affecting the problem areas we're dealing with. (Sounds so simple, doesn't it? )

By the way, I understand that CodeWeavers will let you make your own builds from their CVS for free, but you won't have their support of course, and anyhow compiling something like CrossOver would be terrifying for newbies, no matter how well-written our Howto is.

I haven't tried the April build of Wine yet (their SuSE packager just got around to making a SuSE RPM), but I think I'll give it a try before digging into the XO sources.

[mindpirate]

mindpirate, on Apr 20 2004, 05:52 PM, said:

By the way, I understand that CodeWeavers will let you make your own builds from their CVS for free

Er, maybe that's wrong, and only applicable to TransGaming's WineX CVS. I can't seem to find info on any public CodeWeavers CVS... swear I read something about it.

[Painkiller Jane]

Quote

...their SuSE packager just got around to making a SuSE RPM...

yepp, noticed that too. downloaded the sources from dev page couple of days ago, though.
if i could only remember if i was going to compile them or already did...
anyways, will check on that after/during the cxoffice long time test.

Quote

Er, maybe that's wrong, and only applicable to TransGaming's WineX CVS. I can't seem to find info on any public CodeWeavers CVS... swear I read something about it. 

no idea about that but i think i saw sources on the suse wine rack cd. maybe there's already all you're looking for.

pkj

This post has been edited by Painkiller Jane: 21 April 2004 - 01:24 AM

[mindpirate]

Painkiller Jane, on Apr 20 2004, 08:19 PM, said:

no idea about that but i think i saw sources on the suse wine rack cd. maybe there's already all you're looking for.

Didn't think of that, but I just looked and there are no sources on my CD... so I wonder how one is supposed to get access to the source, since Wine is LGPL'ed, and XO is based on it. Wtf...

[mindpirate]

They've skillfully obscured the location of the source here.

I downloaded the ambiguously-named "wine.tgz" file from there and it's Wine version 20030318, so that's apparently what they built CrossOver 2.1 on. I guess we just apply the patches from the SuSE Wine Rack CD to that source. Or maybe what we're really looking for is in those patches...

[Painkiller Jane]

hrm, the source packages on cd are just gnome and python stuff. no sign of a wine source package and no wine src patches either...
what patches are you talking about?

besides my patch confusion,

Quote

I guess we just apply the patches from the SuSE Wine Rack CD to that source. Or maybe what we're really looking for is in those patches...

sounds like a plan to me.

-pkj

This post has been edited by Painkiller Jane: 21 April 2004 - 02:34 AM

[mindpirate]

Painkiller Jane, on Apr 20 2004, 09:31 PM, said:

what patches are you talking about?

Silly me... I thought the "patches" directory contained patches for CrossOver... looks like SuSE's RPM data instead.

Now I'm stumped. Guess I'll just ask CodeWeavers.

[mindpirate]

After exhaustively scouring the CodeWeavers mailing list archive, I've learned two things:

• CodeWeavers is strangely evasive about anything having to do with CrossOver source code, even when asked specific questions directly. I think they've got Sun Syndrome.
  
  
• The "wine.tgz" file is in fact their version of Wine, no patches needed. I'm gonna compile it and see if it flies.

[Painkiller Jane]

Quote

CodeWeavers is strangely evasive about anything having to do with CrossOver source code, even when asked specific questions directly. I think they've got Sun Syndrome.

it's kinda interesting how they pulled off a commercial product by using only gpl'ed software (except for their gui). no wonder they actually don't want to comment on the changes they've made to wine. nonetheless gpl requires some kind of changelog or comments with dates in the sources marking the changed parts.
let's assume they follow gpl requirements. so there've to be some more or less obvious hints what they've changed.

i guess diffing their and the official wine sources of that date will also do the trick.

Quote

The "wine.tgz" file is in fact their version of Wine, no patches needed. I'm gonna compile it and see if it flies.

let's hope so and it better be the wine used for their version 2.1-14.

pkj

This post has been edited by Painkiller Jane: 21 April 2004 - 01:04 PM

[mindpirate]

Painkiller Jane, on Apr 21 2004, 07:58 AM, said:

i guess diffing their and the official wine sources of that date will also do the trick.

Good idea. I found a matching version in Wine CVS. I'm pulling it down now, then I'll run a diff with CodeWeavers' version.

[Edit] Bloody hell, their CVS is slower than an AOL user. This may take all day...

[Edit 2] FYI, the German mirror is much faster than the US, even though I'm in the US... go figure...

[Edit 3] There are significant differences in both "20030318" versions, especially in comctl32 (where I believe most of our GUI grief stems from). So I'm going to compare CodeWeavers' "20030318" version with the most recent build of Wine to see if those changes ever made their way into the Wine source tree as CodeWeavers claims is their policy. I suspect the changes that work so well for us probably were introduced into the Wine tree, but were probably broken shortly after by some subsequent patching.

This post has been edited by mindpirate: 21 April 2004 - 05:47 PM

[mindpirate]

Just in comctl32 alone, there are a few functions and data structures missing from the latest Wine build that are in CodeWeavers' 20030318 build. (There are also many new additions that aren't present in the XO version, as expected.) The XO patches were either added to the Wine tree then superceded by improvements, or were never added.

Either way, whatever they've been doing recently in the official Wine tree is a few steps in the wrong direction as far as eMule under Wine is concerned. I wonder if XO version 3.0 (due out any day now) will also break eMule functionality.

The way I see it, that leaves us with little choice but to require compilation of Wine for our Howto, and the easiest path would be to build from XO's source.

I really wanted to avoid compilation in the Howto, but at the moment I can't see any practical alternative. Perhaps I can script most or all of the process for the newbies.

Any ideas?

[Edit] By the way, how is eMule doing so far under XO for you?

This post has been edited by mindpirate: 21 April 2004 - 06:22 PM

[Painkiller Jane]

so far emule works pretty ok under XO 2.1-14 on the same machine which we nearly suspected to be somehow defect.
i still haven't run any long time test yet (need the line for other stuff atm) but i've up/downloaded a few files without problems (no crashing while finishing a file).
the 'dbl-clk-on-file-to-expand-sources' crash is completely gone and all else seem to work properly too (no freezes or such like under XO 2.1.0).
all in all it looks very promising.

Quote

The way I see it, that leaves us with little choice but to require compilation of Wine for our Howto, and the easiest path would be to build from XO's source.

I really wanted to avoid compilation in the Howto, but at the moment I can't see any practical alternative. Perhaps I can script most or all of the process for the newbies.

maybe it's possible to compile only the comctl32.so and replace the file of a installed rpm'ed wine instead of compiling the whole thing?
but i guess that implies certain gpl requirements have to be followed if one rips out that particular part of the XO wine source.

compiling the wine package is certainly the 'cleanest' way.
of course this can be an obstacle for newbies but sooner or later they have to deal with compiling stuff on linux anyways. it's that or someone is able/willing to maintain a compiled rpm'ed package esp. for the 'emule-wine'.

-pkj

This post has been edited by Painkiller Jane: 21 April 2004 - 08:10 PM

[mindpirate]

Painkiller Jane, on Apr 21 2004, 03:06 PM, said:

maybe it's possible to compile only the comctl32.so and replace the file of a installed rpm'ed wine instead of compiling the whole thing?
but i guess that implies certain gpl requirements have to be followed if one rips out that particular part of the XO wine source.

I was thinking the same thing. CodeWeavers is distributing that source code under LGPL (I can't find anything that makes exclusions on their particular contributions in the distro docs) so it appears we can safely use their code or make patches consisting of their changes if necessary.

Reading on the Wine list though, replacing one of Wine's internal libs with a different version could really screw things up. I suppose there's no harm in trial-and-error though. I've already installed and re-installed Wine/XO probably 2 dozen times during the course of this project.

Your socket trouble was with dll's other than comctl32 however. If we're looking at replacing more than a handful of dll's, then we might as well just use CodeWeavers' entire codebase for the build. We know it works together, at least for our purposes.

I've discovered it's possible to have more than one Wine implementation on your box. Because the CodeWeavers version is so old, I can make the installation script ask the user if they are already using Wine and if they would like a parallel installation expressly for eMule. Or they could optionally elect to uninstall their current Wine version, or whatever. A Wine installation is tiny anyhow, no harm in having multiples.

Just kinda thinking out loud here...

[Painkiller Jane]

completely agreed.

i just noticed 2 things when running emule 0.42e under XO 2.1-14.

1st is what you already mentioned before. expanding an item/file in the transfer window displays kinda wrong results. seems always the 1st file in the list (regardless which was clicked) gets expanded. once expanded it gives ya a hard time to unexpand the display. no crash like under 2.1.0, though.

2nd is that in extended settings the check boxes for 'check hd space' and 'advanced controls...' are overlapping which makes switching on/off the A4AF features impossible (unless one edits preferences.ini manually).
the check HD space options seems to work fine, though.

i have the impression that XO doesn't handle tree displays correctly (file expand, extended options). i can't remember if these problems were present under official wine. IIRC you mentioned the source expand problem wasn't present under XO with emule 0.42d. if it's not too much hassle, do you mind to double check that?

-pkj

This post has been edited by Painkiller Jane: 21 April 2004 - 10:45 PM