dosbox-staging (DOSBox Git repo)

Developer's Forum, for discussion of bugs, code, and other developmental aspects of DOSBox.

Re: dosbox-staging (DOSBox Git repo)

Postby Qbix » 2019-10-09 @ 08:41

Just a quick question, The advantages that are being "linked" to switching to git, like the CI and such, isn't that just advantages of gitlab/github whatever and has little to do with switching to git itself ?

so is the request to switch the main repo to GIT or to move development away from sourceforge (as sf.net can host git as well) ? (which is a request of a totally different order)

I am still a bit puzzeled on why git is so much better. if a patch breaks with a commit, git isn't going to magically fix it either.. The person still has to do the actually touching of the code.. Or I have been using git wrong..

the sourceforge email aliases do forward email. At least mine does.
so I don't really appreciate the commit message that you added.
Water flows down the stream
How to ask questions the smart way!
User avatar
Qbix
DOSBox Author
 
Posts: 10914
Joined: 2002-11-27 @ 14:50
Location: Fryslan

Re: dosbox-staging (DOSBox Git repo)

Postby krcroft » 2019-10-09 @ 14:46

jmarsh wrote:Normally you'd get those functions from winmm.lib and ws2_32.lib, but I can't vouch for mingw having the same libs as VS. They're not linked by default (like kernel32.lib and friends) so not surprising they're not included by using -mwindows.

jmarsh, thanks for the tips. I've added -lwinmm -lws2_(64 or 32) to their respective LIBS variables. The CI chain has been kicked off and can be watched live: https://github.com/dreamer/dosbox-stagi ... =258082148
Will check in after ~20 minutes and report the results.
User avatar
krcroft
Member
 
Posts: 313
Joined: 2017-4-29 @ 15:07
Location: Ogden's Retreat

Re: dosbox-staging (DOSBox Git repo)

Postby jmarsh » 2019-10-09 @ 15:20

64-bit still uses ws2_32.lib(/.dll) because it signifies the win32 API (as opposed to the win16 API).
jmarsh
Member
 
Posts: 273
Joined: 2014-1-04 @ 09:17

Re: dosbox-staging (DOSBox Git repo)

Postby krcroft » 2019-10-09 @ 15:37

jmarsh wrote:64-bit still uses ws2_32.lib(/.dll) because it signifies the win32 API (as opposed to the win16 API).

Brilliant; 32bit completed and 64bit is underway with round two here: https://github.com/dreamer/dosbox-stagi ... =258172843
Relief is upon me - thank you jmarsh!
User avatar
krcroft
Member
 
Posts: 313
Joined: 2017-4-29 @ 15:07
Location: Ogden's Retreat

Re: dosbox-staging (DOSBox Git repo)

Postby DosFreak » 2019-10-09 @ 15:54

Kisai wrote:If an OS is no longer under development I'd probably recommend not trying to support it unless someone is willing to actually support it themselves. Win95 and OS/2 are so old that the number of people who actually do this probably can't run a recent version of DOSBOX in the first place. Microsoft is officially no longer supporting Win7 this year, so people still using Win7, use it at their own risk. Binaries produced with MSVC 14.2 (2019) only produce binaries that work on Win10 (32-bit x86 , x86-64, ARM32, ARM64) unless the Windows SDK 140 (2015) is installed that enables XP binaries. MSVC can also use clang but I've not tried to build DOSBOX with it.



Windows XP is supported in VS2019 by using the VS2017 v141 toolset
https://docs.microsoft.com/en-us/cpp/bu ... ew=vs-2019

I see no reason why >XP can't work when compiled with VS2019 using the v142 toolset but I have yet to test 2019.

Just because you may not want to support it doesn't mean it doesn't work and don't make assumptions on what hardware people run DOSBox on.

ESU support for Windows 7 ends on 2023 but obviously a regular person won't receive those updates. It's unsure if people will be able to use a setting like XP POS or if MS will release security updates for major security risks like wannacry.

