Talk:DOSBox

Different versions for different consoles

Instead of removing platform-specific information (such as the GP2X paragraph removed on April 18), why not start a new section focusing on the differences between DOSBox versions on different platforms?

This article is pretty short anyway, some expansion won't hurt it... Esn (talk) 03:25, 1 May 2008 (UTC)

I guess we could do that. But the main contention I have is that nearly all of these ports are source forks managed by one or more third parties, and they are not official releases from the DOSBox team. Features and design considerations may overlap or contradict each other, so the article must remain clear on the point that these versions are not handled by the DOSBox team. If a particular fork is notable in and of itself, as the GP2X might be, consider creating its own article, such as DOSBox (GP2X). Ham Pastrami (talk) 10:08, 1 May 2008 (UTC)

Would there be any sense in creating a separate article when most of the information would be identical, though? Also, since this is an open-source project, why should it matter whether or not a port to another platform is "official"? I thought the whole point of "open-source" is that no particular person or group owns the code.

I'm not saying separation is absolutely necessary, but being open source means, well we've already seen from the article that a lot of forks exist, so inviting discussion about them here has a potential to snowball. I also do not want to see a situation where each field of the infobox has a dozen lines to account for all possible forks. The point of open source is... beyond the scope of this discussion, but in fact the code is owned by the authors and that is how they are able to enforce the license. Ham Pastrami (talk) 00:04, 2 May 2008 (UTC)

Anyway, quick question: which ports are "official"? Esn (talk) 22:58, 1 May 2008 (UTC)

The ones that are available from the official site.[1] Ham Pastrami (talk) 00:04, 2 May 2008 (UTC)

Well, it's obvious that I have no idea what I'm talking about... I'm still not even really sure what the difference is between "official" and "unofficial". I'd just like the article to include a bit of more info about the differences between different versions, that's all... Would it be allowed to link to the GP2X DOSBox article here, for example? Maybe use that as the "source" instead of (or in addition to) the link to GP2X.de, since it provides more information? Esn (talk) 08:19, 2 May 2008 (UTC)

It shouldn't replace the gp2x.de article because that article is being used as a reference, and wikis are not reliable references. But you are right that the wiki has a lot of content for the GP2X version, so I'm not opposed to adding your link as a standalone external link. In fact, that seems to be a pretty good solution for redirecting GP2X discussion. I'll make the edit now. Ham Pastrami (talk) 17:50, 2 May 2008 (UTC)

Um, this will sound rather impolite I suppose, but ya'll really had this nice little discussion about minor tweaks and nobody took the time to rmv that awful list format and try to make a proper article out of this? Ah well, I shouldn't complain, tis just the sort of thing I enjoy doing anyways. :) Still needs a better format though, with subsection headings and additional detail. Something with a flow, like 'intro, history, advanced features, availability & etc' might make good sections. I dunno, that is not the sort of thing I enjoy (at this moment, anyways). Hope someone else does. Eaglizard (talk) 09:38, 6 May 2008 (UTC)

Complaining about the emulator

This is not the place to express your dislike of the emulator, to complain about its interface, speed or any other part of it.

Please take any further comments, complaints and questions on these matters to the official forum: http://vogons.zetafleet.com/index.php?c=7

PS. I've left a note to the same extent as a commented-out block of text at the top of the article, so that any future "commenters" notice it first (and hopefully take their frustrations to the emulators' official forum instead). --The Fifth Horseman (talk) 19:46, 10 July 2008 (UTC)

And, just because I want to put a closure for a few common myths I've seen repeated over and over in here:

• DOSBox was written for single-core CPUs. There is no gain in performance if running it on multicore.
• Your graphics card does not really matter. It will run every jot the same on an 8-MB ATI Rage XL with no hardware acceleration capabilities or integrated graphics chip like those present in some motherboards as it will on a brand new GeForce 9800 or whatever is the newest, fastest card on the market at the time.
• 512 MB of RAM is more than sufficient to run DOSBox in Windows XP.
• DOSBox is not, and will never be as fast as VisualBoy Advance, ePsxe, ZSNES or any other of the dozens of emulators some people have compared against it as examples of "fast emulators" in the past. Whereas all of these emulate very simple machines, DOSBox is emulating an entire x86 PC running a DOS operating system - which was several times faster and more complex than GBA, PSX or SNES and as such requires accordingly greater processing power.
• Despite some newbies being convinced of the contrary, DOSBox can smoothly run resource-demanding games like Doom, Duke Nukem 3D or Quake on systems that are pretty low-end for modern standards. I've got a machine with an AMD Sempron 2500+ CPU clocked at 1,69 gHz running all three just fine after tweaking the config a little.

