NY00123

Might this depend on the version of Ubuntu? With 20.04.6 LTS, I could right-click on the ISO and use the GNOME Disk Image Mounter. Alternatively, using the command "mount" with the switches "-o loop" also did the job, obviously with certain differences in behaviors (access permissions probably being the most obvious). It's not impossible an additional package or more had to be installed for support of the filesystem, but I don't know the answer for this right now. It still didn't seem to take care of file names using characters outside of ASCII. There are files using character 0xAA, and they couldn't be copied out of the mounted ISO in the usual manner. My guess being that the encoding in use was Mac OS Roman. But at least for the DOS sources I built exes from, this wasn't a problem for me. btw, you can give unar (not unrar) a try in order to extract StuffIt (.sit) archives.

I can mention now that I tried building the exes on my own. Instead of appending the matching dos4gw code, I rather compared to the original executables after stripping dos4gw. But otherwise, as in Nuke.YKT's case, the newly built exes were matching byte-by-byte, including also paddings between string literals. The latter surprised me a bit as I mentioned earlier. I recall how even just the definition of one more environment variable could - albeit rarely - lead to Watcom C generating a function a bit differently, which was still enough in order to make it not match another exe. Regarding differences in string paddings, I suspect that it has more to do with the textual contents of the source code / compilation units, and not necessarily the comments. To further add to what was explained by Nuke.YKT earlier: - Watcom doesn't seem to accept sources using CR-formatted new lines. So, I converted these to LF. - You might have to copy missing ASM files from a different directory that has them. - For the 1.9 series, the DMX version is dmx37; Basically an older DMX version with the files from dmx37lib used with a higher priority IIRC. 1.7 and 1.7a use a modification of dmx34a. - I actually didn't have to modify gamesrc-ver-recreation/doom/makefile or newdoom.lnk as currently present. I just had to create a directory matching the desired version (per the list in gamesrc-ver-recreation) and call wmake with appver_exedef being appropriately set, e.g., "wmake appver_exedef=DM19". - I didn't even bother to rename the directories with the sources; They were simply present without a-prior renaming under (emulated) D: drives, while Watcom C 9.5b was at (emulated) location C:\CPP_95B in my case. - For Doom 1.9 (not The Ultimate Doom tree which already covered these), the macro FRENCH had to be undefined in DOOMDEF.H, and a typo in HU_STUFF.C had to be fixed (comercial -> commercial). - Two archives seem to match 1.7 (not 1.7a), even if the sole real difference is of one space character in R_DRAW.C. As mentioned by Nuke.YKT, changing 1.7 into 1.7a should be trivial.

This archive is indeed far from the usual find for the average day; And, at least when it comes to DOS sources, it's great to see from Nuke.YKT that the files match the originals; A bit surprised to see that gaps between C string literals weren't the cause of differences in the output EXEs, but this might simply be a matter of luck (even with unmodified original sources that lack, e.g., changes to source comments or exact line numbers). On the other hand, I won't speak for Nuke.YKT or others, but I'll probably still be quite careful with the contents; So far, my preference has been to refrain from directly having leaked sources within gamesrc-ver-recreation. The closest that I got to for Doom Engine games was making use of DMX; Even then, the DMX files are not in the public gamesrc-ver-recreation Bitbucket team page as of today.

All right, thanks for going through the data on the hdd. What this does mean again, is that the (currently still private) git repositories for duke3d_w32 and xDuke cover what's knowingly out there at the moment.

Didn't even realize that up to a difference of a day or two, it had been exactly a year since I originally created the threads here and on Duke4.net. Unrelated to the above, I wanted to respond on the following post: If you don't mind, do you think there's still a chance you might have them? If not, then I'll maybe get a repository or two up. I know that in case a new source tarball is discovered after publishing a git repository, I can change it by making a forced git push; I guess that I preferred to not do it, at least back then. This might be less important for repositories used as public archives.

Bio Menace (which celebrated its 30th anniversary last week, btw) and Dangerous Dave are two examples coming to mind. TED5.EXE is all you need for editing levels and tile properties with BM, provided all files expected by TED are present; And in the case of Dangerous Dave in the Deserted Pirate's Hideout (DOS version), Camoto Studio was used on a few occasions. And yet, so far, I'm aware of the existence of these: - For Bio Menace: One complete level pack, a single level demo of a mod that was eventually not continued and a patched version of the 1st episode with two more levels. - For Dangerous Dave in the Deserted Pirate's Hideout (DOS): One single level, one level set and one mod. I don't have an answer for the following games in the series. Of course, on top of other games previously listed (like Catacomb 3-D), you can mention many other games from Apogee/id/Softdisk or related companies which didn't get their own modding communities (especially in cases there haven't been tools making this feasible).

I was surprised to hear that Doom95 was built with Watcom back when you initially told me about these efforts. It's impressive that you managed to get it to the current state as of Doom's birthday.

