Ok, you are right in the sense that to support all platforms a toolkit is much simpler. But
Threads and processess are not really a problem. llibUPnP compiles and works in Windows, Mac, Linux, and other stuff, and they use no toolkit, just pthread support.
Strings could be a problem because std::wstring uses wchar_t, which is not guaranteed to be 32 bits. But again, in any of these platforms is wchar_t different from 32 bits? Look:
#include <string>
#include <stdio.h>
int main(void)
{
printf("sizeof (wchar_t) = %zd\n", sizeof (wchar_t));
return 0;
}
output on both x86_64 and i386:
$ g++ -Wall -o t t.cpp
$ ./t
sizeof (wchar_t) = 4Please, someone test it in windows and Mac.
Filenames are another issue, but we already use a toolkit and filenames are still an issue, so the toolkit hasn't really helped us here.
So, to be quite frank, I do believe you can do it without toolkits. As I said before, there may be some platform dependent code for sockets, but very little. Other than that, we would need a routine to convert UNICODE to and from UTF-8, which is something simple and common.
GUI is a complete different story, I think we both agree here on the importance of a toolkit.
Oh, and I almost forgot, there is nothing wrong with EC. It needs attention because it is incomplete in the sense that aMuleGUI does not have the full functionality of aMule. Not a big deal, this is easy to add nowadays.
Cheers!
