Cross platform winmx

[shamil]

We live in a day and age where the other operating systems are actually a serious contending alternative to just microsoft windows. The big contenders are famously macosx and of course linux.

The thing that pains me is the fact that with the few winmx clients in development is that they are being made for the windows platform. There's only one true cross platform project that i'm looking forward to which is winpy; which is based on python. Then there's the other clients being  based on the microsoft software stack.

Then we have this great area of the forum called winmx not on windows. Winmx on other platforms is something that should definitely be taken seriously for a future winmx client. There is a sizable enough chunk of winmx users that are not windows users (including myself). Sure i love the old client the best, and when one of these new clients actually comes to completion...depending on what those clients have to offer i'd probably stick with the old one unless something ground breaking happened such as modernizing and plugging the holes in the protocol with a new client (which would be a very major change in the winmx community at the same time).

My concern comes from the fact that wine compatibility is taken for granted. With a future winmx client, i believe it'd be better if wine compatibility wasn't taken for granted by having a true winmx cross platform client. Running something natively is of course the recommended option.

[Pri]

Lack of programmers. That is the main reason that most 3rd party WinMX development is targeting Windows. Most people use Windows including developers and most of the ones we have here in our community know how to program for Windows but not Linux or Mac OS X.

This is a hurdle that we will keep coming up against I'm afraid and there isn't much we can do about it. The winpy client is interesting from a tech demo standpoint but being in Python it isn't really usable as a GUI Application and the development has ceased by the original developer. Those taking up the work of winpy haven't spoken much publicly about where the project is right now either but I hope they are making progress.

I'll be honest with you the future for WinMX is bleak for not just cross platform ports but for its survival on Windows as-well. There are a lot of technical issues with the software that are starting to show as it ages. It isn't ready for IPv6, it doesn't support file transfers over 2GB it doesn't support file shares over 5000 to be browsed (but they can still be searched). It is problems like these that aren't going away and will make people exit in the future. We can only hope that the future 3rd party clients being developed get released and fix these things for us to begin building the community base up again but don't forget it has been 5 years since the shut down and we've not got very far yet, we have many chat clients but nothing that can truly replace the default client in all its functions. I mean hell we don't even have a Primary capable client yet, just proof of concept clients at this point, nothing released.

[shamil]

In that case focusing on the windows platform sounds sufficient since it's what the few developers around here know. Wine compatibility being what it is is very dependable, i'm happy it exists. And that absolutely sucks for winpy.

It's showing it's age in more areas than i thought of. That's a biggie list for sure. I'm assuming people are focussing on doing a primary connection on a third party client right now or whenever, sounds like a big priority for sure. After that, ipv6 and other stuff would probably require modernizing the protocol which would essentially create a new network (but really just upgraded it is all). Ipv6 would be another priority too which would help with adoption of the client. Another thing would be support for more file types.

For file searching and the 2gb file size limitation, i think everybody could deal with that for a little bit longer. Basically a modernized rebuild needs to happen, which would of course mean that everyone needs to download a new client.

I did check out winzo. Not as featureful, but it gives you the basics that are desired out of everyone who uses winmx. It's a cool little client.

[GhostShip]

I have asked all of the existing developers to concentrate on a secondary client solution in the first instance, this is purely a matter of common sense as a stable secondary build will gather a solid reputation and engender confidence in those undertaking a step up task to primary and its at this stage we can make primary network changes that are then catered for by the secondary client, to change the structure the other way around would be a major handicap for developers and with so few programmers it was thought a reasonable path for the future.

A primary version of WinPy does exist but its not complete and there are few if any folks taking an interest in completeing it, as Pri states lack of programmers is really the limiting factor in all this, if there where more folks on the job major increases in both clients and features could be delivered in a short space, we havent been backwards in our ideas dept even if the actual codebase is a bit more rudimentary that it need be. 

[shamil]

