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

Jump to content


  • (16 Pages)
  • +
  • « First
  • 2
  • 3
  • 4
  • 5
  • 6
  • Last »

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

#61 User is offline   Painkiller Jane 

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

Posted 23 March 2004 - 08:44 PM

ah, nice.
the howto gets more and more complete.
i think even though it's not a wine related problem you should mention that ping related features i.e. upload speed sense need some linux tweaking before it can be used.

Quote

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.


hehe, yeah, that could be the case. i don't follow wine development closely (i just try it every few months and see if old problems have been solved.) so i can't really judge the state of the project.

anyways, another file finished. another crash but with unexpected results.
emule doesn't even run to the point where the completefile thread is spawned.
need to add more check point code...

when i restart emule the file completion thread is spawned and and does it's work flawlessly.

my crude log output:

Quote

23.03.2004 23:07:33: Completing file-hashing for "painkiller jane & the punisher - love sick.cbr"
23.03.2004 23:07:33: CPartFile::RemoveAllSources(bool bTryToSwap) - start
23.03.2004 23:07:33: CPartFile::RemoveAllSources(bool bTryToSwap) - end
23.03.2004 23:07:33: CPartFile::PerformFileComplete() - CSingleLock sLock(&m_FileCompleteMutex, TRUE)
23.03.2004 23:07:33: CPartFile::PerformFileComplete() - Prepare filenames/dirs
23.03.2004 23:07:33: CPartFile::PerformFileComplete()á // close permanent handle
23.03.2004 23:07:33: CPartFile::PerformFileComplete() rename
23.03.2004 23:07:33: CPartFile::PerformFileComplete()á Uncompress file
23.03.2004 23:07:33: CPartFile::PerformFileComplete()á remove temp files
23.03.2004 23:07:33: CPartFile::PerformFileComplete()á sLock.Unlock()
23.03.2004 23:07:33: CPartFile::PerformFileComplete()á Post Message
23.03.2004 23:07:33: CPartFile::PerformFileComplete()á DONE


it seems that the singlelock doesn't cause the problem.
i've put in more check point code.

waiting for the next file to complete...

-pkj

This post has been edited by Painkiller Jane: 23 March 2004 - 08:51 PM

0

#62 User is offline   mindpirate 

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

Posted 23 March 2004 - 09:18 PM

Painkiller Jane, on Mar 23 2004, 03:44 PM, said:

ah, nice.
the howto gets more and more complete.
i think even though it's not a wine related problem you should mention that ping related features i.e. upload speed sense need some linux tweaking before it can be used.


Yeah I should definitely write up something about ICMP. If users have a firewall or NAT installed, due to the variety of such packages for Linux instructing users how to enable ICMP packets under non-root privileges could be a monumental task. The mini-HOWTO would become a full-fledged HOWTO, and that would probably scare off more than a few n00bs. :D

Think I'll just work up a basic solution for non-firewalled systems then provide links to the relevant documentation of the major Linux firewalls. In my particular case I've got my SuSE boxes NATing through a Debian-based router box, so I'd have to screw around with that too to get ICMP working (but of course that's also true when I run eMule under Windows).

Quote

anyways, another file finished. another crash but with unexpected results.
emule doesn't even run to the point where the completefile thread is spawned.
need to add more check point code...

when i restart emule the file completion thread is spawned and and does it's work flawlessly.


That is surprising indeed. Is there some other blocking I/O operation going on after the download finishes but before the file is hashed?
0

#63 User is offline   Painkiller Jane 

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

Posted 23 March 2004 - 09:40 PM

wrt to the ping issue i think merely mentioning it in the howto and maybe point to a few places (howtos, faqs, etc) which explain how to enable icmp is enough.

concerning the file completing issue: afai can see (the code has changed a lot since i looked at it the last time) there's a hash thread using locks which is spawned by the file completition thread (if the file hasn't been already hashed before) which also uses locks.
i've tagged the code with check point code so when the next file is going to be finished we should see where emule crashes unless i've done something completely moronic. ;)