PS. Anyone who has questions about this emulator or requests for help with using it is welcome to read the information here. I'm a member of that forum, and will gladly answer any further questions you ask - as long as this keeps them off the Wikipedia's article and article talk pages. --The Fifth Horseman (talk) 19:46, 10 July 2008 (UTC)

First, I restored the formatting and section order of this talk page. Also, I removed the HTML comment from the article body, as on Wikipedia it is generally bad form for the first thing someone to see is a message dissuading them from editing the page, and telling them to go to another website. I appreciate your intent but that's just not how we do things here. Yes, the article has had some vandals in the past, but it is a minor nuisance and doesn't require a heavy-handed reaction like this -- every article on Wikipedia experiences its share of vandalism. The message will also do nothing to stop the vandal, as he is obviously quite determined to edit the page when he is possessed to do so. The solution here is the same as it is everywhere else on Wikipedia -- be vigilant in watching changes to the page, undo vandalism when you see it, and otherwise just relax. Ham Pastrami (talk) 23:04, 10 July 2008 (UTC)

Then dont make dosbox emulate verything ,ccan you explain to my why alot harder games have been emulated in other emulators smoothly then dosbox such as in playstation 1,some mame roms like area 51 and so on —Preceding unsigned comment added by 85.197.238.83 (talk) 22:41, 22 August 2008 (UTC)

Check: Talk:DOSBox/Archive_1#slow_program and Talk:DOSBox/Archive_1#Lexi.

* DOSBox does not emulate everything. It emulates what is neccesary to run the games and what is neccesary to achieve good compatibility with them. You can shut down some of the emulated sound devices, disable graphic scalers, force dynamic code recompilation and manually tweak the cycles value (which usually leads to better results than leaving it on autodetection) to improve overall performance. I've described the process in more detail here.

* A 486 PC the DOSBox emulates is a significantly more complex system than the original Playstation or the Area 51 arcade machine evere were. See Playstation#Technical_specifications.

* Smoothly emulating a 2D game (or a pseudo-3D game) from a purpose-built arcade machine or a gaming console (also a purpose-built system) is not comparable with smoothly emulating a PC computer with its graphic and sound hardware. But FYI: DOSBox can run Duke Nukem 3D - hell, even Quake- smoothly if you know how to do it.

Of course, in order for them to operate without slowdowns you need a comparably faster machine than for a PSX emulator.

And the moral of it all? If you don't know anything about things you're trying to compare... don't do it. --The Fifth Horseman (talk) 12:22, 27 August 2008 (UTC)

Resolved?

The article said the GPL issue was resolved. The source given was Slashdot, which isn't a reliable source. Slashdot sources a blog, which isn't one either.

There is a thread on the DOSBOX forums at http://vogons.zetafleet.com/viewtopic.php?t=16285 which points out that Valve "resolved" the issue by adding the text files and source, but the source was for an unmodified copy of DOSBOX and the version they used was modified. They never released modified source, so they're still violating the GPL.

I get the impression that the authors thought that this was close enough. But you can't resolve a GPL violation by having the authors say "it's still a violation, but close enough we don't care" unless all the authors agree, including everyone who contributed code to the project--not just the main authors. Ken Arromdee (talk) 20:00, 10 November 2008 (UTC)

The current version that is being distributed on steam is unmodified. —Preceding unsigned comment added by 82.74.95.41 (talk) 00:11, 13 November 2008 (UTC)

@Horseman

I'm trying to join the abandonia.com forums but get the message "Sorry, registration has been disabled by the administrator." Is this situation permanent? 2fort5r (talk) 11:27, 17 August 2009 (UTC)

Seems to be working now. On the other hand, the file server is broken for Christmas... --jpgordon^{::==( o )} 07:31, 28 December 2009 (UTC)

Still confusing

The main page of this article contains an illustration of DOSBox in action. If the picture is reliable, it indicates how DOSBox runs on a Windows platform, and opens up inside a screen-sized window of cyn-colored pixels, with a DOS prompt running down the left side of this window. The main part of this window is black. But there are still those light blue "cyn" colored pixels surrounding it.

Is there a version of DOSBox that takes over the entire screen? Some people (like me) find the cyn-colored pixels to be really annoying and distracting. I haven't got a copy of DOSBox yet, so I have no way of trying it out for myself. The main page of this article could be improved with a discussion of how screen colors can be handled, and whether the DOSBox window can be big enough to fill the entire screen. 216.99.198.146 (talk) 20:40, 21 July 2010 (UTC)

Press Atl+Enter and the window will be expanded to full screen. The only thing you will then see is the game/DosBOX screen, no borders or surrounding parts. Naki (talk) 12:32, 22 September 2010 (UTC)

Manually mounting drive letters versus traditional DOS

DOSBox is different to DOS in the way of drive letters.

