Feature request (sort of)

[Scoofy12]

I Guess this post belongs here...

The fact that the text client (being in a DOS box, i guess) won't die peacefully when w98 shuts down seems to be causing users a fair amount of grief. I seem to remember some way to avoide the message it gives you, I think you still lose your work, and the lock file stays there. I must confess I don't know much about the innards of windows, but I know the NT service will save its progress and shut down in a hurry when it needs to (i assume this is because there is some way for windows to tell it to do so on shutdown). I would think that there would be some way for a text client to catch a SIGTERM and do something similar to facilitate shutdowns (is there a windows equivalent to this? I'm trying to remember whether signalsh is ANSI C or just linux). Can windows even do something like that for a dos box or does it just kill it?

[IronBits]

_default.pif is what you are talking about.
If there isn't one in C:\Windows
Create a new one.
Then do a properties on it, go to the misc. TAB,
make sure there is no check mark in the "Warn if still active"
and save changes.
This should allow it to close down the DOS app and shutdown.
However, I do not know if it leaves the lockfile there or not.
YMMV ;)

[IronBits]

I ran around looking for other tools that might help...
http://www.aplus-certification.com/shutdown.htm
http://howto.lycos.com/lycos/series/1,,5+26+35991+34528+25576,00.html
http://www.protect-me.com/freeware.html
http://www.lucyscreek.com/2046.html
http://www.winutility.com/qsd/
http://www.mediahorizon.net/search/System_Utilities/Startup_Shutdown/index.shtml
I hope someone will let us know which one really works :)

[Scoofy12]

The reason I posted this in the first place was because when I tried installing the text client on my parents' w98 box I wanted some way that would be automatic and out of the way. I figured they wouldnt mind just clicking OK whey they tried to shut down, but when I would install it and come back later I would find the lock file still in there and the client not running. Now I find that winoldap is crashing when we I try to shutdown/log out on this machine. I dont know whether it was from me messing with the pifs or not. My main interest (and others too, I suspect) is just to have it run, hidden except for maybe a tray icon, and be able to gracefully exit and pick up where it left off when you reboot. Since this box is apparently b0rked and I dont have any other w98 boxes to test on, can someone say if this actually works in 98? ie, if you do whatever it takes to suppress the shutdown warning, will the client resume crunching on reboot? I had assumed that it did not, just because I was finding that on this particular box, but maybe it's been crashing all along. Can someone confirm this?

boy, that was long-winded :)

[tpdooley]

Since the computers at work run win98se, I use dfGUI with the client set for invis, &start and stop on dfGUI's status. And the client seems to be running after the computer is turned back on.

[Scoofy12]

Ah, thanks for the reply. I actually tested it in linux by killall-ing it and it did delete the lock file. I think maybe this has been added since the last time I tried that (which, was, admittedly, a long time ago). Guess i just havent rebooted the thing since the last time I compiled a new kernel anyway, so havent had to think about it. now guess I have to reinstall windows on that machine if I want that extra half GHz :D

[Brian the Fist]

SIGTERM is indeed ANSI C. However, Micro$oft does not ever send this signal (according to MSDN) including on shutdown. Basically there is no communication between Windows and the DOS box on shutdown, as far as I can tell. If any experienced C coders out there know how to tell when WIN98 is shutting down from inside a Console program, please let me know and Ill add it in.

[MAD-ness]

Yes, it appears that Win9.x is a real pain in the arse in this regard (not to mention just a FEW others). I tried the conagent trick but I haven't tried the .pif trick.

If someone happens to know how to help Howard out with this one I know that myself and many others will be very grateful. At this point running DF on Win9.x computers is just not practical for me (the screensaver is more trouble than it is worth, either people want thier own screensaver or it gets odd errors that didn't seem worth trouble shooting).

[bwkaz]

You might be able to check the Windows message queue (PeekMessage / GetMessage), and watch for a WM_QUIT. That's how it works if your process has a window handle associated with it, anyway.

Since this is console Windows, you do have access to most of the Windows API (at least... I think you do). Try something like this, in your main loop:


MSG *msg;

msg = (MSG *)malloc(sizeof(MSG));

/* You'll probably want to check msg for non-NULL */

PeekMessage(msg, NULL, 0, 0, PM_NOREMOVE);

if(msg->message == WM_QUIT) {
/* flush, remove lockfile, whatever*/
}Edit: I have, of course, left out details like header files, libs to link with, etc. I think if you include windows.h, you should get all the declarations. And I think if you link with gdi32.lib, you'll get the implementations. Not sure on that last one, though.

[Brian the Fist]

And for our friends who are still running good old DOS 6.22? ;)

[bwkaz]

:rotfl: :rotfl:

DOS 6.22! Oh, that was too much!

(If you're running DOS, why are you using the "idle cycles" for DF? DOS is single-tasking...)

[Joe O]

Does the text client really run under DOS 6.22?
Is anyone running it under DOS 6.22?
If they are doing it for efficiency, and their machine will run W95, W98, or WNT then they should benchmark it under Windows. They might be suprised. I've run 4 or 5 projects that had a DOS client, and in every case it ran no slower under W9x or WNT, in fact, in some cases it ran faster!

[Joe O]

My experience is that you do want the "Warn if still active box" on the Misc tab checked so that it will complete deleting the lock file.
But you also need to have the "close on exit" box checked on the program tab. This is a must. Otherwise the DOS box sticks around even after the client stops.

Instead of changing the default PIF, I created a FOLDIT.PIF by right clicking on FOLDIT.BAT and then clicking on properties.