Mingw and Mingw-w64 and SDL2 still support XP and considering Qbix still uses the original Mingw for DOSBox compilation there is no reason to cut out XP support when DOSBox moves to SDL2 especially considering the forum we are discussing this on.

Potentially DOSBox may work on <XP SP3 when compiled with VS2017 which I am looking into as part of my compilation guides, if so this would be great since currently you have to use the VS2008 toolset for NT3.50,NT3.51,NT4,9x,2000. (Obviously you can use VS2010 for 2000 but not much point)
https://stackoverflow.com/questions/195 ... 6#53548116
User avatar
DosFreak
l33t++
 
Posts: 10422
Joined: 2002-6-30 @ 16:35
Location: Your Head

Re: dosbox-staging (DOSBox Git repo)

Postby Kisai » 2019-10-09 @ 16:30

krcroft wrote:Calling out for Windows build help!

I'm using a GitHub workflow to build DOSBox under MSYS2, MinGW 64 and 32bit, and I cannot solve two link errors, which appear to be looking for midi and serial port symbols.
I've tried linking with ld vs g++, static vs dynamic, explicitly including various windows libraries (gdi, ole, w2), explicitly adding gcc libraries (-static-libgcc -static-libstdc++), and combinations of these groups - but to no avail.

g++ as the linker appears to the doing the right thing by added these itself: -L/mingw64/lib -lmingw32 -lSDLmain -lSDL -mwindows -lpng -lz -lSDL_net -lopengl32; however midi and serial functions aren't being picked up under the -mwindows set of libraries.


__imp means that it's an import from another library. I usually just search for the name of the import without __imp and that says what lib is needed.

Depending on the OS, it can change a little. This is what I have for MSVC:
Preprocessor: DSOUND_SUPPORT;FLUIDSYNTH_NOT_A_DLL;ZLIB_WINAPI;WIN32;NDEBUG;_CONSOLE;%(PreprocessorDefinitions)

Libraries: Dsound.lib;fluidsynth1.lib;mt32emu.lib;Iphlpapi.lib;Setupapi.lib;Imm32.lib;version.lib;opengl32.lib;winmm.lib;zlibstat.lib;libpng16.lib;sdl_net.lib;sdl2main.lib;sdl2.lib;pdcurses.lib;pdcurses-wincon.lib;odbc32.lib;odbccp32.lib;ws2_32.lib;%(AdditionalDependencies)

These are all static libraries, so if you're using shared libraries, some of these might actually be included as part of SDL2. It's the worst-case scenario for imports.
DosFreak wrote:
Kisai wrote:If an OS is no longer under development I'd probably recommend not trying to support it unless someone is willing to actually support it themselves. Win95 and OS/2 are so old that the number of people who actually do this probably can't run a recent version of DOSBOX in the first place. Microsoft is officially no longer supporting Win7 this year, so people still using Win7, use it at their own risk. Binaries produced with MSVC 14.2 (2019) only produce binaries that work on Win10 (32-bit x86 , x86-64, ARM32, ARM64) unless the Windows SDK 140 (2015) is installed that enables XP binaries. MSVC can also use clang but I've not tried to build DOSBOX with it.



Windows XP is supported in VS2019 by using the VS2017 v141 toolset
https://docs.microsoft.com/en-us/cpp/bu ... ew=vs-2019

I see no reason why >XP can't work when compiled with VS2019 using the v142 toolset but I have yet to test 2019.

Just because you may not want to support it doesn't mean it doesn't work and don't make assumptions on what hardware people run DOSBox on.


All I did was list off what was available.
C++ Windwos XP Support for VS2017 (v141) tools [Deprecated]

Considering there is some pretty wide performance gaps found on consumer Win10 machines, particularly the ARM devices (Surface Pro X), if the choice comes down to supporting an underpowered Win10 ARM or an unsupported WinXP x86-32 platform, which one likely has a larger install base? Saddling the ARM device with having to run an x86 emulation on top of a second x86 emulation seems rather silly.

Anyway my point was that if you want to support an older OS forever, you will eventually run into a brick wall where you can't support newer platforms, or decisions made on certain OS's (eg Apple dropping 32-bit, Ubuntu dropping 32-bit) may eventually force that decision for you.
Kisai
Member
 
