Ignore lines in winboard protocol

[Fermin Serrano]

Hi

In my engine I send information to the console other than protocol says, basically extra info for the operator, like the stats of last move. It is nice for debugging purposes.

I have noticed that winboard ignore that lines, but I am intrigued if that could cause problems in any situation. I would think that the correct way to send that kind of comments is with a command like "COMMENT ....", or a symbol "; .....", so that line is ignored. Now, I am not sure, but winboard is processing lines that could cause some kind of problem.

is there any safe way to send "ignore lines" to winboard?

thx

[Teemu Pudas]

feature FEATURE1=VALUE1 FEATURE2=VALUE2 ...
...
debug (boolean, default 0)
If debug=1, it means the engine wants to send debug output prefixed by '#', which WinBoard should ignore, except for including it in the winboard.debug file. As this feature is added to protocol 2 ony late, so that not all protocol-2 supporting versions of WinBoard might implement it, it is important that engines check if WinBoard accepts the feature. If the feature is rejected, engines must refrain from sending the debug output, or do so at their own risk.

[Fermin Serrano]

feature FEATURE1=VALUE1 FEATURE2=VALUE2 ...
...
debug (boolean, default 0)
If debug=1, it means the engine wants to send debug output prefixed by '#', which WinBoard should ignore, except for including it in the winboard.debug file. As this feature is added to protocol 2 ony late, so that not all protocol-2 supporting versions of WinBoard might implement it, it is important that engines check if WinBoard accepts the feature. If the feature is rejected, engines must refrain from sending the debug output, or do so at their own risk.

where is this info published? I am looking at http://www.tim-mann.org/xboard/engine-intf.html and the above text is not there......

[Teemu Pudas]

where is this info published? I am looking at http://www.tim-mann.org/xboard/engine-intf.html and the above text is not there......

I already linked to it.

http://home.hccnet.nl/h.g.muller/engine-intf.html#9

[EugeneCarey]

where is this info published? I am looking at http://www.tim-mann.org/xboard/engine-intf.html and the above text is not there......

I already linked to it.

http://home.hccnet.nl/h.g.muller/engine-intf.html#9

You should also point out that this is an unofficial extension to the winboard / xboard protocol and that it's quite possible that Muller's hacked winboard may be the only one to ever support it.

Others may support it in the future, but until such time you are better off not sending any unexpected output.

And since Muller's extension is optional, you'll have to support the possibility that the winboard gui doesn't accept it, so why bother expecting it to exist?

And since Muller made his own extensions (and still doing so), and still calling them v2, all it's really doing is causing confusion with the real, official v2 protocol.

Muller should have made them v3 instead of v2. Since he didn't, follow the real specs is my advice.

And that means not sending any output that might confuse winboard. And it can happen. I've had it happen.

[Roger Brown]

You should also point out that this is an unofficial extension to the winboard / xboard protocol and that it's quite possible that Muller's hacked winboard may be the only one to ever support it.

Hello Eugene,

H.G. makes it clear that 4.3 is an independent development so I guess his hacks are to be understood to be relevant only to his project...

Others may support it in the future, but until such time you are better off not sending any unexpected output.

And since Muller's extension is optional, you'll have to support the possibility that the winboard gui doesn't accept it, so why bother expecting it to exist?

And since Muller made his own extensions (and still doing so), and still calling them v2, all it's really doing is causing confusion with the real, official v2 protocol.Muller should have made them v3 instead of v2. Since he didn't, follow the real specs is my advice.

Again, he did say why he did this. In his opinion he is not creating anything new, merely extending and clarifying possible gray areas in the protocol. I guess the full possibilities of protocol 2 (indeed Winboard) are yet to be fully explored much less stepped up to version 3.

And that means not sending any output that might confuse winboard. And it can happen. I've had it happen.

Later.

[Harald Johnsen]

You should also point out that this is an unofficial extension to the winboard / xboard protocol and that it's quite possible that Muller's hacked winboard may be the only one to ever support it.

