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: 10947
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: 404
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: 317
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: 404
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: 10498
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: 134
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
Oldbie
 
Posts: 516
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: 10498
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: 134
Joined: 2010-5-05 @ 08:04

Re: dosbox-staging (DOSBox Git repo)

Postby llm » 2019-10-24 @ 17:08

@dreamer_

thank you for starting this github project - it will maybe help to consolidate the branching/forking a litte and the multi compiler builds and the static analyze feature are very nice

some questions:
-could you add a readme.md to the github project like your first post here?
-how can i get to the detail report of the static analyze - i can't find any link (is it this link: https://github.com/dreamer/dosbox-stagi ... /244580904)
-how to get to the build results from the github project front page
-would it be possible to add other targets or on-submit-builds like watcom v2 or scummvm does? https://github.com/open-watcom/open-watcom-v2/releases (recently switched to github actions for building serveral platform releases)
llm
Newbie
 
Posts: 51
Joined: 2009-1-18 @ 16:57

Re: dosbox-staging (DOSBox Git repo)

Postby dreamer_ » 2019-10-26 @ 18:07

llm wrote:-could you add a readme.md to the github project like your first post here?

Yes. I haven't added any content to readme.md file yet, because I am not 100% sure how our working relation to DOSBox svn/upstream looks like yet. Very soon I'll post the second patch series for inclusion upstream, and depending on how maintainers will react to it, the focus and some details about the repo might change a little.

llm wrote:-how can i get to the detail report of the static analyze - i can't find any link (is it this link: https://github.com/dreamer/dosbox-stagi ... /244580904)

In top-right part of the screen there's a button "Artifacts", with report.zip file inside. Long-term, I would like to have reports files uploaded and hosted by GitHub, so they could be easily navigated, but I don't like how GitHub Action for uploading static files to hosting looks like at the moment (it requires generating a dummy commit on branch representing GitHub pages).

llm wrote:-how to get to the build results from the github project front page

Right now: click on "Commits" to see the log, next to commit date there's either green "✓", red "✕", or yellow dot (representing build is in progress). Click on it to see details. You can also access the list of recent builds by clicking on "Actions" tab (but this part of UI might be hidden if you haven't joined GitHub Actions open beta - I'm not sure).

After content to README.md will be introduced: recently GitHub Actions fixed their support for build badges, so I will just add a badge.

llm wrote:-would it be possible to add other targets or on-submit-builds like watcom v2 or scummvm does?

krcroft is working on it as we speak :) He reorganized build process a little and we are working on reviewing and adapting it for inclusion in master branch.
Code: Select all
| ← Ceci n'est pas une pipe
User avatar
dreamer_
Newbie
 
Posts: 43
Joined: 2019-5-17 @ 20:19

Re: dosbox-staging (DOSBox Git repo)

Postby krcroft » 2019-10-26 @ 19:09

llm, regarding building DOSBox under Open Watcom V2 - I see this compiler and tool chain has recently come alive with activity, which is very exciting given its impressive heritage.

Are you currently building DOSBox using it? For our CI workflow, we start with essentially clean Virtual Machines (Windows, Ubuntu Linux, and OS X). We proceed up from first-principles by installing development tools and library dependencies, tailoring the environment, configuring DOSBox, and finally compiling it. Any help you can provide in this regard with Open Watcom V2 would be a great start!
User avatar
krcroft
Member
 
Posts: 404
Joined: 2017-4-29 @ 15:07
Location: Ogden's Retreat

Re: dosbox-staging (DOSBox Git repo)

Postby llm » 2019-10-28 @ 09:18

Are you currently building DOSBox using it?


