RE: [Patch for Windows implementation of play-sound]

RE: [Patch for Windows implementation of play-sound]

[Ben Key]

> I've asked the author about it. Among other things, when compiling with
> MSVC it requires the newest release of the compiler and/or the SDK, and
> That's Not Good IMHO.

This is not true.  I did not say that the newest version of MSSDK is
required.  I said that I have it installed.  My patch will work with the
include files that are included with Visual C++ 6.0.  You will, however, see
a large number of warning messages due to the following segment of the
version of WINDOWS.H that is included with Visual C++ 6.0:

  #if(WINVER >= 0x0500)
  #pragma message ("")
  #pragma message ("NOTE: WINVER has been defined as 0x0500 or greater which
enables")
  #pragma message ("Windows NT 5.0 and Windows 98 features. When these
headers were released,")
  #pragma message ("Windows NT 5.0 beta 1 and Windows 98 beta 2.1 were the
current versions.")
  #pragma message ("")
  #pragma message ("For this release when WINVER is defined as 0x0500 or
greater, you can only")
  #pragma message ("build beta or test applications.  To build a retail
application,")
  #pragma message ("set WINVER to 0x0400 or visit
http://www.microsoft.com/msdn/sdk")
  #pragma message ("to see if retail Windows NT 5.0 or Windows 98 headers
are available.")
  #pragma message ("")
  #pragma message ("See the SDK release notes for more information.")
  #pragma message ("")
  #endif


This warning message is displayed because I had to define WINVER and
_WIN32_WINNT to at least 0x0500 to avoid a compilation error I was
experiencing.  I do not at this time have the details about that compilation
error.

Re: [Patch for Windows implementation of play-sound]

[Juanma Barranquero]

On Mon, 21 Oct 2002 21:08:51 -0400, "Ben Key" <Bkey1@tampabay.rr.com> wrote:

> This is not true.  I did not say that the newest version of MSSDK is
> required.  I said that I have it installed.  My patch will work with the
> include files that are included with Visual C++ 6.0.  You will, however, see
> a large number of warning messages due to the following segment of the
> version of WINDOWS.H that is included with Visual C++ 6.0:

Ok, you're right, it does not *require* it. Still, getting such a large
list of (menacing) warnings for the benefit of adding a function (even
if play-sound can be considered an important one) doesn't seem right.

> This warning message is displayed because I had to define WINVER and
> _WIN32_WINNT to at least 0x0500 to avoid a compilation error I was
> experiencing. I do not at this time have the details about that compilation
> error.

Then please investigate that further. Perhaps it is as simple as a new
struct or whatever that could be copied. OTOH, I don't know the legal
status of copying a fragment of a Microsoft #include file for use in a
program, although I know that bindings to other languages routinely do
adapt code from windows.h and other includes.

Thanks,

                                                           /L/e/k/t/u

Re: [Patch for Windows implementation of play-sound]

[jasonr]

If you need to copy structs from include files,
the mingw32 w32 headers are a safer option, since
they are already reverse engineered from the w32 APIs
and GPLed, and the fragment is usually small enough
that we won't need papers for it.

I agree that setting WINVER and _WIN32_WINNT explicitly
is not a viable solution, as these are internal to
the compiler, and may cause the compiler to make invalid
assumptions if set incorrectly.

>  from:    Juanma Barranquero <lektu@terra.es>
>  date:    Tue, 22 Oct 2002 08:37:53
>  to:      Bkey1@tampabay.rr.com
>  cc:      emacs-devel@gnu.org
>  subject: Re: [Patch for Windows implementation of play-sound]
> 
> On Mon, 21 Oct 2002 21:08:51 -0400, "Ben Key" <Bkey1@tampabay.rr.com> wrote:
> 
> > This is not true.  I did not say that the newest version of MSSDK is
> > required.  I said that I have it installed.  My patch will work with the
> > include files that are included with Visual C   6.0.  You will, however, see
> > a large number of warning messages due to the following segment of the
> > version of WINDOWS.H that is included with Visual C   6.0:
> 
> Ok, you're right, it does not *require* it. Still, getting such a large
> list of (menacing) warnings for the benefit of adding a function (even
> if play-sound can be considered an important one) doesn't seem right.
> 
> > This warning message is displayed because I had to define WINVER and
> > _WIN32_WINNT to at least 0x0500 to avoid a compilation error I was
> > experiencing. I do not at this time have the details about that compilation
> > error.
> 
> Then please investigate that further. Perhaps it is as simple as a new
> struct or whatever that could be copied. OTOH, I don't know the legal
> status of copying a fragment of a Microsoft #include file for use in a
> program, although I know that bindings to other languages routinely do
> adapt code from windows.h and other includes.
> 
> Thanks,
> 
>                                                            /L/e/k/t/u
> 
> 
> 
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://mail.gnu.org/mailman/listinfo/emacs-devel

RE: [Patch for Windows implementation of play-sound]

[jasonr]

In addition to finding another way around the WINVER problem,
I think you should just define HAVE_SOUND instead of
introducing a new conditional USE_W32SOUND.

