TrueCraft VS MS-DOS

There was TrueCraft that attempts to reimplement Beta 1.7.3 but it has been abandoned for a few years now.

You might find this project interesting: TrueCraft (The physics are really janky in my experience unfortunately.)

Calling the ability of third party launchers to launch Minecraft a feature of Minecraft seems odd. I imagine you could make a launcher for pretty much any game for Windows (or many Linux-based operating systems)). I don't think that makes game launchers illegal in general though, but it does mean that launchers are not necessarily legal in all cases (i.e. if the launcher does something illegal, like circumvent DRM). I don't know how to tell if a launcher is circumventing DRM by for example lying to the Minecraft client to trick it into allowing play, other than by examining the source code of the launcher and/or Minecraft and I don't have time to do that (plus I'd like to be able to freely contribute to projects like TrueCraft).

You might be interested in TrueCraft, or other third-party clients/servers, or perhaps MineClone (not a re-implementation, but just a similar game). All of these are incomplete I think, for now.

That said, if you want to go back to when Minecraft was simple, you might be interested in TrueCraft (It's not very playable IMO, but it is interesting.).

Well, I guess I am sort of repeating things I don't fully understand. I've never actually read the source code of Minecraft, because I want to be allowed to contribute to re-implementations like TrueCraft, for example (even though currently, I don't really have the skills to do that).

There was TrueCraft which was a clean room implement of Minecraft beta 1.7.3 in C#.

Your comment intrigued me so I did a little bit of digging.

> I remember Drew DeVault (sircmpwn) used to have a big scary warning saying if I have looked at the official minecraft code, I should not contribute to truecraft (now archived I believe).

The repository is indeed archived, but is still available on GitHub. It was changed in 2015 [0]. The older notice is as you recall:

> Pull requests will be rejected from authors who have read any decompiled official Minecraft code.

The current notice [1] adds some other ways the formerly rejected developers could get involved:

> If you are a developer, you have two paths. If you have not read the Minecraft source code, you are what we call a "clean dev", and you should stay that way. If you have read the source code, you are what we call a "dirty dev", and the way you can contribute is different. If you are a clean dev, you're welcome to contribute to this repository by adding features and functionality from Minecraft Beta 1.7.3, fixing bugs, refactoring, etc - the usual. Send pull requests with your work.

> If you are a dirty dev, you are more limited in how you can help. You can work on projects that are related to TrueCraft, but not on TrueCraft itself. Direct contributions that you can participate in includes the website and the artwork. You can also work on things like helping to build a community by spreading the word, participating in IRC or the subreddit, etc. You may also work on reverse engineering Minecraft to provide documentation for clean devs to use - see reverse engineering guidelines on the wiki for details on how you can do this. Under no circumstances may you ever share any code with a clean dev, decompiled or otherwise.

[0] https://github.com/ddevault/TrueCraft#get-involved

[1] https://github.com/ddevault/TrueCraft/commit/fcfd3886746fd1f...

This 4.0 code contains references to 4.00, though: https://github.com/microsoft/MS-DOS/blob/main/v4.0/src/BOOT/...

I recently stumbled across the MS-DOS 1.25 and 2.0 source code [1].

[1] https://github.com/microsoft/MS-DOS

“Despite this reduction in scope for MS-DOS 2.0, it did carry many bits of XENIX. The system adopted I/O redirection via less-than and greater-than symbols, piping, a hierarchical directory tree, file handles […]”

The source code for MSDOS 2 is available and the file descriptor stuff appears to be in https://github.com/microsoft/MS-DOS/blob/master/v2.0/source/... and XENIX2.ASM. It stands in contrast to the File Control Block API which MSDOS 1 (née 86-DOS) modeled after CP/M’s API.

Asynchronous I/O figures in prominently in Windows NT. I was really surprised to see[0]:

Each driver in the chain defines two entry points; the strategy routine and the interrupt routine. The 2.0 DOS does not really make use of two entry points (it simply calls strategy, then immediately calls interrupt). This dual entry point scheme is designed to facilitate future multi-tasking versions of MS-DOS. In multi-tasking environments I/O must be asynchronous, to accomplish this the strategy routine will be called to queue (internally) a request and return quickly. It is then the responsibility of the interrupt routine to perform the actual I/O at interrupt time by picking requests off the internal queue (set up by the strategy routine), and process them. When a request is complete, it is flagged as "done" by the interrupt routine. The DOS periodically scans the list of requests looking for ones flagged as done, and "wakes up" the process waiting for the completion of the request.

I didn't realize that kind of forwarding-looking perspective was going into the design of MS-DOS.

[0] https://github.com/microsoft/MS-DOS/blob/master/v2.0/source/...

>Any others I'm missing?

I would suggest MS-DOS: https://github.com/microsoft/MS-DOS