[bager]

Heliotropo, on 15 March 2021 - 05:21 PM, said:

Quote

Tried that amazing thing called searching alredy. Did not work. If curious, you can try it out yourself according to the link you specified.

Try with hxxps://support.mozilla.org/en-US/kb/https-only-prefs [change 'xx' to 'tt']

I wasnt clear it seems. The mozilla link works fine, but the solution it presents does not.

[mortbrad]

Is there any way to provide additional information for 0.60 crashing where 0.51 ran for months without ever crashing, on the same machine with the same settings.

Can't seem to be get 0.60 to stay running for much more than 2-3 days without crashing out.

[fox88]

mortbrad, on 21 March 2021 - 11:19 AM, said:

Is there any way to provide additional information for 0.60 crashing

Certainly. Please see this message..

This post has been edited by fox88: 07 April 2021 - 12:11 PM

[QICKV8]

Is it possable to get an eMule that can upload more than 1 file at a time to a client?

This post has been edited by QICKV8: 07 April 2021 - 08:27 AM

[Stulle]

QICKV8, on 07 April 2021 - 09:25 AM, said:

Is it possable to get an eMule that can upload more than 1 file at a time to a client?

Nope, that would basically require a full rewrite of the code and protocol.

[Stulle]

Hey fox88,

I got a find that leaves me a little unsure. Merging PartFile.cpp I noticed in CreatePartFile you replaced code like:

	m_SrcpartFrequency.SetSize(GetPartCount());
	for (UINT i = 0; i < GetPartCount();i++)
		m_SrcpartFrequency[i] = 0;

With something along the lines of:

	m_SrcPartFrequency.SetSize(GetPartCount());
	if (GetPartCount())
		memset(&m_SrcPartFrequency[0], 0, GetPartCount() * sizeof m_SrcPartFrequency[0]);

I get the basic idea but I still did some research because I was really wondering if this can work with a predefined class from VC++. Turns out I could nowhere find any such combination on the web. Might be poor Google skills but whatever.

Anyhow, I continued my research and eventually checked out the definition of CArray:SetSize. The most important bit I found is probably this:

		TYPE* pNewData = (TYPE*) new BYTE[(size_t)nNewMax * sizeof(TYPE)];

		// copy new data from old
		::ATL::Checked::memcpy_s(pNewData, (size_t)nNewMax * sizeof(TYPE),
			m_pData, (size_t)m_nSize * sizeof(TYPE));

		// construct remaining elements
		ASSERT(nNewSize > m_nSize);
		memset((void*)(pNewData + m_nSize), 0, (size_t)(nNewSize-m_nSize) * sizeof(TYPE));
		for( int i = 0; i < nNewSize-m_nSize; i++ )
#pragma push_macro("new")
#undef new
			::new( (void*)( pNewData + m_nSize + i ) ) TYPE;
#pragma pop_macro("new")

		// get rid of old stuff (note: no destructors called)
		delete[] (BYTE*)m_pData;
		m_pData = pNewData;
		m_nSize = nNewSize;
		m_nMaxSize = nNewMax;

It would be called when we grow the CArray object after it's initialization (CreatePartFile is virtually only called from constructors). Now, from what I understand about the code I found in the definition of CArray:SetSize it basically allocates a memory block of the newly desired size, copies the old stuff to the beginning and then initializes the remainder to 0. Then the memory is filled with objects of the desired type (over the 0-filled memory), deletes the old data and moves the pointer to the new data. When the CArray object is empty to begin with it just omits the handling of existing data/memory, really.

So am I wrong to assume that we do not need to initialize the object any further if we use a fundamental type and desire all entries to be 0? In that case we could just skip the memset you added altogether.

What do you say? As always: I am no expert on this so I may well be overlooking stuff because I just lack some expert knowledge of C++.

This post has been edited by Stulle: 09 April 2021 - 03:39 PM

[Campo]

For your information:

it seems nearly all 0.60 clients are getting banned in my morph 12.7

examples
09.04.2021 18:25:40: [Bad MODSTRING]-() Client xxxxxxxx(xxxxxx) 'xxxxxx' (eMule v0.60b,None/None/None)
09.04.2021 18:33:45: [Bad MODSTRING]-() Client xxxxxxxx(xxxxxx) 'xxxxxx' (eMule v0.60b,None/None/None)
09.04.2021 18:36:31: [Bad MODSTRING]-() Client xxxxxxxx '...' (eMule v0.60b,None/None/None)

