dfGUI v1.8 for Windows available (With Source)

[Digital Parasite]

A new version of dfGUI has been released (v1.8). This new version adds support for people running the DF Client as a Service. It will let you start and stop the client and configure the service options through dfGUI. It acts the same as the non-service version, you just need to click the right box to tell dfGUI to treat your install as a Service client. Any options that are not supported will be disabled. You won't need to open your services tab anymore to start and stop the client, you can control everything from dfGUI.

You can get it in the regular location:
http://gilchrist.ca/jeff/dfGUI/

v1.8 (Aug. 22, 2002)
- Now using GetVersionEx() system call to determine which version of Windows is running (thanks bwkaz).

- Fixed minor bug in NT4 registry code (thanks Aly)

- Added support for controlling DF Client installed as service. Can now Start and Stop service client, and configure service options using dfGUI. It automatically handles the case of having 2 DF Client services installed and will start the correct one. Upload button also works with Service version.

MD5 Sums:
0c3fa4bd6890822b21d6863e44cf4fc5 dfGUIv18.zip
e68ddc299d02edc933615327ed2f131b dfGUIv18src.zip

If you have any problems please let me know.

Jeff.

[Halon50]

Excellent! I've been waiting for a version with services support for my dual machine. Great work as always! :cheers: :cheers:

[Paratima]

Jeff, you sure do great work! A-friggin-mazing!

Thanks for all you do. :thumbs:

[pointwood]

Very cool - thanks a lot Jeff! :notworthy :thumbs:

[hallmar]

Good stuff Jeff, there will be more than a few at OCAU that will apprecite this new version :cheers:

[IronBits]

My brother told me that he used this program to do a BM and it modified his foldit.bat file...

So, I run it JUST to do a benchmark...
My foldit.bat file was modifed to!
It removed ALL the command line paramters! :swear:
I highly suggest to everyone that even looked at this application to double check your foldit.bat file.
Loosing the -rt switch alone could hurt alot! :bang:

Suggestions:
1) DO NOT modify the foldit.bat file unless I click on an option that says A)pply changes to foldit.bat.

2) While I was 'playing' with it, looking down in the right hand corner where you can change how often to upload. I tried to type 5000 and it wouldn't let me. I had to use my cursor arrow to move it to the 1st digit, change it, cursor over a place and change that digit, etc. Shouldn't that be just a text box to fill in?

[tpdooley]

You should request that it reads the current options from the current foldit.bat file. I've been using it to change my foldit.bat settings.
It's also been useful to show when a few of the computers need the clients restarted; (Over the past 3 weeks, I've had 2 or 3 of the 6 computers at work start producing 2-4k structures a day, instead of the 22-180k structures/day that they should be doing..)

[Digital Parasite]

Originally posted by IronBits
[1) DO NOT modify the foldit.bat file unless I click on an option that says A)pply changes to foldit.bat.


Ironbits: dfGUI doesn't modify your foldit.bat file unless you hit the START/UPLOAD/RECOVER button which implies you want dfGUI to to launch the DF Client for you with the settings you have configured in the right hand side. If you just load dfGUI to monitor/benchmark it doesn't touch any of your config files.

If you never hit the START/UPLOAD/RECOVER button in dfGUI then something else modified your foldit.bat file. Does foldit.bat get upgraded every time auto-update happens?

Jeff.

[Digital Parasite]

Originally posted by IronBits
2) While I was 'playing' with it, looking down in the right hand corner where you can change how often to upload. I tried to type 5000 and it wouldn't let me. I had to use my cursor arrow to move it to the 1st digit, change it, cursor over a place and change that digit, etc. Shouldn't that be just a text box to fill in? [/B]

It is using a box that will not allow you to select a digit that is invalid. So for the upload frequency the minimum value is 999 and the max value is 10000. If you wanted to enter 5000 then you would click on the second digit and enter 5000 (no need to use the cursor at all). It will only let you enter a 1 or a 0 for the first digit since anything else is invalid.

If you RTFM you would have seen that dfGUI modifies your foldit.bat file in certain circumstances.

Jeff.

[IronBits]

