I don't think I want to screw around making a new app_info from scratch.
It is far easier to just trim out the signature element for the replacement switcher in client_state.
Maybe not! I was looking at the wrong task running! :-O
OK, so why can't we just replace the sinature for the original with the one for the replacement?
OK, so why can't we just replace the sinature for the original with the one for the replacement?
As far as I understand the replacement actually didn't solve the problem, did it? I compiled the replacement switcher with the oldest version of Visual Studio that works with BOINC (2003), and I don't know what else (i.e. which other "old libraries") I could use. Hm, maybe I should try to port that small switcher code to VC6?
What you could do of course (for a test or a solution) is to write an app_info.xml for your system that completely leaves out the switcher and uses the executable suitable for your computer as the application binary.
First, the project refuses to send anything to the host if there is an app_info file in the EAH directory.
Second, I decided to try some standalone testing before incorporating my new app_info file and executable set into BOINC directly.
None of the S5R4 apps (including the substitute switcher) will execute on NT4. They all exit at startup with error message:
"The procedure entry point Thread32Next could not be located in the dynamic link library KERNEL32.dll.
As a check, I tried running the S5R3 app in standalone mode. It did execute properly, exiting with an init_data.xml and an stderr file which indicated I had not supplied any arguments or parameters (not surprisingly). ;-)
OK, so why can't we just replace the sinature for the original with the one for the replacement?
As far as I understand the replacement actually didn't solve the problem, did it? I compiled the replacement switcher with the oldest version of Visual Studio that works with BOINC (2003), and I don't know what else (i.e. which other "old libraries") I could use. Hm, maybe I should try to port that small switcher code to VC6?
What you could do of course (for a test or a solution) is to write an app_info.xml for your system that completely leaves out the switcher and uses the executable suitable for your computer as the application binary.
BM
No it did Error 128 on both WU. Remember I am running BOINC client 5.8.16 as this is the last one compatible with NT4. Seti at home also does not run on these machines since their exe became a 6.x. Also to repeat because there 2 of us with problems I do not run graphics.
OK, so why can't we just replace the sinature for the original with the one for the replacement?
As far as I understand the replacement actually didn't solve the problem, did it? I compiled the replacement switcher with the oldest version of Visual Studio that works with BOINC (2003), and I don't know what else (i.e. which other "old libraries") I could use. Hm, maybe I should try to port that small switcher code to VC6?
What you could do of course (for a test or a solution) is to write an app_info.xml for your system that completely leaves out the switcher and uses the executable suitable for your computer as the application binary.
BM
No it did Error 128 on both WU. Remember I am running BOINC client 5.8.16 as this is the last one compatible with NT4. Seti at home also does not run on these machines since their exe became a 6.x. Also to repeat because there 2 of us with problems I do not run graphics.
Chablis
@ Chablis:
Just to make sure we're still on the same page here:
Are you still running stock, or did you make an app_info file to point to the application executable directly?
Also, you can work around this problem on SAH using the app_info method and have it point to the 5.27 application (or one of the Coop's opti's as appropriate).
@ Bernd: After reading up on the missing entry point error I got in standalone testing, I'm of the opinion the problem is with the new method of determining whether the CC is still running or not, and not a graphics problem per se. The anecdotal evidence from SAH tends to support that hypothesis.
So based on that, I doubt trying to compile with VC 6 would make any difference since the system function calls required for the new heartbeat just aren't supported in NT4. I suppose something which might work would be to have the v6 apps revert back to the old heartbeat mechanism when they detect that support for the old method is not available before exiting with an irrecoverable fault.
Also, do you have any guidance on why the project is rejecting work requests when it detects the anonymous platform still?
Also, do you have any guidance on why the project is rejecting work requests when it detects the anonymous platform still?
Alinator
?????
I have an app_info on all rigs (Windows - the type that specifies stock app for S5R4, and Power App for S5R3). No sign of any work rejection here - just a few server stutters.
Also, do you have any guidance on why the project is rejecting work requests when it detects the anonymous platform still?
Alinator
?????
I have an app_info on all rigs (Windows - the type that specifies stock app for S5R4, and Power App for S5R3). No sign of any work rejection here - just a few server stutters.
Hmmm...
Did you take a look at the snippet I posted earlier? Maybe you can point out where I botched it. ;-)
Also, do you have any guidance on why the project is rejecting work requests when it detects the anonymous platform still?
Alinator
?????
I have an app_info on all rigs (Windows - the type that specifies stock app for S5R4, and Power App for S5R3). No sign of any work rejection here - just a few server stutters.
Hmmm...
Did you take a look at the snippet I posted earlier? Maybe you can point out where I botched it. ;-)
Alinator
Well, I didn't see any message log snippet indicating a server refusal, LOL!
This app_info started out as a working copy as described. I'm editing out the bits that are not relevant for your purpose as I go along: should end up with something comparable.
The major difference seems to be the app_name: you have the friendly version, where I have the internal name.
LOL...
Thanks, that helped get things working! Apparently it doesn't like using the friendly name in the app_info. ;-)
That's what I get using the official documentation as a guideline! :-)
In any event, there still is the missing entry point into KERENEL32.dll problem. So I'm still leaning towards the new heartbeat stuff hypothesis as the source of the incompatibility for NT4, and not a graphics problem per se.
OK, so why can't we just replace the sinature for the original with the one for the replacement?
As far as I understand the replacement actually didn't solve the problem, did it? I compiled the replacement switcher with the oldest version of Visual Studio that works with BOINC (2003), and I don't know what else (i.e. which other "old libraries") I could use. Hm, maybe I should try to port that small switcher code to VC6?
What you could do of course (for a test or a solution) is to write an app_info.xml for your system that completely leaves out the switcher and uses the executable suitable for your computer as the application binary.
BM
No it did Error 128 on both WU. Remember I am running BOINC client 5.8.16 as this is the last one compatible with NT4. Seti at home also does not run on these machines since their exe became a 6.x. Also to repeat because there 2 of us with problems I do not run graphics.
Chablis
@ Chablis:
Just to make sure we're still on the same page here:
Are you still running stock, or did you make an app_info file to point to the application executable directly?
Also, you can work around this problem on SAH using the app_info method and have it point to the 5.27 application (or one of the Coop's opti's as appropriate).
@ Bernd: After reading up on the missing entry point error I got in standalone testing, I'm of the opinion the problem is with the new method of determining whether the CC is still running or not, and not a graphics problem per se. The anecdotal evidence from SAH tends to support that hypothesis.
So based on that, I doubt trying to compile with VC 6 would make any difference since the system function calls required for the new heartbeat just aren't supported in NT4. I suppose something which might work would be to have the v6 apps revert back to the old heartbeat mechanism when they detect that support for the old method is not available before exiting with an irrecoverable fault.
Also, do you have any guidance on why the project is rejecting work requests when it detects the anonymous platform still?
Alinator
I did an app_info file pointing to the modifid app Bernd created. Everything else I run are stock apps and clients. I have too many machines running too many OS's to optimize. I did nothing for SETI as it only effected 1 computer that is not NT. BTW the reason I have so many OS's (especially servers OS's) is I am a freelance developer in regulated industries (pharma, biotech, food) so I need to be able to replicate client's systems for FDA/USDA issues. Therefore "upgrades" are out of the question. I wiil not even go into the PLCs and DCS systems I own.
Hmmm... OK. I don't
)
Hmmm...
OK.
I don't think I want to screw around making a new app_info from scratch.
It is far easier to just trim out the signature element for the replacement switcher in client_state.
Maybe not! I was looking at the wrong task running! :-O
OK, so why can't we just replace the sinature for the original with the one for the replacement?
Alinator
RE: OK, so why can't we
)
As far as I understand the replacement actually didn't solve the problem, did it? I compiled the replacement switcher with the oldest version of Visual Studio that works with BOINC (2003), and I don't know what else (i.e. which other "old libraries") I could use. Hm, maybe I should try to port that small switcher code to VC6?
What you could do of course (for a test or a solution) is to write an app_info.xml for your system that completely leaves out the switcher and uses the executable suitable for your computer as the application binary.
BM
BM
OK, I seem to be running into
)
OK, I seem to be running into two problems.
First, the project refuses to send anything to the host if there is an app_info file in the EAH directory.
Second, I decided to try some standalone testing before incorporating my new app_info file and executable set into BOINC directly.
None of the S5R4 apps (including the substitute switcher) will execute on NT4. They all exit at startup with error message:
"The procedure entry point Thread32Next could not be located in the dynamic link library KERNEL32.dll.
As a check, I tried running the S5R3 app in standalone mode. It did execute properly, exiting with an init_data.xml and an stderr file which indicated I had not supplied any arguments or parameters (not surprisingly). ;-)
Here's the app_info I devised:
Hierarchical all-sky pulsar search
einstein_S5R4_6.04_windows_intelx86.exe
einstein_S5R4_6.04_graphics_windows_intelx86.exe
Hierarchical all-sky pulsar search
604
windows_intelx86
6.1.0
einstein_S5R4_6.04_windows_intelx86.exe
einstein_S5R4_6.04_graphics_windows_intelx86.exe
graphics_app
My strategy was to masquerade the _0 app as the switcher, and include the graphics app for R4 under the v6 API.
Alinator
RE: RE: OK, so why can't
)
No it did Error 128 on both WU. Remember I am running BOINC client 5.8.16 as this is the last one compatible with NT4. Seti at home also does not run on these machines since their exe became a 6.x. Also to repeat because there 2 of us with problems I do not run graphics.
Chablis
RE: RE: RE: OK, so why
)
@ Chablis:
Just to make sure we're still on the same page here:
Are you still running stock, or did you make an app_info file to point to the application executable directly?
Also, you can work around this problem on SAH using the app_info method and have it point to the 5.27 application (or one of the Coop's opti's as appropriate).
@ Bernd: After reading up on the missing entry point error I got in standalone testing, I'm of the opinion the problem is with the new method of determining whether the CC is still running or not, and not a graphics problem per se. The anecdotal evidence from SAH tends to support that hypothesis.
So based on that, I doubt trying to compile with VC 6 would make any difference since the system function calls required for the new heartbeat just aren't supported in NT4. I suppose something which might work would be to have the v6 apps revert back to the old heartbeat mechanism when they detect that support for the old method is not available before exiting with an irrecoverable fault.
Also, do you have any guidance on why the project is rejecting work requests when it detects the anonymous platform still?
Alinator
RE: Also, do you have any
)
?????
I have an app_info on all rigs (Windows - the type that specifies stock app for S5R4, and Power App for S5R3). No sign of any work rejection here - just a few server stutters.
RE: RE: Also, do you have
)
Hmmm...
Did you take a look at the snippet I posted earlier? Maybe you can point out where I botched it. ;-)
Alinator
RE: RE: RE: Also, do
)
Well, I didn't see any message log snippet indicating a server refusal, LOL!
This app_info started out as a working copy as described. I'm editing out the bits that are not relevant for your purpose as I go along: should end up with something comparable.
einstein_S5R4
einstein_S5R4_6.04_windows_intelx86_0.exe
einstein_S5R4_5.09_0_windows_intelx86.pdb
einstein_S5R4_6.04_graphics_windows_intelx86.exe
einstein_S5R4
604
6.1.0
einstein_S5R4_6.04_windows_intelx86_0.exe
einstein_S5R4_5.09_0_windows_intelx86.pdb
einstein_S5R4_6.04_graphics_windows_intelx86.exe
graphics_app
{my approach is to edit the app_info, and leave the executable names unchanged, but YMMV - important thing is that they match}
The major difference seems to be the app_name: you have the friendly version, where I have the internal name.
RE: The major difference
)
LOL...
Thanks, that helped get things working! Apparently it doesn't like using the friendly name in the app_info. ;-)
That's what I get using the official documentation as a guideline! :-)
In any event, there still is the missing entry point into KERENEL32.dll problem. So I'm still leaning towards the new heartbeat stuff hypothesis as the source of the incompatibility for NT4, and not a graphics problem per se.
Alinator
RE: RE: RE: RE: OK,
)
I did an app_info file pointing to the modifid app Bernd created. Everything else I run are stock apps and clients. I have too many machines running too many OS's to optimize. I did nothing for SETI as it only effected 1 computer that is not NT. BTW the reason I have so many OS's (especially servers OS's) is I am a freelance developer in regulated industries (pharma, biotech, food) so I need to be able to replicate client's systems for FDA/USDA issues. Therefore "upgrades" are out of the question. I wiil not even go into the PLCs and DCS systems I own.
Chablis