in morph, the security functions in the options arent so specific like in xtreme i guess.
i dont want to deactivate the "anti-leecher" and "anti-credit-hack" functions.

can i do something about it at the moment without changeing to a client with less overall options?

[Stulle]

Campo, on 09 April 2021 - 05:40 PM, said:

For your information:

it seems nearly all 0.60 clients are getting banned in my morph 12.7

examples
09.04.2021 18:25:40: [Bad MODSTRING]-() Client xxxxxxxx(xxxxxx) 'xxxxxx' (eMule v0.60b,None/None/None)
09.04.2021 18:33:45: [Bad MODSTRING]-() Client xxxxxxxx(xxxxxx) 'xxxxxx' (eMule v0.60b,None/None/None)
09.04.2021 18:36:31: [Bad MODSTRING]-() Client xxxxxxxx '...' (eMule v0.60b,None/None/None)

in morph, the security functions in the options arent so specific like in xtreme i guess.
i dont want to deactivate the "anti-leecher" and "anti-credit-hack" functions.

can i do something about it at the moment without changeing to a client with less overall options?

Yeah, I am aware for some months now. Apparently there used to be a leecher which identified as eMule 0.60... Now, the most recent update of MorphXT is like 9 years ago so it is an error in good faith.

You can just disable the Anti-leecher control in the Morph settings dialog. I don't think there is great benefit in using it these days, anyway.

[VasiliyRus]

Quote

it seems nearly all 0.60 clients are getting banned in my morph 12.7

Thank you for pointing that out. That explains why i have not seen morph client sources with 0.60 version.
I have changed my Emule to other client and shortly one rare file download started with a morph client source
and another download has a morph client source found with queue.
I wonder how many mods with leech protection are blocking 0.60 branch now...
This looks like a big issue and should be addressed shortly.

[Campo]

Thank you. Ok, i will deactivate the anti leecher.

Now that Stulle mentioned the 0.60 leecher, i remember the warnings that there is no official 60 version. It was announced on some sites and was fake and had viruses or spyware/adware...
Also it was a good move to put it under generel suspicion, because a real 0.60 was nearly impossible in the future.

Iam eager to switch to a 60 mod

[Stulle]

VasiliyRus, on 11 April 2021 - 12:17 AM, said:

Quote

it seems nearly all 0.60 clients are getting banned in my morph 12.7

Thank you for pointing that out. That explains why i have not seen morph client sources with 0.60 version.
I have changed my Emule to other client and shortly one rare file download started with a morph client source
and another download has a morph client source found with queue.
I wonder how many mods with leech protection are blocking 0.60 branch now...
This looks like a big issue and should be addressed shortly.

Well, I believe it should be in just about any of the most recent clients that used "traditional" blacklist type detection. So many old mods will be affected.

Is it a reason for quick action? Not really, IMO. I don't know about the actual distribution of 0.60x versions but I would presume it's less than 25 %. Affected mods will prolly be in the range of 5-10 % tops. That's pretty pessimistic, mind you. So the number of possible matches that are prevented is really only a few couple of percent. Worst case, some releasers (and they are likely the most significant group) will not share with some clients. Their loss if they still think anti leecher controls are so important. I personally don't think worrying about leechers is still important in this time and age.

Campo, on 11 April 2021 - 02:25 AM, said:

Thank you. Ok, i will deactivate the anti leecher.

Now that Stulle mentioned the 0.60 leecher, i remember the warnings that there is no official 60 version. It was announced on some sites and was fake and had viruses or spyware/adware...
Also it was a good move to put it under generel suspicion, because a real 0.60 was nearly impossible in the future.

Iam eager to switch to a 60 mod

Dunno about the specifics... I know we used to ban many such clients in an attempt to make users switch to legit clients instead of using such malware ridden crap. Nowadays, I don't believe it would impact affected users too much to make them wonder. But oh well...

[Stulle]

Hey fox88,

Making this a separate post to hopefully grab your attention. So this is regarding CPartFile::DrawStatusBar where I noticed the following line:

			RECT gaprect = { rect.left, rect.top, rect.left + (LONG)width, gaprect.top + PROGRESS_HEIGHT };

I dunno how this line works now but I believe it's basically a copy and paste error for the bottom member. I reckon it should be

			RECT gaprect = { rect.left, rect.top, rect.left + (LONG)width, rect.top + PROGRESS_HEIGHT };

