[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Patch for Windows implementation of play-sound]
From: |
bkey1 |
Subject: |
RE: [Patch for Windows implementation of play-sound] |
Date: |
Tue, 22 Oct 2002 09:55:33 US/Eastern |
> 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.