Hey, NO ProblemO Jeff... I only do pictures :D /ducking
Just caught me off guard. Figured if it happened to me, it might happen to someone else.
Wanted to let folks know to check and make sure the foldit.bat file has the correct switches they want to use is all.
It's a great tool that's for sure! :smoking:
Thanks for all the hard work . :thumbs:

[Digital Parasite]

Sorry IronBits if my tone sounded harsh, I didn't mean to. I wasn't having the best day today with my ISP threatening to cut off my server because some people have received email from an opt-in list, thought it was spam and reported it. My web site was referenced in their email as a site to check out independent benchmarks on their product so people thought it was a spam advertising my site, send a complaint saying I was spamming them, etc... I wrote that really fast without making sure it sounded ok. :cheers:

Jeff.

[Paratima]

:jester: That's rich! You guys... You got him good, Jeff.

I'm sure IronBits never told anyone else to RTFM! Ha!! :rotfl:

[Halon50]

Originally posted by tpdooley
It's also been useful to show when a few of the computers need the clients restarted; (Over the past 3 weeks, I've had 2 or 3 of the 6 computers at work start producing 2-4k structures a day, instead of the 22-180k structures/day that they should be doing..)

My Win9x (Win98 and WinMe) machines don't respond well to changing the client's priority above its default "Low" setting. When using the "Client Priority" checkbox, these machines crunch far slower than normal - about the 2-4k structures per day you've reported. I believe it's just how Win9x handles thread priorities rather than a bug in the DFGUI app or the DF client.

In fact, if you make the DF client window visible and active in the foreground while in this slow state, it will resume its normal speed.

[runestar]

If DF is too slow, why don't you crank the priority up then? There's only like 41 different possible priority settings for DF with windows. =)

And D.P., I like the RTFM!! LOL It never amazes people get angry when you tell them RTFM after they going asking questions answered in the manual. Its like you're too lazy to read the dang manual and then you get MAD at US because you're lazy?

TTFN,

RS½
PBB

[Halon50]

I encountered this problem on the last 156AA protein with the client priority set to 0 (Normal). Different settings (up to -1; I was too chicken to try going any higher) had no effect on the "slow-state" window (and yes, I restarted the client after each granular change). With the "Client Priority" setting unchecked on DFGUI, the processes under Win9x resumed their normal speed.

EDIT: I meant -1, not -10. I just tested a client running the current 69AA protein and it ran normally at all priorities up to -2. -3 or higher priorities made the backgrounded client run much faster, but I don't want to let client hijack so many resources on machines that are used for other things. The "buggy" client performance was apparently only on the last protein, that I've noticed.

[Halon50]

Never mind, I just picked up the following from my P2-300 running DFGUI with Client Priority checked at -5, and Hidden:

------------------------------------------------------------
Distributed Folding Windows dfGUI v1.8 Benchmark

Sample Size : 20 structures over 735 seconds.
Protein Size: 69AA

Structures Per Second: 0.03
Structures Per Minute: 1.9
Structures Per Hour : 114
Structures Per Day : 2743

OS : Windows ME MHz: ???
CPU: GenuineIntel Pentium(r) II Processor
Client Switches: -df -rt -p -5
------------------------------------------------------------

Since I don't feel like trying other priority settings and waiting 12 minutes for every benchmark, and since -5 is pretty high already, I'll assume that it's a bug with Win9x and DOS window priority settings.

Funny thing though, without overriding the default priority the client runs just fine. Normal Structs/day is about 10x the above benchmark.

[runestar]

Just thought of something...


If its not an NT platform (NT, 2000, XP), you need to edit the Properties of the shortcut. On the last tab, there is a slider that adjusts the idle sensitivity when the application is in the background... slide that all the way to the LEFT to LOW.

