Crossfire has *serious* problems ahead...

[Guest]

Do all other gtk applications running on windows display this behaviour? I doubt that. Is your distrust of GTK based in fact? Then I would say it isn't the libraries exactly but how they are being used in this case - something probably fixable with time.

Just because some applications run under GTK doesn't mean it's stable.

I am afraid that no amount of winking, quoting and clever emotes can make up for a few well placed factual statements.

I agree here, that's why I gave factual information...the client is failing because of GTK library calls (the actual shell output reports GTK lib failure). They simply aren't doing device context copies. This is a fault of the library. This is factual, I have yet to hear someone say why my statement on this is actually wrong, or why it would even be in debate.

If you don't believe the GTK library has a bug in it on Windows then you don't have to. But insisting that it's working when clearly it isn't for some of us is just plain wrong.

Also if the coder had used normal Win32 API calls then you would be seeing a heck of a lot of worse errors when the client was run on other operating systems .

That's why it's called 'non-portable'.

The entire point was that it shouldn't need to run on other systems, just make it run on the one you are coding for. "Do a job and do it well", don't try to make it do everything for everyone is what I am saying.

I've discovered in the past that this concept is hard to understand for many Linux users. They like to say things like "Yeah, but will your Windows application run on Unix?"....um, no, it's not supposed to!

No mistake, I meant because they were portable.

Yes, I thought it was because of portability. That's what my original postings had been based on. This means the messages about it not being a portability issue just confused the issue even more

I think that most reasonable people do want a portable client using libraries that are platform agnostic. Both GTK and SDL are portable libraries and work has already been done on these. I think that it would be better to have people work together than on seperate clients. All the other clients were windows clients (Java, DX, win32) and they are all now defunct.

[hoxu]

I thought you would want a stable and efficient Windows client. I didn't realise that portabliity is more important than functionality. My mistake.

Is there any need to throw either one away?

[Eriwal]

I thought you would want a stable and efficient Windows client. I didn't realise that portabliity is more important than functionality. My mistake.

Is there any need to throw either one away?

It's possible, and preferable, to keep both aspects if possible.

But if there is another solution that will solve a current problem, then it should be at least *considered*. I think that the snide remarks that were thrown my way when I offered to do a native Win32 client were quite rude.

I see no real reason for the rejecting a solution that can fix a current and immediate problem just because someone wants "elegant" code. I offered a viable interim solution to the *terrible* Windows client and it was thrown back in my face because some people put portability issues (ie, code style and paradigm) over real-life requirements.

[hoxu]

I offered a viable interim solution to the *terrible* Windows client and it was thrown back in my face because some people put portability issues (ie, code style and paradigm) over real-life requirements.

Some people? I don' recall anyone preaching about code style or something like that..

[Lauwenmark]

It's possible, and preferable, to keep both aspects if possible.

But if there is another solution that will solve a current problem, then it should be at least *considered*. I think that the snide remarks that were thrown my way when I offered to do a native Win32 client were quite rude.

My fault, probably. Apologizes if I sounded rude - it wasn't the goal.
As for considering that solution, it has already been done. The general consensus is that it isn't a very convenient one, as it would require some 'parallel' work.

I see no real reason for the rejecting a solution that can fix a current and immediate problem just because someone wants "elegant" code.

Stylish code is not the goal. Portable one is. And as it has already been said, you are free to create your own client if you want, or to ask for help to the devel team. But splitting client code base is not the 'official' current position.

I offered a viable interim solution to the *terrible* Windows client and it was thrown back in my face because some people put portability issues (ie, code style and paradigm) over real-life requirements.

You underline the most important drawback to such a solution: an interim one. What about the long-term run ? This is indeed a problem we faced twice in the past - thus you can understand some of us became a little more careful...

I consider portability as a real-life requirement, not a programmers toy. Now it is true that portability has its own constraints, and is definitely not an easy task to achieve. Code style isn't really important, as long as it stays easily understandable by other coders - I think Crossfire only has a few rules regarding programming style: comments, indents, or naming conventions, but nothing going really further.

About the Terrible Win32 client, I agree with you: it currently is terrible... But it is also in quite early beta-stage. The developing task of the maintainer was further complicated by the fact that a lot of new stuff appeared recently in the code. And it is definitely true that although GTK exists under Windows (making the porting job easier), it is not as stable or as well integrated as it is on X servers.

If you want to build a GTK-free Windows client, you would probably not be forced to write everything from scratch. The common/ subdirectory of the client sources contains code that requires only minimal adaptations to run properly on Win32 stations. There is no GUI-related stuff in it - the GUI handling is delegated to other parts of the code (in the x11/, gtk/ or gnome2/). I'd say (but that's a personal opinion only) that the only part that really needs to be portable is what's in common/ - as long as you can bind its content to at least one client on each platform, the goal of 'playing CF everywhere' is reached.

