[Version 2024.12.04] [Win9x/NT4+ Build] Will not start. Error: "The DOSBOX-X.EXE file is linked to missing export KERNEL32.DLL:GetConsoleWindow."

[dg410a]

Not sure if this is a bug or if I'm missing something. So, I'll post this as a blank issue.

I just downloaded the Windows 9x build of DOSBox-X and I could not get it to start on my Windows 98 SE machine. I get the following error:

"The DOSBOX-X.EXE file is linked to missing export KERNEL32.DLL:GetConsoleWindow."

The OS has all updates installed through the Windows 98 SE Unofficial Service Pack 2.1 and I also have Visual C++ 2005 Redistributable installed. I'm not sure what else I need to make this work or if the Win9x build is just broken at the moment. Of course, I could just use KernelEx, but I don't want to go through the trouble of installing it just to get DOSBox-X working on Win 98 SE. For clarification, I am using the latest version of DOSBox-X as I write this.

[Torinde]

Same for me.
Last version that works 2024.03.01
First version that doesn't work 2024.07.02

I assume something changed in how project is compiled/packaged.

[MrMadguy64]

GetConsoleWindow requires Windows 2000. Such functions shouldn't be imported statically. Only via GetProcAddress.

[dg410a]

Alright. So, based on the comments so far, I went ahead and tried the Win9x build version 2024.03.01, and I was able to start it under Windows 98 SE.

So, something must've definitely changed in how it was compiled with regards to the latest version (2024.12.04 as of this writing). Probably the only option for now is to compile it myself, but I'll probably need instructions as to how to properly create a build that actually works under Windows 9x. Or maybe something in the package is broken to the point where it doesn't work on Win9x period no matter how I would compile it.

[Torinde]

GetConsoleWindow requires Windows 2000. Such functions shouldn't be imported statically. Only via GetProcAddress.

The only commit I see with that is 0cb36c6 where it's made to be skipped for HX DOS version...

If @crazii or somebody else can trace what broke the 9x support between March and July and goes to restore it, please check if you can also enable NT3.5x support (maybe similar to DOSBox Compilation Guides (by @DosFreak) instructions for building DOSBox SVN). NT3.51 bare metal enthusiasts can then use it.

[Dobby233Liu]

On Discord:

[Dobby233Liu]

Personally I suspect it being caused by the tinyfiledialogs update

[MrMadguy64]

Searching in sources shows following references to GetConsoleWindow:
\src\debug\debug.cpp: 4460, 4465
\src\gui\menu_callback.cpp: 2352, 2364
\src\gui\sdlmain.cpp: 6862, 8651, 8652

GetConsoleWindow is usually used to obtain default console window handle, created by console application.

[Dobby233Liu]

Searching in sources shows following references to GetConsoleWindow:

All of these have a !defined(_WIN32_WINDOWS) guard

[MrMadguy64]

Searching in sources shows following references to GetConsoleWindow:

All of these have a !defined(_WIN32_WINDOWS) guard

Yeah, you're right.

tinyfiledialogs.c has following references to GetConsoleWindow, that aren't guarded: 2744, 2860, 2902, 3036, 3104, 3158, 3213

P.S. It's the same code, copy-pasted several times.

[maron2000]

Can you try the nightly build by PR #5319.

[Torinde]

It works for me, thanks!

[Torinde]

@maron2000, can you please adapt the DOSBox Compilation Guides instructions and make a build working also on NT3.50?

If possible, supporting running on 386 without FPU.