because referring to a property of the newly initialized struct in the same inline initialization appears like bad style to me.

Also, I would appreciate any feedback on the CArray initialization thingy I mentioned before.

[Campo]

Hi Stulle,

yes youre right. I assume too, that theres no benefit in using a leecher mod anymore.

On one side its true, that theres only a few .60a/b users overall. On the other side it is extreme important on my targeted files (or what they want from me) to get every single client. So, people think (like me), use the newest version, exspecially if theres a new version after so much years and the user cares a bit more. But if they get banned without knowing that, its a problem Now i see the whole time some 60 users for several different files. And i got 3 files ready, which had no source since i added it.

I cant use .60, because i need the bind interface function and like a lot of stuff from the mods.

Its very interesting to get some information about the thoughts from developers.

edit: and if 60 would work me at the moment, i would get banned from a lot of people, who want stuff from me^^

This post has been edited by Campo: 12 April 2021 - 03:08 PM

[p033928]

Campo, on 12 April 2021 - 03:02 PM, said:

Hi Stulle,

yes youre right.and if 60 would work me at the moment, i would get banned from a lot of people, who want stuff from me^^

..that's the matter...using 0.60 ,up to now, means "very likely" to be banned...

[Stulle]

No, rather unlikely because mods are still few and I would hope most releasers are mindful of such things, i.e. disable the Anti Leecher Controls...

[fox88]

Stulle, on 09 April 2021 - 06:35 PM, said:

Then the memory is filled with objects of the desired type (over the 0-filled memory)

What was the point of that memset, if the memory was immediately overwritten with new objects?
The memory contents of the new objects would be implementation dependent, if I got the C++ language standards correctly.
Which means, it would be safer to clear the array explicitly.

Stulle, on 12 April 2021 - 12:13 PM, said:

I dunno how this line works now but I believe it's basically a copy and paste error for the bottom member.

Again, according to the language standards, the code behaves properly; initialisation is performed in the order of declarations.
But I agree that in this case rect.top is preferable to gaprect.top. Thanks for pointing this out.

[stoatwblr]

Campo, on 11 April 2021 - 02:25 AM, said:

Also it was a good move to put it under generel suspicion, because a real 0.60 was nearly impossible in the future.

It's standard practice for most software to skip malware versions or ones which had warnings issued in order to avoid that kind of confusion

Perhaps the release version should incrememnt to 0.61?

[stoatwblr]

Heliotropo, on 20 January 2021 - 05:16 PM, said:

I only have problems with the upload. Emule finds users normally, but in the first seconds of the connection most of the users are rejected, the connection is cut. With the users who stay on the climb it seems that everything is going well. As can be seen in the lines of the verbose that I have put, the problem is that the remote host forces the break connection for some reason.

I came to this thread to make a similar comment. Running 64-bit 0.60b in wine here and amule 2.3.3 + 2.4.0-svn(various to test interoperation)

There's definitely a problem sending things to amule (and a few older clients). It _seems_ to manifest when higher bandwidth is avilable (300kB/sec uploads break) and calm down as more slots get occupied (30kB/s ones are generally OK).

There will be a burst of high traffic and then things stall out after 1-3MB, whereas when upload bandwidth is already more fully occupied the transfer progresses more happily

FWIW the clients have quite different views of KAD space too

This isn't just restricted to 0.60 either. It's pretty clear that most emule .5* variants (except 0.50d for some reason) have trouble talking to amule whilst 0.4* ones are fine

Edit: when I say "talking to amule" I mean sending to it. Amule sending to emule seems to be unaffected and runs as fast as bandwidth allows (up to 1MB/sec in my case)

This post has been edited by stoatwblr: 05 May 2021 - 06:12 PM

[stoatwblr]

stoatwblr, on 05 May 2021 - 07:02 PM, said:

Edit: when I say "talking to amule" I mean sending to it. Amule sending to emule seems to be unaffected and runs as fast as bandwidth allows (up to 1MB/sec in my case)

Following up on this: It only seems to happen if emule gets faster than about 100kB/sec and it appears to be triggered when amule flushes its buffers - this causes a momentary hiccup in the flow and it looks like emule can't handle that (0.51d can, as mentioned. So can other clients - I've seen throughputs exceeding 300kB/sec from all of these)

[Heliotropo]

If we right-click on a friend user, shouldn't the option to remove it from the friends list appear, instead of "add to friends"?