In DOSBox, you type mount driveletter: path which mounts the directory as a drive letter.

In DOS, the drive letters are already available. DOSBox does not give your storage devices drive letters, only directories.

I definitely think this should be mentioned in the article. TurboForce (talk) 23:30, 14 December 2010 (UTC)

There are several misconceptions here. First of all, even real DOS does not give drive letters to a storage device (a physical drive unit). It gives letters to drive partitions, which is just another way of saying that it mounts a section of the drive to a designation such as C:. Pretty much all file systems do this in one way or another. Secondly, you can configure the drive mountings in DOSBox to be exactly the same as the way your physical drives are mapped, if for some strange reason you desire to do so. Other than that, the mount command in DOSBox is really just a convenience to let you dynamically change the emulator's configuration. You would normally add your mount commands to the .ini file so that they are set up when DOSBox initializes. Ham Pastrami (talk) 07:20, 15 December 2010 (UTC)

Yeah, I agree that even real DOS gives letters to drive partitions, but I've never known real DOS give letters to directories. The difference between running DOSBox compared to a virtual DOS session in Microsoft Windows (cmd.exe or command prompt) is that DOSBox gives you the Z:\ and will not allocate drive letters for other partitions or storage devices automatically. This is an important difference between DOSBox, real DOS and a "DOS Window" within Microsoft Windows.

I've 100% success with DOSBox running old games and software, which refuse to run in Windows. :) TurboForce (talk) 17:02, 15 December 2010 (UTC)

This still sounds more like user confusion than anything else. The DOS emulation that is running inside DOSBox does not differentiate between drives mounted as drives and folders mounted as drives. That is something only the emulator itself understands. So the DOS programs still see DOS drive letters and only DOS drive letters, and as far as they know, those letters represent whole partitions. It does not affect the DOS emulation in any way. Beyond that, the discussion seems to be about how to use DOSBox, which is user manual content and not encyclopedia content. Ham Pastrami (talk) 07:37, 16 December 2010 (UTC)

No, it's merely a difference between DOSBox and DOS, not "how to use DOSBox". It's a difference that's important enough to mention in the main page I think.

This is what I could add to the main page:

DOSBox is different from DOS; directories are manually mounted as drive letters using the syntax mount drive letter: path and drive letters other than Z:\ are not immediately available until mounted.

TurboForce (talk) 09:14, 16 December 2010 (UTC)

Of course DOSBox is different from DOS. DOSBox is an emulator, which is stated in the first sentence. That alone is the reason for the difference. The emulation of DOS performed by DOSBox is not different from DOS in this regard. That's where you seem to be confused, by blurring the emulator with the emulation. Mounting drives is merely a matter of learning to configure the emulator, and it does not produce a difference in the way DOS programs run (the emulation). You also don't seem to have considered that Windows is the only DOSBox host OS that uses drive letters. What do you expect to happen when there is no actual 'C' (or whatever) drive? Also please do not make changes to the article when the discussion is still ongoing. Ham Pastrami (talk) 01:22, 18 December 2010 (UTC)

I'm surprised my point is being missed. The difference between DOSBox and any DOS is that in DOS, the drive letters are already allocated to storage devices and partitions, typically A: and B: for floppy drives, C: for the hard drive and a drive letter for the CD ROM drive is usually D: (once the CD ROM drivers are loaded) and of course letters for drive partitions. In DOSBox, the storage devices don't have the drive letters automatically allocated. It's just a difference between DOSBox and real DOS, not a criticism. I went to a lot of trouble to edit the page with the information about mounting drive letters in DOSBox to show the difference between DOSBox and DOS.

Please add my edits, which I've copied and pasted below:

DOSBox is different from DOS in handling directories and drive letters. Directories (folders) are mounted as drive letters, using this syntax ("mount" is not case sensitive)

MOUNT [Drive-Letter] [Local-Directory]

Any drive letter can be used, except for Z (DOSBox always uses Z:\). The mounted directory and its contents can be accessed like a real storage device, similar to real DOS, with the syntax

[Drive-Letter]: and pressing Enter

(that is the allocated drive letter and colon). Games and programs in the mounted directory can now be run

TurboForce (talk) 11:42, 22 December 2010 (UTC)

I am sorry, but this is really tutorial content rather than something that needs to pointed out as an important difference between DOS and DOSBox. (And btw, DOSBox is obviously not different in handling directories.) I agree with Ham Pastrami's revert. Nageh (talk) 12:28, 22 December 2010 (UTC)

Looks like my efforts have gone to waste, unless the original DOS used a "mount" command? I don't think so, therefore we have an obvious difference between DOSBox and original DOS. It looks like tutorial content, however I went to a lot of trouble writing that to explain to readers how "mount" is different to DOS. All efforts are wasted, now it's been taken out of the article! Thanks for nothing!! TurboForce (talk) 15:52, 23 December 2010 (UTC)