Note that Cyrano is sending that crap (lines starting with #) since day 1 (Gerbil was doing the same). It has never been a problem under any gui, in WB or UCI mode (but since Cyrano support both wb & uci mode I have not tested polyglot).


HJ.

[H.G.Muller]

You should also point out that this is an unofficial extension to the winboard / xboard protocol and that it's quite possible that Muller's hacked winboard may be the only one to ever support it.

Wrong:

it is the official extension of the protocol for WinBoard version 4.3 and higher. Which I do consider the main branch of WinBoard development. If you thnk there will ever be another version from Tim Mann's development team: keep on dreaming...

Others may support it in the future, but until such time you are better off not sending any unexpected output.

There are already other GUIs that are suporting some of the protocol extensions I introduced, (e.g. ChessGUI).

And since Muller's extension is optional, you'll have to support the possibility that the winboard gui doesn't accept it, so why bother expecting it to exist?

Because if you make your engine send protocol-violating output, (as virtually every engine does for debugging purposes), it is always better to only crash some GUIs than to crash all GUIs. In general prefixing a protocol-violating line with '#' will not increase its probability to confuse any known GUI; in the worst case they just skip over the '#'.

And since Muller made his own extensions (and still doing so), and still calling them v2, all it's really doing is causing confusion with the real, official v2 protocol.

Muller should have made them v3 instead of v2. Since he didn't, follow the real specs is my advice.

There is no danger of confusion, as the extensions are fully compliant with the existing v2 protocol. The reaction of the GUI to receiving feature commands it does not recognize (e.g. like feature debug=1) is fully described by this protocol, and consists of rejected debug. The v2 protocol does not guarantee that every feature it defines will be implemented: it grants the GUI the right to refuse features.

Neither does it guarantee that every feature not in the original protocol definition will be rejected by the GUI. And even if it did, it seems a bit far-fetched to suppose that there will ever be an engine whose correct operation will depend on sending a nonexistent feature, and it then being rejected.

So if you can do something that work better in some cases, and never worse, do it. That is my advice...

And that means not sending any output that might confuse winboard. And it can happen. I've had it happen.

In practce everyone just does it anyway, because the risk is small, and the benifit enormous. And if they are going to do it anyway, they might as well prefix it with a '#' and send the debug=1 feature... They can do that even if the feature is rejected, it would still be better than sending the lines without 'protection'. Because even if the GUI does not understand the '#' (e.g. because it is an obsolete WinBoard version), the lines will still end up in the debug file, and other programs that use the debug file (like TLCS) might benifit from the '#' prefix. It is more common for TLCS being confused by spurious engine output, than the GUI.

So my advice to engine authors is: never use the protocol v2 specification on Tim Mann's website, but always use mine. Then you can be 100% sure that your engine runs without problems on GUIs that only implement Tim Mann's version, but in addition it won't function sub-optimally when you are using a state-of-the-art GUI.

[EugeneCarey]

You should also point out that this is an unofficial extension to the winboard / xboard protocol and that it's quite possible that Muller's hacked winboard may be the only one to ever support it.

Hello Eugene,

H.G. makes it clear that 4.3 is an independent development so I guess his hacks are to be understood to be relevant only to his project...

But Teemu Pudas didn't say that.

He was telling Fermin about it as if it was the official version.

Others may support it in the future, but until such time you are better off not sending any unexpected output.

And since Muller's extension is optional, you'll have to support the possibility that the winboard gui doesn't accept it, so why bother expecting it to exist?

And since Muller made his own extensions (and still doing so), and still calling them v2, all it's really doing is causing confusion with the real, official v2 protocol.Muller should have made them v3 instead of v2. Since he didn't, follow the real specs is my advice.

Again, he did say why he did this. In his opinion he is not creating anything new, merely extending and clarifying possible gray areas in the protocol. I guess the full possibilities of protocol 2 (indeed Winboard) are yet to be fully explored much less stepped up to version 3.

And that means not sending any output that might confuse winboard. And it can happen. I've had it happen.

Later.

Again, Teemu wasn't saying that. He was presenting it as if it was the official version, rather than a fork.

I have no problem with anybody creating a private fork, provided it's clear that it is a private fork.

Changing the protover from 2 to 3 (or even to 2.1) would help idicate that.

[EugeneCarey]

You should also point out that this is an unofficial extension to the winboard / xboard protocol and that it's quite possible that Muller's hacked winboard may be the only one to ever support it.

Wrong:

it is the official extension of the protocol for WinBoard version 4.3 and higher. Which I do consider the main branch of WinBoard development. If you thnk there will ever be another version from Tim Mann's development team: keep on dreaming...

Caling it an "official extension" is an oxymoron.

If it's an official v2, then it's not an extension.

If it's an extension, then it can not be v2.

It's like saying it's a large tiny change to a program.

Or a safe, dangerous surgical procedure.


As to whether or not there will be another version from Tim Mann is irrelevant. Not even close to being relevant to the discussion.

His is the official version 2.

If you want to do your own version, then great. No problem.

If you want to fork your own and make radical or minor changes, then fine. Just don't call it v2, because it's not.

Call it v2.1 or v3 or whatever, but it's not v2.

Others may support it in the future, but until such time you are better off not sending any unexpected output.

There are already other GUIs that are suporting some of the protocol extensions I introduced, (e.g. ChessGUI).

I did say that others may support.

That means both ways.

And since Muller's extension is optional, you'll have to support the possibility that the winboard gui doesn't accept it, so why bother expecting it to exist?

Because if you make your engine send protocol-violating output, (as virtually every engine does for debugging purposes), it is always better to only crash some GUIs than to crash all GUIs. In general prefixing a protocol-violating line with '#' will not increase its probability to confuse any known GUI; in the worst case they just skip over the '#'.

I didn't say it was or was not a good idea.

It is a change that can potentially cause problems.

Do # for your v2.1 extensions and don't send any unsafe output when using v2 does require a change.

Sending # lines to a v2 gui when there's a chance it'll cause problems is just plain foolish. Hence for v2 you can't safely send any debugging etc. lines. You are right back where you started with real v2 winboard.

And since Muller made his own extensions (and still doing so), and still calling them v2, all it's really doing is causing confusion with the real, official v2 protocol.

Muller should have made them v3 instead of v2. Since he didn't, follow the real specs is my advice.

There is no danger of confusion, as the extensions are fully compliant with the existing v2 protocol.

There is a danger of confusion. Just look at this thread. Teemu, for example, though it was official winboard protocol.

The reaction of the GUI to receiving feature commands it does not recognize (e.g. like feature debug=1) is fully described by this protocol, and consists of rejected debug. The v2 protocol does not guarantee that every feature it defines will be implemented: it grants the GUI the right to refuse features.

I understand all that.

But you are still making private changes to an 'official' protocol.

And then trying to confuse people by keeping it as v2.

The v2 protocol says the listed features are v2.

The features you are including are not part of v2.

In fact, Tim Mann specifically made 'protover num' for future additions. Like the additions you are doing.


It's the same kind of nonsense that Microsoft regularly does. They take an official standard, modify the heck out of it, then claim it's still the standard because it has the same name.

Neither does it guarantee that every feature not in the original protocol definition will be rejected by the GUI. And even if it did, it seems a bit far-fetched to suppose that there will ever be an engine whose correct operation will depend on sending a nonexistent feature, and it then being rejected.

So if you can do something that work better in some cases, and never worse, do it. That is my advice...

And that means not sending any output that might confuse winboard. And it can happen. I've had it happen.

In practce everyone just does it anyway, because the risk is small, and

Not so small.

What happens is that most engines slowly change over time so they manage not to send risky output to the gui.

the benifit enormous. And if they are going to do it anyway, they might as well prefix it with a '#' and send the debug=1 feature... They can do

I'm not saying it's not a useful feature.

I'm just saying don't call it v2, because that's a lie.

that even if the feature is rejected, it would still be better than sending the lines without 'protection'. Because even if the GUI does not understand the '#' (e.g. because it is an obsolete WinBoard version), the lines will still end up in the debug file, and other programs that use the debug file (like TLCS) might benifit from the '#' prefix. It is more common for TLCS being confused by spurious engine output, than the GUI.

So my advice to engine authors is: never use the protocol v2 specification on Tim Mann's website, but always use mine. Then you can be 100% sure that your engine runs without problems on GUIs that only implement Tim Mann's version, but in addition it won't function sub-optimally when you are using a state-of-the-art GUI.

No, you won't be sure.

Your own suggestion of sending # output even if the GUI rejects and might get confused it is downright foolish & misguided.


Call your protocol v2.1 or v3 and that'll take care of my complaints.

I have no objections to the changes themselves.

My objections are you calling your personal version to be v2 when it is clearly not. It is based on v2, but it is not v2 anymore.

Call it 2.1, or 3.0beta or something else. But it's not the official v2 protocol.


You've taken winboard, decided to make significant changes to it and the protocol, and self claimed it to be the new official branch of winboard.

How can you possibly keep calling it v2, then??

[Teemu Pudas]

Teemu, for example, though it was official winboard protocol.

No, I didn't! I just thought the opposite was so obvious that it didn't need to be explained. Not to mention irrelevant - the description of the debug feature specifically warns that not all protocol-2 supporting versions of WinBoard might implement it. Remember this thread was originally only about sending debug info to Winboard...

[H.G.Muller]

Caling it an "official extension" is an oxymoron.

If it's an official v2, then it's not an extension.

If it's an extension, then it can not be v2.

Apparently we have different interpretation of what a version of the protocol means. In my definition, a version is different if it prescribes things that might crash another version. Protocol v2 is different from v1 because it sends the protover command, and there is no guarantee that that command would not make a v1 engine crash. And indeed there are engines that do.

Version 2 defines the feature mechanism to let GUI and engine negociate what they can do. The document by Timm Man explicitly states that in protocol 2 any feature can be requested by the engine, even features that are not defined in that document.

His is the official version 2.

If you want to do your own version, then great. No problem.

If you want to fork your own and make radical or minor changes, then fine. Just don't call it v2, because it's not.

Call it v2.1 or v3 or whatever, but it's not v2.

My document clearly states that you could call it v2f if you want. But what I am not going to do, is have WinBoard send anyting else but protover 2, as this might confuse some engines, where now no confusion is possible: engines that stick to the obsolete standard will simply never sent the feature command.

I didn't say it was or was not a good idea.

You adviced against using it...

It is a change that can potentially cause problems.

Oh yeah? Which problem?

Do # for your v2.1 extensions and don't send any unsafe output when using v2 does require a change.

Sending # lines to a v2 gui when there's a chance it'll cause problems is just plain foolish.

But people do it anyway. and if they intend to do it anyway, they might as well prefix it with '#'. That is all I am saying. It is safe for them to send feature debug=1 to a prototocol-2 GUI. If they want to know if it is supported, they should pay attention to the accepted / rejected responses.

If it is not supported, they should refrain from sending any debugging output, or do so at their own risk. This just explicitly describes what Tim Mann's version 2 already described implicitly. Stepping up the protocol number would not change anything to that: the fact that a GUI says it is using protover 3 need not imply it supports every feature of that version. This is also explicitly stated in Timm Mann's document. So even if I would call it v3, engines woud still have to test if the feature is accepted or not.

[EugeneCarey]

Teemu, for example, though it was official winboard protocol.

No, I didn't! I just thought the opposite was so obvious that it didn't need to be explained.

In that case, I stand corrected. But by quoting only the one relevant part and not saying it was Muller's unofficial extended version, it did give the impression it was from the real specs.

Not to mention irrelevant - the description of the debug feature specifically warns that not all protocol-2 supporting versions of WinBoard might implement it. Remember this thread was originally only about sending debug info to Winboard...

That it was from an unofficial extension is hardly irrelevant.

A lot of v2 features aren't always supported, but they are still official v2 features.

[EugeneCarey]

Caling it an "official extension" is an oxymoron.

If it's an official v2, then it's not an extension.

If it's an extension, then it can not be v2.

Apparently we have different interpretation of what a version of the protocol means.

Apparently. I think "official" means the real stuff and you think that any modified version that some hack puts toegher can also be called 'official'.

In my definition, a version is different if it prescribes things that might crash another version. Protocol v2 is different from v1 because it sends the protover command, and there is no guarantee that that command would not make a v1 engine crash. And indeed there are engines that do.


Version 2 defines the feature mechanism to let GUI and engine negociate what they can do. The document by Timm Man explicitly states that in protocol 2 any feature can be requested by the engine, even features that are not defined in that document.

His is the official version 2.

If you want to do your own version, then great. No problem.

If you want to fork your own and make radical or minor changes, then fine. Just don't call it v2, because it's not.

Call it v2.1 or v3 or whatever, but it's not v2.

My document clearly states that you could call it v2f if you want. But what I am not going to do, is have WinBoard send anyting else but protover 2, as this might confuse some engines, where now no confusion is possible: engines that stick to the obsolete standard will simply never sent the feature command.

I didn't say it was or was not a good idea.

You adviced against using it...

I advised against using it if you are trying to do a v2 protocol chess engine.

If an engine author *wants* to use unofficial extensions that somebody hacked together, then go ahead. I don't care in the slightest.

It is a change that can potentially cause problems.

Oh yeah? Which problem?

Crashing the gui.

Causing the gui to think you made a move that you didn't, because it misunderstood some debugging output.

Both of which have happened with my older winboard programs while debugging.

For real v2 winboard, it is not safe to send unexpected output.

Your recommending that people do it anyway is not responsible.

Do # for your v2.1 extensions and don't send any unsafe output when using v2 does require a change.

Sending # lines to a v2 gui when there's a chance it'll cause problems is just plain foolish.

But people do it anyway. and if they intend to do it anyway, they might as well prefix it with '#'. That is all I am saying. It is safe for them to send feature debug=1 to a prototocol-2 GUI. If they want to know if it is supported, they should pay attention to the accepted / rejected responses.

Again, you are trying to change the subject. Seems to happen a lot with you.

If it is not supported, they should refrain from sending any debugging output, or do so at their own risk. This just explicitly describes what Tim Mann's version 2 already described implicitly. Stepping up the protocol number would not change anything to that: the fact that a GUI says it is using protover 3 need not imply it supports every feature of that version. This is also explicitly stated in Timm Mann's document. So even if I would call it v3, engines woud still have to test if the feature is accepted or not.

HG... I've seen enough of your other threads to know you aren't going to be persuaded by reason.

So let's just say that you and I significantly disagree on very basic common sense things.

[H.G.Muller]

Apparently. I think "official" means the real stuff and you think that any modified version that some hack puts toegher can also be called 'official'.

Can't you read, or what? since when do you spell "version" as O F F I C I A L ???

It is time you stop dreaming in limboland, and wake up to the reality that there has been no fork, and will not be a fork. A fork is when development progresses in different directions. In this case development progresses only in one direction: mine. That is not called a 'fork', it is called 'progress'. Tim Mann's version 4.2.7 is not a separate branch of the evolution of WinBoard from 4.3.15. Not even a dead one. It is a living fossil, soon to be extinct...

I advised against using it if you are trying to do a v2 protocol chess engine.

If an engine author *wants* to use unofficial extensions that somebody hacked together, then go ahead. I don't care in the slightest.

An that was bad advice. Authors that want to do a v2 protocol engine should do it as I specify in my v2 description: send feature debug=1, receive and interpret the rejected debug reply by the GUI, and then refrain from sending protocol-violating output. If they do it that way, they keep the chance open to strike paydirt, by getting the reply accepted debug. and then they can do what they like to do.

And for an engine that wants to take the risk sending debug output even to GUIs that reject the feature, it would still be good practice to prefix it with '#'. Because even if the GUI has a large chance to survive this, the users of the debug files might not.

You sure make a lot of noise for someone who 'doesn't care the slightest'. (I wouldn't call them arguments...)

