Windows NT4 No Longer Compatible?

Alinator
Alinator
Joined: 8 May 05
Posts: 927
Credit: 9,352,143
RAC: 0

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

Bernd Machenschalk
Bernd Machenschalk
Moderator
Administrator
Joined: 15 Oct 04
Posts: 4,049
Credit: 224,470,668
RAC: 23,026

RE: OK, so why can't we

Message 83777 in response to message 83776

Quote:
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

BM

Alinator
Alinator
Joined: 8 May 05
Posts: 927
Credit: 9,352,143
RAC: 0

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

chablis
chablis
Joined: 18 Jan 05
Posts: 10
Credit: 1,716,171
RAC: 0

RE: RE: OK, so why can't

Message 83779 in response to message 83777

Quote:
Quote:
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

Alinator
Alinator
Joined: 8 May 05
Posts: 927
Credit: 9,352,143
RAC: 0

RE: RE: RE: OK, so why

Message 83780 in response to message 83779

Quote:
Quote:
Quote:
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

Richard Haselgrove
Richard Haselgrove
Joined: 10 Dec 05
Posts: 2,059
Credit: 961,319,522
RAC: 1,475,966

RE: Also, do you have any

Message 83781 in response to message 83780

Quote:

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.

Alinator
Alinator
Joined: 8 May 05
Posts: 927
Credit: 9,352,143
RAC: 0

RE: RE: Also, do you have

Message 83782 in response to message 83781

Quote:
Quote:

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

Richard Haselgrove
Richard Haselgrove
Joined: 10 Dec 05
Posts: 2,059
Credit: 961,319,522
RAC: 1,475,966

RE: RE: RE: Also, do

Message 83783 in response to message 83782

Quote:
Quote:
Quote:

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.


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.

Alinator
Alinator
Joined: 8 May 05
Posts: 927
Credit: 9,352,143
RAC: 0

RE: The major difference

Message 83784 in response to message 83783

Quote:

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.

Alinator

chablis
chablis
Joined: 18 Jan 05
Posts: 10
Credit: 1,716,171
RAC: 0

RE: RE: RE: RE: OK,

Message 83785 in response to message 83780

Quote:
Quote:
Quote:
Quote:
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.

Chablis

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.