[Win2k] It doesn't shutdown completely the first time

[pointwood]

Hi,

This is really just a small "bug"!

I just have noticed that after updating the client (with the autoupdate feature but without the autoupdate.cfg file), it will not shutdown the console when I hit 'q'. The client closes, but you end up with a console that says: "Done."

[pointwood]

This little bugger still exists in the lastest version.

[pointwood]

The client updated fine on my linux box (Gentoo Linux), but the same thing happened when I hit 'Q' here.

I didn't get a command line back :swear:

Now, I'm a Linux newbie, but I tried to hit CTRL+C and other combinations I could think of, but none worked :(

I started the client with ./foldit

[pointwood]

Would anyone care to answer this question?

[Jodie]

From the Win2k side of the house -

That's not a bug at all. It's a feature - and - it's a fact of dealing with winders.

If you start the batch file by double-clicking on the foldit.bat icon from explorer - the window should close when it's "done"

If you kill the client from within the client itself and not the batch file, the command line will never return. The window is NOT a dos-prompt. It's a 32bit command shell - nothing to do with DOS other than sharing most of the same built-in commands. IE it's not an Operating System. It's a window onto the operating system. It's really quite tough to spawn and close those windows. From the batch file itself, it's easy. But once the batch file turns-over control to the program, life gets complicated. The client will send an interrupt 20h to the command shell which is a "process terminated normally" message. I believe the MICROSOFT architectural design methodology was "a user will want to know that the process terminated normally. So we'll leave the window up and display 'Done' rather than just closing off the window and giving you no indication of how things ended-up"

You could terminate the windowed process abnormally and effectively crash the window. Or you could execute a system call to close the window. The downside there is that once you return your int 20h, you're no longer in control. If you close your window, you can't execute further code on the stack. That's a security measure. The silly thing is that then you establish a memory leak if you're not really careful.

It's a tough "problem"... I guess the real issue is that microsoft does this somewhat inconsistantly depending upon a lot of parameters that often appear, to me atleast, to be random... ;) Sometimes you get the "done" sometimes microsoft takes its own initiative and closes the window... It's really programatically not in the DF author's control, AFAIK...

Someone correct me if you've found stable code to do this in a way that doesn't bring windows to its knees or start leaking like a sieve.

---

On the Linux side -

I don't know Gentoo. I've read of a lot of issues with it, but have no experience with that distro personally.

You're starting it from what kind of terminal? Gnome, Xterm, KDE, eTerm, virtual tty....? What shell are you using?

I run mine from pttys and from eTerm's and Xterm's. I don't experience that on Redhat 6.1/7.1/7.2 running under those terms and ttys. Generally either bash or tcsh depending whether it's a clustered machine (bash with ssh) or a stand-alone userland box (tcsh).

[Paratima]

Try adding the following line to the end of the batch file. :)

exit

[Jodie]

:p

True - but the point is there's no guarantee that control will ever get returned to the batch file - as there was under DOS.

[pointwood]

Okay, thanks for the info!

Guess it's just one of those things I'll have to live with :)