unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: bkey1@tampabay.rr.com
Cc: emacs-devel@gnu.org
Subject: RE: [Patch for Windows implementation of play-sound]
Date: Tue, 22 Oct 2002 13:56:21 +0000 (UTC)	[thread overview]
Message-ID: <200210221355.g9MDtXMl006559@smtp-server1.tampabay.rr.com> (raw)

> 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.

             reply	other threads:[~2002-10-22 13:56 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-22 13:56 bkey1 [this message]
  -- strict thread matches above, loose matches on Subject: below --
2002-10-22  9:28 [Patch for Windows implementation of play-sound] jasonr
2002-10-22  9:05 jasonr
2002-10-21  6:52 [Bkey1@tampabay.rr.com: Patch " Juanma Barranquero
2002-10-22  1:08 ` [Patch " Ben Key
2002-10-22  7:37   ` Juanma Barranquero

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200210221355.g9MDtXMl006559@smtp-server1.tampabay.rr.com \
    --to=bkey1@tampabay.rr.com \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).