Why do you take it so personal? Wikipedia is based on consensus, and people have pointed out that the mount command was merely a convenient way of configuring the emulator. FYI, DOSBox is different from DOS in lots of ways because it is not a full-featured DOS emulator but provides just sufficient functionality to support gaming! And BTW, yes, DOS had something like the DOSBox' mount command: it is named subst. Finally, don't whine about a few lost lines, I think other people have put in lots of more effort into Wikipedia articles. Heads up, though, and keep going! Cheers, Nageh (talk) 16:53, 23 December 2010 (UTC)

I don't see any consensiu here though, just two people arguing. Personally I think how an emulator handles storage (there are many ways ranging from "permanently map the host drives" to "work entirely with image files and don't allow file exchange with the host at all") is an important aspect of the emulation (at least as important as say the list of soundcards or videocards) and can be mentioned in a way that doesn't turn into a howto. 00:57, 3 January 2011 (UTC) —Preceding unsigned comment added by 80.0.68.41 (talk)

Your edit seems reasonable to me. But you and TurboForce are not claiming the same thing. You're saying that the emulator's choice of storage model can be important -- I won't disagree with that. But TurboForce was saying that the need to map storage is an important difference from DOS. That statement is not only misleading, it is also oblivious to the nature of emulation. Ham Pastrami (talk) 05:16, 3 January 2011 (UTC)

DOSBox in DOS

There is a bit in the article about running DOSBox in DOS mode which seems interesting. Unfortunately there is no further information on either how effective this is (would games executed in this manner run better than in Windows?) or on how to do so (such as a link to an article or forum thread or something). The only thing I could find on this with a Google search was a similarly brief mention on the HX page. Perhaps someone could add a bit of info for this option. — Preceding unsigned comment added by Synetech (talk • contribs) 08:30, 27 December 2010 (UTC)

DOSBox being integrated in the Wine compatibility layer.

As more information becomes available, I think the page should mention that DOSBox has been included with the Wine compatibility layer. It's still early days: DOSBox and Wine.

Hope this helps. TurboForce (talk) 13:44, 24 August 2011 (UTC)

Unofficial builds

[Copied from an old revision.] There are several unofficial DOSBox builds providing additional functionality compared to the official release:

• ykhwong's build (with the xBRZ scaler by Zenju): Glide, MT-32, Save/Load states, etc. This build updates not only with stable DOSBox releases, but with intermediate SVN builds too.
• gulikoza's build: Glide, etc.

References

Language

The side-bar for this page says that DosBox is programmed in c/c++, but after downloading the project I did not see any c-headers. If someone referring to a library attached to DosBox, does that even make sense to include as that would not constitute as the project in question. Just thought that I would check here before making any changes Thinkincode (talk) 12:06, 10 February 2013 (UTC)

Hello, ThinkinCode

I downloaded DOSBox's source code (dosbox-0.74.tar.gz) and see that it is a Visual C++ project. I see at least 36 header files. I am afraid there is no doubt that the article is correct.

Best regards,

Codename Lisa (talk) 19:51, 10 February 2013 (UTC)

Sorry, I wasn't being very clear. What I meant to say was that I failed to see any .c extensions, if the article says that the code is c/c++ it implies that the are at least some .c extensions. But if there are only .cpp extensions wouldn't that mean that it's programmed in c++?

Thinkincode (talk) 23:51, 11 February 2013 (UTC)

Hi. There are .h files written in C. In addition, SourceForge page list C as well as C++. So, I think this concludes the matter. Best regards, Codename Lisa (talk) 08:53, 12 February 2013 (UTC)

DOSBox is not bilingual. It is programmed in C++ and compiled with a C++ compiler. What you consider C code is actually the common subset between C and C++. It is technically correct to mark DOSBox as a C++ program. Ant 222 (talk) 23:34, 20 August 2022 (UTC)

More Commercial Use of DOSBox

It seems that Electronic Arts is also using DOSBox for its classic games. For example, I downloaded Wing Commander 3 during its appearance in one of EA's "On the House" free game promotions in Origin--I downloaded the game 7 Aug. 2014. A DOSBox window pops up when I run the game and it seems likely that some of the other EA/Origin classic games--such as the Ultima series--also uses DOSBox.

With the popularity of classic games doing well on things such as Nintendo's Virtual console, it looks like even more PC game developers are jumping on the classic game bandwagon. We may see more old games coming out using this useful tool.

I didn't feel that I could properly edit the entry and perhaps a little more research will turn up more examples that could be added to the main article.

96.25.66.96 (talk) 18:13, 8 August 2014 (UTC) The Smokin' Deist