-pkj
0

#64 User is offline   mindpirate 

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

Posted 23 March 2004 - 10:49 PM

Painkiller Jane, on Mar 23 2004, 04:40 PM, said:

wrt to the ping issue i think merely mentioning it in the howto and maybe point to a few places (howtos, faqs, etc) which explain how to enable icmp is enough.

Bah, it looks like enabling outbound pings is going to be more difficult than enabling inbound. On Linux boxes the /bin/ping command is owned by root. It has suid root set, but Wine apparently doesn't allow you to take advantage of that, meaning your Wine apps can't grab permission to execute /bin/ping unless Wine itself is running under root, which everyone and their dog knows is a bad idea.

I have a couple of ideas to get around this that I'm going to try. If they don't work then it would seem the only solution would be to chown the /bin/ping command to the user's ownership instead of root's, and that would mean leaving your box open to being used as a DoS agent. But giving Windows executables under Wine access to /bin/ping is probably more dangerous I suppose when you really think about it. Ah well, we can leave such concerns to the discretion of each user, and just give them a stern warning. ;)
0

#65 User is offline   mindpirate 

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

Posted 24 March 2004 - 12:13 AM

Okay, /bin/ping can't be chowned because it needs root privleges to use ICMP packets, and messing with security at that level of networking on a Linux box would simply be too dangerous when weighed against the relatively miniscule benefit of enabling eMule to use /bin/ping.

Unfortunately it seems that all solutions to this (short of the Wine devs changing their policy on the suid issue or at least allowing use of /bin/ping) involve security risks. Of these, the solution that would present the least amount of risk IMO would be to chown Wine's copy of emule.exe to root and set suid on it. Note that this will still be dangerous (I won't elaborate because I don't want to give anyone any evil ideas ;) ), but to put it into perspective it would not be any more dangerous than running eMule under a real Windows environment, which most eMule users do every day quite uneventfully anyhow. ;)

If anyone has a better idea please speak up, else I'll add this solution to the howto.
0

#66 User is offline   mindpirate 

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

Posted 24 March 2004 - 02:25 AM