no, i never tried - i don't know if its even possible - i just want to give a hint to support multi platform releases like watcom does (watcom gets build on every change)
(or scummvms huge release list: https://www.scummvm.org/downloads/)
llm
Newbie
 
Posts: 51
Joined: 2009-1-18 @ 16:57

Re: dosbox-staging (DOSBox Git repo)

Postby dreamer_ » 2019-10-28 @ 11:49

llm wrote:i just want to give a hint to support multi platform releases like watcom does (watcom gets build on every change)

We don't publish releases nor nightly builds yet, but dosbox-staging is being built on every change pushed to the repo and we do it multi-platform since the very beginning.
Code: Select all
| ← Ceci n'est pas une pipe
User avatar
dreamer_
Newbie
 
Posts: 43
Joined: 2019-5-17 @ 20:19

Re: dosbox-staging (DOSBox Git repo)

Postby fr500 » 2019-10-28 @ 14:25

Qbix wrote: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.


@Qbix, you're actually right. Many of the advantages are related to the platform (gitlab/github), pretty much every dev out there has a github account. The github/gitlab workflow is quite easy to follow even for new contributors.

Basically everyone works in their own fork, and once they are done they can send a pull-request to upstream.
That pull request is visible for everyone, it can be reviewed, rebased, sent to CI and tested by a bigger community (most people don't really know how to apply patches).

Without the actual toolset that github and gitlab have, using git or svn or mercurial or whatever is pretty much the same, just version control with a different set of limitations.
fr500
Newbie
 
Posts: 25
Joined: 2018-7-10 @ 22:49

Re: dosbox-staging (DOSBox Git repo)

Postby dreamer_ » 2019-10-28 @ 18:45

fr500 wrote:Without the actual toolset that github and gitlab have, using git or svn or mercurial or whatever is pretty much the same, just version control with a different set of limitations.

As far as Mercurial/Git I would agree - they are pretty similar (I still think Git has more useful features and better documentation, but that's in the realm of opinion, I just have more experience with Git).

When talking about SVN tough… Centralized version control workflow is an objectively worse way of developing software. Compared to Git, Subversion is slow, clunky, badly documented, and in certain cases - outright broken; e.g. lacks proper branch and tag support, does not (cannot) support 3-way merges or other merge strategies built-in Git, does not preserve authorship info in commits, svn locking mechanism is broken, lacks git functionalities like: local repos, bisect, describe, git-grep, rebase, reset, shortlog, stash, notes, filter-branch, read-tree, offline usage… I could go on, and on. Sure, SVN is better than e.g. ClearCase, CVS or SourceSafe - but it pales in comparison to Git. I mean, yesterday `$ svn log` in DOSBox SVN repo didn't work for several hours in the morning - c'mon.

GitHub does provide some nice features, yes - but it is just a pragmatic choice - personally I prefer GitLab (actually, I prefer Gerrit over both GitHub and GitLab, but that's besides the point).

I decided to host this project on GitHub, because:

  • First-party support for Windows CI (which is a unique GitHub feature; GitLab does not offer Windows on CI machines in free tier); I am a Linux developer and won't reboot to Windows just to check if my commit is still building, and I don't have access to macOS machines at all.
  • Most other related projects (like Munt, OpenGlide, DOSBox-X, duganchen/dosbox, Daum - by no means an exhaustive list) migrated to GitHub, so it will make it easier to communicate and cooperate with those devs (e.g. via cross-linking GitHub issues).
  • Based on my other projects, I see that an open-source project hosted on GitHub attracts ~8-9x as many user traffic, and developer attention as a project hosted on GitLab - that results in more PRs from new developers over time, and it's important.

If anyone's interested, I do have automatic mirror prepared on GitLab though (just in case): https://gitlab.com/dreamer-tan/dosbox-staging
Code: Select all
| ← Ceci n'est pas une pipe
User avatar
dreamer_
Newbie
 
Posts: 43
Joined: 2019-5-17 @ 20:19

Re: dosbox-staging (DOSBox Git repo)

Postby krcroft » 2019-10-28 @ 22:41

The invention of the distributed SCM is like a world-wonder in Civilization, where each engineer produces twice the lightbulbs.

In reality, git seems to bring even more to the table - its light-weight branching and ability to version your code away from the centralized repo removes the fear and risk developers normally face when embarking on medium to large changes or high-risk changes.

This all sounds "squishy" and woo-woo.. but it's a huge factor even among small teams, especially of people with varying skills. Here's a relevant 10-second read with fantastic art: https://www.git-tower.com/blog/why-subv ... scares-me/ (who knew there were artists cranking out SCM-related material?)

If DSCM's were roughly on par we'd see a similar mix of mercurial, darcs, and git shops like the old days when CVS, ClearCase, and Perforce were jockeying for lead. But we don't see that in practice.. companies have almost universally switched to git because it increases efficiency. This is exclusive of GitHub and GitLab too - the Linux kernel's rate of change elbowed up when they switched to git, years before GitHub was even an idea.

Historically, interest in SVN grew until the start of 2008 after which it's been losing ground to git on a 1-to-1 basis. The two crossed in 2012 with git continuing its trend upward for the last 7 years.
https://trends.google.com/trends/explor ... %2F04g0kcw
User avatar
krcroft
Member
 
Posts: 404
Joined: 2017-4-29 @ 15:07
Location: Ogden's Retreat

Re: dosbox-staging (DOSBox Git repo)

Postby fr500 » 2019-10-29 @ 14:02

dreamer_ wrote:
fr500 wrote:Without the actual toolset that github and gitlab have, using git or svn or mercurial or whatever is pretty much the same, just version control with a different set of limitations.

As far as Mercurial/Git I would agree - they are pretty similar (I still think Git has more useful features and better documentation, but that's in the realm of opinion, I just have more experience with Git).

When talking about SVN tough… Centralized version control workflow is an objectively worse way of developing software. Compared to Git, Subversion is slow, clunky, badly documented, and in certain cases - outright broken; e.g. lacks proper branch and tag support, does not (cannot) support 3-way merges or other merge strategies built-in Git, does not preserve authorship info in commits, svn locking mechanism is broken, lacks git functionalities like: local repos, bisect, describe, git-grep, rebase, reset, shortlog, stash, notes, filter-branch, read-tree, offline usage… I could go on, and on. Sure, SVN is better than e.g. ClearCase, CVS or SourceSafe - but it pales in comparison to Git. I mean, yesterday `$ svn log` in DOSBox SVN repo didn't work for several hours in the morning - c'mon.

GitHub does provide some nice features, yes - but it is just a pragmatic choice - personally I prefer GitLab (actually, I prefer Gerrit over both GitHub and GitLab, but that's besides the point).

I decided to host this project on GitHub, because:

  • First-party support for Windows CI (which is a unique GitHub feature; GitLab does not offer Windows on CI machines in free tier); I am a Linux developer and won't reboot to Windows just to check if my commit is still building, and I don't have access to macOS machines at all.
  • Most other related projects (like Munt, OpenGlide, DOSBox-X, duganchen/dosbox, Daum - by no means an exhaustive list) migrated to GitHub, so it will make it easier to communicate and cooperate with those devs (e.g. via cross-linking GitHub issues).
  • Based on my other projects, I see that an open-source project hosted on GitHub attracts ~8-9x as many user traffic, and developer attention as a project hosted on GitLab - that results in more PRs from new developers over time, and it's important.

If anyone's interested, I do have automatic mirror prepared on GitLab though (just in case): https://gitlab.com/dreamer-tan/dosbox-staging


Yes I agree, I was exaggerating to make a point.
Point is that both are tools after all, and when you're used to a workflow you don't really need to change such tool.

That said, I love git workflows. I hope eventually dosbox switches and I can stop using tools like git svn. There was one time were I lost my local copy of the repo and everything got screwed up.
fr500
Newbie
 
Posts: 25
Joined: 2018-7-10 @ 22:49

Re: dosbox-staging (DOSBox Git repo)

Postby dreamer_ » 2019-11-03 @ 09:10

Second patch series of changes from dosbox-staging was just submitted for inclusion in SVN. You can follow discussion in here: https://sourceforge.net/p/dosbox/patches/284/

Summary of changes:

- Update to distclean makefile target (2 patches)
- Add prerequisite libraries needed for krcroft's patch, 1 library per commit: dr_flac, dr_mp3, dr_wav, stb_vorbis, xxHash, archive (C++ object serializer), and subset of necessary files from SDL_sound. These commits only include the library files - they do not hook them up in buildsystem yet - if included, it will make it easier to review and merge-in rest of krcroft's patch later on. (7 patches)
- krcroft's changes to SDL_sound library necessary for future usage in DOSBox (6 patches)
- Remove of dependency on 2 macros from SDL_cdrom library - this is prerequisite for future SDL2 work (2 patches)
- Silence compiler warnings introduced in r4277
- Prevent potential null pointer dereference in dynamic core code - fixes 1 issue reported by Clang static analyzer
- Add DOSBox splash screen graphic in SVG format
Code: Select all
| ← Ceci n'est pas une pipe
User avatar
dreamer_
Newbie
 
Posts: 43
Joined: 2019-5-17 @ 20:19

Re: dosbox-staging (DOSBox Git repo)

Postby DosFreak » 2019-11-08 @ 15:05

Deleted post. Rants be gone.

All has been stated already about git,SVN and DOSBox. If you have something new to bring to the table then start another thread. This thread topic is for dosbox-staging (DOSBox Git repo)

As for yet another complaint about patches. People complain about patches but I've yet to see a comprehensive or hell even a minimal list of patches benefiting DOS games. If this bothers you so much then that shouldn't be too difficult. If it is too difficult then you have no reason to complain. If you have something new to bring to the table then start another thread. See this post for an example: viewtopic.php?f=32&t=69497#p791033
User avatar
DosFreak
l33t++
 
Posts: 10498
Joined: 2002-6-30 @ 16:35
Location: Your Head

PreviousNext

Return to DOSBox Development

Who is online

Users browsing this forum: No registered users and 2 guests