Retry: Rybka 1.0 Beta Node Count Patch

[ernest]

So DZA Patcher adds a small program that only runs when you run the modified .exe

Then why don't I see that small program running as a process, with Task Manager?

[Osipov Jury]

Rick !

I believe that your final purpose is to obtain the exact copy of Rybka 1.0 beta from Strelka sources.
I am sure that it is impossible. The differences between Rybka and Strelka are much greater than you think.
I don't know how can i help you.

P.S. It is very difficult for me read and write at English.

[rfadden]

As far as I can tell the Patcher works by somehow starting a thread within the one main process of the program, and then it immediately does it's thing of changing memory locations and then it terminates itself.

If you want to see a demonstration of this error then take the file of patches and add a duplicate patch at the end of the list, and then patch a new .exe, and call this .exe something like "Crazy_patcher_error.exe"

When you run your own Crazy_patcher_error.exe file and if you run into the same symptoms and error that I ran into, then your CPU usage display will stay "pegged" at 100% utilization although the main program that you patched may be sitting idle. If you have a tool for seeing this there will be an indication that your program contains two threads and one of them is looping like crazy and using all of your CPU. That "stuck" thread is the DZA Patcher code that got stuck due to the unexpected input.

So if this little thread code runs correctly then there would be no sign of it remaining. I would expect this thread to only take a few microseconds, or at most a millisecond to run, since all it does in my example is it changes 68 bytes of the original program.

Why don't I see this thread running? Because the thread is gone within one millisecond after running, and you can't react that fast, man!

After carying out the patch the little thread has no reason to keep running, it only stays running at full tilt when it gets stuck due to unexpected input...

Thanks.

[ernest]

Why don't I see this thread running? Because the thread is gone within one millisecond after running...

OK, Rick, I understand.
I thought from your previous explanation, that it was stuck in infinite loop.

[Uri Blass]

Well Jury, as I have said elsewhere I think you did a beautiful job of reverse engineering and I'll go ahead and add the fact that I couldn't do it. I do not have your skill.

I can see inside Rybka well only with the help of your source code.

I have said that you deserve some credit for your great effort. Also I think your code is clean and decent. It is easy to read. Your choice of variable names (motivated by Fruit I guess) and the whole package is to me "like a work of art." Yes I said elsewhere that I consider Rybka to be a work of art but note that I also said that your work to me also looks like a work of art.

Honestly what I want is your original source, the Strelka 1.0 source because my guess has been that your first code was a "Pure" reverse engineer effort with all of Rybka decoded, including the few small, missing pieces. Here's some evidence:

Someone on another forum was stating that in your earliest version you used the exact same data tables as Rybka, not generated by subroutines but from the tables of constants supplied in the Rybka .exe. They said you used some faint attempts at hiding this by running an Exclusive Or across the tables to decrypt your own encrypted versions of Vas's constants.

Well let me be clear. I would like your original work, your original pure reverse engineering of Rybka because that to me would be even more beautiful. Pure unaltered Rybka is beautiful, man... (except Vas's own obfuscation logic is sickening, ugly, foul stuff that should be removed).

So notice what's happening. I am finishing taking Strelka 2.0 and turning it into a pure and exact Rybka 1.0 beta and yet you already have this and you took out or deleted these few parts that I'm working on, specifically to avoid getting in trouble.

Ok, now you are fully "in trouble" and that part is over with, so now could you please send me a copy of the original? This would save me a number of days of work, perhaps even a few weeks of work.

For example I have to go extract the tables from the binary, then put this into a file, and I have to write the file save and file load routines, etc. You would have already done this probably over a year ago. Why duplicate this effort?

(My email address is rfadden@rasteroutput.com, and this is forwarded to my own personal email account, so if I get junk mail I can shut off my own forwarding.)

I have already seen that your code is nice and readable, and so yes your Strelka 1.0, and Strelka 1.8 code would be really nice to have and to continue working with.

Oh by the way, I found a free tool for converting your comments from Russian to English, and this whole process is fun (the translations often require further interpretation).

I have just a simple question and I'm not being critical, so please do not be bothered by my question:

"Why are the comments in Russian?"

I mean you write and speak English and your code is perfectly "english" in nature. Your selected variable names are in English, so why not put the comments in English. This would simply save the effort of translation...

In this case I would like to know your thougths. I'm not saying you shouldn't do it that way, I'm just curious to know your thoughts on the subject.

So please... can I have Strelka 1.0, 1.8 source? The original more pure version?

----------

About the ex-KBG, or GRU comments... I am not afraid of the GRU now... but I do plan on being afraid of them in the future after the place goes completely back to the ways of the past. I have read about those ways in many books, and yes that is truly a scary thought.

Someone who works in the back rooms on decoding problems is not scary to me. It's the front-office guys who are scary.

Also, one other thought to your buddies at the agency... Please do not hurt Gary Kasparov. He is my hero and I hope he is left alone. What is your feeling on this subject?

Thanks,
Rick

Rick,
Juri did something that is not easy to do but
I disagree that the code is easy to read.

The code has clear disadvantages.

1)There is special code for white and black.
My private version of strelka has no special code for white and black in the move generator and the speed is almost the same.

I also changed the evaluation to have no special code for white and black but unfortunately it seems that the new code is 5% slower or something like that so it seems that it is better to have special code for white and black in the evaluation.

2)There are functions that get too many parameters and it is possible to get the same output with less parameters.

It is possible that vasik did it on purpose in order to protect the code.

3)The code clearly have bugs.

4)Part of the names of the variables are not good names(variables about pawn structures do not get significant names and this was changed in my private version of strelka).

I guess that Juri is right that the difference between strelka and rybka is more than what you think and I believe that the task of making something identical to rybka based on strelka is less easy relative to what you expect.

Note that I do not say that it is impossible but my guess is that this is an hard work to do it.

The way to try to do it is probably to try to get first the same output in simple positions(starting with king against king and simple tablebase positions).

Uri

[rfadden]

Uri I'm thinking about your points here and I'm agreeing with you.

On the last point about the difference being larger than I described, I guess what I could do is something like this:

I'll work on it and along the way I'll describe how difficult and how much stuff is missing. I can focus on just reporting accurately what I'm encountering.

So instead of defending my original statement I'll just plug away at it and see how it goes.

In my normal line of work I write a lot of software, I write whole systems and I really get cranking. I also have been estimating how long it takes to develop something in software (as part of my job) and ummm we all have been getting these estimates wrong since the beginning of computer science.

If things take longer than I think, that's probably normal.