Just read a post on the eMule Plus forums (at least I think that's where I was :confused:) that said UploadSpeedSense doesn't use standard ICMP pings, but creates custom ICMP packets instead.

Can someone confirm this? I couldn't find any relevant info at ZZ's site or in the forum hosted here.

Naturally I checked the source code for Wine's ICMP API (icmp_main.c), and it appears /bin/ping isn't used after all. The good news is that chowning emule.exe to root and setting suid as I outlined in my previous post should still solve the ping problem regardless. But I'd still be more comfortable knowing what exactly we're dealing with here with these USS pings.
0

#67 User is offline   Painkiller Jane 

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

Posted 24 March 2004 - 01:22 PM

non standard icmp pings? ook?
well, maybe inquire about that by pm to zz?
i wouldn't know the difference between standard and custom icmp packets.

wrt to the file finishing problem.

2 files finished on my emule.

1st one was 108 megs big and didn't produce a crash.
my crude check point log shows it goes all the way through file completion without problems.

Quote

24.03.2004 15:28:44: Finished part 8 of "professor xavier and the x-men 01- 18 - (phalkon).rar"
24.03.2004 15:28:44: CPartFile::CompleteFile(bool bIsHashingDone) -start
24.03.2004 15:28:44: CPartFile::CompleteFile(bool bIsHashingDone) - GetKadFileSearchID()
24.03.2004 15:28:44: CPartFile::CompleteFile(bool bIsHashingDone) -á this->srcarevisible
24.03.2004 15:28:44: CPartFile::CompleteFile(bool bIsHashingDone) -á this->srcarevisible
24.03.2004 15:28:44: CPartFile::CompleteFile(bool bIsHashingDone) -á !bIsHashingDone = false
24.03.2004 15:28:44: CPartFile::CompleteFile(bool bIsHashingDone) -á !bIsHashingDone done
24.03.2004 15:28:44: CAddFileThread::Run() - start
24.03.2004 15:28:44: CAddFileThread::Run() -á CoInitialize(NULL);
24.03.2004 15:28:44: CAddFileThread::Run() - CSingleLock sLock1(&theApp.hashing_mut)
24.03.2004 15:28:44: CAddFileThread::Run() - sLock1.Lock();
24.03.2004 15:28:44:á CAddFileThread::Run() -á sLock1.Lock(); - success
24.03.2004 15:28:44: CAddFileThread::Run() - newrecord->CreateFromFile
24.03.2004 15:28:44: CKnownFile::CreateFromFile(LPCTSTR in_directory, LPCTSTR in_filename) - start
24.03.2004 15:28:44: CKnownFile::CreateFromFile(LPCTSTR in_directory, LPCTSTR in_filename) -á // open file
24.03.2004 15:28:44: CKnownFile::CreateFromFile(LPCTSTR in_directory, LPCTSTR in_filename) -á FILE* file = fopen(strFilePath, ...
24.03.2004 15:28:44: CKnownFile::CreateFromFile(LPCTSTR in_directory, LPCTSTR in_filename) -á // set filesize
24.03.2004 15:28:44: CKnownFile::CreateFromFile(LPCTSTR in_directory, LPCTSTR in_filename) - SetFileSize(_filelength(file->_file));
24.03.2004 15:28:44: CKnownFile::CreateFromFile(LPCTSTR in_directory, LPCTSTR in_filename) -á setvbuf(file, NULL, _IOFBF, 1024*8*2);
24.03.2004 15:28:45: CKnownFile::CreateFromFile(LPCTSTR in_directory, LPCTSTR in_filename) - // create hashset
24.03.2004 15:28:45: Hashing file: "z:\home\jane\emule\temp\001.part"
24.03.2004 15:28:50: CKnownFile::CreateFromFile(LPCTSTR in_directory, LPCTSTR in_filename) -á // set lastwrite date
24.03.2004 15:28:50: CKnownFile::CreateFromFile(LPCTSTR in_directory, LPCTSTR in_filename) - fclose(file);
24.03.2004 15:28:50: CKnownFile::CreateFromFile(LPCTSTR in_directory, LPCTSTR in_filename) -á UpdateMetaDataTags();
24.03.2004 15:28:50: CKnownFile::CreateFromFile(LPCTSTR in_directory, LPCTSTR in_filename) - UpdatePartsInfo();
24.03.2004 15:28:50: CKnownFile::CreateFromFile(LPCTSTR in_directory, LPCTSTR in_filename) - END
24.03.2004 15:28:50: Completing file-hashing for "professor xavier and the x-men 01- 18 - (phalkon).rar"
24.03.2004 15:28:50: CPartFile::CompleteFile(bool bIsHashingDone) -start
24.03.2004 15:28:50: CPartFile::CompleteFile(bool bIsHashingDone) - GetKadFileSearchID()
24.03.2004 15:28:50: CPartFile::CompleteFile(bool bIsHashingDone) -á this->srcarevisible
24.03.2004 15:28:50: CPartFile::CompleteFile(bool bIsHashingDone) -á this->srcarevisible
24.03.2004 15:28:50: CPartFile::CompleteFile(bool bIsHashingDone) -á !bIsHashingDone = true
24.03.2004 15:28:50: CPartFile::RemoveAllSources(bool bTryToSwap) - start
24.03.2004 15:28:50: CPartFile::RemoveAllSources(bool bTryToSwap) - end
24.03.2004 15:28:50: CPartFile::CompleteFile(bool bIsHashingDone) -á create thread
24.03.2004 15:28:50: CPartFile::CompleteFile(bool bIsHashingDone) -á thread created and resumed
24.03.2004 15:28:50: CPartFile::CompleteFile(bool bIsHashingDone) -á Update lists etc.
24.03.2004 15:28:50: CPartFile::CompleteFile(bool bIsHashingDone) -á DONE!
24.03.2004 15:28:50: CPartFile::CompleteThreadProc - start
24.03.2004 15:28:50: CPartFile::CompleteThreadProc - pFile->PerformFileComplete()
24.03.2004 15:28:50: CPartFile::PerformFileComplete() - CSingleLock sLock(&m_FileCompleteMutex, TRUE)
24.03.2004 15:28:50: CPartFile::PerformFileComplete() - CSingleLock sLock(&m_FileCompleteMutex, TRUE) - success
24.03.2004 15:28:50: CPartFile::PerformFileComplete()á // close permanent handle
24.03.2004 15:28:50: CPartFile::PerformFileComplete() rename
24.03.2004 15:28:50: CPartFile::PerformFileComplete()á Uncompress file
24.03.2004 15:28:50: CPartFile::PerformFileComplete()á remove temp files
24.03.2004 15:28:50: CPartFile::PerformFileComplete()á sLock.Unlock()
24.03.2004 15:28:50: CPartFile::PerformFileComplete() -á sLock.Unlock(); - success
24.03.2004 15:28:50: CPartFile::PerformFileComplete()á Post Message
24.03.2004 15:28:50:á CPartFile::PerformFileCompleteEnd - start
24.03.2004 15:28:50: Downloading professor xavier and the x-men 01- 18 - (phalkon).rar complete :-)
24.03.2004 15:28:51:á CPartFile::PerformFileCompleteEnd - end
24.03.2004 15:28:51: CPartFile::PerformFileComplete()á DONE
24.03.2004 15:28:51: CPartFile::CompleteThreadProc - end
24.03.2004 15:28:50: CAddFileThread::Run() - sLock1.Unlock();
24.03.2004 15:28:51:á CAddFileThread::Run() -á sLock1.Unlock(); - success
24.03.2004 15:28:51: CAddFileThread::Run() - CoUninitialize();
24.03.2004 15:28:51: CAddFileThread::Run() - DONE


the second file was 168 megs and made emule crash

log

Quote

24.03.2004 16:09:34: Finished part 16 of "tubs.304.avi"
<- HERE I WAS EXPECTING A FILE COMPLETION THREAD TO START. BUT NADA!
24.03.2004 16:09:40: gogmm: Upload session ended due to score.
24.03.2004 16:10:39: RCV: Source Request to fast. (This is testing the new timers to see how much older client will not receive this)
<- CRASH


emule doesn't even start the complete file thread. it crashes somewhere earlier(?).
even weirder, when the 1st file finished downloading it's last part the file completion thread started imediately (in the very same second the last part was finished).

Quote

24.03.2004 15:28:44: Finished part 8 of "professor xavier and the x-men 01- 18 - (phalkon).rar"
24.03.2004 15:28:44: CPartFile::CompleteFile(bool bIsHashingDone) -start
...


the file which crashed emule didn't spawn a file completion thread.
but emule crashed 1 minute and 5 seconds after finishing the last part.

1+ minute and no file completiton thread? wtf?
only reason that i can think of is that another file is being hashed so the new completing thread has to wait. but the last file hashing was already done 40 mins ago. so that's out of question.

guess i have to dig deeper into the code and add even more check point code...
but 1st some sleep. my w2k box died last night (for no obvious reason, i suspect it was sulking 'cause i've spent so much time tinkering with linux ;) ) and i spent the whole night setting up a new machine, doh!