Oh yeah? Which problem?

Crashing the gui.

Causing the gui to think you made a move that you didn't, because it misunderstood some debugging output.

Both of which have happened with my older winboard programs while debugging.

As I described above, nothing of that can happen to engines that follow my protocol specification: the rejected debug command would stop them from sending the output.

For real v2 winboard, it is not safe to send unexpected output.

Your recommending that people do it anyway is not responsible.

First try to understand what I recommend, befor criticizing it...

Again, you are trying to change the subject. Seems to happen a lot with you.

I thought the subject was how people that would use my protocol v2 description would get in trouble with the obsolete v2 version. But why am I sure you are going to tell us different now?

HG... I've seen enough of your other threads to know you aren't going to be persuaded by reason.

So let's just say that you and I significantly disagree on very basic common sense things.

Well, replace 'reason' by 'stupidity', and we might even agree. But, before taking a tone like that, it would be wise to first say something that was correct yourself...

[Olivier Deville]

All off-topic posts have been deleted from this thread.

Please don't do it again.

Olivier

[H.G.Muller]

Good! Now we can go back to business.

What I actually recommend to people building an engine that i supposed to run under protocol v2 is what already was quoted above:

feature FEATURE1=VALUE1 FEATURE2=VALUE2 ...
...
debug (boolean, default 0)
If debug=1, it means the engine wants to send debug output prefixed by '#', which WinBoard should ignore, except for including it in the winboard.debug file. As this feature is added to protocol 2 ony late, so that not all protocol-2 supporting versions of WinBoard might implement it, it is important that engines check if WinBoard accepts the feature. If the feature is rejected, engines must refrain from sending the debug output, or do so at their own risk.