If the client is already up, you can hit <ALT>-<SPACE> to bring up the properties (assuming you didn't turn off any windows shortcut keys for that shortcut).


RS½
PBB

[runestar]

D.P.,

Check out the attached screenshot... even though dfGUI is set to have DF write every 100 structures, at the moment its running every 15 as you can see. The only thing I did different was shortly before I used the Recover command.

<Thinks> Didn't you say Recover resets everything? If so, then apparently dfGUI won't write any new options to the batch file. That would explain why I am having to close dfGUI out and come back in for it to take effect.

RS½

[runestar]

P.S. I checked the foldit.bat and the switches were there. I think the key to getting dfGUI to reset is that you have to change something in the options to get it to write out the switches. When I stopped dfGUI and restarted it, it went back to normal.

RS½
PBB

[Digital Parasite]

Originally posted by runestar½
P.S. I checked the foldit.bat and the switches were there. I think the key to getting dfGUI to reset is that you have to change something in the options to get it to write out the switches. When I stopped dfGUI and restarted it, it went back to normal.


Every time you hit Start it will write out whatever options you have selected. Listen to what you said, you had dfGUI configured so the client only outputs every 100 structures. You noticed dfGUI was reporting after 15 (note: dfGUI reads progress.txt from the DF client and reports whatever is in that file). Then you checked the foldit.bat file and the proper command line was there.

So why do you think it is still dfGUI that is having the problem and not the DF client? That by restarting the DF Client a second time it solved the problem. I have noticed this too that on occasion the DF Client doesn't write out the number of structures you are expecting. This also happend to me on the Service install where you couldn't select the output value at the time and it would output at strange intervals.

Why does everyone always want to blame dfGUI for everyhing :confused: <sniff, sniff>

Jeff.

[pointwood]

I would just like to say that I have had no problems with this great program!

It rocks! :notworthy :smoking: :thumbs:

[1fast6]

I agree... great proggie... ;)

[MAD-ness]

I blame dfGUI for easy benchmarks, client monitoring and easy configuration of the DF text client.

;)

Keep up the good work.

[Paratima]

Yeah, what's Jeff trying to do...make it easy & convenient to help out a great project? :rolleyes:

[runestar]

I can think of one things better... dfGUI able to display info from statsman and/or the DF website. =)

RS½

[runestar]

Originally posted by Digital Parasite

So why do you think it is still dfGUI that is having the problem and not the DF client? That by restarting the DF Client a second time it solved the problem. I have noticed this too that on occasion the DF Client doesn't write out the number of structures you are expecting. This also happend to me on the Service install where you couldn't select the output value at the time and it would output at strange intervals.

Why does everyone always want to blame dfGUI for everyhing :confused: <sniff, sniff>


I think you answered your own question about why I think it was dfGUI. LOL

Well, if you think about it, nothing else modifies the foldit.bat (except possibly a protein update.)


How about this, when you start the client, dfGUI backs up the the current foldit.bat. Include an option to always delete any lock file found on Start, OR an alternate button to send a stop signal and a kill command to any lock file found (greyed out unless client started). The recover button could be used instead to revert back to the previously backed up foldit.bat. This option would still kill any lock file found though.


Just two-pence worth of thoughts... =)

RS½

P.S. While you're at it... can you include an option to do the dishes too?

[McGoff]

http://users.bigpond.net.au/duenorth/pics2/error1.jpg

this startup error is from an all-in-one headless box 1.2 duron gigabyte 7V-kml
the os is win 98 oem
accessed via VNC

this download works fine on my main box and reports all my machines including this one via the network

as your great program only reports the machine specs of the the box it is running on I wanted to install it on the head less box to give the proper info for bench marks (call me fussy)

where do I find the .dll file ?
and what device is not functioning ?

McGoff

[Digital Parasite]

Originally posted by McGoff
the os is win 98 oem
accessed via VNC

as your great program only reports the machine specs of the the box it is running on I wanted to install it on the head less box to give the proper info for bench marks (call me fussy)

where do I find the .dll file ?
and what device is not functioning ?

Hmmm, very strange, I have never seen this kind of error before. None of the Windows boxes I have tried dfGUI on have ever complained about not finding a DLL so I'm not sure why it is complaining on your machine. On my system I have OLEAUT32.DLL in my System32 directory and it is about 613KB. Have you ever downloaded any patches or security fixes for your Win98 box? I wonder if this DLL comes with a version of IE or some other app, I'm not sure.

The device error message is even more strange. So you don't have a monitor attached to that machine right? I don't see how that would affect things. Windows seems to be doing something strange unless it is an odd incompatability with VNC. Or it could be a strange artifact of not having the DLL and if you did everything would work fine.