night,

-pkj

edit:
a very small (500kb) file just finished and crashed emule.
this time during the file completion process:

Quote

24.03.2004 16:58:58: Finished part 0 of "blargh.rar"
24.03.2004 16:58:58: CPartFile::CompleteFile(bool bIsHashingDone) -start
24.03.2004 16:58:58: CPartFile::CompleteFile(bool bIsHashingDone) - GetKadFileSearchID()
24.03.2004 16:58:58: CPartFile::CompleteFile(bool bIsHashingDone) -á this->srcarevisible
24.03.2004 16:58:58: CPartFile::CompleteFile(bool bIsHashingDone) -á this->srcarevisible
24.03.2004 16:58:58: CPartFile::CompleteFile(bool bIsHashingDone) -á !bIsHashingDone = false
24.03.2004 16:58:58: CPartFile::CompleteFile(bool bIsHashingDone) -á !bIsHashingDone done
24.03.2004 16:58:59: CAddFileThread::Run() - start
24.03.2004 16:58:59: CAddFileThread::Run() -á CoInitialize(NULL);
<- CRASH


crashed right before the 1st Lock should have been initiated.
can't make any sense out of that at the moment (unless wine's threading code is buggy).
but now. SLEEP...

This post has been edited by Painkiller Jane: 24 March 2004 - 03:29 PM

