sdl options are set when configured + built (ie: if you dont have png libs, it wont compile png support into sdl image), and in often runtime loaded for certain things. dosbox when run with ./configure will show you what its using (sdl, sdl image, sdl net, sdl ttf, sdl mixer) when it looks for them.

look in the autoconf files, grep the source files for SDL etc..

BloddyCactus this is not what yesterplay was asking. You listed other libraries that are dependant on SDL. Dosbox only uses SDL_net (for network support) and SDL_sound (for mp3/ogg support in bin/cue images) of those. Png is used directly via Libpng.
Yesterplay: the whole backend of Dosbox, communication with the host OS and hardware is being done via SDL. Display, fullscreen, windowed window, keyboard, CD-Rom, Joystick etc... is all being passed through SDL. Which one could do without SDL but that is reinventing the wheel and of course prone to many bugs since everything you do on your own isn't as much tested as SDL. AND if you want easy portability (Windows, linux, os x...) that problem multiplies.
Go through the source and look for instances wher SDL_something is used to tell where it is used exactly...

Dominus wrote:

BloddyCactus this is not what yesterplay was asking. You listed other libraries that are dependant on SDL.

The OP specifically spoke about SDL with ALSA, OSS etc, those are backend libraries SDL compiles against. That SDL gets built against many back end libraries, does not mean they get used. OP seems confused by backend libraries and front end apps interfacing with SDL.

yeah, same as you seem confused about things you can configure SDL for 😉 (png for example has nothing to do with SDL 😉)

Maybe I should clarify what my intention is: Since the sdl.dll that comes with the precompiled development libraries of SDL doesn't support DirectDraw, I wanted to compile a new, DirectDraw capable sdl.dll for my DosBox builds. So I downloaded the SDL source code for SDL 1.2.15, changed the parts of the video code that ripsaw8080 told me and tried to compile the DLL. In Visual Studio 2015 the DLL came out with about 500 KByte in size but is depending on 2 runtime DLLs from Visual C. And it doesn't work in older Windows any more. So I tried to compile it under MinGW, as well as I do with DosBox. The DLL came out with 1,3 MByte and is still looking for a libgcc_s_dw2-1.dll.

Now I stumbled over all the features that SDL supports, that one can list with

1./configure --help

Things like ALSA, PulseAudio, etc. And I thought, that maybe I could reduce the size of the DLL by disabling features that DosBox doesn't even need and/or support. And maybe that would get rid of the remaining dependancy with the libgcc_s_dw2-1.dll (LDFLAGS="-static-libgcc -static libc++" didn't work).

Dominus wrote:

yeah, same as you seem confused about things you can configure SDL for 😉 (png for example has nothing to do with SDL 😉)

it has nothing to do with sdl and everything to do with sdl_image tho.

presuming that you want png support in sdl_image...

as I said, if you dont have png libs, and you build sdl_image... sdl_image wont have png support.. or if you want jpg support in sdl_image you need libjpeg.. want tiff support? you need libtiff, libjpeg and libz.. (or dll's if your a windows user).

this is in the sdl_image docs.

maybe were crosstalking something different..

Bloody Cactus, it's just that you brought up SDL_image that has no relation to Dosbox...

Yesterplay, when you compile SDL everything that does not apply to Windows (Alsa, pulseaudio, x11...) is disabled. No need to tinker with it.
The size of the mingw compiled sdl.dll can be further reduced by using strip. As for the dll dependency, you might need to google how to make a static compile for that dll. The sdl.dll that comes with Dosbox was cross-compiled on linux AFAIK, btw - maybe that got rid of that dependency.

I'd also recommend using the current code of the SDL-1.2 branch of SDL's mercurial. It might have additional fixes for Windows since the SDL 1.2.15 release. Not 100% sure if there are any since I left the Windows world mostly behind some years ago, so I don't look out for that.

Yesterplay80 wrote:

Maybe I should clarify what my intention is: Since the sdl.dll that comes with the precompiled development libraries of SDL doesn't support DirectDraw, I wanted to compile a new, DirectDraw capable sdl.dll for my DosBox builds. So I downloaded the SDL source code for SDL 1.2.15, changed the parts of the video code that ripsaw8080 told me and tried to compile the DLL. In Visual Studio 2015 the DLL came out with about 500 KByte in size but is depending on 2 runtime DLLs from Visual C. And it doesn't work in older Windows any more.

Platform Toolset: Visual Studio 2015 - Windows XP, though it won't work with Windows older than that (which is pretty, pretty old).
Runtime Library: Multi-threaded (/MT) negates the dependency on Visual Studio runtimes at the expense of file size.

Thanks, bloodbat, I managed to compile SDL and so far it looks quite promising. I tested it with a physical Windows 7 machine and a virtual XP machine, though in which DDRAW didn't strecth when using fullscreen, the pictuer remained small in the centre of the screen. If anyone (especially with a real XP machine) would like to try out the new SDL.DLL, please feel free to do so: https://drive.google.com/open?id=0BxEUSpZ8xHk … T0Q2RFZOenBBR3c

I'd be glad if you could give me some feedback if you try out the DLL!