Skip Menu |
 

Subject: MessageBox calls in leashw32.dll cause problems for non-interactive applications
The leashw32.dll is filled with calls to MessageBox(). The assumption
was that if an error occurred within the krb5 library that it should be
displayed to the end user. The problem is that KFW is no used only for
interactive applications and even when it is the generation of
MessageBoxes from the library as opposed to reporting the errors to the
application and letting the application interact with the user is
(perhaps) a poor choice.

Attached is a patch that disables all of the MessageBox calls within
leashw32. It permits USE_MESSAGE_BOX to be specified at compile time in
order to re-enable the MessageBox calls.
Download lsh-no-msgbox.patch
application/octet-stream 7KiB

Message body not shown because it is not plain text.

Date: Sat, 14 Mar 2009 15:46:35 -0400
From: Danny Mayer <mayer@ntp.isc.org>
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #6410] MessageBox calls in leashw32.dll cause problems for non-interactive applications
RT-Send-Cc:
Jeffrey Altman via RT wrote:
Show quoted text
> The leashw32.dll is filled with calls to MessageBox(). The assumption
> was that if an error occurred within the krb5 library that it should be
> displayed to the end user. The problem is that KFW is no used only for
> interactive applications and even when it is the generation of
> MessageBoxes from the library as opposed to reporting the errors to the
> application and letting the application interact with the user is
> (perhaps) a poor choice.
>
> Attached is a patch that disables all of the MessageBox calls within
> leashw32. It permits USE_MESSAGE_BOX to be specified at compile time in
> order to re-enable the MessageBox calls.

It seems to me that a better solution would be to replace calls to
MessageBox with a call to a different function and have that function
decide how to deal with the message. Since this is a DLL it needs to
decide at run-time whether or not it's interactive and what to do with
the message.

Danny

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Date: Sun, 15 Mar 2009 10:43:31 -0400
From: Jeffrey Altman <jaltman@secure-endpoints.com>
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #6410] MessageBox calls in leashw32.dll cause problems for non-interactive applications
RT-Send-Cc:
Download (untitled) / with headers
text/plain 1.6KiB
mayer@ntp.isc.org via RT wrote:
Show quoted text
> Jeffrey Altman via RT wrote:
>> The leashw32.dll is filled with calls to MessageBox(). The assumption
>> was that if an error occurred within the krb5 library that it should be
>> displayed to the end user. The problem is that KFW is no used only for
>> interactive applications and even when it is the generation of
>> MessageBoxes from the library as opposed to reporting the errors to the
>> application and letting the application interact with the user is
>> (perhaps) a poor choice.
>>
>> Attached is a patch that disables all of the MessageBox calls within
>> leashw32. It permits USE_MESSAGE_BOX to be specified at compile time in
>> order to re-enable the MessageBox calls.
>
> It seems to me that a better solution would be to replace calls to
> MessageBox with a call to a different function and have that function
> decide how to deal with the message. Since this is a DLL it needs to
> decide at run-time whether or not it's interactive and what to do with
> the message.
>
> Danny

Danny:

I have to ask what benefit the extra work would provide? Simply
because the process happens to be running in an interactive environment
does not mean that a library should throw up arbitrary dialog boxes.
leashw32.dll was a support library for Leash32.exe and that ticket
manager relied on the library displaying the errors for help desk
support. Leash32.exe is no longer supported and cannot be compiled
with the latest Visual Studio. leashw32.dll is simply a support library
for gssapi32.dll and krb5_32.dll. In that role I do not believe there
is any reason to have it display dialogs.

Jeffrey Altman
Date: Sun, 15 Mar 2009 13:30:45 -0400
From: Danny Mayer <mayer@ntp.org>
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #6410] MessageBox calls in leashw32.dll cause problems for non-interactive applications
RT-Send-Cc:
Jeffrey Altman via RT wrote:
Show quoted text
> mayer@ntp.isc.org via RT wrote:
>> Jeffrey Altman via RT wrote:
>>> The leashw32.dll is filled with calls to MessageBox(). The assumption
>>> was that if an error occurred within the krb5 library that it should be
>>> displayed to the end user. The problem is that KFW is no used only for
>>> interactive applications and even when it is the generation of
>>> MessageBoxes from the library as opposed to reporting the errors to the
>>> application and letting the application interact with the user is
>>> (perhaps) a poor choice.
>>>
>>> Attached is a patch that disables all of the MessageBox calls within
>>> leashw32. It permits USE_MESSAGE_BOX to be specified at compile time in
>>> order to re-enable the MessageBox calls.
>> It seems to me that a better solution would be to replace calls to
>> MessageBox with a call to a different function and have that function
>> decide how to deal with the message. Since this is a DLL it needs to
>> decide at run-time whether or not it's interactive and what to do with
>> the message.
>>
>> Danny
>
> Danny:
>
> I have to ask what benefit the extra work would provide? Simply
> because the process happens to be running in an interactive environment
> does not mean that a library should throw up arbitrary dialog boxes.
> leashw32.dll was a support library for Leash32.exe and that ticket
> manager relied on the library displaying the errors for help desk
> support. Leash32.exe is no longer supported and cannot be compiled
> with the latest Visual Studio. leashw32.dll is simply a support library
> for gssapi32.dll and krb5_32.dll. In that role I do not believe there
> is any reason to have it display dialogs.
>
> Jeffrey Altman

I didn't know the context. For this you may be right but as a general
principle I encapsulate these things so that I have a generic function
that can easily redirect the output based on the circumstances. Building
for flexibility is harder than hardcoding.

Danny

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Date: Sun, 15 Mar 2009 16:19:16 -0400
From: Jeffrey Altman <jaltman@secure-endpoints.com>
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #6410] MessageBox calls in leashw32.dll cause problems for non-interactive applications
RT-Send-Cc:
mayer@ntp.org via RT wrote:
Show quoted text
> I didn't know the context. For this you may be right but as a general
> principle I encapsulate these things so that I have a generic function
> that can easily redirect the output based on the circumstances. Building
> for flexibility is harder than hardcoding.
>
> Danny
>
I agree and if you had made this comment back in 1999 when the library
was created it could have been taken into consideration.

:-(
Download smime.p7s
application/x-pkcs7-signature 3.2KiB

Message body not shown because it is not plain text.