[tchize]

Those errors, technically, comes not for the 'code for portability' but from the fact someone, one day, decided to compile the gtk under windows, a realm where gtkclient wasn't suppposed to stand. If you want us to stop coding for portability this would mean your client will not crash anymore, since there won't be anymore client.

This is a bit contradictory...you just said that the GTK client wasn't written for portability. But then said the only reason there is a Windows client is because the GTK client was written to be portable.

A bit of misunderstanding. The client wasn't at the beginning written for any portability except X-window platforms. Then came the different unix client flavors (gcfclient cfclient). Use of GTK, am pretty sure, maybe am wrong, was simply an interface and speed improvement coding not a portability aimed developpement.
What i wanted to say is if the gtk client wasn't written using a portable library (though am pretty sure portability problem wasn't an aim when developping gtk client), it wouldn't have been possible to compile it under windows.

And if you stop coding for portability there wouldn't be a client?

Err cut out portability from gtkclient right now! Do you have another client available for windows right now? I just wanted to say that portable but instable code you have for now is better than nothing. Some people are working to tune the portability problems, but it may take time.

That's wrong because there was a DirectX client that apparently worked until the server upgraded. Unfortunately it can't be maintained since the sources weren't released.

That's just what I said. You have nothing other than gtk client working under windows for now.

But I'm pretty sure it's no accident that the one working Windows client happened to be done in non-portable, Windows specific code.

Ask his code writter why. I can't give you the reason.

I see no real reason for the rejecting a solution that can fix a current and immediate problem just because someone wants "elegant" code. I offered a viable interim solution to the *terrible* Windows client and it was thrown back in my face because some people put portability issues (ie, code style and paradigm) over real-life requirements.

You have a working native client? You worked fast, a few days ago you were asking how protocol works. Glad to hear about it! But who throwed you your client back to the face? I want the name of those bad guys. btw, where can we download this solution? Could be interresting to put a link on crossfire web page.

I don't think anyone here has ever refused a client because it was not portable. What we just wanted to point is that for us, developpers, it's easier to maintain one client than several. Now if you want to code and maintain you own client, perhaps with help of some other developpers, i have nothing against it. And if it's put under GPL and well maintained, i see no reason why it couldn't be added to the CVS.

[Eriwal]

Sorry if I sounded abruput in my previous replies, but I was a bit annoyed by the initial replies I got when first proposing a native win32 client (they seemed were rude to me at the time , anyway).


> You have a working native client?

No I don't have a working client. I was offering to perhaps do one since there is no stable, working Windows client.

The primary reason for prefering a native Win32 client is that it would be much faster to get it up and going when compared to a 'portable' client (that would also likely not be as efficient or bug free as a native one).

The idea was simply that a quickly written Win32 client that was at least stable would help attract more Windows players. Currently there almost nobody playing CF who uses Windows because the Windows clients just don't work well enough (most Windows users like stuff to be simple and stable...they aren't like Unix and Linux users).


> But who throwed you your client back to the face?

Not this thread, read the thread in "suggestions" forum where I first suggested this. I was told quite plainly that I shouldn't write a new Win32 client.


> btw, where can we download this solution? Could be interresting to put
> a link on crossfire web page.

Heh...that is premature. Right now I'm in limbo about the entire idea. If I did write one it would likely take 2 - 4 months if I really got into it, or 6+ months if I was feeling slack.

[tchize]

I also am not sure completely writting a native windows client is a good idea. However, as has already been written on this thread, creating a native GUI using the current common/ part of client (containing mostly only algorithmic behaviour related to client/server communication) and perhaps, but not sure if needed, rewriting socket handling (but am pretty sure the way it is written for now is posix compatible so windows compatible too) is a better way. You should reallly think about using the common/ part of current client as a starting point. This would prevent you to code the complex crossfire protocol and provide you with faster developpement.

However, this is not because most developper think writing a pure windows client is a bad idea you are forbidden to write it. There has never been code in server to forbid third party clients. The only thing asked is to respect the crossifre communication protocol.

[Lauwenmark]

rewriting socket handling (but am pretty sure the way it is written for now is posix compatible so windows compatible too)

Only very small adaptations are actually needed (mostly including the right headers and call to the Win32-specific socket initialization function WSAStartup()).

Minor adaptations are required in the Metaserver query function - the current implementation attempts to do an fdopen() call over a socket, which does work differently under Win32. Again, that should be pretty easy to solve for a good Windows programmer.

[ycavan]

fdopen() definitely doesn't work correctly for the metaserver code under windoze. It's use is to quickly read in lines of text. I got around it pretty simply by reading into a buffer until a newline was encountered. The parsing code is already there, so you don't need to do much...