Ctrl-C singal handler under Win32 platform

Hi,

I encounter a problem to use Ctrl-C handler in my console program under Windows.
In my code I create signal handler like:

class TInterruptHandler : public TSignalHandler {
   public:
      TInterruptHandler() : TSignalHandler(kSigInterrupt, kFALSE) { }

      virtual Bool_t Notify()
      {
         // do anything
          return kTRUE;
      }
};

In the beginning of the program I install that handler:

...
      fxInterruptHandler = new TInterruptHandler();
      fxInterruptHandler->Add();     
...

Under Linux this method works perfectly - I can catch Ctrl-C keys combination
and terminate my program properly. Under Windows in no circumstances Notify() method is
called.

If I look precisely in Windows implementation (function ConsoleSigHandler() in TWinNTSystem.cxx file),
I see that none of user handlers are called. As result, I get no any callback in case Ctrl-C is pressed.

Sergey

Hi Sergey,

I’ll try to see if this can be done on Windows… :wink:

Cheers, Bertrand.

Hi Bertrand,

I have also some other nasty features, connected with ROOT on Windows:

[ul]

  1. rootcint under Windows does not delete temporary files it creating.
    After compilation of big project (ROOT, for instance) I get a lot of
    files like xyz._rootcint. Can one delete them automatically?
    [/ul]

[ul]
2) I encounter problem to use binary root, compiled with VC++ 9,
with the newest Visual Studion 2010 Express (VC++ 10).
Is there plans to provide binaries for that platform?
[/ul]

[ul]
3) Information on this page:

http://root.cern.ch/root/Procedure/Procedure%20to%20install%20the%20free%20Microsoft%20Visual%20C.htm

is out of date. At least instrallation of MS Express is much more easy now.
From the other hand, after such default installation one need to introduce several
softlinks that full pathes to installed SDK and VC2010 contains no spaces.
[/ul]

Regards,
Sergey

Hi Sergey,

  1. Well, concerning this issue (._rootcint temp files), we all suffer from this :frowning: But I’ll try to revive the subject :wink:
  2. The binaries for MSVC++10.0 are available on the root ftp site now (they have been uploaded today :slight_smile:)
  3. Thanks, I suppose we will remove these pages (since it is so easy now). But I don’t get your point with softlinks… Could you be more precise? I never had to make any softlink to be able to use Visual Studio or nmake…

Cheers, Bertrand.

Hi Bertrand,

By default VisualC installed in directory “C:/Program Files/Microsoft Visual Studio/”.
When compiling from cygwin, one need to specify PATH to some subdirectories from visual studio.
And it is not convenient to handle spaces in name of subdirectory.
Therefore I normally crate symbolic link to such directory like:

mklink /D c:\soft\vc "C:\Program Files\Microsoft Visual Studio"

Probably, one can work without such symlinks.

Sergey

Hi Sergey,

The only thing I usually need is to add this line:

at the beginning of the cygwin.bat file…

Cheers, Bertrand.

This is the Win32 feature :unamused:

[quote=“linev”]If I look precisely in Windows implementation (function ConsoleSigHandler() in TWinNTSystem.cxx file),
I see that none of user handlers are called. As result, I get no any callback in case Ctrl-C is pressed.
[/quote]It is not a reason.

  • Under UNIX the CTRL-C interrupts the process and the CTRL-C handler is invoked.
  • Under WIN32 the CTRL-C does not interrupt the process at all. It creates a NEW concurrent THREAD :open_mouth: within the existing process scope and the CTRL-C handler is invoked within the new thread scope without interruption :smiling_imp: of the the main(your) thread. The default Microsoft implementation stops and kills the main thread. However, this is not what we usually want with ROOT.

This is where all problems are coming from and this is why you see the different behavior under Win32 and UNIX. The correct treatment of CTRL-C under Win32 was implemented for CERNLIB and PAW package at CERN