new wip: emulators/dosbox-x (was: Re: patch: emulators/dosbox add 'dyncore', 'ne2000', 'nosplash' flavours)
[trimming the Cc list a bit since this is a diff subject...] Haai, "Thomas Frohwein" wrote: Attached is the tarball of the most recent dosbox-x built against system SDL1 for testing and comments. Builds && runs on 6.5 on me Thinkpad R40. No further testing done yet, however... - This is built with dynamic core and USE_WXNEEDED=Yes for testing purposes. Indeed this is w/ 'USE_WXNEEDED=Yes', but needlessly so, as the dynamic core is not present in the generated executable. Is this only for amd64? (If so, you've lost me). --zeurkous. -- Friggin' Machines! dosbox-x.tgz Description: dosbox-x.tgz
Re: patch: emulators/dosbox add 'dyncore', 'ne2000', 'nosplash' flavours
A dosbox-x.conf to get started with that got fullresolution set to 1920x1080, as well as opengl and dynamic core set is here: https://thfr.info/pub/dosbox-x.conf Run it e.g. with '$ dosbox-x -conf /path/to/dosbox-x.conf'
Re: patch: emulators/dosbox add 'dyncore', 'ne2000', 'nosplash' flavours
On Sun, Jun 02, 2019 at 06:34:22AM +0200, zeurk...@volny.cz wrote: [...] > Mehasn't been monitoring dosbox development much, due to the lack of > Code quality and indeed plain English quality... mewas thus unaware of > the fork and will investigate, thanks for bringing it me attention. [...] Hi, Attached is the tarball of the most recent dosbox-x built against system SDL1 for testing and comments. - fullscreen resolution isn't automatically detected and fails with the standard settings. I manually set 'fullresolution=1920x1080' in the dosbox-x.conf - configure stage checks g++ even though it's never used (I grepped through the build log). Would appreciate if someone knows a straightforward way to disable this. - This is built with dynamic core and USE_WXNEEDED=Yes for testing purposes. - I have not tested voodoo emulation with this version. I tested that about a year ago and back then it was only partial and not really usable without severe graphics distortions. - I haven't tested running Windows 95/98 in this version, but with a previous one from about a year ago. It worked reasonably well with non-3D-accelerated applications. I even got the game Deus Ex from the year 2000 to launch, but no playable 3D graphics. Some highly unofficial resources on running Win9x in dosbox (and dosbox-x) can be found here: http://dosbox95.darktraveler.com/index.html I would like comments, tests, numbers (videos ??) about the performance advantage of dynamic core over normal core before deciding about the best configuration for the port. I'm doing some testing at the moment, but there are so many use cases and configurations that I would appreciate hearing from others' experiences with the difference between normal and dynamic core. I would prefer to avoid wxneeded unless the performance advantage is clear and significant. dosbox-x.tgz Description: Binary data
FU: RE: patch: emulators/dosbox add 'dyncore', 'ne2000', 'nosplash' flavours
mewrote: > > And honestly, emulated network setups w/ tap(1) are just easier to > monitor, debug, and generally play with. grah, ,s/1/4/. It's the heat over here. --zeur. -- Friggin' Machines!
RE: patch: emulators/dosbox add 'dyncore', 'ne2000', 'nosplash' flavours
"Jonathan Gray" wrote:
>
> You gave no justification for wanting us to carry a third party patch
> for the ne2k support instead of using existing ipx and modem emulation.
That's actually not entirely true: mehinted at the ease of playing
network games with players on real machines. Also, there are a lot of
other programs of hysterical value that use TCP, which is obviously not
{,directly }covered by either IPX or Hayes modem.
And honestly, emulated network setups w/ tap(1) are just easier to
monitor, debug, and generally play with.
Sometimes, the follow-the-instructions, batteries-included stuff just
doesn't cut it. In this case, the ne2000 emulation forms an escape for
such occasions.
--zeurkous.
--
Friggin' Machines!
Re: patch: emulators/dosbox add 'dyncore', 'ne2000', 'nosplash' flavours
On Sun, Jun 02, 2019 at 06:34:22AM +0200, zeurk...@volny.cz wrote: > "Thomas Frohwein" wrote: > > > > For the record, I'm against dynamic core and against disabling the > > splash. I'm indifferent regarding ne2000. > > Since the latter seems to be the least controversial, perhaps meshould > trim the patch down to that first...? jsg@, you're maintainer, please > speak up :) You gave no justification for wanting us to carry a third party patch for the ne2k support instead of using existing ipx and modem emulation.
RE: patch: emulators/dosbox add 'dyncore', 'ne2000', 'nosplash' flavours
theo wrote: > >> The ideal future state would be removing W|X from those remaining >> ports. > > That is seriously idealistic. > > The upstream software teams must decide to do that. > > After that, the "port" has no work to do. > > It is generally impossible for a "port" to solve this problem. > It's like adding pledge, unveil, or privsep to a piece of > software upstream-maintained by a group who doesn't understand > the concept or benefit yet... Would you mind if for a change, mejust shamelessly agrees w/ you this time? =) Ideals are good. They are not always workable. That's why they're ideals. --zeurkous. -- Friggin' Machines!
RE: patch: emulators/dosbox add 'dyncore', 'ne2000', 'nosplash' flavours
"Thomas Frohwein" wrote: > > For the record, I'm against dynamic core and against disabling the > splash. I'm indifferent regarding ne2000. Since the latter seems to be the least controversial, perhaps meshould trim the patch down to that first...? jsg@, you're maintainer, please speak up :) > The ideal future state would be removing W|X from those remaining > ports. In the ideal future ports wouldn't be needed and all third-party software would fit in perfectly with base ;) But yeah. > Therefore, the burden of proof should lie with anyone wanting > to go in the opposite direction. You want dynamic core? Convince us > that the benefit is worth going _against_ our security mitigations. You > should seriously consider showing numbers or comparison videos to make > your case. Uhm, as me's said, me's not *forcing* anyone to run the dyncore... me's not even proposing it as a default. Just an option. If this were in base, mewouldn't bother proposing it, but hey, this is ports, it's full of junk that people need despite it being so. > Even then I'm likely not going to think it's worth it. There is a fork > of dosbox called dosbox-x [1] that has seen continuous improvement and > regular releases over the recent years. Mehasn't been monitoring dosbox development much, due to the lack of Code quality and indeed plain English quality... mewas thus unaware of the fork and will investigate, thanks for bringing it me attention. > The project is complex and a > little messy, which is why I haven't sent it to ports@ yet. I had an > SDL1-based version that worked very well about a year ago. There was a > noticeable performance advantage in the game Tie Fighter over then > dosbox 0.74, with the normal core. That to me was good enough to lose > any interest in the dynamic core. It even runs Windows 98 acceptably, > but 3D acceleration isn't fully there in Win98. Medoesn't know that game, but meexperience is that some games really do try to be too clever with optimizations, turning them into pessimizations within an emulator of any kind. The dynamic core somewhat (sometimes greatly) alleviates that. > The port has since seen a few updates. I just built the most recent one > with SDL2, but there are several bugs that I'd like to address before > it's ready. > > I would recommend to check out dosbox-x and how it performs with its > normal core before looking into dynamic core and the associated > reduction in mitigations. IME running dosbox in general is not so much putting the door ajar as it is removing it from its frame entirely and junking it. >>> A better way to spend time on dosbox would be to investigate ways to >>> improve speed without sacrificing basic security protections. > > dosbox-x may offer this; however I haven't tried most recent dosbox > 0.74-2 yet. I should soon have a version to share for testing. Well, if this "dosbox-x" does the job, we of course don't need the dyncore. Just don't make it drag in gtk+? and python (or similar horrors), please... > I think upstream made it clear enough that the splash should remain > part of the application. Imagine the mess if we started adding patches > to ports for anything that someone might consider "convenient". It brings the functionality of the port closer to base, doesn't it? Honestly, I don't find "you're allowed to modify everything *except* that bit", when "that bit" gets in the way, much acceptable. Someone /could/ go and ask the developers what their intentions were, and if they're fine w/ removal for completely non-commercial reasons. It won't be me since they barely ever responded to me about anything in the first place. (But others seem to have this problem as well.) --zeurkous. -- Friggin' Machines!
Re: patch: emulators/dosbox add 'dyncore', 'ne2000', 'nosplash' flavours
Thomas Frohwein wrote: > The ideal future state would be removing W|X from those remaining > ports. That is seriously idealistic. The upstream software teams must decide to do that. After that, the "port" has no work to do. It is generally impossible for a "port" to solve this problem. It's like adding pledge, unveil, or privsep to a piece of software upstream-maintained by a group who doesn't understand the concept or benefit yet...
Re: patch: emulators/dosbox add 'dyncore', 'ne2000', 'nosplash' flavours
On Sat, Jun 01, 2019 at 05:53:27PM +0200, zeurk...@volny.cz wrote: [...] > Me data is 'it helps me, and me's willing to accept the risk when > necessary'. Obviously, only the big, bloated, poorly-programmed stuff > (such as the Build engine) really benefits :) > > And please do note that the dynamic core is a run-time *option*: > core=normal *still* works even with this patch applied. For the record, I'm against dynamic core and against disabling the splash. I'm indifferent regarding ne2000. The ideal future state would be removing W|X from those remaining ports. Therefore, the burden of proof should lie with anyone wanting to go in the opposite direction. You want dynamic core? Convince us that the benefit is worth going _against_ our security mitigations. You should seriously consider showing numbers or comparison videos to make your case. Even then I'm likely not going to think it's worth it. There is a fork of dosbox called dosbox-x [1] that has seen continuous improvement and regular releases over the recent years. The project is complex and a little messy, which is why I haven't sent it to ports@ yet. I had an SDL1-based version that worked very well about a year ago. There was a noticeable performance advantage in the game Tie Fighter over then dosbox 0.74, with the normal core. That to me was good enough to lose any interest in the dynamic core. It even runs Windows 98 acceptably, but 3D acceleration isn't fully there in Win98. The port has since seen a few updates. I just built the most recent one with SDL2, but there are several bugs that I'd like to address before it's ready. I would recommend to check out dosbox-x and how it performs with its normal core before looking into dynamic core and the associated reduction in mitigations. [...] > > A better way to spend time on dosbox would be to investigate ways to > > improve speed without sacrificing basic security protections. dosbox-x may offer this; however I haven't tried most recent dosbox 0.74-2 yet. I should soon have a version to share for testing. [...] > Me's not removing any copyright notices at all :s Just a funky splash > screen that just *happens* to get in me way. I think upstream made it clear enough that the splash should remain part of the application. Imagine the mess if we started adding patches to ports for anything that someone might consider "convenient". [...] [1] https://github.com/joncampbell123/dosbox-x/releases
RE: patch: emulators/dosbox add 'dyncore', 'ne2000', 'nosplash' flavours
[blah, volny flagged your message as spam...] "Jeremie Courreges-Anglas" wrote: > >[about the dynamic core...] > >> It's a risk and people are free to take it or not to take it. Me's just >> contributing a patch :) > > Who should provide actual data regarding the risk increases and the > *actual benefits* if not you? Me data is 'it helps me, and me's willing to accept the risk when necessary'. Obviously, only the big, bloated, poorly-programmed stuff (such as the Build engine) really benefits :) And please do note that the dynamic core is a run-time *option*: core=normal *still* works even with this patch applied. > While Jonathan (maintainer) has the final > say here, I would object to such a FLAVOR and patch being added. *shrugs* Your objection is noted. It might help other people. Me's not dictating anything to anyone... > A better way to spend time on dosbox would be to investigate ways to > improve speed without sacrificing basic security protections. A better way would IMNSHO be to port all those fun games the hell away from the obscure platform, *w/o* including a dependency tree that ultimately involves gnome and python! >[about the splash screen...] > > For the record: > --8<-- > bc 1.07.1 > Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006, 2008, 2012-2017 Free > Software Foundation, Inc. > This is free software with ABSOLUTELY NO WARRANTY. > For details type `warranty'. > -->8-- Yes, exactly :r Nice if you're juggling numbers in your head and quickly want to invoke bc to flush them... > You're indeed free to do whatever you want on your machines, but the > OpenBSD ports tree can't get away with removing copyright notices from > software later distributed on the mirrors. Me's not removing any copyright notices at all :s Just a funky splash screen that just *happens* to get in me way. > Again, maybe not for your own use case. Yes, YMMV, as always. > emulators/dosbox/Makefile: > > PERMIT_PACKAGE_CDROM= Yes > > so people may sell packages produced with the port. If that's really so much of a problem, we can disable that for the 'nosplash' flavour. And quite possibly not even build it by default. >[about whether or not me patch constitutes a formal proposal...] > > Proposals need to be reviewed, tested and committed. This takes time, > and time is a scarce resource. So again, please make it clear whether > you consider your next contributions proper for inclusion in the ports > tree. Alright, me'll make it clear: "me's honestly not sure". Y'know, medid anticipate all these point of principle. > You'll save other people's time and you'll avoid rants from > grumpy porters like me: a clear win for everybody. Rants are fine. Criticism is more than appreciated. But medoesn't like to waste people's time, no: if medid, mehereby offers me sincere apologies. >[about possible dep-reducing flavours...] > > Looking at the deps of feh and fceux, I doubt you're having a point > here. fceux: devel/desktop-file-utils, devel/scons, x11/gtk+2 feh: devel/desktop-file-utils, x11/gtk+3 And all that stuff pulls in python. Some things just go too far for me. --zeurkous. -- Friggin' Machines!
Re: patch: emulators/dosbox add 'dyncore', 'ne2000', 'nosplash' flavours
On Sat, Jun 01 2019, wrote: > Haai, > > "Jeremie Courreges-Anglas" wrote: >> >> Not to rain on your parade, but... > > Don't worry, me's just sharing a WFM :) > >>> 'dyncore': re-enable the dynamic core (possibly insecure) >> >> You don't mention a rationale for this. The only wxneeded report I know >> of mentions no performance change. > > Mehasn't measured, but on me (by your standards possibly ancient ;) > machines it really does help performance a lot (mewouldn't have > bothered if it didn't). > >> https://marc.info/?l=openbsd-ports=149053625314161=2 >> >> So what's the point of lowering the security of an emulator possibly >> used to run untrusted images? > > That's the one thing medoesn't do, mehas a background in IBM PC poop > (the horrors of me youth), so mealways manually installs stuff. Of > course, one needs to know what one is doing, but UNIX ain't for lusers. > > Of course, your point remains: most stuff running inside the emulator > is inherently untrusted (since most often no source code is available), > so there's still a risk. Honestly, though, given the general, ehrm, > "quality" of dosbox code, mesuspects some much larger holes in there > than --disable-dynamic-core could possibly address. > > It's a risk and people are free to take it or not to take it. Me's just > contributing a patch :) Who should provide actual data regarding the risk increases and the *actual benefits* if not you? While Jonathan (maintainer) has the final say here, I would object to such a FLAVOR and patch being added. A better way to spend time on dosbox would be to investigate ways to improve speed without sacrificing basic security protections. [...] >>> 'nosplash': disable spam piccy upon invocation >> >> Is that a serious proposal? The wording used for the ifdef doesn't seem >> appropriate. > > *shrugs* It's up to individual operators what runs on their machines, > and how it runs. Do we really want to end up w/ things like bc(1) first > sprouting lines of copyright info before accepting any input (the GNU > version does)? For the record: --8<-- bc 1.07.1 Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006, 2008, 2012-2017 Free Software Foundation, Inc. This is free software with ABSOLUTELY NO WARRANTY. For details type `warranty'. -->8-- You're indeed free to do whatever you want on your machines, but the OpenBSD ports tree can't get away with removing copyright notices from software later distributed on the mirrors. > Besides, me's always figured that the ad was put in as a response to > commercial peddlers wrapping old games inside dosbox and re-selling them > w/o giving any credit or indeed any indication, which is definitely not > the case here. Again, maybe not for your own use case. emulators/dosbox/Makefile: PERMIT_PACKAGE_CDROM= Yes so people may sell packages produced with the port. >> Regarding the intent, your diff contains the surrounding >> line: >> >>> + /* Please leave the Splash screen stuff in working order in DOSBox. We >>> spend a lot of time making DOSBox. */ >> >> That change doesn't look desirable in the ports tree IMO. > > It's a patch, and an optional one: individual operators are free to > honour or disregard the request. Me's giving choice, not a strait > jacket. > >> Obviously tests on -current would be better. > > Medoesn't have any machine that runs -current right now, sorry. > >> If you're proposing this diff for inclusion in the ports tree, please >> make that clear. > > Medoesn't know. Depends on whether or not people like it enough. > >> Your earlier proposal (with MAINTAINER in Cc) > > Meforgot the Cc this time, so mesent it separately to the maintainer > moments later. > >> didn't >> make it clear either: >> >> https://marc.info/?l=openbsd-ports=154669079320603=2 > > Well, honestly, me's been burned a little here and there when trying to > contribute to OpenBSD... If there's interest, me's certainly inclined to > rework it to make it more suitable for inclusion. Proposals need to be reviewed, tested and committed. This takes time, and time is a scarce resource. So again, please make it clear whether you consider your next contributions proper for inclusion in the ports tree. You'll save other people's time and you'll avoid rants from grumpy porters like me: a clear win for everybody. >> FLAVORS should be seldom used, they add complexity and make >> tests/updates harder. > > The lack of FLAVORS in several packages (feh, fceux...) actually made me > build them manually, in order to cut down on the bloat. So that argument > works both ways. Looking at the deps of feh and fceux, I doubt you're having a point here. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
RE: patch: emulators/dosbox add 'dyncore', 'ne2000', 'nosplash' flavours
"Marc Espie" wrote: > > Easy to run as a user who doesn't have any rights whatsoever Yup, the practical problems are limited. But it still ain't correct! :) --zeur. -- Friggin' Machines!
Re: patch: emulators/dosbox add 'dyncore', 'ne2000', 'nosplash' flavours
On Sat, Jun 01, 2019 at 04:55:58PM +0200, zeurk...@volny.cz wrote: > "Marc Espie" wrote: > > > > There are quite a few networked games that run in DOSbox. > > Yup, me point :) > > > I doubt you can 0wn anything but the game itself... > > It's mess-dos: pwn one program, pwn everything. And then there's the > emulated 'mount' command that any program can call... bit of a mess. > > Thus, medoes somewhat share the security concerns. > > --zeurkous. Easy to run as a user who doesn't have any rights whatsoever
RE: patch: emulators/dosbox add 'dyncore', 'ne2000', 'nosplash' flavours
"Marc Espie" wrote: > > There are quite a few networked games that run in DOSbox. Yup, me point :) > I doubt you can 0wn anything but the game itself... It's mess-dos: pwn one program, pwn everything. And then there's the emulated 'mount' command that any program can call... bit of a mess. Thus, medoes somewhat share the security concerns. --zeurkous. -- Friggin' Machines!
Re: patch: emulators/dosbox add 'dyncore', 'ne2000', 'nosplash' flavours
On Sat, Jun 01, 2019 at 01:25:18PM +0200, Jeremie Courreges-Anglas wrote: > I guess this is the easiest way to get networking support in dosbox. > But is that a good thing? Running DOS applications on the modern > internet looks dubious at best. There are quite a few networked games that run in DOSbox. I doubt you can 0wn anything but the game itself...
RE: patch: emulators/dosbox add 'dyncore', 'ne2000', 'nosplash' flavours
Haai, "Jeremie Courreges-Anglas" wrote: > > Not to rain on your parade, but... Don't worry, me's just sharing a WFM :) >> 'dyncore': re-enable the dynamic core (possibly insecure) > > You don't mention a rationale for this. The only wxneeded report I know > of mentions no performance change. Mehasn't measured, but on me (by your standards possibly ancient ;) machines it really does help performance a lot (mewouldn't have bothered if it didn't). > https://marc.info/?l=openbsd-ports=149053625314161=2 > > So what's the point of lowering the security of an emulator possibly > used to run untrusted images? That's the one thing medoesn't do, mehas a background in IBM PC poop (the horrors of me youth), so mealways manually installs stuff. Of course, one needs to know what one is doing, but UNIX ain't for lusers. Of course, your point remains: most stuff running inside the emulator is inherently untrusted (since most often no source code is available), so there's still a risk. Honestly, though, given the general, ehrm, "quality" of dosbox code, mesuspects some much larger holes in there than --disable-dynamic-core could possibly address. It's a risk and people are free to take it or not to take it. Me's just contributing a patch :) >> 'ne2000': add third-party ne(4) emulation > > I guess this is the easiest way to get networking support in dosbox. > But is that a good thing? Running DOS applications on the modern > internet looks dubious at best. Actually, friends have used this in the past to play network doom w/ me running it on a real machine =) There are some other uses, as well. Me's not shooting anyone for this not being included in the first place, but it's handy at times. > Technically such a patch should probably be handled using > PATCHFILES/SUPDISTFILES. Yeah, you're prolly right, me's not that familiar w/ ports so metook the most straightforward way... >> 'nosplash': disable spam piccy upon invocation > > Is that a serious proposal? The wording used for the ifdef doesn't seem > appropriate. *shrugs* It's up to individual operators what runs on their machines, and how it runs. Do we really want to end up w/ things like bc(1) first sprouting lines of copyright info before accepting any input (the GNU version does)? Besides, me's always figured that the ad was put in as a response to commercial peddlers wrapping old games inside dosbox and re-selling them w/o giving any credit or indeed any indication, which is definitely not the case here. > Regarding the intent, your diff contains the surrounding > line: > >> + /* Please leave the Splash screen stuff in working order in DOSBox. We >> spend a lot of time making DOSBox. */ > > That change doesn't look desirable in the ports tree IMO. It's a patch, and an optional one: individual operators are free to honour or disregard the request. Me's giving choice, not a strait jacket. > Obviously tests on -current would be better. Medoesn't have any machine that runs -current right now, sorry. > If you're proposing this diff for inclusion in the ports tree, please > make that clear. Medoesn't know. Depends on whether or not people like it enough. > Your earlier proposal (with MAINTAINER in Cc) Meforgot the Cc this time, so mesent it separately to the maintainer moments later. > didn't > make it clear either: > > https://marc.info/?l=openbsd-ports=154669079320603=2 Well, honestly, me's been burned a little here and there when trying to contribute to OpenBSD... If there's interest, me's certainly inclined to rework it to make it more suitable for inclusion. > FLAVORS should be seldom used, they add complexity and make > tests/updates harder. The lack of FLAVORS in several packages (feh, fceux...) actually made me build them manually, in order to cut down on the bloat. So that argument works both ways. > s/WANT_LIB/WANTLIB/ below Ah, sorry, will fix on this end :) Again, if there's any interest (please speak up folks!), me'll work on this further. --zeurkous. -- Friggin' Machines!
Re: patch: emulators/dosbox add 'dyncore', 'ne2000', 'nosplash' flavours
On Fri, May 31 2019, wrote:
> [not subscribed, please Cc, thanks.]
Not to rain on your parade, but...
> 6.5 update of the previous patch, w/ additional 'ne2000' flavour.
>
> 'dyncore': re-enable the dynamic core (possibly insecure)
You don't mention a rationale for this. The only wxneeded report I know
of mentions no performance change.
https://marc.info/?l=openbsd-ports=149053625314161=2
So what's the point of lowering the security of an emulator possibly
used to run untrusted images?
> 'ne2000': add third-party ne(4) emulation
I guess this is the easiest way to get networking support in dosbox.
But is that a good thing? Running DOS applications on the modern
internet looks dubious at best.
Technically such a patch should probably be handled using
PATCHFILES/SUPDISTFILES.
> 'nosplash': disable spam piccy upon invocation
Is that a serious proposal? The wording used for the ifdef doesn't seem
appropriate. Regarding the intent, your diff contains the surrounding
line:
> + /* Please leave the Splash screen stuff in working order in DOSBox. We
> spend a lot of time making DOSBox. */
That change doesn't look desirable in the ports tree IMO.
> Tested only in the most limited of fashions (on 6.5), but expected to
> work fine. As always, {bug,test} reports are very welcome.
Obviously tests on -current would be better.
If you're proposing this diff for inclusion in the ports tree, please
make that clear. Your earlier proposal (with MAINTAINER in Cc) didn't
make it clear either:
https://marc.info/?l=openbsd-ports=154669079320603=2
FLAVORS should be seldom used, they add complexity and make
tests/updates harder.
s/WANT_LIB/WANTLIB/ below
> Enjoy!
>
> --zeurkous.
>
> --- ports/emulators/dosbox/Makefile.orig Tue Jan 22 04:31:41 2019
> +++ ports/emulators/dosbox/Makefile Fri May 31 19:34:00 2019
> @@ -6,6 +6,7 @@
>
> VERSION= 0.74-2
> DISTNAME=dosbox-${VERSION}
> +REVISION=0
> PKGNAME= dosbox-${VERSION:S/-/./}
> CATEGORIES= games x11 emulators
> MASTER_SITES=${MASTER_SITE_SOURCEFORGE:=dosbox/}
> @@ -37,8 +38,26 @@
> CONFIGURE_ENV+=LDFLAGS="-L${LOCALBASE}/lib -L${X11BASE}/lib"
> CONFIGURE_ARGS+= --disable-alsatest
>
> +PATCH_LIST= patch-*
> +
> +FLAVORS= dyncore ne2000 nosplash
> +FLAVOR?=
> +
> +.if ${FLAVOR:L:Mne2000}
> +PATCH_LIST+= ne2000
> +WANT_LIB+=pcap
> +.endif
> +
> +.if ${FLAVOR:L:Mnosplash}
> +PATCH_LIST+= nosplash
> +.endif
> +
> +.if ${FLAVOR:L:Mdyncore}
> +PATCH_LIST+= wxneeded
> +.else
> # needs W+X memory
> CONFIGURE_ARGS+= --disable-dynamic-core
> +.endif
>
> pre-configure:
> cp ${FILESDIR}/midi_sndio.h ${WRKSRC}/src/gui
>
> --- /dev/null Fri May 31 19:56:39 2019
> +++ ports/emulators/dosbox/patches/ne2000 Fri May 31 19:45:02 2019
> @@ -0,0 +1,2047 @@
> +--- visualc_net/dosbox.vcproj.orig Thu Jul 5 13:24:23 2018
> visualc_net/dosbox.vcprojFri May 31 18:19:21 2019
> +@@ -480,6 +480,9 @@
> + +
> RelativePath="..\src\hardware\mixer.cpp">
> +
> ++ ++
> RelativePath="..\src\hardware\ne2000.cpp">
> ++
> + + RelativePath="..\src\hardware\pic.cpp">
> +
> +@@ -827,6 +830,9 @@
> +
> + + RelativePath="..\include\mouse.h">
> ++
> ++ ++RelativePath="..\include\ne2000.h">
> +
> + + RelativePath="..\include\paging.h">
> +
> +--- src/platform/visualc/config.h.orig Mon Aug 27 14:55:55 2018
> src/platform/visualc/config.hFri May 31 18:19:21 2019
> +@@ -12,6 +12,9 @@
> + /* Define to 1 to enable internal modem support, requires SDL_net */
> + #define C_MODEM 1
> +
> ++/* Define to 1 to enable NE2000 ethernet passthrough, requires libpcap */
> ++#define C_NE2000 1
> ++
> + /* Define to 1 to enable IPX networking support, requires SDL_net */
> + #define C_IPX 1
> +
> +
> +--- src/hardware/ne2000.cpp.orig Fri May 31 18:19:21 2019
> src/hardware/ne2000.cpp Fri May 31 18:28:13 2019
> +@@ -0,0 +1,1660 @@
> ++#include "config.h"
> ++
> ++#ifdef C_NE2000
> ++
> ++
> ++#include "dosbox.h"
> ++#include
> ++#include
> ++#include "support.h"
> ++#include "inout.h"
> ++#include "setup.h"
> ++#include "callback.h"
> ++#include "timer.h"
> ++#include "pic.h"
> ++#include "cpu.h"
> ++
> ++/* Couldn't find a real spec for the NE2000 out there, hence this is
> adapted heavily from Bochs */
> ++
> ++
> ++/
> ++// $Id: ne2k.cc,v 1.56.2.1 2004/02/02 22:37:22 cbothamy Exp $
>
patch: emulators/dosbox add 'dyncore', 'ne2000', 'nosplash' flavours
[not subscribed, please Cc, thanks.]
6.5 update of the previous patch, w/ additional 'ne2000' flavour.
'dyncore': re-enable the dynamic core (possibly insecure)
'ne2000': add third-party ne(4) emulation
'nosplash': disable spam piccy upon invocation
Tested only in the most limited of fashions (on 6.5), but expected to
work fine. As always, {bug,test} reports are very welcome.
Enjoy!
--zeurkous.
--- ports/emulators/dosbox/Makefile.origTue Jan 22 04:31:41 2019
+++ ports/emulators/dosbox/Makefile Fri May 31 19:34:00 2019
@@ -6,6 +6,7 @@
VERSION= 0.74-2
DISTNAME= dosbox-${VERSION}
+REVISION= 0
PKGNAME= dosbox-${VERSION:S/-/./}
CATEGORIES=games x11 emulators
MASTER_SITES= ${MASTER_SITE_SOURCEFORGE:=dosbox/}
@@ -37,8 +38,26 @@
CONFIGURE_ENV+=LDFLAGS="-L${LOCALBASE}/lib -L${X11BASE}/lib"
CONFIGURE_ARGS+= --disable-alsatest
+PATCH_LIST=patch-*
+
+FLAVORS= dyncore ne2000 nosplash
+FLAVOR?=
+
+.if ${FLAVOR:L:Mne2000}
+PATCH_LIST+= ne2000
+WANT_LIB+=pcap
+.endif
+
+.if ${FLAVOR:L:Mnosplash}
+PATCH_LIST+= nosplash
+.endif
+
+.if ${FLAVOR:L:Mdyncore}
+PATCH_LIST+= wxneeded
+.else
# needs W+X memory
CONFIGURE_ARGS+= --disable-dynamic-core
+.endif
pre-configure:
cp ${FILESDIR}/midi_sndio.h ${WRKSRC}/src/gui
--- /dev/null Fri May 31 19:56:39 2019
+++ ports/emulators/dosbox/patches/ne2000 Fri May 31 19:45:02 2019
@@ -0,0 +1,2047 @@
+--- visualc_net/dosbox.vcproj.orig Thu Jul 5 13:24:23 2018
visualc_net/dosbox.vcproj Fri May 31 18:19:21 2019
+@@ -480,6 +480,9 @@
+
+
++
++
+
+
+@@ -827,6 +830,9 @@
+
+
++
++
+
+
+
+--- src/platform/visualc/config.h.orig Mon Aug 27 14:55:55 2018
src/platform/visualc/config.h Fri May 31 18:19:21 2019
+@@ -12,6 +12,9 @@
+ /* Define to 1 to enable internal modem support, requires SDL_net */
+ #define C_MODEM 1
+
++/* Define to 1 to enable NE2000 ethernet passthrough, requires libpcap */
++#define C_NE2000 1
++
+ /* Define to 1 to enable IPX networking support, requires SDL_net */
+ #define C_IPX 1
+
+
+--- src/hardware/ne2000.cpp.orig Fri May 31 18:19:21 2019
src/hardware/ne2000.cppFri May 31 18:28:13 2019
+@@ -0,0 +1,1660 @@
++#include "config.h"
++
++#ifdef C_NE2000
++
++
++#include "dosbox.h"
++#include
++#include
++#include "support.h"
++#include "inout.h"
++#include "setup.h"
++#include "callback.h"
++#include "timer.h"
++#include "pic.h"
++#include "cpu.h"
++
++/* Couldn't find a real spec for the NE2000 out there, hence this is adapted
heavily from Bochs */
++
++
++/
++// $Id: ne2k.cc,v 1.56.2.1 2004/02/02 22:37:22 cbothamy Exp $
++/
++//
++// Copyright (C) 2002 MandrakeSoft S.A.
++//
++//MandrakeSoft S.A.
++//43, rue d'Aboukir
++//75002 Paris - France
++//http://www.linux-mandrake.com/
++//http://www.mandrakesoft.com/
++//
++// This library is free software; you can redistribute it and/or
++// modify it under the terms of the GNU Lesser General Public
++// License as published by the Free Software Foundation; either
++// version 2 of the License, or (at your option) any later version.
++//
++// This library is distributed in the hope that it will be useful,
++// but WITHOUT ANY WARRANTY; without even the implied warranty of
++// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
++// Lesser General Public License for more details.
++//
++// You should have received a copy of the GNU Lesser General Public
++// License along with this library; if not, write to the Free Software
++// Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
++
++// Peter Grehan (gre...@iprg.nokia.com) coded all of this
++// NE2000/ether stuff.
++
++#include "ne2000.h"
++
++#define HAVE_REMOTE
++
++#include "pcap.h"
++// Handle to WinPCap device
++pcap_t *adhandle = 0;
++static void NE2000_TX_Event(Bitu val);
++
++#ifdef WIN32
++// DLL loading
++#define pcap_sendpacket(A,B,C)PacketSendPacket(A,B,C)
++#define pcap_close(A) PacketClose(A)
++#define pcap_freealldevs(A) PacketFreealldevs(A)
++#define pcap_open(A,B,C,D,E,F)PacketOpen(A,B,C,D,E,F)
++#define pcap_next_ex(A,B,C) PacketNextEx(A,B,C)
++#define pcap_findalldevs_ex(A,B,C,D) PacketFindALlDevsEx(A,B,C,D)
++
++int (*PacketSendPacket)(pcap_t *, const u_char *, int) = 0;
++void (*PacketClose)(pcap_t *) = 0;
++void (*PacketFreealldevs)(pcap_if_t *) = 0;