If people follow this advice, their engine is 100% compatible with protocol v2: GUIs not implementing the debug feature are required (by the original description of protocol 2) to send rejected debug to the engine. And I recommend the engine not to send any protocol-violating lines in that case.

So there is zero danger of an engine built according to my specifications of the protocol will ever crash a GUI that is built according to Tim Mann's specs (nor the other way around). This is why I consider them the same protocol.

The added remark that sending protocol-violating output is at your own risk, is valid in any version of any protocol. It is just stating the obvious. I don't even mention that the risk is very low.

Actually, in future descriptions of the protocol, I should go even further here, and encourage people that want to take the risk of violating the protocol in case of the rejected response, should still prefix the output by '#'. Even if they know the GUI will not pay any attention to the '#' at all. Because the GUI would still copy the '#' through to the debug file, and you never know with which programs someone would later want to process this debug file. Not even the one responsible for the selection of the GUI might know this, as debug files are often sent around as bug reports. Perhaps to the author of the opponent engine. So writing the '#' before any debug output that you foolhardily sent to unhelpful GUIs might still make life better for someone, even if it doesn't mean anything to the GUI. Therefore: always do it!

Perhaps I should clear up some misunderstanding about my remark about the 'living fossil', that was not understood by everyone: this was not meant as a derogative term to belittle the contribution to WinBoard of those who have been working it before me. It is a biological term to indicate a species that evolved into other live forms, but failed to become extinct (as usually happens), and survived unchanged to present times, next to its evolutionary successor. This exactly describes the situation of WinBoard 4.2.7: it has been superseeded by several generations of 100% upward-compatible WinBoard versions, WinBoard_x being one of them. Yet 4.2.7 remained around since 2001 without being actively developed. But if this lack of development will continue forever (as is extremely likely, considering Tim Mann's current attitude towards computer Chess), it is unavoidabe that its use will decline. If not because people are switching to WinBoard_x or WinBoard 4.3, then because they will switch to Arena, ChessGUI, or other GUIs.

[Michel]

Reading this discussion I wonder how the independent development of 4.3 came about. Was TIm Mann unwilling to accept patches? Has he officially indicated he is no longer working on Winboard/Xboard?

In any case, since this is an independent project, I think it would have been better to choose a different name, like Winboard-ng or something.

Michel

[Don Cross]

If careful compatibility with older versions of WinBoard/xboard is of concern (as it is with me, trying to support both Windows and Linux with the same C++ chess engine source code), perhaps there are other options available if "feature debug=1" is rejected.

When I read the original Tim Mann spec, it says that when thinking, continuation lines are allowed so long as they begin with at least 4 spaces. These lines are allowed to contain free-form text. So during search, when "post" is active, debug output prefixed with 4 spaces should be allowed on any WinBoard/xboard.

Another, perhaps less attractive option, but which I think would be safer and more flexible: If your engine receives "protover", you can assume any feature request is safe, even if rejected. You could deliberately use a feature request that you know will be rejected, just for the side effect of getting something into the log file without crashing the host. For example:

feature ignorethis="I am entering the function HappyFunBall()"

You would keep getting "rejected ignorethis", but as a safe hack for getting info into the debug log, this should be 100% compatible with any version 2 or greater.

- Don

[H.G.Muller]

Reading this discussion I wonder how the independent development of 4.3 came about. Was TIm Mann unwilling to accept patches? Has he officially indicated he is no longer working on Winboard/Xboard?

In any case, since this is an independent project, I think it would have been better to choose a different name, like Winboard-ng or something.

Tim Mann has unofficially let me know that his current interest in computer Chess is "roughly zero". I don't think it would be decent to publish an e-mail here that he sent me in private, but when I asked him if he could clarify something that was ambiguous in the protocol specs, his reaction was something along the line: "to know what is wrong, I would have to read your mail, and as it is about computer Chess, and nearly a page long, don't hold your breath". Since then I haven't heard anything from him...

I started out choosing a different name, "WinBoard_F", but it turned out that this deterred people from using it, as they seemed to think it was only a GUI for Chess variants, unsuitable for nortmal Chess. So I switched to using a different version number, rather than a different name. That seems clear enough, and in fact expresses much more truthfully what WinBoard 4.3 actually is: the most advanced main branch of the evolution of WinBoard, containing 100% of WinBoard 4.2.7 and WinBoard_x.

I think it is safe to say that by now, WinBoard 4.3 is so far ahead of where Tim Mann's team stopped, that they would never be able to catch up with it, unless they would start working from the 4.3 code.