[tHeWiZaRdOfDoS]

Maybe the easiest way is to track the SetStatus() function of CPartFile and the corresponding enums that are used (e.g. PS_ERROR/PS_INSUFFICIENT/PS_COMPLETING/PS_COMPLETE) - search for those and you'll find most of the stuff you need.

[Fareed]

tHeWiZaRdOfDoS, on 29 October 2009 - 11:34 AM, said:

Maybe the easiest way is to track the SetStatus() function of CPartFile and the corresponding enums that are used (e.g. PS_ERROR/PS_INSUFFICIENT/PS_COMPLETING/PS_COMPLETE) - search for those and you'll find most of the stuff you need.

I know of the CPartFile enumerations, but I wasn't aware of the SetStatus() function.
I belive these events would be a good match, but I could take a second opinion to heart.

CPartFile Windows 7
========= =========
PS_ERROR TBPF_ERROR
PS_INSUFFICIENT TBPF_ERROR
PS_COMPLETING Show Progress
PS_COMPLETE TBPF_INDETERMINATE <--- Shows just a looped animation of the progress action taking place, used primarily as a way to show that the progress bar will show and calculates in the background how much work will need to be done.

[Fareed]

Hit a major stall!

1) Could use function overloading to pass the HWND function to use, but their are several occurrences of the function so it's a maze.
2) And their is no way to pass on information to tell the function to recognize it's running on Windows 7.
3) Not a problem, but can ruin the Windows 7 experience the Tray Design.

[tHeWiZaRdOfDoS]

Sometimes I don't understand you...
1) What function do you want to pass the HWND to?
2) You can write your own detection, in otherfunctions.cpp is a detection scheme for XP/Vista/etc. and you could enhance that to detect 7
3) ???

[Fareed]

tHeWiZaRdOfDoS, on 31 October 2009 - 09:07 AM, said:

Sometimes I don't understand you...
1) What function do you want to pass the HWND to?
2) You can write your own detection, in otherfunctions.cpp is a detection scheme for XP/Vista/etc. and you could enhance that to detect 7
3) ???

I know! :S

1) The handle for the main window has to be passed in the Taskbar function. DrawStatusBar has the 2 error states which should trigger the Windows 7 Taskbar UI notifications (1 PS_COMPLETE || status == PS_COMPLETING, 2 eVirtualState == PS_INSUFFICIENT || status == PS_ERROR).

2) While using the Shell Version Detection in Emule.cpp, I can detect Windows 7 running. But the problem is I don't know how to tell the smaller functions.

3) I fear that the eMule minimize in tray by design might cause problems with the Windows 7 UI.

[tHeWiZaRdOfDoS]

1) You don't have to pass that one, you may use theApp.emuledlg->GetSafeHWnd()
2) Well, here's a snippet how to modify the existing functions:

Otherfunctions.h:

Quote

#define _WINVER_95_ 0x0400 // 4.0
#define _WINVER_NT4_ 0x0401 // 4.1 (baked version)
#define _WINVER_98_ 0x040A // 4.10
#define _WINVER_ME_ 0x045A // 4.90
#define _WINVER_2K_ 0x0500 // 5.0
#define _WINVER_XP_ 0x0501 // 5.1
#define _WINVER_2003_ 0x0502 // 5.2
#define _WINVER_VISTA_ 0x0600 // 6.0
#define _WINVER_WIN7_ 0x0610 // 6.1

Otherfunctions.cpp:

Quote

WORD DetectWinVersion()
{
OSVERSIONINFOEX osvi;
ZeroMemory(&osvi, sizeof(OSVERSIONINFOEX));
osvi.dwOSVersionInfoSize = sizeof(OSVERSIONINFOEX);
if (!GetVersionEx((OSVERSIONINFO*)&osvi))
{
osvi.dwOSVersionInfoSize = sizeof(OSVERSIONINFO);
if (!GetVersionEx((OSVERSIONINFO*)&osvi))
return FALSE;
}

switch (osvi.dwPlatformId)
{
case VER_PLATFORM_WIN32_NT:
if (osvi.dwMajorVersion <= 4)
return _WINVER_NT4_;
if (osvi.dwMajorVersion == 5 && osvi.dwMinorVersion == 0)
return _WINVER_2K_;
if (osvi.dwMajorVersion == 5 && osvi.dwMinorVersion == 1)
return _WINVER_XP_;
if (osvi.dwMajorVersion == 5 && osvi.dwMinorVersion == 2)
return _WINVER_2003_;
if (osvi.dwMajorVersion == 6 && osvi.dwMinorVersion == 0)
return _WINVER_VISTA_;
if (osvi.dwMajorVersion == 6 && osvi.dwMinorVersion == 1)
return _WINVER_WIN7_;
return _WINVER_VISTA_; // never return Win95 if we get the info about a NT system

case VER_PLATFORM_WIN32_WINDOWS:
if (osvi.dwMajorVersion == 4 && osvi.dwMinorVersion == 0)
return _WINVER_95_;
if (osvi.dwMajorVersion == 4 && osvi.dwMinorVersion == 10)
return _WINVER_98_;
if (osvi.dwMajorVersion == 4 && osvi.dwMinorVersion == 90)
return _WINVER_ME_;
break;
}

return _WINVER_95_; // there should'nt be anything lower than this
}