Editing and TSR's

I downloaded DOSBox and ran a program I wrote some years ago. It ran very well on Win 7 and I'm very pleased. DOSBox help files seem to be written only from the perspective of helping game users. My program is not a game and uses a TSR which must be loaded before the program so that the program can find it and access the serial port. I'm pleased to say that TSR operation works fine, although I haven't connected anything to a USB port yet to check whether the hardware works. All I can report is that my program would have crashed if the TSR was not present, consequently TSR loading seems to be fine and there are no conflicts. This feature is not mentioned in the article, but may be helpful to those who wonder whether TSR operation is possible. Now a problem: I have trawled through the help files and the Readme and nowhere can I find the command that allows me to edit a file at the Z: or C: prompt. The DOS command "Edit" doesn't work. Advice please. Akld guy (talk) 21:01, 22 May 2016 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on DOSBox. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20141013114801/http://www.japheth.de/HX.html to http://www.japheth.de/HX.html

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 23:24, 20 July 2016 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on DOSBox. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20081211084510/http://www.surg3.com:80/dfl/news_detail.php?id=42 to http://www.surg3.com/dfl/news_detail.php?id=42

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 20:47, 4 December 2016 (UTC)

Further development in hibernation, or abandoned? Or final product achieved?

Since the last build arrived quite a few years have passed. So I'm wondering if development is in hibernation or if it has been abandoned or simply the final product achieved. Any info on that? --122.103.84.111 (talk) 05:32, 9 August 2017 (UTC)

After 8 years, a new version was actually released some days ago, looks like DOSBox hasn't said the last word yet... -Cardace (talk) 22:55, 1 September 2018 (UTC)

Removing the configuration section?

Is there anything of use that can really be salvaged from the configuration section, or should it just go altogether? Doesn't seem like something that belongs on Wikipedia to me --LichWizard talk 21:41, 13 January 2019 (UTC)

"History" and "Ports" sections are misleading

The history section mentions some forks, but this is both inaccurate and misleading. It's inaccurate because these forks are separate projects, and misleading because major forks like ECE or dosbox-staging are not mentioned while a patch implementing LFN is listed as a fork (when it's merely a patch - now merged with DOSBox-X). So it reads a bit like self-promotion written by fans/users of those particular projects.

