On Wednesday 04 July 2007 11:52, George Woltman wrote: > At 02:19 PM 7/2/2007, Brian Beesley wrote: > >put a copy of mprime somewhere on the path( ~/bin is a good choice) > > Remember that mprime and prime95 looks for all the ini files and save files > in the same directory as the executable. You can change that behavior > with the -W command line argument.
Hmmm. My impression is that mprime looks for its files in the current working directory. On a dual processor system (an old one running factoring assignments using mprime v24.14) I have only one copy of the executable (in ~/bin) but two working directories one for each process. What I do is change directory into the appropriate working directory then just run mprime -d & in each (in two separate virtual consoles). If I create a new empty directory, change into that and run mprime, I get the "just testing" dialogue and the .ini files are created in the new directory, even though mprime could quite happily create them in ~/bin The point about having only one copy of the executable is that updating to a new version is made easier... > > >but you might want to convert it from windoze EOL to unix EOL by running > >dos2unix on it (changes carriage return+line feed to just line feed) > > This is strictly for your benefit mprime can read either EOL format. > The problem here is when you switch between windoze and linux - I used to do this on a dual boot system. Windoze utilities got terribly confused about what appeared to be CRLF files that suddenly dropped the CR part way through, some of them crashed through trying to fit a "line" of text into a buffer that wasn't big enough. Even though those same utilities worked OK for a file that consistently used LF only from the start. If you never look at results.txt (or prime.log) then the line formatting isn't an issue. But you might as well just delete the files as convert them to the new OS. Which is why I suggested deleting prime.log, it is actually pretty worthless unless you happen to be troubleshooting PrimeNet comms problems. Suggestion, make the client automatically trim "old" entries from prime.log - suggest keeping 30 days by default. Incidentally I may have a pointer to the "Vista problem". Apparently Vista uses IPv6 internally. There is scope for a problem with any program that has IPv4 addresses hard-coded into it. This will be a problem for some users only depending on how the internet service provider copes with IPv6. If Vista discovers the external network supports only v4 you will probably get away with it. Otherwise you may get a program crash when the client tries to communicate with the PrimeNet server. If I'm right about this then the best solution may be to do the client-server communication via DNS lookup even though this does waste time, make man-in-the-middle hostile interceptions much more feasible and cause severe problems should anyone ever forget to renew the domain name registration. Regards Brian Beesley _______________________________________________ Prime mailing list [email protected] http://hogranch.com/mailman/listinfo/prime
