This is one of the many problems caused by the fact that
all of the SDL libs are statically linked against
libcmt.lib, thereby each one carrying around private
copies of malloc, fopen, fread & friends.
But for some reason I can’t convince Sam to use msvcrt.dll…
It caused sound breakage on NT. The waveOut intialization failed with
a bad parameter, and the only thing that changes between the version that
works and the version that doesn’t is whether or not msvcrt.dll is used
or not. If we can find a fix for this, I would be more than happy to
use the DLL, since it reduces the size of the library.
See ya,
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
I had more than 40.000 PySol downloads from ZDNet in the last 2 months,
and nobody has complained about any non-working sound (I’m using
a self compiled msvcrt SDL version), so I’d guess the problem
must be caused by something else.
MarkusOn 30-May-2000 Sam Lantinga wrote:
This is one of the many problems caused by the fact that
all of the SDL libs are statically linked against
libcmt.lib, thereby each one carrying around private
copies of malloc, fopen, fread & friends.
But for some reason I can’t convince Sam to use msvcrt.dll…
It caused sound breakage on NT. The waveOut intialization failed with
a bad parameter, and the only thing that changes between the version that
works and the version that doesn’t is whether or not msvcrt.dll is used
or not. If we can find a fix for this, I would be more than happy to
use the DLL, since it reduces the size of the library.
See ya,
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
---- Markus F.X.J. Oberhumer @ http://oberhumer.tsx.org ----
---- 5E CB 5C 85 DE AF 9E BF E9 DA 7E 6A 39 F8 CC 67 ----
3 WARPS TO URANUS
“Sam” == Sam Lantinga writes:
>> This is one of the many problems caused by the fact that all of
>> the SDL libs are statically linked against libcmt.lib, thereby
>> each one carrying around private copies of malloc, fopen, fread
>> & friends.
>> But for some reason I can't convince Sam to use msvcrt.dll....
Sam> It caused sound breakage on NT. The waveOut intialization
Sam> failed with a bad parameter, and the only thing that changes
Sam> between the version that works and the version that doesn't
Sam> is whether or not msvcrt.dll is used or not. If we can find
Sam> a fix for this, I would be more than happy to use the DLL,
Sam> since it reduces the size of the library.
I remember stumbling across that bug. Due to lack of resources
(mostly lack of time, but I also didn’t have VisualC at the time, and
of course Sam didn’t have NT), we (Sam and I) stopped looking once Sam
found that staticly linking against libcmt.lib worked.
One avenue to pursue would be to artificially move the waveOutOpen
call out of SDL_dibaudio.c and into the “main” routine (whatever it’s
called these days), just to see if the darned system call works. If
it does, then SDL is probably doing something that causes problems.
If waveOutOpen being called ASAP works, then the routine can be moved
about the source like you would do with a binary search to figure out
just what SDL is doing that causes the waveOutOpen call to fail. If
it doesn’t work at all, then perhaps someone with some contacts at
Microsoft could try to figure out why it fails using msvcrt.dll.
So, is there anyone out there with an NT system and some time to try
to figure this out?
I’ve just been gone for two weeks (Linux Canada Expo + vacation +
sickness + Memorial Day), and am totally swamped. If nobody else can
do this test, I can do it eventually. Helping out in my tiny way with
SDL is a high priority over here, but getting my head above water is
just slightly higher.
–Cliff
@Clifford_T_Matthews
In article ,
slouken at devolution.com says…
This is one of the many problems caused by the fact that
all of the SDL libs are statically linked against
libcmt.lib, thereby each one carrying around private
copies of malloc, fopen, fread & friends.
But for some reason I can’t convince Sam to use msvcrt.dll…
It caused sound breakage on NT. The waveOut intialization failed with
a bad parameter, and the only thing that changes between the version that
works and the version that doesn’t is whether or not msvcrt.dll is used
or not. If we can find a fix for this, I would be more than happy to
use the DLL, since it reduces the size of the library.
Do you mean that SDL MUST use the Mutithreaded.DLL during build? I
am having trouble with sound in w2k and have found all kinds of
weirdness occuring when linking with differing libs. These include
exceptions being thrown from within SDL.dll
-dv