Posts: 125
Joined: 2010-5-05 @ 08:04

Re: dosbox-staging (DOSBox Git repo)

Postby kjliew » 2019-10-09 @ 17:08

krcroft wrote:Calling out for Windows build help!

I'm using a GitHub workflow to build DOSBox under MSYS2, MinGW 64 and 32bit, and I cannot solve two link errors, which appear to be looking for midi and serial port symbols.
I've tried linking with ld vs g++, static vs dynamic, explicitly including various windows libraries (gdi, ole, w2), explicitly adding gcc libraries (-static-libgcc -static-libstdc++), and combinations of these groups - but to no avail.

I am surprised you would even see a tiny tinny issue building DOSBox SVN with MSYS2/mingw64. I have been building DOSBox on MSYS2/mingw64 for years without any issue with just:
Code: Select all
$ mkdir build
$ cd build
$ ../dosbox-code-0/configure && make

And, it's done, everything is perfectly automated and no more messy stuffs to deal with libraries linkage. Are you trying to do a fully static build or what? I won't bother with fully static build. Static builds are bad in my opinion, and just stick with the upstream. The DOSBox devs have done a very good job in build automation.
kjliew
Member
 
Posts: 475
Joined: 2004-1-08 @ 03:03

Re: dosbox-staging (DOSBox Git repo)

Postby DosFreak » 2019-10-09 @ 18:47

No you listed VS2015 which was incorrect. I corrected you.

The underpowered arm is likely slower than the unsupported XP but not necessarily so. I don't know why you are referring to double emulation. Can the Windows 10 arm device not run a DOSBox binary compiled for arm 32bit or 64bit?

Which one has a larger install base? The more important and likely only question is which one the DOSBox devs care about. I know which one matters more to me and you probably wouldn't like the answer.

Why drop support before you have to, just because? Moving to SDL2 and still supporting XP doesn't hurt anything except for <XP users. When SDL2 and/or compilers drop support for XP then that would be a discussion.

Apple dropping 32bit and Ubuntu dropping 32bit (Ubuntu is not at least not any time soon) doesn't have any factor on DOSBox since DOSBox supports 64bit.

Visual Studio 2017 is supported until 2027 which is likely longer than SDL2 will support XP but we'll see.
User avatar
DosFreak
l33t++
 
Posts: 10422
Joined: 2002-6-30 @ 16:35
Location: Your Head

Re: dosbox-staging (DOSBox Git repo)

Postby Kisai » 2019-10-10 @ 00:36

kjliew wrote:And, it's done, everything is perfectly automated and no more messy stuffs to deal with libraries linkage. Are you trying to do a fully static build or what? I won't bother with fully static build. Static builds are bad in my opinion, and just stick with the upstream. The DOSBox devs have done a very good job in build automation.


If you're going to say something is bad, you better justify why it's bad.

Static builds are probably what you want when redistributing a binary and have no control over the target platform libraries. This is why CLI tools are better statically compiled because they can be portable by themselves and survive OS updates. A program distributed as one static binary or one binary and 100 shared libraries that stay in the same directory is essentially identical from a functionality point of view, but results in more disk space and memory being used as all the different versioned libraries are loaded and then remain resident in memory.

The point of a shared library has largely been lost due to version creep. The primary benefit to a shared library now is "plugin"/"extension" systems, but that requires the program to actually be written to load the libraries on demand, and then probe for support and version conflicts. In Dosbox's case, it doesn't benefit from shared libraries, and doesn't benefit from being statically compiled. IMO, it should be distributed as a static binary if it's going to be distributed with a game (eg on GOG or Steam) and packed in way so that the same build of Windows/Linux/OSX Dosbox can be shipped with the game without having to ship all the support libraries for every version of the OS it can run on.
Kisai
Member
 
Posts: 125
Joined: 2010-5-05 @ 08:04

Previous

Return to DOSBox Development

Who is online

Users browsing this forum: No registered users and 1 guest