Are you building it with GCC (mingw)? If so, you can pass your own compiler flags to the configure script. For an non-debug (optimized) build that targets 386, you can use:

1./configure CFLAGS="-O2 -fomit-frame-pointer -march=i386 -mtune=generic" <your other options here>

This will produce machine instructions that can run on 386, but will optimize for all CPUs. If you want a build that specifically optimizes for 386 (and may runs slow on other CPUs), replace "generic" with "i386".

./configure won't work in MinGW (I'm running MinGW for Windows on Windows 10 64-bit). I'm using the file SDL-devel-1.2.15-mingw32(.tar.gz). I've taken it from the Developement library in the Win32 section with (MinGW32) https://www.libsdl.org/download-1.2.php .

Edit: Trying the source code now (https://www.libsdl.org/release/SDL-1.2.15.zip)

Edit: I've compiled SDL and called make install to install the library into the correct location? Now trying to compile SDL_gfx using the new SDL library (same method) and then my application using it again.

Edit: I've compiled SDL, SDL_gfx and then my emulator with the settings you gave (with an added --prefix=/mingw for SDL and SDL_gfx before the CFLAGS. It seems to compile fine. Now to test the new dlls(copy dlls and x86emu.exe to seperate folder, open command prompt, clear path variable to prevent default sdl libraries from being used and testrun).

Edit: It seems SDL still needs the static linking to the gcc resources (which are in my emulator as well), so "-enable-core-inline -static-libgcc -static-libstdc++" on before of those options you gave. Also with this build, my emulator kind of goes weird (when opening the emulator BIOS the onscreen emulator keyboard seems to flip and the emulator starts doing lots of screen captures for some reason:S)

It seems to need some gcc dlls. I try to compile it with enable-core inline, static-libgcc and static-libstdc++, but when getting to "checking whether the C compiler works..." windows tells me a.exe has crashed and gcc tells me "configure: error: cannot run C compiled program".

My configuration command for my new SDL library:
./configure CFLAGS="-O2 -enable-core-inline -static-libgcc -static-libstdc++ -fomit-frame-pointer -march=i386 -mtu
ne=generic"

Display:

1$ ./configure CFLAGS="-O2 -enable-core-inline -static-libgcc -static-libstdc++ -fomit-frame-pointer -march=i386 -mtu
2ne=generic"
3checking build system type... i686-pc-mingw32
4checking host system type... i686-pc-mingw32
5checking for gcc... gcc
6checking for C compiler default output file name... a.exe
7checking whether the C compiler works... configure: error: cannot run C compiled programs.
8If you meant to cross compile, use `--host'.
9See `config.log' for more details.

Strange enough if I choose to find errors during the crash and choose no to the Visual Studio 2015 Community dialog, the configuration continues. This happens with conftest.exe. Suddenly AVG detects SDL_gfx-2.0.25\conftest.exe as a Win32/Heur virus? I'm using the default SDL_gfx-2.0.25 from sourceforge?

I think I will reinstall my full MinGW installation to see if that works.

I have to wonder though. What't the point in limiting yourself to 386? I doubt the emulator is even remotely useful when running on such a slow machine.

Windows 95 has the minimum requirement of a 386 and Bochs using Windows 95 won't run the application (using it for testing compatibility with Windows 95+) because SDL.dll at least uses Pentium Pro instructions for some reason, which will crash the application on Windows 95@Intel 386 because those instructions don't exist (I believe it's opcode 0F 4X according to the Windows 95 crash report (first bytes in the reported frame data). And I simply want my application to run on any x86 Windows platform for simplicity (not needing to have a very new PC to run it, and testable in e.g. Bochs/Dosbox running Windows 95/98/ME).

Also isn't Dosbox also made for Windows 95+ (so it would have to support a 386 processor)?

I've just installed MinGW again and tried compiling SDL, then SDL_gfx with the above command. But when using the static stuff, that conftest.exe keeps crashing(even when ignoring), triggering an error message aborting the configuration process.

You're sacrificing a lot of performance to target a CPU that nobody uses though. Targeting w95 doesn't mean you need to restrict your code to 386. You're giving up optimizations for newer CPUs and the code will run quite a bit slower.

W95 itself might support 386, but that doesn't mean applications that run in w95 need to do the same. There was w95 software that required a Pentium and MMX, for example.

For testing my own projects in w95, I've created a w95 VM in VMware Workstation. There's no reason to use Bochs. But I always target "-march=i686 -mtune=generic" for 32-bit, and "-march=x86-64 -mtune=generic" for 64-bit.

Well strange things happening here: when trying to compile SDL_gfx from my new MinGW Windows installation, suddenly the msys.bat has disappeared... Did the crashing program have anything to do with it?

Then I opened the MinGW package manager, which AVG detects as a virus.

You also have to factor in what the application is for. The SDL guys rightfully assumed that everything running through SDL needs a faster machine than a 386. I doubt the slideshow that bocs or dosbox would show on such a machine is worth anything.
Except for some very few fringe cases no one is using a 386 or 486 with Windows 95 for anything than a very specific case.
Don't overthink it....

Btw now I think about it, does Dosbox need some Visual C++ redistributable to run? Even the applications I create with MinGW need it for some reason, even though it shouldn't be needed according to what I could find.

I've reversed the conversion to i386 in my project for now. Now I just have to get MinGW up and running again(for some reason my desktop keeps crashing since I've tried those things a few posts back. Even simply creating a shortcut makes it crash. Also renaming the shortcut afterwards makes it unresponsive for a little bit. (I also removed AVG and installed 360 Total Security by advice of a friend. It's currently cleaning up my hard disk and compressing system files. This could play a part in it? Although the unresponsiveness started happening after I messed with the compiler flags? Maybe the test executables of SDL_gfx/SDL during ./configuration broke something in Windows 10 x64?). Implemented some missing mono Covox Speech Thing support in my emulator in the meanwhile(still need to test when compiled).

Edit: Can't compile anything using MinGW at the moment: When starting the freshly installed shell(sh.exe) it crashes and gives me an error message in the prompt that a stack trace dump has been made?

1      0 [main] us 0 open_stackdumpfile: Dumping stack trace to us.stackdump
2      0 [main] sh 5748 sync_with_child: child 9168(0x228) died before initialization with status code 0x0
3    190 [main] sh 5748 sync_with_child: *** child state waiting for longjmp
4sh: fork: Resource temporarily unavailable
5sh-3.1$

When starting the prompt, windows tells me that sh.exe has crashed in it's usual Windows 10 version of Windows 95's General Protection error(#GP), just like the other crashes mentioned earlier.

Currently running System File Checker (sfc /scannow) to verify my Windows 10 isn't corrupted.

Edit: SFC reports that my Windows 10 installation is corrupted. Is there a way to fix Windows 10 automatically without having to remove all software and files(I have a new antivirus now)? Or do I have to execute a full system reset (using the boot menu)?

I've executed the Windows 10 factory reset, but sfc /scannow still tells me that my Windows 10 installation has corrupted files and the problems still apply (all of them).

Edit: My PC and GCC work correctly again after a Windows Update. Apparently Microsoft made an update again which screws up things, which they then fix as fast as possible (within days after release), like the bug with the settings panel not opening at all when started (and immediately closing). Same with the windows calculator a bit later.

IIRC AFAIK newer GCCs introduced regressions for older OSes, might be worth using an older GCC for Win9X targets. I personally didn't look into it because I haven't upgraded my GCC to notice this either.

./configure won't work in MinGW

It works. You need to have MinGW running together with MSYS POSIX emulation layer, but still using MinGW gcc compiler instead of MSYS gcc compiler. This is the *default* setup if you follow the MSYS/MinGW installation properly. I have been building SDL-1.2.15 and SDL2-2.0.3 from source using just the tarball source for MinGW development. As long as you are using the MinGW gcc compiler, it still produces the native codes and does not link against POSIX emulation layer such as msys-1.0.dll.

-march=i386 -mtune=generic

In theory, this should work. But unfortunately, MinGW/MSYS (from mingw.org) maintainers are volunteers. They are not paid to maintain CPU backward compatibility and lack the obligation to do so. At some point of time, the MinGW startup runtime was broken as it contained CMOV instructions, which requires at least i686. Hence and so forth, every libraries (EXE/DLL) produced thereafter may have been polluted with i686 instructions even though gcc was instructed to i386 code generation. I have personally confirmed that mingwrt-4.x will produce C/DLL win32 startup code with CMOV instructions. You can switch back to mingwrt-3.x, but this may not be enough. You need to trace every dependencies libraries to check if they have been built with mingwrt-4.x and rebuild them from source with mingwrt-3.x.

I got to learn all this thanks to my adventure into running Win98 with DOSBox SVN and gulikoza's 3Dfx pass-through. A simple "Hello World!" from MinGW ended up in GPF under Win98 DOSBox due to the i686 CMOV instructions as DOSBox does not emulate CMOV instructions.

You might be better off trying to use a Microsoft compiler. I had issues trying to compile SDL 1.2.15 with Cygwin and couldn't manage it without it segfaulting. Works fine with TDM though.

https://cygwin.com/ml/cygwin/2016-01/msg00041.html