Similar with "Ports" section - it lists some abandoned projects like jDosbox; also reads like self-promotion. Info about Wine integrating DOSBox is also outdated - that "integration" was finished several years ago (Wine simply calls dosbox to handle 16-bit binaries, that's all).

I suggest rewriting the "History" section to indicate, that development of DOSBox project stalled / project is no longer actively developed and create new section dedicated to listing active forks (ECE, DOSBox-X, dosbox-staging) and not active, but historically notable ones (e.g. DOSBox-Daum).

Disclaimer: I prefer not to do it myself, because of WP:COI - I am one of maintainers of dosbox-staging fork. I can help with identifying sources, pointing to facts, or answer technical questions about DOSBox or forks. Dreamer_ (talk) 16:39, 20 August 2020 (UTC)

ACM article

• Black, Michael David; Komala, Priyadarshini (March 2011). "A full system x86 simulator for teaching computer organization". SIGCSE. Association for Computing Machinery. doi:10.1145/1953163.1953272. Retrieved November 16, 2020.

I have looked into this ACM article for anything that may be relevant to this article. As it turns out, there disappointingly was not much to say about DOSBox, other than that according to page 365, it is a full-system emulator and according to page 366, it is "hardwired for DOS" such that for example, it does not use a BIOS ROM image, but rather imitates frequent BIOS calls. I am not sure what to think of the said information, or whether any of it is even relevant. I mean, what does it mean by "full-system"? That the emulator lacks a BIOS ROM image may be useful, but the calls are already discussed in the article, albeit still unsourced. Bruce1ee, what is your judgement on the source's contents about DOSBox? I mean, you were the one who helped give me access to the source, and I am one who is tempted to not make the access request at WP:RX pointless. FreeMediaKid! 00:39, 17 November 2020 (UTC)

@FreeMediaKid!: You're asking the wrong person. I sent you the article only because I have access to ACM publications – I know nothing about DOSBox or DOS emulators in general. I'm sorry, I can't help you. —Bruce1ee^talk 06:52, 17 November 2020 (UTC)

I should be the one apologizing, as I had assumed that you might offer a basic, not necessarily specialized opinion on what to make of my findings. My bad on my part of not verifying that you would be able to answer. FreeMediaKid! 11:33, 17 November 2020 (UTC)

No problem – glad I could at least get the article for you. —Bruce1ee^talk 12:41, 17 November 2020 (UTC)

I have boldly gone ahead and added the information. If anyone else wants to discuss the change, you are welcome to do so. It does not look as if it will happen soon, though, as I seem to be the only prominent editor as of this post. FreeMediaKid! 23:47, 23 December 2020 (UTC)

GA Review

This review is transcluded from Talk:DOSBox/GA1. The edit link for this section can be used to add comments to the review.

Reviewer: Whiteguru (talk · contribs) 05:54, 10 January 2021 (UTC)

Starts GA Review; the review will follow the same sections of the Article. --Whiteguru (talk) 05:54, 10 January 2021 (UTC)

 

---

Lead

1. Is it reasonably well written?

• Short and snappy. Has all the details

Development

1. Is it reasonably well written?

• Gives a concise narrative of the history of DOS and how Windows 3.0 ran on top of this. The evolution to Windows 95 and thereafter to Windows XP - which would not run DOS applications is given. The end of support for DOS by MS is given, along with the development of DOSBox, leading to a beta test release on Sourceforge. Concise, to the point.

Features

1. Is it reasonably well written?

• This contains necessary infomation to understand the operation of DOSBox on new machines with different filesystems. A graphical front end is noted, along with the long-forgotten 8.3 file naming system. The note about DOS Malware is cautionary. Facilities such as screenshots, audio codecs and mapping a game controller are mentioned.

OS Emulation

1. Is it reasonably well written?

• This refers to the capacity of DOSBox to run operating systems (Windows 3.1) and access commands used at the Dos prompt. Mounting itself to a virtual drive is an important note - particularly with regard to host box system security; configurability options are given.

Hardware Emulation

1. Is it reasonably well written?

• Hardware emulation is explained - real mode and protected mode as required by DOS programs. Other options are provided by dynamic instruction translation. The ability to use the DirectDraw or OpenGL APIs is a vital element for DOS gaming. Emulation of 3dfx Voodoo Graphics sound cards and Direct3D citations appear to need updating. Access to modems using TCP/IP protocol and IPX network tunneling is noted along with ports for joysticks and flightsticks for gaming / multiplayer gaming.

Reception

1. Is it reasonably well written?

• It would seem this section needs updating. July 2008 and October 2015 are statistically distant!

Usage

1. Is it reasonably well written?

• It is good to see the development of the Wine compatibility layer. It is also appropriate to note the Internet Archive's repository of DOS games to its software library and other options - playing in a web browser - that are available to the teeny boppers of today that never had to enter a command on a black screen to start a program. Sheesh.

Commercial

1. Is it reasonably well written?

• The viability and utility of DOSBox is illustrated by its inclusion in commercial releases of DOS games; Valve's Steam, LucasArts, Sierra Entertainment, and so forth. It is interesting to see EA Games use this also. Wolfenstein 3D? My, my.

 

---

This review is incomplete; following sections to come. --Whiteguru (talk) 02:08, 13 January 2021 (UTC)

Notes

1. Is it reasonably well written?

• Interesting to see the SVN Changelog is upto 2021-01-12 18:52 - that is, today.
• Notes are all relevant to the article and contain accessdates; linked to archived dates where needful.
• Note 58 (German) is a dead link.

 

---

GA Review completed upto the end of NOTES. More to come. --Whiteguru (talk) 02:30, 13 January 2021 (UTC)

End Matter

References

• References are appropriate.

External Links

• Goes to DOSBox website; appropriate.

Is it is Broad in its coverage?

1. Is it reasonably well written?

• A broad coverage that any user of MS-DOS could comprehend - along with any DOS gamer who booted a machine directly into their games bypassing Windows 3.x
• The sections on OS Emulation and Hardware Emulation are needful inclusions with developments and the present capacity of DOSBox and gaming functionality.
• A broad coverage, not overweening in any manner. Well scribed which leads to the following:

More End Matter Stuff:

• Does it follow the neutral point of view policy?
• Mais oui; Yes.

1. Is it stable?

• This page was first created on 31 August 2004 and has had 974 editors since.
• Lot of IP addresses have done editing (152.132.8.71) along with bots doing cleanup.
• Stable page with a long history due unfolding developments and the long life of Windows XP and its protected mode preventing access to the system hardware.

1. Top editors are

• FreeMediaKid
• Hampastrami
• GuyMacon
• Monkbot

• It is illustrated by images ?
• Images are appropriate.

Overall

A well scribed article with NPOV and excellent notes. A great history of computing and gaming included in the narrative of DOSBox.

Conclusion

• Lets sort the matters raised above.

--Whiteguru (talk) 03:00, 13 January 2021 (UTC)

Whiteguru, I looked at the three issues that needed some fixing. I repaired one link that you reported was broken, and I decided to delete the mention of the 3dfx Voodoo graphics card, due to the lack of news since the 2010 announcement. The last issue, about expanding the Reception section, unfortunately seems impossible or at least extremely difficult to get over, for before and since this review I have searched a great deal of the Internet and Internet Archive, using important keywords and even broadening my searches by limiting the keywords in hopes of finding another DOSBox review. If grinding the Internet seemed boring, it did not help that I was not able to find anything useful, but at least I can lay the issue of missing content to rest. I hope this article can now pass the GA test. FreeMediaKid! 00:26, 17 January 2021 (UTC)

@FreeMediaKid!: OK, thanks for taking those steps and resolving the issues. I will resolve the GA Review now. --Whiteguru (talk) 05:52, 17 January 2021 (UTC)

 Resolved

Preview release / SVN revision is misleading

Infobox contains this information: "Preview release SVN r4336 (April 12, 2020; 9 months ago[2][3][4])", which is very misleading - the link refers to SVN r4336, which is Apache Subversion revision. SVN revisions, or CVS revisions, or Git commits are not "releases" and it's confusing to conflate the two. Aside of that, the first source link is broken, the second does not support the "preview release" claim, the third one is a link to 3rd party website that publishes auto-generated articles based on new commits landing in source code repositories.

Also, the information cannot be automatically updated (Vanilla DOSBox is currently at SVN r4416). The real last stable release is 0.74-3 - that's the one listed in WikiData (https://www.wikidata.org/wiki/Q479783) - and this should be listed as the released version.

Also, the date for initial release is incorrect (see WikiData for date of 0.1 release).

I suggest removing "Preview release" line from the infobox and update the initial release date to reflect factual information. Dreamer_ (talk) 01:56, 19 January 2021 (UTC)

LFN

FTA: ‘because DOS does not support them’

DOS does support LFN though.

— Preceding unsigned comment added by 77.61.180.106 (talk • contribs) 01:18, 31 July 2021 (UTC)

Some versions of DOS support it. 184.146.9.16 (talk) 00:50, 22 September 2022 (UTC)

Discontinued

No new version in 2.5 years. Please stop removing this. There obviously can't be sources for what isn't there (i.e. a new version). -Cardace (talk) 16:39, 14 January 2022 (UTC)

Please stop adding it. Sigh. No updates doesn't mean discontinued. The site is 100% live and still functional. Unless they declare the project is ended, you cannot WP:OR that no updates means it's 100% discontinued and done. The downloads are still available, it still works. Products are not automatically discontinued after some arbitrary period of inactivity on new versions. A patch was released just a year ago. -- ferret (talk) 16:46, 14 January 2022 (UTC)

Yes, this. Like all content additions, if you want to add discontinued, provide a source that verifies it. Sergecross73 msg me 14:25, 15 January 2022 (UTC)

The main filesystem ‘vulnerability’ is still there

Whoever added this to the article ...:

Because DOSBox accesses the host computer's file system, there thus is a risk of DOS malware exploiting the emulator's security vulnerabilities and causing damage to the host machine, although these vulnerabilities continue to be patched with new DOSBox updates.

... didn't read the cited source. At best it could be seen as based on a misunderstood reading of the summary.

Because DOSBox accesses the host computer's file system

That isn't the problem here. Almost every piece of software does that. Even if some utility itself only needs RAM, Windows of course loads the .exe, registry access could make it load or update the hive, and so on, so it's indirectly still using the filesystem. A console emulator needs to load ROM files, it will certainly access the host computer's filesystem, but it isn't a problem, because the software in the ROM has no access to the host filesystem. It is precisely this that DOSBox does allow; by default all software in DOSBox runs with the same permissions as the DOSBox process. It isn't a security vulnerability per se, because as far as I know DOSBox doesn't claim to protect you from the software it runs. The MOUNT command is there principally for convenience, because DOS programs don't always play well with paths that e.g. contain spaces, long folder names or multiple levels of nesting. The developers consider CVE-2007-6328 invalid, no doubt because -securemode does lock the doors (permanently: after activating this mode you cannot use MOUNT ever again).

On the other hand I think the lack of information on the topic is hugely irresponsible. If you look at the information page this is the full text shown there:

DOSBox is a DOS-emulator that uses the SDL-library which makes DOSBox very easy to port to different platforms. DOSBox has already been ported to many different platforms, such as Windows, BeOS, Linux, MacOS X...

DOSBox also emulates CPU:286/386 realmode/protected mode, Directory FileSystem/XMS/EMS, Tandy/Hercules/CGA/EGA/VGA/VESA graphics, a SoundBlaster/Gravis Ultra Sound card for excellent sound compatibility with older games...

You can "re-live" the good old days with the help of DOSBox, it can run plenty of the old classics that don't run on your new computer!

DOSBox is totally free of charge and Open Source.

When a user who has experience running emulators and with the way they usually work reads this, I think the expectation is that the user will think DOSBox is like those other emulators in this regard. Also, none of the CVE numbers here is even mentioned on their site, only CVE-2019-7165. I think that's very childish and defensive.

The closest DOSBox comes to properly informing its users is in the manual, in the description of the -securemode parameter:

... (which in turn disables any changes to how the drives are mounted inside DOSBox).

Reading between the lines, they're saying that unless you use this command, the host filesystem isn't secure from the emulated software. I wonder how many people read the full manual? I would have much preferred a solution that's secure by default; this is unsecure unless you've thoroughly trawled through the manual.

risk of DOS malware exploiting the emulator's security vulnerabilities

There is, in principle, always a risk that a malware author might try to exploit a security vulnerability in an emulator. In practice, this may be rather hard, impossible even, and in any case the linked reference doesn't describe any sort of attempt to exploit a bug in the emulator for example.

these vulnerabilities continue to be patched

According to the cited source the DOSBox programmers only promised to fix CVE-2019-12594. I've had to work with programmers a lot during my professional life and a promise by a programmer is worth about as much as a promise by Boris Johnson. The vulnerabilities mentioned in the source are CVE-2007-6328, the fact that emulated software has access to the host filesystem, CVE-2018-20343, a 25-year old arbitrary code execution vulnerability in the Build engine, and CVE-2019-12594, a vulnerability that doesn't affect most users because it was only present in the Linux version, which allowed emulated software to immediately execute native code. (If you accept that CVE-2007-6328 is invalid this isn't even an emulator bug; it's just a logical consequence of software being trusted with access to the filesystem and the filesystem exposing the process's address space in /proc/ that the software can execute native code. If you don't trust it with that kind of access, why would you still trust it with full filesystem access?) Of these, only the last one was fixed, and that one didn't affect most users because most of them run Windows. You can check here yourself that the developers didn't attempt to e.g. hot-patch the Build bug or rework the MOUNT infrastructure. The following QBasic code by default still works on the latest version of DOSBox:

DIM Temp AS STRING
Temp = ENVIRON$("TEMP") + "\UserList.txt"
SHELL "MOUNT -U V"
SHELL "MOUNT V C:\Users"
SHELL "DIR/B/AD V:\>" + Temp
OPEN Temp FOR INPUT AS #1
WHILE NOT EOF(1)
    LINE INPUT #1, Temp: PRINT Temp; ": ";
    ON ERROR GOTO nope
    OPEN "V:\" + Temp + "\AppData\Roaming\Micros~1\Windows\StartM~1\Programs\StartUp\p0wned.bat" FOR OUTPUT AS #2
    ON ERROR GOTO 0
    PRINT #2, "@echo This could have been a lot worse."
    PRINT #2, "@pause"
    CLOSE #2
    COLOR 12: PRINT ".bat file dropped.": COLOR 7
nxt:
WEND
CLOSE #1
END

nope: COLOR 2: PRINT "drop failed.": COLOR 7: RESUME nxt

'By the way, this shouldn't work:
'OPEN Temp FOR OUTPUT AS #1
'PRINT #1, "MOUNT -U V"
'PRINT #1, "MOUNT V "; CHR$(34); "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp"
'CLOSE #1
'SHELL Temp
'The mount will succeed, but unless you ran DOSBox elevated,
'the folder will be read-only.

Sooner or later the user will reboot. A malicious program could also still delete or encrypt all your documents, insert macros in your documents, change your .ini and .rc files or do any number of other nasty things. DOSBox wasn't meant to protect you from malicious software and as such I wonder what the point of fixing CVE-2019-12594 ultimately was. The devs fixed CVE-2019-12594, and Boris got Brexit done.

And that part of the article snippet is wrong in another way as well: it conjures up an image of a stream, or at least a trickle, of security vulnerabilities discovered and patched, the mighty developers protecting us from slimy programs that want to escape their box, whereas the actual situation is that I only know of two related bugfixes, maybe there could be one or two I've missed, but not a stream by a far stretch and we're on the other side of the airtight hatchway regardless.

So, as you can see, the fragment I quoted from the article doesn't do the actual situation justice at all. — Preceding unsigned comment added by 77.61.180.106 (talk) 23:41, 9 May 2022 (UTC)

Differentiation from FreeDOS

A small section which compares and contrast DOSBox to FreeDOS is welcome. These projects each have different main use cases, but have a lot of overlap (especially when it comes to emulating non-game applications). Because DOSBox provides an emulation runtime, some users install FreeDOS into DOSBox.

I understand basic differences, but I am not a user enough of both to make such a comparison. Scootz555 (talk) 17:18, 3 January 2023 (UTC)