0

#68 User is offline   mindpirate 

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

Posted 24 March 2004 - 04:53 PM

Yeah it's looking like a third thread (and maybe 4th, 5th,...) is involved, something that's unrelated to the completion thread but still accesses a common synchronized code block.

Incidentally I'm also having trouble with my real Windows installation (it dual boots with SuSE on this box) -- XP has started spontaneously rebooting on me. :( Good thing I rarely need to boot into Windows anymore. This coincides with my heavy use of Wine (no jokes please ;)), and I haven't had any such problems when I was using CrossOver exclusively. Wonder if Wine has done something to hose our real Win2K/XP installations. Oh well, no big loss since I've almost completely weaned myself from the tits of that monopoly. ;)

On the crypto front, still no word from the Wine devs. I guess the (very) few devs I've seen helping users on the newsgroup and mailing list only have time to answer the easy questions. I'm hitting up CrossOver support now since it also has the crypto problem. TransGaming's "support" forum looks like a joke, dozens of unanswered questions, so I'm not wasting my time there.
0

#69 User is offline   mindpirate 

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

Posted 24 March 2004 - 05:21 PM

Just as I feared. Wine won't impose Unix file security restrictions on Windows executables, so UploadSpeedSense can't be made to work simply by setting suid root on emule.exe.

This means Wine itself absolutely must be running under root privileges in order for eMule's UploadSpeedSense to have access to Linux's ICMP facilities. Setting suid root on Wine itself would be the most dangerous way to achieve this because any Linux application could use Wine to exploit the shit out of your box without being required to know the root password. So that leaves us with running Wine as root using sudo which will of course require the user to enter the root password every time they launch eMule.

This post has been edited by mindpirate: 24 March 2004 - 05:26 PM

0

#70 User is offline   mindpirate 

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

Posted 24 March 2004 - 10:00 PM

Good news: my Windows XP crashes weren't caused by Wine.

Bad news: my 3-month old Abit NF7-S motherboard is toast. No leaky capacitors this time, and I don't even overclock. It just suddenly started acting up in the past week for no apparent reason. All the hardware and BIOS settings have remained the same since I installed it. So this morning I swapped out my memory, CPU and video card for less demanding ones I had lying around, and the spontaneous rebooting problem only got worse. :(

It may take me a day or two (or even a week if shipping is involved) to get it sorted and possibly buy a new mobo if necessary, so I'll be out of the loop on our eMule/Wine project until then. :(

I've had more trouble with motherboards than any other type of hardware in the past 8 years. I'm pretty damn sick of it. Seems like all mobo's are made in Taiwan, so even the high-end ones are not immune to poor quality components, laughable driver and customer support, and questionable business practices.
0

#71 User is offline   Painkiller Jane 

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

Posted 25 March 2004 - 02:09 AM

i'm sorry to hear that. :(

anyways, a few more files tried to complete and a few more crashes happend.
atm it seems that the type 3 crash the one that crashes doing this:

24.03.2004 16:58:59: CAddFileThread::Run() - CoInitialize(NULL);

is the most common. i've put some more diagnostic code in to see what screws up.

what CoInitialize(NULL); is supposed to do according to msdn:

Quote

Initializes the COM library on the current thread and identifies the concurrency model as single-thread apartment (STA). Applications must initialize the COM library before they can call COM library functions other than CoGetMalloc and memory allocation functions.


i'm wondering which COM object it is that shall be initialized.
as far as i am concerned the COM thingies are the ones that need to be interfaced via their IUnknown interface.
afai can tell emule only uses that once in DropTarget.cpp (QueryInterface, that is).
so, why mess with COM in the file completion thread at all?

-pkj

This post has been edited by Painkiller Jane: 25 March 2004 - 07:30 AM

0

#72 User is offline   mindpirate 

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

Posted 25 March 2004 - 05:05 AM

Well I've never cared for C++, but it takes someone like Mickeysoft to make it really nauseating. Nightmarish component models, libraries designed by masochists, Hungover notation, an army of monkeys with keyboards slaving away under the iron fist of Billy G... it's amazing that Windows even works at all. :D

Had to RMA my mobo, it won't even boot into Linux or Wind'ohs anymore. Should receive my replacement early next week from newegg.com. I'm bummed. Oh well, think I'll hit the sack now. Good luck in the debugging... :sleep:
0

#73 User is offline   Painkiller Jane 

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

Posted 26 March 2004 - 07:20 AM

last wine/emule run ~11 hours (new record). completed 4 files. each ~170 megs.
4th produced a crash type 3.
posted in dev forum and asked about that CAddFileThread::Run() - CoInitialize(NULL); code. no answers from devs so far. either they don't care or the question is so trivial that it's not worth to be answered.
anyways, one of the modders (slugfiller) gave his point of view concerning that code and he can't see any good reason for it being involved in the file completion process either.
since this code seems to be the point where wine/emule always crashes i have removed that code and sit and watch if things have changed...

interesting thing, though, that code is used in the webserver part too. that has not only proven to be a serious memory leak on my machine but also another good way to crash wine/emule. (same X11 socket error).

-pkj

ps.: is there any way to make wine/emule take links? i.e. clicking on a ed2k link in let's say mozilla/opera/konquerer and wine/emule 'catches' it? any ideas?

This post has been edited by Painkiller Jane: 26 March 2004 - 07:38 AM

0

#74 User is offline   mindpirate 

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

Posted 26 March 2004 - 05:13 PM

Painkiller Jane, on Mar 26 2004, 02:20 AM, said:

posted in dev forum and asked about that CAddFileThread::Run() - CoInitialize(NULL); code.  no answers from devs so far. either they don't care or the question is so trivial that it's not worth to be answered.
anyways, one of the modders (slugfiller) gave his point of view concerning that code and he can't see any good reason for it being involved in the file completion process either.
since this code seems to be the point where wine/emule always crashes i have removed that code and sit and watch if things have changed...

interesting thing, though, that code is used in the webserver part too. that has not only proven to be a serious memory leak on my machine but also another good way to crash wine/emule. (same X11 socket error).

That would be great if the same code were causing the memleaks and completion crashes. We'd be able to eliminate 2 major issues with one solution. :D And they should add your name to the eMule dev list for fixing that code. ;)

Quote

ps.: is there any way to make wine/emule take links? i.e. clicking on a ed2k link in let's say mozilla/opera/konquerer and wine/emule 'catches' it? any ideas?


I do believe it's possible because Wine is able to handle things like .jpg's launched externally from eMule by launching KDE's image viewer. I'd be surprised if you couldn't also assign URL handlers externally. I'll look into it.

On other matters, I've discovered how CrossOver handles certain things and I now believe I can make Wine behave the same, so that eMule will work with Win98 dll's more smoothly than with XP dll's, and it should solve most of the oustanding GUI issues as well (corrupted icons, tab anomalies...). I won't know for sure until my replacement motherboard arrives because my other Linux boxes are X-less so I can't use them for testing. Sadly it's looking more like my mobo might arrive later next week than earlier. So it's all research and no testing for me until then.
0

