This is a long one… (sorry for not having diff’s, but some of this is just
pseudo). Also, I understand you don’t currently have developement abilities
for Win x64 and I don’t fully expect you to jump on this right now if you
don’t want to, I’m just trying to help where I can. If you get lost in my
poor explainations, the last to blocks of this message are a generic
summary. I apologize in advance for how poorly I have written this, but I
think all information needed still gets through.
Here’s the related diff, but I don’t see where it would be a problem:
http://www.libsdl.org/cgi/cvsweb.cgi/SDL12/src/audio/windib/SDL_dibaudio.c.diff?r1=1.14&r2=1.15I assume this is waveout audio, right?
waveout, yes. However, this is not the problem, as I mentioned, a compile
from 2/27 had the static present (I made sure to go back that far because I
saw that patch you just pointed out which wasn’t applied until March 1st).
This appears to have happened either while you were working on getting rid
of c runtimes or the whole SDL_config reorginaztion. When I get more time,
I’ll work on getting it to compile from more timeframes to try and narrow it
down.
I did revert that patch to verify that it does not make the static go away
just in case.
I’d like to see your patch first. I’m leaving casts on data exposed in
the
API to be fixed in 1.3, where we can break binary compatibility. The rest
of
the fixes might apply cleanly to both win32 and win64.I’m generally leaving WIN32 to refer to windows (should we change it
to
WINDOWS?) and then _WIN32_WCE and _WIN64 are variants on that
platform.
Changing it to WINDOWS would probably be a good idea. A small block for
#ifndef _WIN64 could be placed around SDL_ASSEMBLY_ROUTINES should be the
only thing required assuming the HAVE_LIBC problems will eventually be
resolved.
On a further tangent, will there be non-in-line asm replacements for the
functions made to replace LIBC? As of current, x64 needs HAVE_LIBC 1 and
#undef SDL_ASSEMBLY_ROUTINES, so msvcrt is still needed.If somebody writes them.
I don’t have an x64 system, so I can’t tell
what needs to be done or test any changes made.
I’ll look to see what I can come up with. Problem for me is I have no
experience with ASM in the first place, which is why I’ve avoided it thus
far. There are often rather simple (though less efficient) C replacements
though. The only problem currently with SDL_ASSEMBLY_ROUTINES undef’d is
SDL_stdlib.c (hence I specifically mentioned LIBC) which only HAVE_LIBC can
get around.
As for LIBC, I left HAVE_LIBC undef’d and bypassed the ASM in SDL_stdlib.c
(knowingly breaking functionality, just to check what problems may exist in
compiling alone) and it is giving unresolved externals for memset and
memcpy, which I can’t figure out as they seem to be set the same as
compiling in win32.
Aside from that, on to castings, I’ll just paste the list of warnings here
and you can decide what you wish to do:
1>…\src\main\win32\SDL_win32_main.c(183) : warning C4267: ‘=’ :
conversion from ‘size_t’ to ‘int’, possible loss of data
1>…\src\main\win32\SDL_win32_main.c(185) : warning C4244: ‘=’ :
conversion from ‘__int64’ to ‘int’, possible loss of data
1>SDLmain - 0 error(s), 2 warning(s)
1>…\src\timer\win32\SDL_systimer.c(191) : warning C4028: formal
parameter 3 different from declaration
1>…\src\timer\win32\SDL_systimer.c(191) : warning C4028: formal
parameter 4 different from declaration
1>…\src\timer\win32\SDL_systimer.c(191) : warning C4028: formal
parameter 5 different from declaration
1>…\src\cdrom\win32\SDL_syscdrom.c(172) : warning C4244: ‘=’ :
conversion from ‘DWORD_PTR’ to ‘int’, possible loss of data
1>…\src\stdlib\SDL_string.c(1193) : warning C4244: ‘return’ : conversion
from ‘__int64’ to ‘int’, possible loss of data
1>…\src\file\SDL_rwops.c(273) : warning C4244: ‘return’ : conversion
from ‘__int64’ to ‘int’, possible loss of data
1>…\src\file\SDL_rwops.c(293) : warning C4267: ‘return’ : conversion
from ‘size_t’ to ‘int’, possible loss of data
1>…\src\file\SDL_rwops.c(298) : warning C4244: ‘=’ : conversion from
’__int64’ to ‘int’, possible loss of data
1>…\src\stdlib\SDL_getenv.c(72) : warning C4267: ‘function’ : conversion
from ‘size_t’ to ‘DWORD’, possible loss of data
1>…\src\stdlib\SDL_getenv.c(83) : warning C4267: ‘function’ : conversion
from ‘size_t’ to ‘DWORD’, possible loss of data
1>…\src\video\windib\SDL_dibevents.c(154) : warning C4244: ‘function’ :
conversion from ‘WPARAM’ to ‘UINT’, possible loss of data
1>…\src\video\windib\SDL_dibevents.c(201) : warning C4244: ‘function’ :
conversion from ‘WPARAM’ to ‘UINT’, possible loss of data
1>SDL - 0 error(s), 12 warning(s)
The only thing that absoletly needs to be changed to avoid errors compiling
- SDL_lowvideo.h’s WinMessage needs to be updated to LRESULT (to match your
recent change to SDL_sysevents.c) - All instances of GCL_ and GWL_ need to be changed to GCLP_ and GWLP_
respectively. However, this will cause problems for VC5/6 without platform
sdk updates (as I believe some of the LONG_PTR / DWORD_PTR stuff you added
recently do).
If changing to the new LongPointer method is not an option, it can be fixed
with a small bit of work in an #ifdef _WIN64 section in the sdl windows
config (which is what I had done to not get any errors as seen above).
Well, this certainly got dis-organized as I typed it, so I’ll summarize:
- SDL_lowvideo.h’s WinMessage needs to be updated to LRESULT (to match your
recent change to SDL_sysevents.c) - GCL_ & GWL_ needs to be changed in some form to the LongPointer friendly
versions
SDL_ASSEMBLY_ROUTINES must be undef’d
In order for runtime free compilation:
- memset & memcpy need to be resolved
- non-in-line asm replacements (as well as a SDL_ASSEMBLY_ROUTINES check)
need to be added to SDL_stdlib.c
–William
