Official eMule-Board: Emule On Linux With Wine Mini-howto - Official eMule-Board

Jump to content


  • (16 Pages)
  • +
  • 1
  • 2
  • 3
  • 4
  • 5
  • Last »

Emule On Linux With Wine Mini-howto Fresh and up-to-the-minute

#41 User is offline   mindpirate 

  • Premium Member
  • PipPipPipPipPip
  • Group: Members
  • Posts: 299
  • Joined: 06-January 03

Posted 22 March 2004 - 08:34 PM

Oops, just updated it again. I had inserted the wrong registry patch modification. :-k
0

#42 User is offline   Painkiller Jane 

  • Splendid Member
  • PipPipPipPip
  • Group: Members
  • Posts: 104
  • Joined: 23-November 03

Posted 22 March 2004 - 08:36 PM

Quote

If it works, great, but unfortunately I won't be able to use that particular solution in the howto because I designed the howto to be newbie friendly and hence compiling eMule is excluded.


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

0

#43 User is offline   mindpirate 

  • Premium Member
  • PipPipPipPipPip
  • Group: Members
  • Posts: 299
  • Joined: 06-January 03

Posted 22 March 2004 - 09:11 PM

Painkiller Jane, on Mar 22 2004, 03:36 PM, said:

but since wine obviously doesn't even support the ms crypto random number generator...


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. :)
0

#44 User is offline   Painkiller Jane 

  • Splendid Member
  • PipPipPipPip
  • Group: Members
  • Posts: 104
  • Joined: 23-November 03

Posted 22 March 2004 - 09:47 PM

ok. i see.
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

0

#45 User is offline   mindpirate 

  • Premium Member
  • PipPipPipPipPip
  • Group: Members
  • Posts: 299
  • Joined: 06-January 03

Posted 22 March 2004 - 10:10 PM

Painkiller Jane, on Mar 22 2004, 04:47 PM, said:

ok. i see.
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. :thumbup: 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.
0

#46 User is offline   mindpirate 

  • Premium Member
  • PipPipPipPipPip
  • Group: Members
  • Posts: 299
  • Joined: 06-January 03

Posted 22 March 2004 - 10:12 PM

Painkiller Jane, on Mar 22 2004, 04:47 PM, said:

edit: possible workaround for unpatched emule:
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...
0

#47 User is offline   mindpirate 

  • Premium Member
  • PipPipPipPipPip
  • Group: Members
  • Posts: 299
  • Joined: 06-January 03

Posted 22 March 2004 - 10:19 PM

Sometimes I swear I'm half-baked when I post. :confused:

We would obviously want to use gpg in the script to generate the keypair, not libgcrypt.
0

#48 User is offline   mindpirate 

  • Premium Member
  • PipPipPipPipPip
  • Group: Members
  • Posts: 299
  • Joined: 06-January 03

Posted 22 March 2004 - 10:35 PM

Bummer, I can't get gpg to generate a 384-bit RSA key. The minimum it will spit out is 1024 bits. Any ideas?
0

#49 User is offline   Painkiller Jane 

  • Splendid Member
  • PipPipPipPip
  • Group: Members
  • Posts: 104
  • Joined: 23-November 03

Posted 22 March 2004 - 10:38 PM

Quote

...maybe we can simply write a little script...


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

0

#50 User is offline   mindpirate 

  • Premium Member
  • PipPipPipPipPip
  • Group: Members
  • Posts: 299
  • Joined: 06-January 03

Posted 22 March 2004 - 10:53 PM

Painkiller Jane, on Mar 22 2004, 05:38 PM, said:

no idea about that. my experience with linux scripting is very limited.


No problem, I can whip something up.

Quote

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.


That might be overkill. :D Let's call that one Backup Plan B, and the script option Backup Plan A.

Quote

but 1st i'd like to see if the wine devs come up with a workaround for ms crypto api.


Agreed. That's the Original Plan. :D

Quote

btw, the memleak/extra thread when using the webinterface is still present (using winxp dlls). :/
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.
0