#75 User is offline   Painkiller Jane 

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

Posted 27 March 2004 - 06:03 AM

Quote

On other matters, I've discovered how CrossOver handles certain things and I now believe I can make Wine behave the same, so that eMule will work with Win98 dll's more smoothly than with XP dll's, and it should solve most of the oustanding GUI issues as well (corrupted icons, tab anomalies...).


that'd be great.

my last wine/emule run (on remote session!) lasted 21(!) hours but then wine quit saying:

Quote

X Error of failed request:á BadRequest (invalid request code or no such operation)
á Major opcode of failed request:á 0 ()
á Serial number of failed request:á 203692811
á Current serial number in output stream:á 203692811


emule wasn't doing anything special at that time.
before crashing it completed 2 big files without problems so i'm optimistic that the patch for file completion helps.

as for the webserver mem leak/thread problems: they get worse because of my patches. now using the webinterface not only spawns 1 new thread but 4(!).
so i think we definitely found that wine can't cope too well with CoInitialize(NULL).
i looked at their 'compatibility chart' but couldn't see any COM issues mentioned.

-pkj

This post has been edited by Painkiller Jane: 27 March 2004 - 06:04 AM

0

#76 User is offline   mindpirate 

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

Posted 27 March 2004 - 06:13 AM

Painkiller Jane, on Mar 27 2004, 01:03 AM, said:

as for the webserver mem leak/thread problems: they get worse because of my patches. now using the webinterface not only spawns 1 new thread but 4(!).
so i think we definitely found that wine can't cope too well with CoInitialize(NULL).
i looked at their 'compatibility chart' but couldn't see any COM issues mentioned.


Interesting, and if it's COM troubles we're facing here with our WinXP dll's then I have a feeling this issue might be cleared up with Wine under Win98 emulation using native DCOM98 libs, which also happens to be part of the solution to other problems I referred to in my previous post. I won't be able to test that theory for a few days though, but if you have the time (or the patience heh) you might want to give that a try.
0

#77 User is offline   Painkiller Jane 

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

Posted 27 March 2004 - 06:22 AM

erm, ok. what am i supposed to do?
just switch wine to w98 emulation and use w98 comctl32 and riched20?

-pkj

edit: with my w98se comctl32, commctrl, riched20 wine won't start emule giving me some crap about commctrl maybe not being the right version that comctl32 requires. they're from same win98se cd, though.
guess that one has to wait until you figure it out. :P

This post has been edited by Painkiller Jane: 27 March 2004 - 08:54 AM

0

#78 User is offline   mindpirate 

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

Posted 27 March 2004 - 05:02 PM

Painkiller Jane, on Mar 27 2004, 01:22 AM, said:

erm, ok. what am i supposed to do?
just switch wine to w98 emulation and use w98 comctl32 and riched20?

-pkj

edit: with my w98se comctl32, commctrl, riched20 wine won't start emule giving me some crap about commctrl maybe not being the right version that comctl32 requires. they're from same win98se cd, though.
guess that one has to wait until you figure it out. :P

Sorry, should have said something about that. When you switch to native comctl32.dll with Win98 emulation, you also need to copy over and include the native version of its 16-bit ancestor commctrl.dll. So your config will look like this:

;; eMule
[AppDefaults\\emule.exe\\DllOverrides]
"*" = "builtin, native"
"commctrl" = "native"
"comctl32" = "native"


From what I remember you won't need to use the native riched20.dll in Win98 "mode", so don't worry about that.

Next, use Wine to install the Common Controls update for Win98 from:

http://www.microsoft...66-93AF0D8D4A1E

Finally install the DCOM98 package from here:

http://www.microsoft...m98/dcom1_3.asp

Wish I could try all this out before possibly steering you wrong, but you'll have to be the guinea pig for now. ;)
0

#79 User is offline   Painkiller Jane 

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

Posted 28 March 2004 - 10:44 AM

report:

