This is the mail archive of the
mailing list for the Cygwin project.
Re: Is there a way to avoid dialog boxes?
- To: "Geoff Hart" <ghart at siemens-psc dot com>
- Subject: Re: Is there a way to avoid dialog boxes?
- From: Larry Hall <lhall at rfk dot com>
- Date: Tue, 02 Jun 1998 10:00:42 -0400
- Cc: gnu-win32 at cygnus dot com
At 11:16 AM 6/1/98 -0500, you wrote:
>I'm trying to configure some NT boxes as remote development
>servers, for users to telnet into from NT and non-NT machines.
>I'm using Sergey's inetd port, and things are working fine
>for the most part. However, I have one nagging problem:
> system error dialog boxes!
>Is there a way I can turn off error dialog boxes? Things like
>"cygwinb19.dll not found in PATH ....", or "an exception has
>occurred ...". These boxes popup on the NT server machine's
>screen, which doesn't help remote users.
>I know about the "...\AeDebug\Auto" registry flag, but that's
>not what I want. Are there other registry entries which control
I only know of a programmatic way to turn off dialog boxes generated by
errors. Of course, this means you need to add this to the effected programs
and recompile. The API is called SetErrorMode(). Here's the doc:
SetErrorMode <Picture> <Picture> <Picture>
The SetErrorMode function controls how the operating system handles several types of serious errors. You can specify that the operating system will handle these errors or that the application will receive and handle them.
// set of bit flags that specify error-handling properties
A set of bit flags that specify system error-handling properties. The following error mode bit flag constants are defined; you can set any combination of them:
If this flag is set, the operating system does not display the critical-error-handler message box when such an error occurs. Instead, the operating system sends the error to the calling process.
Windows NT RISC only: If this flag is set, the operating system automatically fixes memory alignment faults and makes them invisible to the application. It does this for the calling process and any descendant processes.
This flag has no effect on x86 processors.
If this flag is set, the operating system does not display the general-protection-fault message box when such an error occurs. This flag should only be set by debugging applications that handle general protection (GP) faults themselves via an appropriate exception handler.
If this flag is set, the operating system does not display a message box when it fails to find a file. Instead, the error is returned to the calling process.
The return value is the previous state of the error-mode bit flags.
A child process inherits the error mode of its parent process.
The default state for the error mode properties set by this function is OFF.
Windows NT: On some non-x86 processors misaligned memory references cause an alignment fault exception. The SEM_NOALIGNMENTFAULTEXCEPT flag lets you control whether the operating system automatically fixes such alignment faults, or makes them visible to an application.
On a MIPS platform, an application must explicitly call SetErrorMode, setting the SEM_NOALIGNMENTFAULTEXCEPT flag, to have the operating system automatically fix alignment faults. The default setting is for the operating system to make alignment faults visible to an application.
On an ALPHA platform, the operating system automatically fixes alignment faults. Therefore, the SEM_NOALIGNMENTFAULTEXCEPT flag affects ALPHA processors only if the EnableAlignmentFaultExceptions value in the following registry key is set to REG_DWORD 0x1.
The default setting for this registry key is REG_DWORD 0x0. When the registry key is set to REG_DWORD 0x1, the operating system makes alignment faults visible to an application, and an application must then call SetErrorMode to have the operating system automatically fix alignment faults.
On an x86 platform, the operating system does not make alignment faults visible to an application. Therefore, specifying the SEM_NOALIGNMENTFAULTEXCEPT flag on an x86 system is not an error, but Windows NT is free to silently ignore and not properly preserve the flag. This means that code sequences such as the following are not always valid on x86 systems:
fuOldErrorMode = SetErrorMode(0);
ASSERT(fuOldErrorMode == SEM_NOALIGNMENTFAULTEXCEPT);
Larry Hall email@example.com
RFK Partners, Inc. (781) 239-1053
8 Grove Street (781) 239-1655 - FAX
Wellesley, MA 02181 http://www.rfk.com
For help on using this list (especially unsubscribing), send a message to
"firstname.lastname@example.org" with one line of text: "help".