After these changes you can use thePrefs.GetWindowsVersion() == _WINVER_WIN7_ to check for Win7.
Please note, however, that you have to adapt all occurences of _WINVER_VISTA_, too or eMule might not work correct, anymore.

3) maybe, but I'd simply try it out

[tHeWiZaRdOfDoS]

Any news about your project?

[netfinity]

Work in progress!!!



Progress and up/down-load indicator in a test build of the NetF WARP mod.

/netfinity

[Enig123]

A little bit OT. NetFinity, any new ideas we can expect with your upcoming new version of WARP?

[netfinity]

Enig123, on 16 January 2010 - 01:46 PM, said:

A little bit OT. NetFinity, any new ideas we can expect with your upcoming new version of WARP?

Mostly bugfixes and disk IO optimizations. But also somewhat faster searching in Kad (done), the Windows 7 UI stuff (need some polishing), and possibly a feature that uses the builtin Snapshot/Backup feature of Windows to recover damaged configuration files (code to read files from snapshots is done, but not integrated yet).

[tHeWiZaRdOfDoS]

I checked out the documentation by M$ and it looks pretty easy to add that functionality though I don't want to upgrade to Visual Studio 2008 because there are some issues left IIRC... how did you solve those, netfinity?

[Andu]

Hehe that reminds me of VS 2010 which is being pushed back because MS can't get performance up to expectations.

The Win7 UI work looks good although I'd be more interested in the 64Bit, crumbs, disk IO optimization features to reach maturity

[netfinity]

tHeWiZaRdOfDoS, on 16 January 2010 - 06:26 PM, said:

I checked out the documentation by M$ and it looks pretty easy to add that functionality though I don't want to upgrade to Visual Studio 2008 because there are some issues left IIRC... how did you solve those, netfinity?

Yeah it took just an evening to get it running. The issue is to get the progress bar to show anything useful. It's more of a logical problem when having multiple files downloading, rather than a technical problem.