Oh yeah, thought i should mention so people don't ask me later. I don't know how to code. Some very limited experience with java is it, and all i left it at.

I am definitely good for giving help where i can, writing up documentation, and making web pages. Speaking of which i love the layout of winmxworld. The winmxworld website is such no nonsense that it's what keeps it speedy, not hard on the eyes, and has an simple logical layout for where everything is to be easily found.

[Will]

What would be the ideal language of choice for everyone and why?

[GhostShip]

That's a hard one Willmav, for the younger programmers there is in my opinion a definite preference of C# (and some interest in Mono), older folks like myself play with C++ MFC and more talented folks use C or C++, Java, Python and even Php have been experimented with by one or two folks but the majority of community src code is created in C flavours.

This is of course half the battle with arranging a working team of coders on the same project, I,m sure with a minimum of 3 folks something could be completed of substantial quality but finding 3 folks who will work together as a team and all be at a similar working skill level is a hard task that I have so far been unable to achieve with my own efforts, the real hindrance to even setting up a team is that in real life there needs to be an exceptionally talented programmer and that person should be at the head of the team to lead the overall effort and slot their own work and the work of the others into a complete project, not having any serious programming talent willing and able to take up the key programming/organizational role is why I think most of the prior efforts are failing or have failed, many folks have stepped forward with ideas plans and even some decent code but the true scale of the completed job has seen many disappear as fast as they arrived, and their projects have been in the main based more on their "small project" programming style than anything that can be used as part of a similar larger project.

What do the rest of you think of the programming language issue, Willmavs question is pretty spot on in terms of a starting point for those actually interested in making a difference.

[White Stripes]

for cross platform i vote java... its everywhere...

C# is a microsoft patent trap...

--edit--

ofc ANSI C native binary for each platform would be best... but java could 'fill in' till a native port was created...

[RebelMX]

native C surely has to be the most prudent choice, as it can *fairly* easily be ported into other languages but not so easy visa versa.
The background coding in C is fairly easy once you have the correct protocol documentation, the difficulty is always going to be the gui as there is no simple solution in C except creating window classes for each "box".

[Will]

Don't quote me on this but, I'm almost certain you can use GTK with C.

[Will]

I was right . Also if anyone knows a little C and want's to have a fiddle around, I would have to recommend taking a look at String's DraconisMX .
You can find it in the archives, but if you can't be bothered looking then here's a link httpss://archive.winmxworld.com/String/Strings%20DraconisMX/ 

[shamil]

What is draconismx exactly?

[Max™]

its an old chat client, small, doesn't connect, no channel list, you have to enter the room_hash to enter

[Will]

its an old chat client, small, doesn't connect, no channel list, you have to enter the room_hash to enter

Not quite true, if you take a look at "DraconisMX-0.0.2" then you would see that it is able to connect and get the current list of channels, and you don't need to use the room hash as you just choose from the list.

[Max™]

oops, sorry i only tried the older client many months ago.

[GhostShip]

This one-off side project from Bender was an attempt to create a server that could be used cross platform, it has some of the useful code items all WPN based projects require.

httpss://archive.winmxworld.com/MxControl/MxControl%20Miscellaneous/crossHost.tar

[White Stripes]

GTK can not just be used with C but C++ C# (gtk# in mono project.. ick..) perl, ruby on rails, python (the list goes on).... and its ported to mac & windows and of course is on linux as well

C native with GTK UI... ...you also get the advantage that libcairo can use GPU accel if available...

with the bonus that pidgin users that have used version prior to 1.7 most likely still have a global GTK install on their windows boxen

http://gtk-win.sourceforge.net/home/index.php/en/Home (windows port)

http://gtk-osx.sourceforge.net/ (mac port)

http://www.gtk.org/ (its home page)

[RebelMX]

Sounds like you found your answer there then!!

Another suggestion for fellow C language programmers is the client "Afterthought" which is a C based version of DraconisMX (might even be String's after all).