#51 User is offline   Painkiller Jane 

  • Splendid Member
  • PipPipPipPip
  • Group: Members
  • Posts: 104
  • Joined: 23-November 03

Posted 22 March 2004 - 10:59 PM

i agree with 'the plans'.

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

0

#52 User is offline   mindpirate 

  • Premium Member
  • PipPipPipPipPip
  • Group: Members
  • Posts: 299
  • Joined: 06-January 03

Posted 23 March 2004 - 01:56 AM

This time my machine froze after completion of a 30 MB file download. It wasn't just X that froze, but everything, and it wasn't recoverable.

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. :rolleyes:
0

#53 User is offline   Painkiller Jane 

  • Splendid Member
  • PipPipPipPip
  • Group: Members
  • Posts: 104
  • Joined: 23-November 03

Posted 23 March 2004 - 02:44 AM

my wine/emule just crapped out right after finishing a file (300 megs).
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

0

#54 User is offline   mindpirate 

  • Premium Member
  • PipPipPipPipPip
  • Group: Members
  • Posts: 299
  • Joined: 06-January 03

Posted 23 March 2004 - 02:35 PM

Painkiller Jane, on Mar 22 2004, 09:44 PM, said:

it seems smth in the file completition process 'blocks' the GUI and sockets from working. GUI freezes. sockets timeout.


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

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.


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

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.


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

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.


Heh, ok we're definitely thinking along the same lines here.

Quote

i wonder if threre's a tool (win32 or linux) which allows monitoring of the message queue so i can verify that theory.


In Linux you can try DDD. You should have a copy on your SuSE discs.

Quote

edit: i also wonder if wine emulates w9x socket limits (50?) too. that'd really suck.


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

0

#55 User is offline   Painkiller Jane 

  • Splendid Member
  • PipPipPipPip
  • Group: Members
  • Posts: 104
  • Joined: 23-November 03

Posted 23 March 2004 - 05:00 PM

ok. this seems to be definitive one reason for wine/emule crashes.
again a crash and again a file is complete but just not copied to the incoming dir.

Quote

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.


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

Well you might want to check this page out. Don't let it discourage you.


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

0

#56 User is offline   mindpirate 

  • Premium Member
  • PipPipPipPipPip
  • Group: Members
  • Posts: 299
  • Joined: 06-January 03

Posted 23 March 2004 - 05:12 PM

Painkiller Jane, on Mar 23 2004, 12:00 PM, said:

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.


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

nay, like i said before: wine is alpha software and emule constantly 'beta' how stable can i get? so much for my expectations. ;)
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. :D
0

#57 User is offline   Painkiller Jane 

  • Splendid Member
  • PipPipPipPip
  • Group: Members
  • Posts: 104
  • Joined: 23-November 03

Posted 23 March 2004 - 05:30 PM

Quote

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.


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

0

#58 User is offline   mindpirate 

  • Premium Member
  • PipPipPipPipPip
  • Group: Members
  • Posts: 299
  • Joined: 06-January 03

Posted 23 March 2004 - 06:17 PM

Network events + GUI events + exception handling + blocking code = thread spaghetti. Not my favorite dish. :cry2:

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.
0

#59 User is offline   mindpirate 

  • Premium Member
  • PipPipPipPipPip
  • Group: Members
  • Posts: 299
  • Joined: 06-January 03

Posted 23 March 2004 - 07:38 PM

Not a peep from the Wine devs on my crypto questions yet even though I posted to both the newsgroup and mailing list. The thought occurs to me that there may not even be any Wine devs anymore, that maybe they're all working for CodeWeavers and TransGaming now. ;) Guess I'll pose the question to their lists also.
0

#60 User is offline   mindpirate 

  • Premium Member
  • PipPipPipPipPip
  • Group: Members
  • Posts: 299
  • Joined: 06-January 03

Posted 23 March 2004 - 07:53 PM

I've added the temporary workaround for secure user ID to the Known Issues seciton of the howto.
0

  • Member Options

  • (16 Pages)
  • +
  • 1
  • 2
  • 3
  • 4
  • 5
  • Last »

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users