To get it work you have to compile with the Windows 7 SDK, which requires a few code lines to change. Most of the problems compiling with VS 2008 is actually due to the Windows Vista SDK (ofcourse using the Windows 7 SDK doesn't make it better) and that it doesn't support Windows 2000 as a target, which is set in the stdafx.h. Compiling for VS 2010 requires some more work as changing some NULL macros to nullptr in the cryptolib and find an alternative to the qedit.h header.

Andu, on 16 January 2010 - 06:50 PM, said:

The Win7 UI work looks good although I'd be more interested in the 64Bit, crumbs, disk IO optimization features to reach maturity

64-bit:
This is easy! Just set the compiler to 64bit mode and fix all warnings. (there are only a couple of thousand warnings so that is quickly done) Maybe there was something more but essentially that was what I did. With some proper rewrite of the crypto code the 64bit build can be be as much as twice as fast under load.

Crumbs:
This one is a bit more complicated. The sharing and downloading of incomplete parts is quite easy, but the asynchronus hashing takes a little bit more time to do.

Disk IO optimizations:
This is esentially fixes to try to align all download requests to 4kB boundaries and setting file cache mode to random access. Hopefully I can find a way to disable snapshotting for part files, so that they don't use up valuable snapshot/backup space and save IO overhead synching with the snapshot.

[Some Support]

netfinity, on 16 January 2010 - 09:08 PM, said:

With some proper rewrite of the crypto code the 64bit build can be be as much as twice as fast under load.

Just to avoid creating new myths: This applies to the crypto lib code only (and 100% is probably a bit to optimistic), which however is not used for any time consuming operation in eMule (obfuscation is not using crptolib). On this topic, it would be however intresting if zlib could be speed up significantly, which might be possible (dont know). Hashing seems unlikely to be able to profit too much since MD4 is using 32bit values.

Quote

Disk IO optimizations

A bit OT, but i think those problems will solve themself in a few years with the success of SSDs. Selfsolving problems are the best anyway

[Andu]

But with SSDs one has to try to minimize write cycles because even with load balancing that is the thing that will kill your SSD at some point.

[Some Support]

Andu, on 16 January 2010 - 10:27 PM, said:

But with SSDs one has to try to minimize write cycles because even with load balancing that is the thing that will kill your SSD at some point.

Yes, but that doesn't needs any optimizing, eMule writes data to the disk only once, except if a part war corrupted of course.

[netfinity]

Some Support, on 16 January 2010 - 10:36 PM, said:

netfinity, on 16 January 2010 - 09:08 PM, said:

With some proper rewrite of the crypto code the 64bit build can be be as much as twice as fast under load.

Just to avoid creating new myths: This applies to the crypto lib code only (and 100% is probably a bit to optimistic), which however is not used for any time consuming operation in eMule (obfuscation is not using crptolib). On this topic, it would be however intresting if zlib could be speed up significantly, which might be possible (dont know). Hashing seems unlikely to be able to profit too much since MD4 is using 32bit values.

It is actually not the larger register size that makes the most of the improvent, but the 8 extra CPU registers that reduces the amount of load and store instructions. This often reduces the amount of assembly instructions with 25%, and when comparing the 32 and 64 bit builds in the taskmanager I see 25 to 30 percent improvent in CPU load (especially when it's minimized to the tray, so the GUI isn't visible). Still 64 bit machines are very fast so the need of the extra performance is questionable, but always welcome.

Some Support, on 16 January 2010 - 10:36 PM, said:

Quote

Disk IO optimizations

A bit OT, but i think those problems will solve themself in a few years with the success of SSDs. Selfsolving problems are the best anyway

Already using SSD for operating system and yeah it's great! But 4kB alignment of the write operations makes the SSD to last a little bit longer (if just very little).

However the discussion topic was actually about this;

[Some Support]

netfinity, on 16 January 2010 - 10:42 PM, said:

It is actually not the larger register size that makes the most of the improvent, but the 8 extra CPU registers that reduces the amount of load and store instructions. This often reduces the amount of assembly instructions with 25%, and when comparing the 32 and 64 bit builds in the taskmanager I see 25 to 30 percent improvent in CPU load (especially when it's minimized to the tray, so the GUI isn't visible). Still 64 bit machines are very fast so the need of the extra performance is questionable, but always welcome.

I must admit i'm not that familiar with the differences on processor architectures, so you might be right. But im skeptical - while the new registers offer a advantages, all adressing operations get more time and space consuming. But if anyone is bored enough to do a real benchmark with eMule (ideally with a 32bit OS vs. 64bit) under load or for simplicity filehashing time, that would be certainly intresting. Right now, having one lean version which runs on all systems just seems like a pretty big advantage (not to talk about the coding work).

Quote

However the discussion topic was actually about this;

Indeed, and once you are finished im quite eager to look at it

[dolphinX]

Yeah, I'm bored enough.

I've test the time consuming of md4, sha and md5 among crypto++ 5.6.0, emule's asm and shareaza's x64 version 6 months ago.
I created a test app to hash 150MB data. To make it simple, the data is filled with a specific char like 0.
The result is (all the tests were on 64bit system)

	asm	crypto++(32bit)	crypto++(64bit)	shareaza(64bit)
md4	359ms	328ms		343ms		343ms
sha	765ms	796ms		609ms		828ms

	emule	crypto++(32bit)	crypto++(64bit)	emule(64bit)
md5	609ms	484ms		500ms		609ms

As the table show 64bit crypto++ is a bit faster than the original.

Another IPFilter time consuming result(Load 17MB)

32bit(SSE2):	563ms
64bit:		478ms

I've changed IPFilter code to make it load faster under VS2008. It won't change that trend in my opinion.

btw, although VS2008 SDK doesn't support Windows 2000 as a target, the exe compiled with VS2008 still can run on Windows 2000.

This post has been edited by dolphinX: 17 January 2010 - 05:09 AM

[Fareed]

I know it's been a while!

My Windows 7 machine was all acting up, finally got a new machine and got my own Windows 7 copy!
I'm trying to compile this time with Visual Studio 2010, and I agree with netfinity it's more logic.