- copied win98se dlls comctl32 and commctrl.dll into wine system dir.
- changed wine's config to:

Quote

...
[Version]
; Windows version to imitate (win95,win98,winme,nt351,nt40,win2k,winxp,win2k3,win20,win30,win31)
"Windows" = "win98"
; DOS version to imitate
;"DOS" = "6.22"
...
;;eMule
[AppDefaults\\emule.exe\\DllOverrides]
"*" = "builtin, native, so"
"comctl32" = "native"
"commctrl" = "native"


- installed COM update:

Quote

jane@linux:~/Documents> wine 50ComUpd.Exe
fixme:ntdll:NtQueryInformationToken (0x3c,2,(nil),0,0x406bfd98): stub
fixme:ntdll:NtQueryInformationToken (0x3c,2,0x40387ea8,12,0x406bfd98): stub
fixme:ntdll:NtQueryInformationToken (0x74,2,(nil),0,0x406bf9c0): stub
fixme:ntdll:NtQueryInformationToken (0x74,2,0x4038d0a8,12,0x406bf9c0): stub
err:setupapi:SetupDefaultQueueCallbackA copy error 32 "E:\\IXP001.TMP\\comcnt.dll" -> "C:\\WINDOWS\\SYSTEM\\comctl32.dll"


- installed DCOM98

MessageBox says:

Quote

DCOM98 can only be installed on Windows98.
For Windows NT, please install latest service packs.


plz note that wine was already switched to w98 mode at that time!

- tried to run emule

Quote

jane@linux:~/wine/c/Program Files/eMule> wine emule
err:thunk:_loadthunk Unable to find thunk data 'Cctl1632_ThunkData16' in commctrl.dll, required by comctl32.dll (conflicting/incorrect DLL versions !?).
err:module:LdrInitializeThunk Main exe initialization for L"C:\\Program Files\\eMule\\emule.exe" failed, status c0000142



then i figured i could fix the COM update error by removing the already copied comctl32 so that the installer can't run into problems overwriting it. but got same error.

then i tried without the COM and DCOM updates with plain (copied freshly from 98se cd) dlls and again got

Quote

err:thunk:_loadthunk Unable to find thunk data 'Cctl1632_ThunkData16' in commctrl.dll, required by comctl32.dll (conflicting/incorrect DLL versions !?).
err:module:LdrInitializeThunk Main exe initialization for L"C:\\Program Files\\eMule\\emule.exe" failed, status c0000142


i'm outto ideas how it's possible to get wine working with comctl32 and commctrl from w98se... except for a desperate try to use even older w98(none SE) dlls.
coming up next ...

-pkj
edit: very same results with 98 (non SE) dlls. :(

This post has been edited by Painkiller Jane: 28 March 2004 - 11:07 AM

0

#80 User is offline   BaggyG 

  • Newbie
  • Pip
  • Group: Members
  • Posts: 4
  • Joined: 23-March 04

Posted 28 March 2004 - 12:02 PM

Hi All.

I've been trying to get wine and emule to work for a week with minor wins along the way but no real success.

I followed the how-to by the letter. Wine work in so far as I can run regedit and install emule (that's all Ive done with windows apps so far).

How ever when I try to run emule I get:

[baggy@server01 eMule]# wine emule.exe
fixme:ole:CoRegisterMessageFilter stub
err:heap:HEAP_ValidateInUseArena Heap 401e0000: prev arena 40249110 is not prev for in-use 40249140
fixme:commctrl:InitCommonControlsEx Unknown class! dwICC=0x8000
err:win:CreateWindowExA bad class name "RichEdit20A"

And all the No debug messages and pointer info after that. I have triple checked riched20.dll that it is in the right place and that the config file is correct, but I just don't know where to go from here.

Cheers,
BaggyG

This post has been edited by BaggyG: 28 March 2004 - 12:03 PM

0

  • Member Options

  • (16 Pages)
  • +
  • « First
  • 2
  • 3
  • 4
  • 5
  • 6
  • Last »

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