I am also concerned about the following line:

+  sprintf(sz_cmd_buf,"open \"%s\" alias SulliTech_PlaySound_Device wait",psz_file);

What is the significance of SulliTech?

It seems to me that is either specific to your hardware,
or you have copied the code from somewhere, which
could expose the FSF to legal risk if we install it.

> > I've asked the author about it. Among other things, when compiling with
> > MSVC it requires the newest release of the compiler and/or the SDK, and
> > That's Not Good IMHO.
> 
> This is not true.  I did not say that the newest version of MSSDK is
> required.  I said that I have it installed.  My patch will work with the
> include files that are included with Visual C++ 6.0.  You will, however, see
> a large number of warning messages due to the following segment of the
> version of WINDOWS.H that is included with Visual C++ 6.0:
> 
>   #if(WINVER >= 0x0500)
>   #pragma message ("")
>   #pragma message ("NOTE: WINVER has been defined as 0x0500 or greater which
> enables")
>   #pragma message ("Windows NT 5.0 and Windows 98 features. When these
> headers were released,")
>   #pragma message ("Windows NT 5.0 beta 1 and Windows 98 beta 2.1 were the
> current versions.")
>   #pragma message ("")
>   #pragma message ("For this release when WINVER is defined as 0x0500 or
> greater, you can only")
>   #pragma message ("build beta or test applications.  To build a retail
> application,")
>   #pragma message ("set WINVER to 0x0400 or visit
> http://www.microsoft.com/msdn/sdk")
>   #pragma message ("to see if retail Windows NT 5.0 or Windows 98 headers
> are available.")
>   #pragma message ("")
>   #pragma message ("See the SDK release notes for more information.")
>   #pragma message ("")
>   #endif
> 
> 
> This warning message is displayed because I had to define WINVER and
> _WIN32_WINNT to at least 0x0500 to avoid a compilation error I was
> experiencing.  I do not at this time have the details about that compilation
> error.

RE: [Patch for Windows implementation of play-sound]

[bkey1]

> In addition to finding another way around the WINVER problem,
> I think you should just define HAVE_SOUND instead of
> introducing a new conditional USE_W32SOUND.

I believe I have resolved the problems I was having earlier
that caused me to redefine WINVER and _WIN32_WINNT
to 0x0501 in nmake.defs.  Last night I worked on
generating a new patch that corrects some mistakes I
made in my initial patch (such as unintended changes).
In this new patch, I did not redefine WINVER and
_WIN32_WINNT.  When I applied this patch to the latest
CVS sources that I downloaded last night, I did not get the
compilation errors I was getting previously when compiling
with MSVC 6.0.  I will make this new patch available as soon
as I have tested it with MinGW, which I will do tonight.

I considered using HAVE_SOUND instead of
USE_W32SOUND.  However, I wanted to ensure that
sound.c and w32sound.c could not inadvertently be
compiled at the same time.  sound.c is only compiled when
HAVE_SOUND is defined due to the following:
  #if defined HAVE_SOUND
  // contents of file here
  #endif /* HAVE_SOUND */
w32sound.c is only compiled if USE_W32SOUND is
defined and HAVE_SOUND is not defined due to the
following:
  #if !defined(HAVE_SOUND) && defined(USE_W32SOUND)
  // contents of file here
  #endif  /* #if !defined(HAVE_SOUND) && defined(USE_W32SOUND) */  
I could, however, change my code so that HAVE_SOUND is used instead.

> 
> I am also concerned about the following line:
> 
> +  sprintf(sz_cmd_buf,"open \"%s\" alias SulliTech_PlaySound_Device 
wait",psz_file);
> 
> What is the significance of SulliTech?
> 
> It seems to me that is either specific to your hardware,
> or you have copied the code from somewhere, which
> could expose the FSF to legal risk if we install it.

As for the significance of SulliTech, at this point there is none.
SulliTech is the name of a concept I have for a company I have
considered starting, but have never gotten around to.  It is short 
for "Sullivan Technologies."  Sullivan is the last name of my wife,
Anne E Sullivan.

I can assure you that I did not copy any code from somewhere.  I
figured out how to write this code by examining the exported functions
of a command line media player WAV.EXE by Dave Navarro (see 
http://www.cmdtools.com/) and looking them up in the MSDN Library.
When I initially wrote this code, it was part of a simple command
line program I wrote that implemented the same functionality as WAV.EXE
but fixed what is to me a very annoying bug, it did not support UNIX
style paths (paths that use the / character as a path separator).
I decided to do this after Dave Navarro chose not to fix this bug
when I reported it to him.

Initially I had some idea of possibly selling this command line
utility as a share ware product released by SulliTech.  But, when
I noticed that this code could be used to improve GNU Emacs by
providing a feature in Windows that was available in Linux, I
decided to make the code open source instead.  When I made that
decision, I forgot to remove the references to SulliTech.  I will
do so tonight.

I hope this explanation eases your concern about any possible
copyright issues with this code.