Emule On Linux With Wine Mini-howto Fresh and up-to-the-minute
#41
Posted 22 March 2004 - 08:34 PM
#42
Posted 22 March 2004 - 08:36 PM
Quote
yes, i thought so.
but since wine obviously doesn't even support the ms crypto random number generator... what's there left to do? same i always do after trying wine?
waiting a couple of months and try again? ;p
-pkj
This post has been edited by Painkiller Jane: 22 March 2004 - 08:38 PM
#43
Posted 22 March 2004 - 09:11 PM
Painkiller Jane, on Mar 22 2004, 03:36 PM, said:
I wouldn't make that conclusion just yet. I put out a call to Wine devs for help regarding the status of Wine's CryptoAPI and explained our current predicament, so I'm waiting for word back from them. I hope they have good news, or at least can offer some clue that we can use to devise a workaround.
#44
Posted 22 March 2004 - 09:47 PM
anyways, i've made some little changes to crypto++ and emule and now secID works under wine.
if there's interest i can make exe and sources availbale on ed2k.
-pkj
edit: possible workaround for unpatched emule:
create a cryptkey.dat on win32.
copy cryptkey.dat into wine/emule's config folder enable use secID.
judging form emule's code the ms crypto api random generator is only used to generate the rsa keypair. it's not involved in sending/checking/etc.
edit2: unpatched emule works fine with secID if there's a 'pre-generated' cryptkey.dat in config dir.
This post has been edited by Painkiller Jane: 22 March 2004 - 10:14 PM
#45
Posted 22 March 2004 - 10:10 PM
Painkiller Jane, on Mar 22 2004, 04:47 PM, said:
anyways, i've made some little changes to crypto++ and emule and now secID works under wine.
if there's interest i can make exe and sources availbale on ed2k.j
That's good news, at least for the more technically adept eMule users out there. Perhaps you can generate source patches and post them here? I suppose the howto can be divided into two sections -- one dealing with tweaking Wine to work with the official eMule binary, and the other with patching and compiling eMule.
BTW, I've updated the Known Issues section of the howto to include the file chooser dialog issue.
#46
Posted 22 March 2004 - 10:12 PM
Painkiller Jane, on Mar 22 2004, 04:47 PM, said:
create a cryptokey.dat on win32.
copy cryptkey.dat into wine/emule's config folder enable use secID.
judging form emule's code the ms crypto api random generator is only used to generate the rsa keypair. it's not involved in sending/checking/etc.
edit2: unpatched emule works fine with secID if there's a 'pre-generated' cryptkey.dat in config dir.
Ah okay, then maybe we can simply write a little script that uses libgcrypt to generate an RSA key pair then formats the results into a proper cryptkey.dat file...
#47
Posted 22 March 2004 - 10:19 PM
We would obviously want to use gpg in the script to generate the keypair, not libgcrypt.
#48
Posted 22 March 2004 - 10:35 PM
#49
Posted 22 March 2004 - 10:38 PM
Quote
no idea about that. my experience with linux scripting is very limited.
but i might look into the possibilities to use crypto++ on linux to create a little executable which generates a compatible cryptkey.dat.
at least it'd make the emule wine-hack and related patch/exe publishing (and everything that gpl implies) unnecessary.
but 1st i'd like to see if the wine devs come up with a workaround for ms crypto api.
btw, the memleak/extra thread when using the webinterface is still present (using winxp dlls). :/
maybe it's my system. guess we have to wait for reports of other ppl joining the 'wine project'.
overall stability seems to be improved, though.
-pkj
edit: missed you post above while typing this:
never tried to use gpg. can't come up with any hints, sorry.
This post has been edited by Painkiller Jane: 22 March 2004 - 10:50 PM
#50
Posted 22 March 2004 - 10:53 PM
Painkiller Jane, on Mar 22 2004, 05:38 PM, said:
No problem, I can whip something up.
Quote
at least it'd make the emule wine-hack and related patch/exe publishing (and everything that gpl implies) unnecessary.
That might be overkill. Let's call that one Backup Plan B, and the script option Backup Plan A.
Quote
Agreed. That's the Original Plan.
Quote
maybe my it's system. guess we have to wait for reports of other ppl joining the 'wine project'.
overall stability seems to be improved, though.
Glad stability has improved. The memory leak is puzzling. I'll keep thinking of ways to troubleshoot it.
#51
Posted 22 March 2004 - 10:59 PM
wrt the webinterface memleak. since the additional thread/mem usage occurs when logging out of emule a workaround might be not to log out but just close the browser window and let the websession time out.
gonna try that next.
-pkj
edit:
the additional thread and mem usage is gone when not logging out but just closing the browser window.
i've noticed smth else. the loading of the emule logo picture on the webinterface's login screen is terribly slow or doesn't load at all (chokes). it should take less than a second on LAN. weird. maybe the leak and the not finished loading of the logo is related...
This post has been edited by Painkiller Jane: 23 March 2004 - 12:03 AM
#52
Posted 23 March 2004 - 01:56 AM
It's possible these memory management and crash/freeze problems are due to the Win2K/XP dll's. One of the Wine devs informed me that Win2K/XP dll's are not supported in Wine, so I'm going to try and retool our approach to use Win98. To speed this along I'm installing Win98SE under VMware at the moment so I can have easy access to a working Win98 environment. Haven't had Win98 on any of my machines in 4 or 5 years, so this should be fun.
#53
Posted 23 March 2004 - 02:44 AM
edit: just did it again. a file is complete but just not copied to incoming folder when it crashed.
same old X11 socket error. so there might be a problem related to completing files like you already suspected.
but there're a good bunch of ppl (including me) who experience freezes and other 'stalling' behaviour of emule while completing files. so that might not be a real wine problem. i guess windows somehow manages to recover from those guifreezes but wine can't. for instance my w2k emule used to drop nearly all sources right after completing a file (including sources not belonging to the finished file).
it seems smth in the file completition process 'blocks' the GUI and sockets from working. GUI freezes. sockets timeout.
trying to deal with that situation i re-coded the whole file completition code of some emule version (0.27 or so). the problems were less noticable afterwards i.e. i only experienced freezing and source drops when big files > 500megs were completed.
but it ultimately showed that there're certain message driven events that need handling while a file completes but they aren't. at least not in time.
this is smth that is well beyond me to fix. seems the file completition thread blocks the main thread and i'm not able to see any reason in the code for that.
wrt the dlls: of course we should only use the OSs dlls which the wine devs suggest but i don't think comctl32 and riched20 have any direct connection to the file completing process and seem to work nicely for me.
my guess is that while completing files a lot messages 'stall' and get queued up in the message queue. when the file is finished all those messages need to be handled (timer messages, sockets, progressbars, etc need to be processed) and wine can't cope with all those messages at once.
i wonder if threre's a tool (win32 or linux) which allows monitoring of the message queue so i can verify that theory.
-pkj
edit: i also wonder if wine emulates w9x socket limits (50?) too. that'd really suck.
This post has been edited by Painkiller Jane: 23 March 2004 - 09:26 AM
#54
Posted 23 March 2004 - 02:35 PM
Painkiller Jane, on Mar 22 2004, 09:44 PM, said:
Hmmm, I think you're on to something. Maybe the hash checking routine is being executed in the event handler thread, which would be a big no-no in proper MVC design. That gives us a plausible explanation why for small files this problem doesn't show itself but for larger files where the hashing is blocking the GUI and all event handling for a longer period, there is a greater chance of the event queue backing up.
Quote
but it ultimately showed that there're certain message driven events that need handling while a file completes but they aren't. at least not in time.
this is smth that is well beyond me to fix. seems the file completition thread blocks the main thread and i'm not able to see any reason in the code for that.
Try lowering the thread priority of the completion/hashing thread. In fact next-to-lowest priority should be fine because it's not exactly a time-dependent operation, the GUI and events are more important.
Quote
True enough. The NT-stream comctl32 and riched20 API's are backwards-compatible, so we're lucky that eMule seems to mostly use calls that are not specific to the newer Win2K/XP API's.
Quote
Heh, ok we're definitely thinking along the same lines here.
Quote
In Linux you can try DDD. You should have a copy on your SuSE discs.
Quote
Well you might want to check this page out. Don't let it discourage you.
http://www.winehq.org/site/status_wine
This post has been edited by mindpirate: 23 March 2004 - 03:06 PM
#55
Posted 23 March 2004 - 05:00 PM
again a crash and again a file is complete but just not copied to the incoming dir.
Quote
the thread has already 'below normal' priority. i tried to set it as low as 'idle' priority but there doesn't seem to be much of a difference but that the completing takes longer. the unwanted effects stay the same, though.
i will put in some code to determine where exactly in the completing process the crash happens.
Quote
oh, yeah. i remember that page. last time i looked at it (when slackware 3.0 or was it suse 4.4(?) was freshly out) at least there's been a lot progress.
but discourage? nay, like i said before: wine is alpha software and emule constantly 'beta' how stable can it get? so much for my expectations.
actually i'm pretty amazed that wine handles emule so 'well'.
-pkj
This post has been edited by Painkiller Jane: 23 March 2004 - 05:41 PM
#56
Posted 23 March 2004 - 05:12 PM
Painkiller Jane, on Mar 23 2004, 12:00 PM, said:
i will put in some code to determine where exactly in the completing process the crash happens.
Okay, then since the thread priority is already as low as it can go, the hashing is almost certainly being called and executed within the event handling thread, so check for that if you can when you debug. If this turns out to be the case, then that behavior needs to be changed in the original eMule source tree, not just some mod for Wine, because that's a definite design flaw. We should notify the eMule dev team if so.
Quote
actually i'm pretty amazed that wine handles emule so 'well'.
True. And I've found that some "alpha" Linux applications are actually more stable than "production" Windows applications.
#57
Posted 23 March 2004 - 05:30 PM
Quote
true.
afai can see in the hashing thread a CSingleLock is used of which i'm not certain that it only holds the hashing thread but also the main thread. will investigate that. there's also exception handling in that thread. i'm also not sure if the thread 'gracefully closes' i.e. removes the CSingleLock and terminates the hashing thread if an exception is triggered. will look into that also.
for now i've added code to see how far file completition gets before crashing wine.
waiting for the next file to complete... grabbing food...
laters,
-pkj
This post has been edited by Painkiller Jane: 23 March 2004 - 05:36 PM
#58
Posted 23 March 2004 - 06:17 PM
I agree that we've zeroed in on the cause of the crashes, if not yet the solution. I'll update the howto's Known Issues section to reflect this new info.
#59
Posted 23 March 2004 - 07:38 PM
#60
Posted 23 March 2004 - 07:53 PM