So basically I don't know what is wrong with your system or how you could fix it. You did bring up a good point that if you are monitoring a client over a network the machine info is obviously not going to be correct so I should change that to read N/A.

Anyone know how to track where an MS DLL came from so you know how to install it on your machine?

Jeff.

[McGoff]

It must be my install as I have the same type of problems trying to run motherboard monitor (different .dll file)
but a check shows that the .dll files are on my computer and the device manager shows all components are working fine

so it is not your program

it's DFing fine and uploading so I best leave it alone

Would it be possible to have a drop down list that remembers the last 10 paths used to get info from our farms so we don't have to click through multipule network folders when we want to monitor/change our network boxes

also would it be possible to read the registry info from the network boxes to give the right OS, CPU, MHz data for bench marks


thanks

McGoff

[Digital Parasite]

Originally posted by McGoff
Would it be possible to have a drop down list that remembers the last 10 paths used to get info from our farms so we don't have to click through multipule network folders when we want to monitor/change our network boxes

also would it be possible to read the registry info from the network boxes to give the right OS, CPU, MHz data for bench marks

As for your first request, I will add the drop down box to the wish-list for me to get to if I have any time.

Your second one will be more difficult. Normally you shouldn't have access to that info over the network from the registry but we are of course talking about MS so it could be that it is wide open. ;) I will have to look into that but I can't promise anything. Have you looked at KDFold? It is a program that can monitor multiple DF installs and supports networked machines as well I think. It may be better suited for people with multiple network installs.

Jeff.

[runestar]

I don't think I remember seeing that one before... I have the file, but there is no information on what it does... it is a Microsoft file though...

I'm suspecting that the problem is not a missing file, but rather you may have a wrong version of the file, such as sometimes happens when applications overwrite shipped DLLs with their own versions. It doesn't happen as much these days, but its still quite possible. When dfGUI makes a call to the file, its expecting certain code within that file to be at a certain location and when its not, it gets really fussy about it.


I'm not familar with VNC, so i can't comment on that. Are you try to doing a remote desktop or something to the machine?

Try using the UNC path (\\MACHINE-NAME\PATHNAME\dfGUI.exe Note that dfGUI generally expects to be running on the machine you are running it from. It was never designed to be run remotely. Although you are calling it on the other system and executes the executable from there, all the system calls will be done on the system you launch it from.

The second error looks it is trying to find a device that is not loaded. Is the hard drive spun up on the remote system? Is the directory shared and the proper rights on it?


TTFN,

RS½

[bwkaz]

That .dll is the one that contains the base code for all OLE automation "stuff" that Windows does. Stuff like COM, ActiveX, etc.

It might just be a registration problem... does doing a Start, Run, regsvr32 <path to oleaut32.dll> help?

To Jeff, you can get at that registry info if it's under HKEY_USERS (and HKEY_CURRENT_USER is just one of the HKEY_USERS subkeys) or under HKEY_LOCAL_MACHINE. What you do is (and this is from memory, so it might not be entirely correct... check the regitry APIs to make sure) call RegConnectRegistry and give it the remote computer's name and the toplevel key that you want, then call RegOpenKey(Ex) with the path to the subkey, then call RegGetValue (or whatever it is) to get the value. In other words, after the RegConnectRegistry, it's the same procedure as on a local machine.

Note that if the target maching isn't running the nmb or the smb service, RegConnectRegistry first blocks for a long while, then fails. What we did in one program was opened up a Winsock connection to port 139 (nmb), and only if that port was listening did we RegConnectRegistry. Maybe worth the trouble for this, maybe not.

Also, RegConnectRegistry probably won't work if the target or source computer is Win9x, unless you install and turn on the Remote Registry service (but I don't know how to do that, so yeah).

[Wedge]

um.. is the website down? cause i've tried to access it from 3 different computers.. so...

[runestar]

Same here... guess we just wait for Jeff to get the message or find out on his own, and then fix it hopefully.

RS½

[Digital Parasite]

Sorry guys, the IP address of my server was changed on me without me knowing. I was out last night at a BBQ and didn't notice until just now. I have updated the DNS but it make take several hours for everyone to be able to connect.

Just relax :|party|: have a good time :jester: and all will be good soon. ;)

Jeff.