Version 0.40.1 has been released. This update mostly consists of usability improvements. Also, for people less familiar with ReflectionHLE, a web page is now up: https://reflectionhle.com/ This release will hopefully resolve usability problems with keyboard overrides, and possibly also with other input devices. But there are great chances that there's a new bug not found by me, so bug reports will be welcome. You can use the GitHub repository's issue tracker, or report in the forums if you prefer so; Albeit I might not necessarily check all forums in which I posted about ReflectionHLE. If you are upgrading from a version preceding 0.40.0, please check migration notes for v0.40.0. The project was renamed to "ReflectionHLE" at the time, and as a side-effect, older settings and saved games have to be manually migrated. Oct 14, 2022 (v0.40.1): * Add a toggle for showing/hiding the ENDOOM screen on exit, currently identified in the launcher as "Wait for input on exit". Regardless of the toggle, it'll still appear in case of a nonzero exit code. Other screens specific to shareware versions of certain games might further keep appearing, or introduce their own delays. * Updated search paths for Wolfenstein 3D and Spear of Destiny game data. * Keyboard overrides don't fully replace the original uses of the keys as of this version. For instance, if the launcher is used to select the key W for moving forward in Catacomb 3-D, it can still be used as a part of debug keys for warping to another level. On the other hand, the familiar functionality of the key otherwise used for the same in-game action will be disabled. To clarify for the example of moving forward, the key generally used for this purpose from Catacomb 3-D's own control panel (the Up arrow by default) will not actually be used for moving forward. Note that mouse button overrides are still full overrides and there's no change in behaviors as describe above. * Miscellaneous internal changes related to user input, related in part to keyboard overrides. One example is a bug fix, where pressing on a key moving Keen left, followed by another key moving Keen right, and then releasing one of the keys, would make Keen stop moving altogether. Also, as of this version, the analog motion is explicitly reserved for analog controller axes; novert impacts these, as well as ordinary mouse movement. * Use more locks for the audio mixer. This particularly helped resolving unexpected slowdowns in Android builds with BE_ST_MANAGE_INT_CALLS_SEPARATELY_FROM_AUDIO=1, during playback of digitized sounds in Wolf3D. * BE_ST_MANAGE_INT_CALLS_SEPARATELY_FROM_AUDIO=1 is used for Android again. * Other updates related to Android builds. * Made a few changes removing dependencies on libgcc and C++ libraries as long as we don't actually need any of them. * Other miscellaneous edits.

Thanks for informing me that you might have a look. Regarding JonoF's ports, I believe that older versions (from 2005 and earlier) are generally available from here: https://dukeworld.com/2001-current/source/jonof/ Despite this, maybe there's still a missing archive which isn't there. I also want to correct myself about Rancidmeat Reloaded, even if I don't provide any new archive. According to an old copy of the page in the internet archive, version 19.3 was released, at least in binary-only form dating back to 20 Nov 2005. The website said this: It also mentioned this, presumably before eventually identifying the following release as v19.5 instead of 19.4: I couldn't find a separate archived page listing v19.5 as released, but v19.6 became available in January or February of 2006. If January, then the binaries were re-packaged, probably to include an additional file named "null.txt" for Dukester X (1.5 series). The source code was packaged in January 2006, according to the timestamps I have here.

This is actually a good example not far in idea from the topic of this thread. I probably got the sources based on a link in the ZDoom Wiki page for ZDuke, obviously based on the re-upload which you referred to. The binary was either from there, or a direct download from the original forum post.

Thanks for mentioning it. I was aware of ZDuke, and I have archived sources and executable from 2003. It's still good that you brought ZDuke up in this thread.

Going to bring up Duke3dw and SWP as well now. I should had mentioned these earlier. While covering just a binary, Forge post about Duke3dw_v 4026.zip (old version of Duke3dw) in the aforementioned Duke4.net thread. In case I won't hear about something new in the following month, I'll allow myself to create at least one public git repository; Not necessarily exactly after a month from now, so this might come later.

Note: I'm quoting the post I originally made here: https://forums.duke4.net/topic/12116-looking-for-old-archived-versions-of-programs-duke3d-source-ports/ Hi all, I want to see if anybody might have at least one early source port version as described here. Archives of these can assist with creating historical git repositories, but even without git, having such archives can still be worthy, say for research. I don't actually expect to see anyone coming up with an archived copy, but I'm still trying. I do want to comply with the GPL for Duke3D, so I ask either for source or source+binary pairs, but not just for a binary-only archive (of a given version of a source port). I also prefer having original timestamps from the era for the archive (e.g., a zip file) and its contents, if present. Here's the list in question: * Versions of duke3d_w32 (Rancidmeat) preceding 19.1. * In theory, versions 19.3 and 19.5 of Rancidmeat Reloaded (xDuke); In practice, probably never released, with version 19.6 being referred to as the first public release in the xDuke webpage. * An early port (probably an initial cDuke3D release not yet titled cDuke3D) mentioned in a removed Shacknews page, with the page itself being linked from here (see the very first news posts): https://web.archive.org/web/20071109063330/https://www.rancidmeat.com/projects/duke3d_w32/html/oldnews.html

Yes, this is indeed the clause that makes the original 4-clause BSD license incompatible with the GNU GPL. A big question is which combinations are still allowed by the GPL, if any. For example, there are instances in which a GPLed program is allowed to be linked with a proprietary system library. For more details, the contents of the relevant GPL document should be inspected. https://www.gnu.org/licenses/gpl-faq.en.html#SystemLibraryException This clearly sounds like a useful approach for the user. Once the relevant parser from another source port is added, some amount of work might be required for replacing hardcoded contents like strings. Hopefully, there won't be as much work for the arrays defined in INFO.C, because there aren't that many of them. Maybe function pointers will need more work for going through them.

Hmm, is it possible that I should maybe clarify what I wrote earlier? Basically, I was wondering if you could build DeHacked from unmodified sources, and then use it with any of the original Doom exes from the 90s (rather than gamesrc-ver-recreation or any other exe). This way, if there's still a problem (say in the UI), then it's probably in the compilation process; Unless there's an actual problem with the original DeHacked sources that I'm not aware of, but after many years, I'm currently having doubts.